linux-stable.git/drivers, branch v3.15.7

iwlwifi: mvm: disable CTS to Self

2014-07-28T15:08:29+00:00

commit dc271ee0d04d12d6bfabacbec803289a7072fbd9 upstream.

Firmware folks seem say that this flag can make trouble.
Drop it. The advantage of CTS to self is that it slightly
reduces the cost of the protection, but make the protection
less reliable.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Greg Kroah-Hartman

gpio: dwapb: drop irq_setup_generic_chip()

2014-07-28T15:08:29+00:00

commit 11d3d334af07408ce3a68860c40006ddcd343da5 upstream.

The driver calls irq_alloc_domain_generic_chips() which creates a gc and
adds it to gc_list. The driver later then calls irq_setup_generic_chip()
which also initializes the gc and adds it to the gc_list() and this
corrupts the list. Enable LIST_DEBUG and you see the kernel complain.
This isn't required, irq_alloc_domain_generic_chips() did the init.

Signed-off-by: Sebastian Andrzej Siewior 
Tested-by: Alan Tull 
Signed-off-by: Linus Walleij 
Signed-off-by: dann frazier 
Signed-off-by: Greg Kroah-Hartman

IB/mlx5: Enable "block multicast loopback" for kernel consumers

2014-07-28T15:08:28+00:00

commit 652c1a05171695d21b84dd3a723606b50eeb80fd upstream.

In commit f360d88a2efd, we advertise blocking multicast loopback to both
kernel and userspace consumers, but don't allow kernel consumers (e.g IPoIB)
to use it with their UD QPs.  Fix that.

Fixes: f360d88a2efd ("IB/mlx5: Add block multicast loopback support")
Reported-by: Haggai Eran 
Signed-off-by: Eli Cohen 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

RDMA/cxgb4: Initialize the device status page

2014-07-28T15:08:28+00:00

commit 6b54d54dea82ae214e4a45a503c4ef755a8ecee8 upstream.

The status page is mapped to user processes and allows sharing the
device state between the kernel and user processes.  This state isn't
getting initialized and thus intermittently causes problems.  Namely,
the user process can mistakenly think the user doorbell writes are
disabled which causes SQ work requests to never get fetched by HW.

Fixes: 05eb23893c2c ("cxgb4/iw_cxgb4: Doorbell Drop Avoidance Bug Fixes").
Signed-off-by: Steve Wise 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

dm cache metadata: do not allow the data block size to change

2014-07-28T15:08:28+00:00

commit 048e5a07f282c57815b3901d4a68a77fa131ce0a upstream.

The block size for the dm-cache's data device must remained fixed for
the life of the cache.  Disallow any attempt to change the cache's data
block size.

Signed-off-by: Mike Snitzer 
Acked-by: Joe Thornber 
Signed-off-by: Greg Kroah-Hartman

dm thin metadata: do not allow the data block size to change

2014-07-28T15:08:28+00:00

commit 9aec8629ec829fc9403788cd959e05dd87988bd1 upstream.

The block size for the thin-pool's data device must remained fixed for
the life of the thin-pool.  Disallow any attempt to change the
thin-pool's data block size.

It should be noted that attempting to change the data block size via
thin-pool table reload will be ignored as a side-effect of the thin-pool
handover that the thin-pool target does during thin-pool table reload.

Here is an example outcome of attempting to load a thin-pool table that
reduced the thin-pool's data block size from 1024K to 512K.

Before:
kernel: device-mapper: thin: 253:4: growing the data device from 204800 to 409600 blocks

After:
kernel: device-mapper: thin metadata: changing the data block size (from 2048 to 1024) is not supported
kernel: device-mapper: table: 253:4: thin-pool: Error creating metadata object
kernel: device-mapper: ioctl: error adding target to table

Signed-off-by: Mike Snitzer 
Acked-by: Joe Thornber 
Signed-off-by: Greg Kroah-Hartman

mtd: devices: elm: fix elm_context_save() and elm_context_restore() functions

2014-07-28T15:08:28+00:00

commit 6938ad40cb97a52d88a763008935340729a4acc7 upstream.

These two function's switch case lack the 'break' that make them always
return error.

Signed-off-by: Ted Juan 
Acked-by: Pekon Gupta 
Signed-off-by: Brian Norris 
Signed-off-by: Greg Kroah-Hartman

random: check for increase of entropy_count because of signed conversion

2014-07-28T15:08:27+00:00

commit 79a8468747c5f95ed3d5ce8376a3e82e0c5857fc upstream.

The expression entropy_count -= ibytes << (ENTROPY_SHIFT + 3) could
actually increase entropy_count if during assignment of the unsigned
expression on the RHS (mind the -=) we reduce the value modulo
2^width(int) and assign it to entropy_count. Trinity found this.

[ Commit modified by tytso to add an additional safety check for a
  negative entropy_count -- which should never happen, and to also add
  an additional paranoia check to prevent overly large count values to
  be passed into urandom_read().  ]

Reported-by: Dave Jones 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

cpufreq: move policy kobj to policy->cpu at resume

2014-07-28T15:08:27+00:00

commit 92c14bd9477a20a83144f08c0ca25b0308bf0730 upstream.

This is only relevant to implementations with multiple clusters, where clusters
have separate clock lines but all CPUs within a cluster share it.

Consider a dual cluster platform with 2 cores per cluster. During suspend we
start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj
would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its
kobj as we want to retain permissions/values/etc.

Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev().
We will recover the old policy and update policy->cpu from 3 to 2 from
update_policy_cpu().

But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a
link for CPU2, but would try that for CPU3 while bringing it online. Which will
report errors as CPU3 already has kobj assigned to it.

This bug got introduced with commit 42f921a, which overlooked this scenario.

To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a
cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here
only for the first CPU of a non-boot cluster. And we can't recover from this
situation, if kobject_move() fails.

Fixes: 42f921a6f10c (cpufreq: remove sysfs files for CPUs which failed to come back after resume)
Reported-and-tested-by: Bu Yitian
Reported-by: Saravana Kannan
Reviewed-by: Srivatsa S. Bhat
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman

hwrng: fetch randomness only after device init

2014-07-28T15:08:27+00:00

commit d3cc7996473a7bdd33256029988ea690754e4e2a upstream.

Commit d9e7972619334 "hwrng: add randomness to system from rng sources"
added a call to rng_get_data() from the hwrng_register() function.
However, some rng devices need initialization before data can be read
from them.

This commit makes the call to rng_get_data() depend on no init fn
pointer being registered by the device.  If an init function is
registered, this call is made after device init.

CC: Kees Cook 
CC: Jason Cooper 
CC: Herbert Xu 
Signed-off-by: Amit Shah 
Reviewed-by: Jason Cooper 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman