linux-stable.git, branch v3.11.3

Linux 3.11.3

2013-10-01T16:41:12+00:00

netfilter: ipset: Fix serious failure in CIDR tracking

2013-10-01T16:41:02+00:00

commit 2cf55125c64d64cc106e204d53b107094762dfdf upstream.

This fixes a serious bug affecting all hash types with a net element -
specifically, if a CIDR value is deleted such that none of the same size
exist any more, all larger (less-specific) values will then fail to
match. Adding back any prefix with a CIDR equal to or more specific than
the one deleted will fix it.

Steps to reproduce:
ipset -N test hash:net
ipset -A test 1.1.0.0/16
ipset -A test 2.2.2.0/24
ipset -T test 1.1.1.1           #1.1.1.1 IS in set
ipset -D test 2.2.2.0/24
ipset -T test 1.1.1.1           #1.1.1.1 IS NOT in set

This is due to the fact that the nets counter was unconditionally
decremented prior to the iteration that shifts up the entries. Now, we
first check if there is a proceeding entry and if not, decrement it and
return. Otherwise, we proceed to iterate and then zero the last element,
which, in most cases, will already be zero.

Signed-off-by: Oliver Smith 
Signed-off-by: Jozsef Kadlecsik 
Signed-off-by: Greg Kroah-Hartman

cw1200: Don't perform SPI transfers in interrupt context

2013-10-01T16:41:02+00:00

commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream.

When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line.  Unfortunately this
involves a SPI transaction in interrupt context.  Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().

So, work around this by using adding a hwbus hook for the cw1200 driver
core to call.  The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.

Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.

Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.

Signed-off-by: Solomon Peachy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

cw1200: Prevent a lock-related hang in the cw1200_spi driver

2013-10-01T16:41:02+00:00

commit 85ba8f529c57ac6e2fca9be0d9e17920a1afb2e8 upstream.

The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock
API, which relies on sdio_claim_host/sdio_release_host to serialize
hardware operations across multiple threads.

Unfortunately the implementation was flawed, as it lacked a way to wake
up the lock requestor when there was contention, often resulting in a
hang.

This problem was uncovered while trying to fix the
spi-transfers-in-interrupt-context BUG() corrected in the previous
patch.  Many thanks to Dave Sizeburns for his assistance in fixing this.

Signed-off-by: Solomon Peachy 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rpc: let xdr layer allocate gssproxy receieve pages

2013-10-01T16:41:02+00:00

commit d4a516560fc96a9d486a9939bcb567e3fdce8f49 upstream.

In theory the linux cred in a gssproxy reply can include up to
NGROUPS_MAX data, 256K of data.  In the common case we expect it to be
shorter.  So do as the nfsv3 ACL code does and let the xdr code allocate
the pages as they come in, instead of allocating a lot of pages that
won't typically be used.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: fix huge kmalloc's in gss-proxy

2013-10-01T16:41:02+00:00

commit 9dfd87da1aeb0fd364167ad199f40fe96a6a87be upstream.

The reply to a gssproxy can include up to NGROUPS_MAX gid's, which will
take up more than a page.  We therefore need to allocate an array of
pages to hold the reply instead of trying to allocate a single huge
buffer.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: comment on linux_cred encoding, treat all as unsigned

2013-10-01T16:41:02+00:00

commit 6a36978e6931e6601be586eb313375335f2cfaa3 upstream.

The encoding of linux creds is a bit confusing.

Also: I think in practice it doesn't really matter whether we treat any
of these things as signed or unsigned, but unsigned seems more
straightforward: uid_t/gid_t are unsigned and it simplifies the ngroups
overflow check.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: clean up decoding of gssproxy linux creds

2013-10-01T16:41:02+00:00

commit 778e512bb1d3315c6b55832248cd30c566c081d7 upstream.

We can use the normal coding infrastructure here.

Two minor behavior changes:

	- we're assuming no wasted space at the end of the linux cred.
	  That seems to match gss-proxy's behavior, and I can't see why
	  it would need to do differently in the future.

	- NGROUPS_MAX check added: note groups_alloc doesn't do this,
	  this is the caller's responsibility.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

cfq: explicitly use 64bit divide operation for 64bit arguments

2013-10-01T16:41:02+00:00

commit f3cff25f05f2ac29b2ee355e611b0657482f6f1d upstream.

'samples' is 64bit operant, but do_div() second parameter is 32.
do_div silently truncates high 32 bits and calculated result
is invalid.

In case if low 32bit of 'samples' are zeros then do_div() produces
kernel crash.

Signed-off-by: Anatol Pomozov 
Acked-by: Tejun Heo 
Signed-off-by: Jens Axboe 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman

bio-integrity: Fix use of bs->bio_integrity_pool after free

2013-10-01T16:41:02+00:00

commit adbe6991efd36104ac9eaf751993d35eaa7f493a upstream.

This fixes a copy and paste error introduced by 9f060e2231
("block: Convert integrity to bvec_alloc_bs()").

Found by Coverity (CID 1020654).

Signed-off-by: Bjorn Helgaas 
Acked-by: Kent Overstreet 
Signed-off-by: Jens Axboe 
Cc: Jonghwan Choi 
Signed-off-by: Greg Kroah-Hartman