3.4.99 > 3.4.100
cgroup: Take css_set_lock from cgroup_css_sets_empty()

As indicated in the comment above cgroup_css_sets_empty it needs the
css_set_lock. But neither of the 2 call points have it, so rather then
fixing
the callers just take the lock inside cgroup_css_sets_empty().

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Change-Id: If7aea71824f6d0e3f2cc6c1ce236c3ae6be2037b
cgroup: Fix use after free of cgrp (cgrp->css_sets)

Running a 3.4 kernel + Fedora-18 (systemd) userland on my Allwinner A10
(arm cortex a8), I'm seeing repeated, reproducable list_del list
corruption
errors when build with CONFIG_DEBUG_LIST, and the backtrace always shows
free_css_set_work as the function making the problematic list_del call.

I've tracked this doen to a use after free of the cgrp struct,
specifically
of the cgrp->css_sets list_head, which gets cleared by
free_css_set_work.

Since free_css_set_work runs form a workqueue, it is possible for it to
not be
done with clearing the list when the cgrp gets free-ed. To avoid this
the code
adding the links increases cgrp->count, and the freeing code running
from the
workqueue decreases cgrp->count *after* doing list_del, and then if the
count
goes to 0 calls cgroup_wakeup_rmdir_waiter().

However cgroup_rmdir() is missing a check for cgrp->count != 0, causing
it
to still continue with the rmdir (which leads to the free-ing of the
cgrp),
before free_css_set_work is done. Sometimes the free-ed memory is re-
used
before free_css_set_work gets around to unlinking link->cgrp_link_list,
triggering the list_del list corruption messages.

This patch fixes this by properly checking for cgrp->count != 0 and
waiting
for the cgroup_rmdir_waitq in that case.

Change-Id: I9dbc02a0a75d5dffa1b65d67456e00139dea57c3
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Revert "s3c2410_wdt: Add locking to cpu frequency transition notifier"

This reverts commit 307dbd1c679d3e9c73f73d921c007b03e44daf0f
usb: gadget: f_audio_source: Fixed USB Audio Class Interface Descriptor

Fixed Android Issue #56549.

When both Vendor Class and Audio Class are activated for AOA 2.0,
the baInterfaceNr of the AudioControl Interface Descriptor points
to wrong interface numbers. They should be pointing to
Audio Control Device and Audio Streaming interfaces.

Replaced baInterfaceNr with the correct value.

Change-Id: Ib20f20c1d65887bac051b7ff9453dc53fc23a8d0
Signed-off-by: Anson Jacob <ansonkuzhumbil@gmail.com>
net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()

memset() the structure ethtool_wolinfo that has padded bytes
but the padded bytes have not been zeroed out.

Change-Id: If3fd2d872a1b1ab9521d937b86a29fc468a8bbfe
Signed-off-by: Avijit Kanti Das <avijitnsec@codeaurora.org>
msm: kgsl: fix a race condition when calling kref_put

Fix a race condition which can occur if a thread tries to acquire
a reference to a mem_entry or context while another thread has
already decremented the refcount to 0 and is in the process of
destroying said mem_entry or context.

CRs-Fixed: 635747
Change-Id: I6be64ca75f9cb12b03e870b9ca83588197c64e5e
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
Staging: android: binder: More offset validation.

Make sure offsets don't point to overlapping flat_binder_object
structs.

Conflicts:
	drivers/staging/android/binder.c

Change-Id: I425ab0c46fbe2b00ed679c5becf9e8140395eb40
Signed-off-by: Arve Hjønnevåg <arve@android.com>
Git-commit: 457c3cd05958b8397211ae1f6dd3c3d325f4c0ea
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
Signed-off-by: Nirmal Abraham <nabrah@codeaurora.org>
Signed-off-by: Prados Das <prados@codeaurora.org>
qseecom: Validate pointer offset in qseecom_send_modfd_cmd

Validate cmd_req_buf pointer offset in qseecom_send_modfy_cmd, and
make sure cmd buffer address to be within shared bufffer.

Signed-off-by: Zhen Kong <zkong@codeaurora.org>

Change-Id: I431511a92ab2cccbc2daebc0cf76cc3872689a97
Signed-off-by: Zhen Kong <zkong@codeaurora.org>
Signed-off-by: Vignesh Veeramani <quicvignes@codeaurora.org>