connection: remove duplicate variable declaration
metadata: reflect change in task_cgroup_name

Change: e61734c55c24cdf11b07e52a74aec4dc4a7f4bd0.
Merged: dc5ed40686a4da95881c35d913b60f867755cbe2 in 3.15-rc1.

task_cgroup_name returns a pointer to the path or NULL if there is not
enough space in the buffer (used to return nonnegative or
-ENAMETOOLONG).

On systemd systems fixes a kernel panic about init dying while opening a
bus. Now it boots properly.
connection: return ESRCH for unknown names consistently

We use ESRCH for unknown names except in GET_CONN_INFO. That's misleading
and makes error forwarding error prone. Fix that and use ESRCH instead of
ENOENT.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
connection: dont modify msg in case of errors in kdbus_conn_get_conn_dst

We shouldn't modify the message before we decided whether to fail or not.
Keep the name-id local and write it only after we checked for all errors.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
names: fix kdbus_name_lookup() race condition

We cannot return pointers to the internal name registry from
kdbus_name_lookup(). No-one guarantees that these entries will stay valid.
Therefore, return the requested information directly with proper
references. This is protected by locks in kdbus_name_lookup() itself and
thus is safe.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
names: fix kdbus_name_lookup() to not ref NULL conns (ABI break)

The previous kdbus_name_lookup() fix assumed kdbus_conn_ref(NULL) is a
no-op. Turns out, it's a panic-op instead... Fix it.

Also add the ABI-break annotation as the previous error-code change
requires new systemd user-space (fixed by Kay).

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
kdbus: fix 'canceled' typo

'canceled' -> 'cancelled'

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
connection: simplify cmd_conn_info()

We only have one path setting 'name'. There's no reason to split
name-handling, so merge them back together.

Also fix a bug where we access the name _before_ checking for strlen.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
handle notify messages in a bus list to preserve bus-global ordering
names: turn registry lock into rwsem

Imagine a racing name-acquire and msg-send. The msg-send might lookup the
destination name, which might be an activator. But before it can queue the
message, the racing name-acquire installs and implementor and moves all
pending messages from the activator to the implementor. If the original
msg-send afterwards continues, it will still queue the in-flight message
on the activator instead of the implementor.

After 1 day of discussion, we decided on turning the registry into a
read-write lock. This way, any msg-send will be locked against
name-changes. A name-change requires a writer lock, but any in-flight
message will hold a regsitry read-lock from the name-lookup until it
queued the message.

This patch only converts the lock, following patches will close the races.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
connection: keep names locked while sending messages

If we send messages and we look up well-known names, we must keep them
locked until we're done. Otherwise, the name might move to another
connection before we queue it on the resolved name.

This fixes the sending path to lock names for the entire function call.
Name-movements already lock the name-registry for the entire move, so we
should be fine now.

We also inline the lookup-helper, as it is only used once and will get
messy if we return kdbus_name_entry objects.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
uksm-0.1.2.2-for-v3.14.patch

from http://kerneldedup.org/projects/uksm/download/
genksyms: fix typeof() handling

Recent increased use of typeof() throughout the tree resulted in a
number of symbols (25 in a typical distro config of ours) not getting a
proper CRC calculated for them anymore, due to the parser in genksyms
not coping with several of these uses (interestingly in the majority of
[if not all] cases the problem is due to the use of typeof() in code
preceding a certain export, not in the declaration/definition of the
exported function/object itself; I wasn't able to find a way to address
this more general parser shortcoming).

The use of parameter_declaration is a little more relaxed than would be
ideal (permitting not just a bare type specification, but also one with
identifier), but since the same code is being passed through an actual
compiler, there's no apparent risk of allowing through any broken code.

Otoh using parameter_declaration instead of the ad hoc
"decl_specifier_seq '*'" / "decl_specifier_seq" pair allows all types to
be handled rather than just plain ones and pointers to plain ones.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Michal Marek <mmarek@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
x86/efi: Correct EFI boot stub use of code32_start

code32_start should point at the start of the protected mode code, and
*not* at the beginning of the bzImage. This is much easier to do in
assembly so document that callers of make_boot_params() need to fill out
code32_start.

The fallout from this bug is that we would end up relocating the image
but copying the image at some offset, resulting in what appeared to be
memory corruption.

Reported-by: Thomas Bächler <thomas@archlinux.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
futex: avoid race between requeue and wake

commit 69cd9eba38867a493a043bb13eb9b33cad5f1a9a upstream.

Jan Stancek reported:
 "pthread_cond_broadcast/4-1.c testcase from openposix testsuite (LTP)
  occasionally fails, because some threads fail to wake up.

  Testcase creates 5 threads, which are all waiting on same condition.
  Main thread then calls pthread_cond_broadcast() without holding mutex,
  which calls:

      futex(uaddr1, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, uaddr2, ..)

  This immediately wakes up single thread A, which unlocks mutex and
  tries to wake up another thread:

      futex(uaddr2, FUTEX_WAKE_PRIVATE, 1)

  If thread A manages to call futex_wake() before any waiters are
  requeued for uaddr2, no other thread is woken up"

The ordering constraints for the hash bucket waiter counting are that
the waiter counts have to be incremented _before_ getting the spinlock
(because the spinlock acts as part of the memory barrier), but the
"requeue" operation didn't honor those rules, and nobody had even
thought about that case.

This fairly simple patch just increments the waiter count for the target
hash bucket (hb2) when requeing a futex before taking the locks.  It
then decrements them again after releasing the lock - the code that
actually moves the futex(es) between hash buckets will do the additional
required waiter count housekeeping.

Reported-and-tested-by: Jan Stancek <jstancek@redhat.com>
Acked-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: rs: fix search cycle rules

commit 8930b05090acd321b1fc7c642528c697cb105c42 upstream.

We should explore all possible columns when searching to be
as resilient as possible to changing conditions. This fixes
for example a scenario where even after a sudden creation of
rssi difference between the 2 antennas we would keep doing MIMO
at a low rate instead of switching to SISO at a higher rate using
the better antenna which was the optimal configuration.

Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iwlwifi: mvm: delay enabling smart FIFO until after beacon RX

If we have no beacon data before association, delay smart FIFO
enablement until after we have this data.

Not doing so can cause association failures in extremely silent
environments (usually only a shielded box/room) as beacon RX is
not sent to the host immediately, and then the association time
event ends without the host receiving any beacon even though it
was on the air - it's just stuck on the FIFO.

Cc: <stable@vger.kernel.org> [3.14]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Merge remote-tracking branch 'github/3.14/uksm' into 3.14/master
Merge remote-tracking branch 'github/3.14/misc' into 3.14/master
Merge remote-tracking branch 'kdbus/master' into 3.14/kdbus