10 years agonet: fix napi_reuse_skb() skb reserve
Eric Dumazet [Wed, 21 Mar 2012 06:58:03 +0000 (06:58 +0000)]
net: fix napi_reuse_skb() skb reserve

[ Upstream commit 2a2a459eeeff48640dc557548ce576d666ab06ed ]

napi->skb is allocated in napi_get_frags() using
netdev_alloc_skb_ip_align(), with a reserve of NET_SKB_PAD +

However, when such skb is recycled in napi_reuse_skb(), it ends with a
reserve of NET_IP_ALIGN which is suboptimal.

Signed-off-by: Eric Dumazet <>
Cc: Herbert Xu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agonet: fix a potential rcu_read_lock() imbalance in rt6_fill_node()
Eric Dumazet [Tue, 27 Mar 2012 09:53:52 +0000 (09:53 +0000)]
net: fix a potential rcu_read_lock() imbalance in rt6_fill_node()

[ Upstream commit 94f826b8076e2cb92242061e92f21b5baa3eccc2 ]

Commit f2c31e32b378 (net: fix NULL dereferences in check_peer_redir() )
added a regression in rt6_fill_node(), leading to rcu_read_lock()

Thats because NLA_PUT() can make a jump to nla_put_failure label.

Fix this by using nla_put()

Many thanks to Ben Greear for his help

Reported-by: Ben Greear <>
Reported-by: Dave Jones <>
Signed-off-by: Eric Dumazet <>
Tested-by: Ben Greear <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agonet: bpf_jit: fix BPF_S_LDX_B_MSH compilation
Eric Dumazet [Sun, 18 Mar 2012 02:40:48 +0000 (02:40 +0000)]
net: bpf_jit: fix BPF_S_LDX_B_MSH compilation

[ Upstream commit dc72d99dabb870ca5bd6d9fff674be853bb4a88d ]

Matt Evans spotted that x86 bpf_jit was incorrectly handling negative
constant offsets in BPF_S_LDX_B_MSH instruction.

We need to abort JIT compilation like we do in common_load so that
filter uses the interpreter code and can call __load_pointer()


Thanks to Indan Zupancic to bring back this issue.

Reported-by: Matt Evans <>
Reported-by: Indan Zupancic <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoipv6: fix incorrent ipv6 ipsec packet fragment
Gao feng [Mon, 19 Mar 2012 22:36:10 +0000 (22:36 +0000)]
ipv6: fix incorrent ipv6 ipsec packet fragment

[ Upstream commit 1f85851e17b64cabd089a8a8839dddebc627948c ]

Since commit 299b0767(ipv6: Fix IPsec slowpath fragmentation problem)
In func ip6_append_data,after call skb_put(skb, fraglen + dst_exthdrlen)
the skb->len contains dst_exthdrlen,and we don't reduce dst_exthdrlen at last
This will make fraggap>0 in next "while cycle",and cause the size of skb incorrent

Fix this by reserve headroom for dst_exthdrlen.

Signed-off-by: Gao feng <>
Acked-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoFix pppol2tp getsockname()
Benjamin LaHaise [Tue, 20 Mar 2012 03:57:54 +0000 (03:57 +0000)]
Fix pppol2tp getsockname()

[ Upstream commit bbdb32cb5b73597386913d052165423b9d736145 ]

While testing L2TP functionality, I came across a bug in getsockname().  The
IP address returned within the pppol2tp_addr's addr memember was not being
set to the IP  address in use.  This bug is caused by using inet_sk() on the
wrong socket (the L2TP socket rather than the underlying UDP socket), and was
likely introduced during the addition of L2TPv3 support.

Signed-off-by: Benjamin LaHaise <>
Signed-off-by: James Chapman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/i915: suspend fbdev device around suspend/hibernate
Dave Airlie [Wed, 28 Mar 2012 09:48:49 +0000 (10:48 +0100)]
drm/i915: suspend fbdev device around suspend/hibernate

commit 3fa016a0b5c5237e9c387fc3249592b2cb5391c6 upstream.

Looking at hibernate overwriting I though it looked like a cursor,
so I tracked down this missing piece to stop the cursor blink
timer. I've no idea if this is sufficient to fix the hibernate
problems people are seeing, but please test it.

Both radeon and nouveau have done this for a long time.

I've run this personally all night hib/resume cycles with no fails.

Reviewed-by: Keith Packard <>
Reported-by: Petr Tesarik <>
Reported-by: Stanislaw Gruszka <>
Reported-by: Lots of misc segfaults after hibernate across the world.
Tested-by: Dave Airlie <>
Tested-by: Bojan Smojver <>
Tested-by: Andreas Hartmann <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoBluetooth: btusb: fix bInterval for high/super speed isochronous endpoints
Bing Zhao [Wed, 21 Dec 2011 02:19:00 +0000 (18:19 -0800)]
Bluetooth: btusb: fix bInterval for high/super speed isochronous endpoints

commit fa0fb93f2ac308a76fa64eb57c18511dadf97089 upstream.

For high-speed/super-speed isochronous endpoints, the bInterval
value is used as exponent, 2^(bInterval-1). Luckily we have
usb_fill_int_urb() function that handles it correctly. So we just
call this function to fill in the RX URB.

Cc: Marcel Holtmann <>
Signed-off-by: Bing Zhao <>
Acked-by: Marcel Holtmann <>
Signed-off-by: Gustavo F. Padovan <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomodule: Remove module size limit
Sasha Levin [Tue, 31 Jan 2012 04:07:22 +0000 (23:07 -0500)]
module: Remove module size limit

commit f946eeb9313ff1470758e171a60fe7438a2ded3f upstream.

Module size was limited to 64MB, this was legacy limitation due to vmalloc()
which was removed a while ago.

Limiting module size to 64MB is both pointless and affects real world use

Cc: Tim Abbott <>
Signed-off-by: Sasha Levin <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoNFSv4.1: Fix layoutcommit error handling
Trond Myklebust [Tue, 27 Mar 2012 22:22:19 +0000 (18:22 -0400)]
NFSv4.1: Fix layoutcommit error handling

commit e59d27e05a6435f8c04d5ad843f37fa795f2eaaa upstream.

Firstly, task->tk_status will always return negative error values,
so the current tests for 'NFS4ERR_DELEG_REVOKED' etc. are all being
Secondly, clean up the code so that we only need to test
task->tk_status once!

Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoNFSv4: Fix two infinite loops in the mount code
Trond Myklebust [Tue, 27 Mar 2012 22:13:02 +0000 (18:13 -0400)]
NFSv4: Fix two infinite loops in the mount code

commit 05e9cfb408b24debb3a85fd98edbfd09dd148881 upstream.

We can currently loop forever in nfs4_lookup_root() and in
nfs41_proc_secinfo_no_name(), if the first iteration returns a
NFS4ERR_DELAY or something else that causes exception.retry to get

Reported-by: Weston Andros Adamson <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoslub: Do not hold slub_lock when calling sysfs_slab_add()
Christoph Lameter [Tue, 17 Jan 2012 15:27:31 +0000 (09:27 -0600)]
slub: Do not hold slub_lock when calling sysfs_slab_add()

commit 66c4c35c6bc5a1a452b024cf0364635b28fd94e4 upstream.

sysfs_slab_add() calls various sysfs functions that actually may
end up in userspace doing all sorts of things.

Release the slub_lock after adding the kmem_cache structure to the list.
At that point the address of the kmem_cache is not known so we are
guaranteed exlusive access to the following modifications to the
kmem_cache structure.

If the sysfs_slab_add fails then reacquire the slub_lock to
remove the kmem_cache structure from the list.

Reported-by: Sasha Levin <>
Acked-by: Eric Dumazet <>
Signed-off-by: Christoph Lameter <>
Signed-off-by: Pekka Enberg <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoxfs: Fix oops on IO error during xlog_recover_process_iunlinks()
Jan Kara [Thu, 15 Mar 2012 09:34:02 +0000 (09:34 +0000)]
xfs: Fix oops on IO error during xlog_recover_process_iunlinks()

commit d97d32edcd732110758799ae60af725e5110b3dc upstream.

When an IO error happens during inode deletion run from
xlog_recover_process_iunlinks() filesystem gets shutdown. Thus any subsequent
attempt to read buffers fails. Code in xlog_recover_process_iunlinks() does not
count with the fact that read of a buffer which was read a while ago can
really fail which results in the oops on
  agi = XFS_BUF_TO_AGI(agibp);

Fix the problem by cleaning up the buffer handling in
xlog_recover_process_iunlinks() as suggested by Dave Chinner. We release buffer
lock but keep buffer reference to AG buffer. That is enough for buffer to stay
pinned in memory and we don't have to call xfs_read_agi() all the time.

Signed-off-by: Jan Kara <>
Reviewed-by: Dave Chinner <>
Signed-off-by: Ben Myers <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agobacklight: fix typo in tosa_lcd.c
Masanari Iida [Wed, 28 Mar 2012 21:42:56 +0000 (14:42 -0700)]
backlight: fix typo in tosa_lcd.c

commit 8da00edc1069f01c34510fa405dc15d96c090a3f upstream.

Fix typo in drivers/video/backlight/tosa_lcd.c
"tosa_lcd_reume" should be "tosa_lcd_resume".

Signed-off-by: Masanari Iida <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodm thin: fix stacked bi_next usage
Joe Thornber [Wed, 28 Mar 2012 17:41:23 +0000 (18:41 +0100)]
dm thin: fix stacked bi_next usage

commit 6f94a4c45a6f744383f9f695dde019998db3df55 upstream.

Avoid using the bi_next field for the holder of a cell when deferring
bios because a stacked device below might change it.  Store the
holder in a new field in struct cell instead.

When a cell is created, the bio that triggered creation (the holder) was
added to the same bio list as subsequent bios.  In some cases we pass
this holder bio directly to devices underneath.  If those devices use
the bi_next field there will be trouble...

This also simplifies some code that had to work out which bio was the

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodm persistent data: fix btree rebalancing after remove
Joe Thornber [Wed, 28 Mar 2012 17:41:23 +0000 (18:41 +0100)]
dm persistent data: fix btree rebalancing after remove

commit b0988900bae9ecf968a8a8d086a9eec671a9517a upstream.

When we remove an entry from a node we sometimes rebalance with it's
two neighbours.  This wasn't being done correctly; in some cases
entries have to move all the way from the right neighbour to the left
neighbour, or vice versa.  This patch pretty much re-writes the
balancing code to fix it.

This code is barely used currently; only when you delete a thin
device, and then only if you have hundreds of them in the same pool.
Once we have discard support, which removes mappings, this will be used
much more heavily.

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodm exception store: fix init error path
Andrei Warkentin [Wed, 28 Mar 2012 17:41:22 +0000 (18:41 +0100)]
dm exception store: fix init error path

commit aadbe266f2f89ccc68b52f4effc7b3a8b29521ef upstream.

Call the correct exit function on failure in dm_exception_store_init.

Signed-off-by: Andrei Warkentin <>
Acked-by: Mike Snitzer <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodm crypt: add missing error handling
Mikulas Patocka [Wed, 28 Mar 2012 17:41:22 +0000 (18:41 +0100)]
dm crypt: add missing error handling

commit 72c6e7afc43e19f68a31dea204fc366624d6eee9 upstream.

Always set io->error to -EIO when an error is detected in dm-crypt.

There were cases where an error code would be set only if we finish
processing the last sector. If there were other encryption operations in
flight, the error would be ignored and bio would be returned with
success as if no error happened.

This bug is present in kcryptd_crypt_write_convert, kcryptd_crypt_read_convert
and kcryptd_async_done.

Signed-off-by: Mikulas Patocka <>
Reviewed-by: Milan Broz <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodm crypt: fix mempool deadlock
Mikulas Patocka [Wed, 28 Mar 2012 17:41:22 +0000 (18:41 +0100)]
dm crypt: fix mempool deadlock

commit aeb2deae2660a1773c83d3c6e9e6575daa3855d6 upstream.

This patch fixes a possible deadlock in dm-crypt's mempool use.

Currently, dm-crypt reserves a mempool of MIN_BIO_PAGES reserved pages.
It allocates first MIN_BIO_PAGES with non-failing allocation (the allocation
cannot fail and waits until the mempool is refilled). Further pages are
allocated with different gfp flags that allow failing.

Because allocations may be done in parallel, this code can deadlock. Example:
There are two processes, each tries to allocate MIN_BIO_PAGES and the processes
run simultaneously.
It may end up in a situation where each process allocates (MIN_BIO_PAGES / 2)
pages. The mempool is exhausted. Each process waits for more pages to be freed
to the mempool, which never happens.

To avoid this deadlock scenario, this patch changes the code so that only
the first page is allocated with non-failing gfp mask. Allocation of further
pages may fail.

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Milan Broz <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agogpio/davinci: fix enabling unbanked GPIO IRQs
Sekhar Nori [Sun, 11 Mar 2012 12:46:12 +0000 (18:16 +0530)]
gpio/davinci: fix enabling unbanked GPIO IRQs

commit 81b279d80a63628e580c71a31d30a8c3b3047ad4 upstream.

Unbanked GPIO IRQ handling code made a copy of just
the irq_chip structure for GPIO IRQ lines which caused
problems after the generic IRQ chip conversion because
there was no valid irq_chip_type structure with the
right "regs" populated. irq_gc_mask_set_bit() was
therefore accessing random addresses.

Fix it by making a copy of irq_chip_type structure
instead. This will ensure sane register offsets.

Reported-by: Jon Povey <>
Tested-by: Jon Povey <>
Signed-off-by: Sekhar Nori <>
Signed-off-by: Grant Likely <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agogpio/davinci: fix oops on unbanked gpio irq request
Sekhar Nori [Sun, 11 Mar 2012 12:46:11 +0000 (18:16 +0530)]
gpio/davinci: fix oops on unbanked gpio irq request

commit ab2dde9924dd1ddb791fa8b14aa52e1df681e20c upstream.

Unbanked GPIO irq setup code was overwriting chip_data leading
to the following oops on request_irq()

Unable to handle kernel paging request at virtual address febfffff
pgd = c22dc000
[febfffff] *pgd=00000000
Internal error: Oops: 801 [#1] PREEMPT
Modules linked in: mcu(+) edmak irqk cmemk
CPU: 0    Not tainted  (3.0.0-rc7+ #93)
PC is at irq_gc_mask_set_bit+0x68/0x7c
LR is at vprintk+0x22c/0x484
pc : [<c0080c0c>]    lr : [<c00457e0>]    psr: 60000093
sp : c33e3ba0  ip : c33e3af0  fp : c33e3bc4
r10: c04555bc  r9 : c33d4340  r8 : 60000013
r7 : 0000002d  r6 : c04555bc  r5 : fec67010  r4 : 00000000
r3 : c04734c8  r2 : fec00000  r1 : ffffffff  r0 : 00000026
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 0005317f  Table: 822dc000  DAC: 00000015
Process modprobe (pid: 526, stack limit = 0xc33e2270)
Stack: (0xc33e3ba0 to 0xc33e4000)
3ba0: 00000000 c007d3d4 c33e3bcc c04555bc c04555bc c33d4340 c33e3bdc c33e3bc8
3bc0: c007f5f8 c0080bb4 00000000 c04555bc c33e3bf4 c33e3be0 c007f654 c007f5c0
3be0: 00000000 c04555bc c33e3c24 c33e3bf8 c007e6e8 c007f618 c01f2284 c0350af8
3c00: c0405214 bf016c98 00000001 00000000 c33dc008 0000002d c33e3c54 c33e3c28
3c20: c007e888 c007e408 00000001 c23ef880 c33dc000 00000000 c33dc080 c25caa00
3c40: c0487498 bf017078 c33e3c94 c33e3c58 bf016b44 c007e7d4 bf017078 c33dc008
3c60: c25caa08 c33dc008 c33e3c84 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08
3c80: c0496d60 bf017484 c33e3ca4 c33e3c98 c022a698 bf01692c c33e3cd4 c33e3ca8
3ca0: c01f5d88 c022a688 00000000 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08
3cc0: c0496d60 00000000 c33e3cec c33e3cd8 c01f5f8c c01f5d10 00000000 c33e3cf0
3ce0: c33e3d14 c33e3cf0 c01f5210 c01f5f58 c303cb48 c25ecf94 c25caa00 c25caa00
3d00: c25caa34 c33e3dd8 c33e3d34 c33e3d18 c01f6044 c01f51b8 c0496d3c c25caa00
3d20: c044e918 c33e3dd8 c33e3d44 c33e3d38 c01f4ff4 c01f5fcc c33e3d94 c33e3d48
3d40: c01f3d10 c01f4fd8 00000000 c044e918 00000000 00000000 c01f52c0 c034d570
3d60: c33e3d84 c33e3d70 c022bf84 c25caa00 00000000 c044e918 c33e3dd8 c25c2e00
3d80: c0496d60 bf01763c c33e3db4 c33e3d98 c022b1a0 c01f384c c25caa00 c33e3dd8
3da0: 00000000 c33e3dd8 c33e3dd4 c33e3db8 c022b27c c022b0e8 00000000 bf01763c
3dc0: c0451c80 c33e3dd8 c33e3e34 c33e3dd8 bf016f60 c022b210 5f75636d 746e6f63
3de0: 006c6f72 00000000 00000000 00000000 00000000 00000000 00000000 bf0174bc
3e00: 00000000 00989680 00000000 00000020 c0451c80 c0451c80 bf0174dc c01f5eb0
3e20: c33f0f00 bf0174dc c33e3e44 c33e3e38 c01f72f4 bf016e2c c33e3e74 c33e3e48
3e40: c01f5d88 c01f72e4 00000000 c0451c80 c0451cb4 bf0174dc c01f5eb0 c33f0f00
3e60: c0473100 00000000 c33e3e94 c33e3e78 c01f5f44 c01f5d10 00000000 c33e3e98
3e80: bf0174dc c01f5eb0 c33e3ebc c33e3e98 c01f5534 c01f5ec0 c303c038 c3061c30
3ea0: 00003cd8 00098258 bf0174dc c0462ac8 c33e3ecc c33e3ec0 c01f5bec c01f54dc
3ec0: c33e3efc c33e3ed0 c01f4d30 c01f5bdc bf0173a0 c33e2000 00003cd8 00098258
3ee0: bf0174dc c33e2000 c00301a4 bf019000 c33e3f1c c33e3f00 c01f6588 c01f4c8c
3f00: 00003cd8 00098258 00000000 c33e2000 c33e3f2c c33e3f20 c01f777c c01f6524
3f20: c33e3f3c c33e3f30 bf019014 c01f7740 c33e3f7c c33e3f40 c002f3ec bf019010
3f40: 00000000 00003cd8 00098258 bf017518 00000000 00003cd8 00098258 bf017518
3f60: 00000000 c00301a4 c33e2000 00000000 c33e3fa4 c33e3f80 c007b934 c002f3c4
3f80: c00b307c c00b2f48 00003cd8 00000000 00000003 00000080 00000000 c33e3fa8
3fa0: c0030020 c007b8b8 00003cd8 00000000 00098288 00003cd8 00098258 00098240
3fc0: 00003cd8 00000000 00000003 00000080 00098008 00098028 00098288 00000001
3fe0: be892998 be892988 00013d7c 40178740 60000010 00098288 09089041 00200845
[<c0080ba4>] (irq_gc_mask_set_bit+0x0/0x7c) from [<c007f5f8>] (irq_enable+0x48/0x58)
 r6:c33d4340 r5:c04555bc r4:c04555bc
[<c007f5b0>] (irq_enable+0x0/0x58) from [<c007f654>] (irq_startup+0x4c/0x54)
 r5:c04555bc r4:00000000
[<c007f608>] (irq_startup+0x0/0x54) from [<c007e6e8>] (__setup_irq+0x2f0/0x3cc)
 r5:c04555bc r4:00000000
[<c007e3f8>] (__setup_irq+0x0/0x3cc) from [<c007e888>] (request_threaded_irq+0xc4/0x110)
 r8:0000002d r7:c33dc008 r6:00000000 r5:00000001 r4:bf016c98
[<c007e7c4>] (request_threaded_irq+0x0/0x110) from [<bf016b44>] (mcu_spi_probe+0x228/0x37c [mcu])
[<bf01691c>] (mcu_spi_probe+0x0/0x37c [mcu]) from [<c022a698>] (spi_drv_probe+0x20/0x24)
[<c022a678>] (spi_drv_probe+0x0/0x24) from [<c01f5d88>] (driver_probe_device+0x88/0x1b0)
[<c01f5d00>] (driver_probe_device+0x0/0x1b0) from [<c01f5f8c>] (__device_attach+0x44/0x48)
[<c01f5f48>] (__device_attach+0x0/0x48) from [<c01f5210>] (bus_for_each_drv+0x68/0x94)
 r5:c33e3cf0 r4:00000000
[<c01f51a8>] (bus_for_each_drv+0x0/0x94) from [<c01f6044>] (device_attach+0x88/0xa0)
 r7:c33e3dd8 r6:c25caa34 r5:c25caa00 r4:c25caa00
[<c01f5fbc>] (device_attach+0x0/0xa0) from [<c01f4ff4>] (bus_probe_device+0x2c/0x4c)
 r7:c33e3dd8 r6:c044e918 r5:c25caa00 r4:c0496d3c
[<c01f4fc8>] (bus_probe_device+0x0/0x4c) from [<c01f3d10>] (device_add+0x4d4/0x648)
[<c01f383c>] (device_add+0x0/0x648) from [<c022b1a0>] (spi_add_device+0xc8/0x128)
[<c022b0d8>] (spi_add_device+0x0/0x128) from [<c022b27c>] (spi_new_device+0x7c/0xb4)
 r7:c33e3dd8 r6:00000000 r5:c33e3dd8 r4:c25caa00
[<c022b200>] (spi_new_device+0x0/0xb4) from [<bf016f60>] (mcu_probe+0x144/0x224 [mcu])
 r7:c33e3dd8 r6:c0451c80 r5:bf01763c r4:00000000
[<bf016e1c>] (mcu_probe+0x0/0x224 [mcu]) from [<c01f72f4>] (platform_drv_probe+0x20/0x24)
[<c01f72d4>] (platform_drv_probe+0x0/0x24) from [<c01f5d88>] (driver_probe_device+0x88/0x1b0)
[<c01f5d00>] (driver_probe_device+0x0/0x1b0) from [<c01f5f44>] (__driver_attach+0x94/0x98)
[<c01f5eb0>] (__driver_attach+0x0/0x98) from [<c01f5534>] (bus_for_each_dev+0x68/0x94)
 r7:c01f5eb0 r6:bf0174dc r5:c33e3e98 r4:00000000
[<c01f54cc>] (bus_for_each_dev+0x0/0x94) from [<c01f5bec>] (driver_attach+0x20/0x28)
 r7:c0462ac8 r6:bf0174dc r5:00098258 r4:00003cd8
[<c01f5bcc>] (driver_attach+0x0/0x28) from [<c01f4d30>] (bus_add_driver+0xb4/0x258)
[<c01f4c7c>] (bus_add_driver+0x0/0x258) from [<c01f6588>] (driver_register+0x74/0x158)
[<c01f6514>] (driver_register+0x0/0x158) from [<c01f777c>] (platform_driver_register+0x4c/0x60)
 r7:c33e2000 r6:00000000 r5:00098258 r4:00003cd8
[<c01f7730>] (platform_driver_register+0x0/0x60) from [<bf019014>] (mcu_init+0x14/0x20 [mcu])
[<bf019000>] (mcu_init+0x0/0x20 [mcu]) from [<c002f3ec>] (do_one_initcall+0x38/0x170)
[<c002f3b4>] (do_one_initcall+0x0/0x170) from [<c007b934>] (sys_init_module+0x8c/0x1a4)
[<c007b8a8>] (sys_init_module+0x0/0x1a4) from [<c0030020>] (ret_fast_syscall+0x0/0x2c)
 r7:00000080 r6:00000003 r5:00000000 r4:00003cd8
Code: e1844003 e585400c e596300c e5932064 (e7814002)

Fix the issue.

Reported-by: Jon Povey <>
Signed-off-by: Sekhar Nori <>
Signed-off-by: Grant Likely <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agogpio/omap: fix _set_gpio_irqenable implementation
Tarun Kanti DebBarma [Fri, 25 Nov 2011 09:57:37 +0000 (15:27 +0530)]
gpio/omap: fix _set_gpio_irqenable implementation

commit 8276536cec38bc6bde30d0aa67716f22b9b9705a upstream.

This function should be capable of both enabling and disabling interrupts
based upon the *enable* parameter. Right now the function only enables
the interrupt and *enable* is not used at all. So add the interrupt
disable capability also using the parameter.

Signed-off-by: Tarun Kanti DebBarma <>
Reviewed-by: Santosh Shilimkar <>
Acked-by: Felipe Balbi <>
Reviewed-by: Kevin Hilman <>
Signed-off-by: Kevin Hilman <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoudf: Fix deadlock in udf_release_file()
Jan Kara [Mon, 20 Feb 2012 16:49:56 +0000 (17:49 +0100)]
udf: Fix deadlock in udf_release_file()

commit a0391a3ae91d301c0e59368531a4de5f0b122bcf upstream.

udf_release_file() can be called from munmap() path with mmap_sem held.  Thus
we cannot take i_mutex there because that ranks above mmap_sem. Luckily,
i_mutex is not needed in udf_release_file() anymore since protection by
i_data_sem is enough to protect from races with write and truncate.

Reported-by: Al Viro <>
Reviewed-by: Namjae Jeon <>
Signed-off-by: Jan Kara <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoARM: tegra: select required CPU and L2 errata options
Stephen Warren [Tue, 14 Feb 2012 20:39:39 +0000 (13:39 -0700)]
ARM: tegra: select required CPU and L2 errata options

commit f35b431dde39fb40944d1024f08d88fbf04a3193 upstream.

The ARM IP revisions in Tegra are:
Tegra20: CPU r1p1, PL310 r2p0
Tegra30: CPU A01=r2p7/>=A02=r2p9, NEON r2p3-50, PL310 r3p1-50

Based on work by Olof Johansson, although the actual list of errata is
somewhat different here, since I added a bunch more and removed one PL310
erratum that doesn't seem applicable.

Signed-off-by: Stephen Warren <>
Signed-off-by: Olof Johansson <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agovfs: fix d_ancestor() case in d_materialize_unique
Michel Lespinasse [Tue, 27 Mar 2012 00:32:44 +0000 (17:32 -0700)]
vfs: fix d_ancestor() case in d_materialize_unique

commit b18dafc86bb879d2f38a1743985d7ceb283c2f4d upstream.

In d_materialise_unique() there are 3 subcases to the 'aliased dentry'
case; in two subcases the inode i_lock is properly released but this
does not occur in the -ELOOP subcase.

This seems to have been introduced by commit 1836750115f2 ("fix loop
checks in d_materialise_unique()").

Signed-off-by: Michel Lespinasse <>
[ Added a comment, and moved the unlock to where we generate the -ELOOP,
  which seems to be more natural.

  You probably can't actually trigger this without a buggy network file
  server - d_materialize_unique() is for finding aliases on non-local
  filesystems, and the d_ancestor() case is for a hardlinked directory

  But we should be robust in the case of such buggy servers anyway. ]
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoext4: check for zero length extent
Theodore Ts'o [Mon, 12 Mar 2012 03:30:16 +0000 (23:30 -0400)]
ext4: check for zero length extent

commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12 upstream.

Explicitly test for an extent whose length is zero, and flag that as a
corrupted extent.

This avoids a kernel BUG_ON assertion failure.

Tested: Without this patch, the file system image found in
tests/f_ext_zero_len/image.gz in the latest e2fsprogs sources causes a
kernel panic.  With this patch, an ext4 file system error is noted
instead, and the file system is marked as being corrupted.

Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoext4: fix race between sync and completed io work
Jeff Moyer [Mon, 5 Mar 2012 15:29:52 +0000 (10:29 -0500)]
ext4: fix race between sync and completed io work

commit 491caa43639abcffaa645fbab372a7ef4ce2975c upstream.

The following command line will leave the aio-stress process unkillable
on an ext4 file system (in my case, mounted on /mnt/test):

aio-stress -t 20 -s 10 -O -S -o 2 -I 1000 /mnt/test/aiostress.3561.4 /mnt/test/aiostress.3561.4.20 /mnt/test/aiostress.3561.4.19 /mnt/test/aiostress.3561.4.18 /mnt/test/aiostress.3561.4.17 /mnt/test/aiostress.3561.4.16 /mnt/test/aiostress.3561.4.15 /mnt/test/aiostress.3561.4.14 /mnt/test/aiostress.3561.4.13 /mnt/test/aiostress.3561.4.12 /mnt/test/aiostress.3561.4.11 /mnt/test/aiostress.3561.4.10 /mnt/test/aiostress.3561.4.9 /mnt/test/aiostress.3561.4.8 /mnt/test/aiostress.3561.4.7 /mnt/test/aiostress.3561.4.6 /mnt/test/aiostress.3561.4.5 /mnt/test/aiostress.3561.4.4 /mnt/test/aiostress.3561.4.3 /mnt/test/aiostress.3561.4.2

This is using the aio-stress program from the xfstests test suite.
That particular command line tells aio-stress to do random writes to
20 files from 20 threads (one thread per file).  The files are NOT
preallocated, so you will get writes to random offsets within the
file, thus creating holes and extending i_size.  It also opens the
file with O_DIRECT and O_SYNC.

On to the problem.  When an I/O requires unwritten extent conversion,
it is queued onto the completed_io_list for the ext4 inode.  Two code
paths will pull work items from this list.  The first is the
ext4_end_io_work routine, and the second is ext4_flush_completed_IO,
which is called via the fsync path (and O_SYNC handling, as well).
There are two issues I've found in these code paths.  First, if the
fsync path beats the work routine to a particular I/O, the work
routine will free the io_end structure!  It does not take into account
the fact that the io_end may still be in use by the fsync path.  I've
fixed this issue by adding yet another IO_END flag, indicating that
the io_end is being processed by the fsync path.

The second problem is that the work routine will make an assignment to
io->flag outside of the lock.  I have witnessed this result in a hang
at umount.  Moving the flag setting inside the lock resolved that

The problem was introduced by commit b82e384c7b ("ext4: optimize
locking for end_io extent conversion"), which first appeared in 3.2.
As such, the fix should be backported to that release (probably along
with the unwritten extent conversion race fix).

Signed-off-by: Jeff Moyer <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoext4: fix race between unwritten extent conversion and truncate
Jeff Moyer [Mon, 20 Feb 2012 22:59:24 +0000 (17:59 -0500)]
ext4: fix race between unwritten extent conversion and truncate

commit 266991b13890049ee1a6bb95b9817f06339ee3d7 upstream.

The following comment in ext4_end_io_dio caught my attention:

/* XXX: probably should move into the real I/O completion handler */

The truncate code takes i_mutex, then calls inode_dio_wait.  Because the
ext4 code path above will end up dropping the mutex before it is
reacquired by the worker thread that does the extent conversion, it
seems to me that the truncate can happen out of order.  Jan Kara
mentioned that this might result in error messages in the system logs,
but that should be the extent of the "damage."

The fix is pretty straight-forward: don't call inode_dio_done until the
extent conversion is complete.

Reviewed-by: Jan Kara <>
Signed-off-by: Jeff Moyer <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoext4: ignore EXT4_INODE_JOURNAL_DATA flag with delalloc
Lukas Czerner [Mon, 20 Feb 2012 22:53:00 +0000 (17:53 -0500)]
ext4: ignore EXT4_INODE_JOURNAL_DATA flag with delalloc

commit 3d2b158262826e8b75bbbfb7b97010838dd92ac7 upstream.

Ext4 does not support data journalling with delayed allocation enabled.
We even do not allow to mount the file system with delayed allocation
and data journalling enabled, however it can be set via FS_IOC_SETFLAGS
so we can hit the inode with EXT4_INODE_JOURNAL_DATA set even on file
system mounted with delayed allocation (default) and that's where
problem arises. The easies way to reproduce this problem is with the
following set of commands:

 mkfs.ext4 /dev/sdd
 mount /dev/sdd /mnt/test1
 dd if=/dev/zero of=/mnt/test1/file bs=1M count=4
 chattr +j /mnt/test1/file
 dd if=/dev/zero of=/mnt/test1/file bs=1M count=4 conv=notrunc
 chattr -j /mnt/test1/file

Additionally it can be reproduced quite reliably with xfstests 272 and
269. In fact the above reproducer is a part of test 272.

To fix this we should ignore the EXT4_INODE_JOURNAL_DATA inode flag if
the file system is mounted with delayed allocation. This can be easily
done by fixing ext4_should_*_data() functions do ignore data journal
flag when delalloc is set (suggested by Ted). We also have to set the
appropriate address space operations for the inode (again, ignoring data
journal flag if delalloc enabled).

Additionally this commit introduces ext4_inode_journal_mode() function
because ext4_should_*_data() has already had a lot of common code and
this change is putting it all into one function so it is easier to

Successfully tested with xfstests in following configurations:

delalloc + data=ordered
delalloc + data=writeback
nodelalloc + data=ordered
nodelalloc + data=writeback
nodelalloc + data=journal

Signed-off-by: Lukas Czerner <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agojbd2: clear BH_Delay & BH_Unwritten in journal_unmap_buffer
Eric Sandeen [Mon, 20 Feb 2012 22:53:01 +0000 (17:53 -0500)]
jbd2: clear BH_Delay & BH_Unwritten in journal_unmap_buffer

commit 15291164b22a357cb211b618adfef4fa82fc0de3 upstream.

journal_unmap_buffer()'s zap_buffer: code clears a lot of buffer head
state ala discard_buffer(), but does not touch _Delay or _Unwritten as
discard_buffer() does.

This can be problematic in some areas of the ext4 code which assume
that if they have found a buffer marked unwritten or delay, then it's
a live one.  Perhaps those spots should check whether it is mapped
as well, but if jbd2 is going to tear down a buffer, let's really
tear it down completely.

Without this I get some fsx failures on sub-page-block filesystems
up until v3.2, at which point 4e96b2dbbf1d7e81f22047a50f862555a6cb87cb
and 189e868fa8fdca702eb9db9d8afc46b5cb9144c9 make the failures go
away, because buried within that large change is some more flag
clearing.  I still think it's worth doing in jbd2, since
->invalidatepage leads here directly, and it's the right place
to clear away these flags.

Signed-off-by: Eric Sandeen <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoPM / Hibernate: Enable usermodehelpers in hibernate() error path
Srivatsa S. Bhat [Fri, 17 Feb 2012 22:39:51 +0000 (23:39 +0100)]
PM / Hibernate: Enable usermodehelpers in hibernate() error path

commit 05b4877f6a4f1ba4952d1222213d262bf8c132b7 upstream.

If create_basic_memory_bitmaps() fails, usermodehelpers are not re-enabled
before returning. Fix this. And while at it, reword the goto labels so that
they look more meaningful.

Signed-off-by: Srivatsa S. Bhat <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoNFSv4: Rate limit the state manager warning messages
Trond Myklebust [Mon, 12 Mar 2012 22:01:48 +0000 (18:01 -0400)]
NFSv4: Rate limit the state manager warning messages

commit 9a3ba432330e504ac61ff0043dbdaba7cea0e35a upstream.

Prevent the state manager from filling up system logs when recovery
fails on the server.

Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
Michael Krufky [Sun, 18 Mar 2012 17:35:57 +0000 (14:35 -0300)]
mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()

commit 3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a upstream.

Remove unnecessary register access in mxl111sf_ep6_streaming_ctrl()

This code breaks driver operation in kernel 3.3 and later, although
it works properly in 3.2  Disable register access to 0x12 for now.

Signed-off-by: Michael Krufky <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agopvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5
Michael Krufky [Tue, 7 Feb 2012 16:28:33 +0000 (13:28 -0300)]
pvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5

commit 9ab2393fc3e460cd2040de1483918eb17abb822f upstream.

The D1F5 revision of the WinTV HVR-1900 uses a tda18271c2 tuner
instead of a tda18271c1 tuner as used in revision D1E9. To
account for this, we must hardcode the frontend configuration
to use the same IF frequency configuration for both revisions
of the device.

6MHz DVB-T is unaffected by this issue, as the recommended
IF Frequency configuration for 6MHz DVB-T is the same on both
c1 and c2 revisions of the tda18271 tuner.

Signed-off-by: Michael Krufky <>
Cc: Mike Isely <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agolgdt330x: fix signedness error in i2c_read_demod_bytes()
Xi Wang [Tue, 14 Feb 2012 17:32:41 +0000 (14:32 -0300)]
lgdt330x: fix signedness error in i2c_read_demod_bytes()

commit 34817174fca0c5512c2d5b6ea0fc37a0337ce1d8 upstream.

The error handling in lgdt3303_read_status() and lgdt330x_read_ucblocks()
doesn't work, because i2c_read_demod_bytes() returns a u8 and (err < 0)
is always false.

        err = i2c_read_demod_bytes(state, 0x58, buf, 1);
        if (err < 0)
                return err;

Change the return type of i2c_read_demod_bytes() to int.  Also change
the return value on error to -EIO to make (err < 0) work.

Signed-off-by: Xi Wang <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agohwmon: (fam15h_power) Correct sign extension of running_avg_capture
Andreas Herrmann [Fri, 23 Mar 2012 09:02:17 +0000 (10:02 +0100)]
hwmon: (fam15h_power) Correct sign extension of running_avg_capture

commit fc0900cbda9243957d812cd6b4cc87965f9fe75f upstream.

Wrong bit was used for sign extension which caused wrong end results.
Thanks to Andre for spotting this bug.

Reported-by: Andre Przywara <>
Signed-off-by: Andreas Herrmann <>
Acked-by: Guenter Roeck <>
Signed-off-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agosysctl: protect poll() in entries that may go away
Lucas De Marchi [Thu, 22 Mar 2012 21:42:22 +0000 (14:42 -0700)]
sysctl: protect poll() in entries that may go away

commit 4e474a00d7ff746ed177ddae14fa8b2d4bad7a00 upstream.

Protect code accessing ctl_table by grabbing the header with grab_header()
and after releasing with sysctl_head_finish().  This is needed if poll()
is called in entries created by modules: currently only hostname and
domainname support poll(), but this bug may be triggered when/if modules
use it and if user called poll() in a file that doesn't support it.

Dave Jones reported the following when using a syscall fuzzer while

RIP: 0010:[<ffffffff81233e3e>]  [<ffffffff81233e3e>] proc_sys_poll+0x4e/0x90
RAX: 0000000000000145 RBX: ffff88020cab6940 RCX: 0000000000000000
RDX: ffffffff81233df0 RSI: 6b6b6b6b6b6b6b6b RDI: ffff88020cab6940
[ ... ]
Code: 00 48 89 fb 48 89 f1 48 8b 40 30 4c 8b 60 e8 b8 45 01 00 00 49 83
7c 24 28 00 74 2e 49 8b 74 24 30 48 85 f6 74 24 48 85 c9 75 32 <8b> 16
b8 45 01 00 00 48 63 d2 49 39 d5 74 10 8b 06 48 98 48 89

If an entry goes away while we are polling() it, ctl_table may not exist

Reported-by: Dave Jones <>
Signed-off-by: Lucas De Marchi <>
Cc: Al Viro <>
Cc: Linus Torvalds <>
Cc: Alexey Dobriyan <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Eric W. Biederman <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiommu/amd: Fix section warning for prealloc_protection_domains
Steffen Persvold [Thu, 15 Mar 2012 14:20:29 +0000 (15:20 +0100)]
iommu/amd: Fix section warning for prealloc_protection_domains

commit cebd5fa4d3046d5b43ce1836a0120612822a7fb0 upstream.

Fix the following section warning in drivers/iommu/amd_iommu.c :

WARNING: vmlinux.o(.text+0x526e77): Section mismatch in reference from the function prealloc_protection_domains() to the function .init.text:alloc_passthrough_domain()
The function prealloc_protection_domains() references
the function __init alloc_passthrough_domain().
This is often because prealloc_protection_domains lacks a __init
annotation or the annotation of alloc_passthrough_domain is wrong.

Signed-off-by: Steffen Persvold <>
Signed-off-by: Joerg Roedel <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoproc-ns: use d_set_d_op() API to set dentry ops in proc_ns_instantiate().
Pravin B Shelar [Fri, 23 Mar 2012 22:02:55 +0000 (15:02 -0700)]
proc-ns: use d_set_d_op() API to set dentry ops in proc_ns_instantiate().

commit 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 upstream.

The namespace cleanup path leaks a dentry which holds a reference count
on a network namespace.  Keeping that network namespace from being freed
when the last user goes away.  Leaving things like vlan devices in the
leaked network namespace.

If you use ip netns add for much real work this problem becomes apparent
pretty quickly.  It light testing the problem hides because frequently
you simply don't notice the leak.

Use d_set_d_op() so that DCACHE_OP_* flags are set correctly.

This issue exists back to 3.0.

Acked-by: "Eric W. Biederman" <>
Reported-by: Justin Pettit <>
Signed-off-by: Pravin B Shelar <>
Signed-off-by: Jesse Gross <>
Cc: David Miller <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86-32: Fix endless loop when processing signals for kernel tasks
Dmitry Adamushko [Thu, 22 Mar 2012 20:39:25 +0000 (21:39 +0100)]
x86-32: Fix endless loop when processing signals for kernel tasks

commit 29a2e2836ff9ea65a603c89df217f4198973a74f upstream.

The problem occurs on !CONFIG_VM86 kernels [1] when a kernel-mode task
returns from a system call with a pending signal.

A real-life scenario is a child of 'khelper' returning from a failed
kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ].
kernel_execve() fails due to a pending SIGKILL, which is the result of
"kill -9 -1" (at least, busybox's init does it upon reboot).

The loop is as follows:

* syscall_exit_work:
 - work_pending:            // start_of_the_loop
 - work_notify_sig:
   - do_notify_resume()
     - do_signal()
       - if (!user_mode(regs)) return;
 - resume_userspace         // TIF_SIGPENDING is still set
 - work_pending             // so we call work_pending => goto
                            // start_of_the_loop

More information can be found in another LKML thread:,457826

[1] the problem was also seen on MIPS.

Signed-off-by: Dmitry Adamushko <>
Cc: Oleg Nesterov <>
Cc: Roland McGrath <>
Cc: Andrew Morton <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoe1000e: Avoid wrong check on TX hang
Jeff Kirsher [Fri, 18 Nov 2011 14:25:00 +0000 (14:25 +0000)]
e1000e: Avoid wrong check on TX hang

commit 09357b00255c233705b1cf6d76a8d147340545b8 upstream.

Based on the original patch submitted my Michael Wang
Descriptors may not be write-back while checking TX hang with flag
So when we detect hang, we just flush the descriptor and detect
again for once.

-v2 change 1 to true and 0 to false and remove extra ()

CC: Michael Wang <>
CC: Flavio Leitner <>
Acked-by: Jesse Brandeburg <>
Tested-by: Aaron Brown <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agousbnet: don't clear urb->dev in tx_complete [Thu, 22 Mar 2012 03:22:38 +0000 (03:22 +0000)]
usbnet: don't clear urb->dev in tx_complete

commit 5d5440a835710d09f0ef18da5000541ec98b537a upstream.

URB unlinking is always racing with its completion and tx_complete
may be called before or during running usb_unlink_urb, so tx_complete
must not clear urb->dev since it will be used in unlink path,
otherwise invalid memory accesses or usb device leak may be caused
inside usb_unlink_urb.

Cc: Alan Stern <>
Cc: Oliver Neukum <>
Signed-off-by: Ming Lei <>
Acked-by: Greg Kroah-Hartman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agousbnet: increase URB reference count before usb_unlink_urb [Thu, 22 Mar 2012 03:22:18 +0000 (03:22 +0000)]
usbnet: increase URB reference count before usb_unlink_urb

commit 0956a8c20b23d429e79ff86d4325583fc06f9eb4 upstream.

Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
recursive locking in usbnet_stop()) fixes the recursive locking
problem by releasing the skb queue lock, but it makes usb_unlink_urb
racing with defer_bh, and the URB to being unlinked may be freed before
or during calling usb_unlink_urb, so use-after-free problem may be
triggerd inside usb_unlink_urb.

The patch fixes the use-after-free problem by increasing URB
reference count with skb queue lock held before calling
usb_unlink_urb, so the URB won't be freed until return from

Cc: Sebastian Andrzej Siewior <>
Cc: Alan Stern <>
Cc: Oliver Neukum <>
Reported-by: Dave Jones <>
Signed-off-by: Ming Lei <>
Acked-by: Greg Kroah-Hartman <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoSUNRPC: We must not use list_for_each_entry_safe() in rpc_wake_up()
Trond Myklebust [Mon, 19 Mar 2012 17:39:35 +0000 (13:39 -0400)]
SUNRPC: We must not use list_for_each_entry_safe() in rpc_wake_up()

commit 540a0f7584169651f485e8ab67461fcb06934e38 upstream.

The problem is that for the case of priority queues, we
have to assume that __rpc_remove_wait_queue_priority will move new
elements from the tk_wait.links lists into the queue->tasks[] list.
We therefore cannot use list_for_each_entry_safe() on queue->tasks[],
since that will skip these new tasks that __rpc_remove_wait_queue_priority
is adding.

Without this fix, rpc_wake_up and rpc_wake_up_status will both fail
to wake up all functions on priority wait queues, which can result
in some nasty hangs.

Reported-by: Andy Adamson <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoUBI: fix eraseblock picking criteria
Artem Bityutskiy [Wed, 7 Mar 2012 17:08:36 +0000 (19:08 +0200)]
UBI: fix eraseblock picking criteria

commit 7eb3aa65853e1b223bfc786b023b702018cb76c0 upstream.

The 'find_wl_entry()' function expects the maximum difference as the second
argument, not the maximum absolute value. So the "unknown" eraseblock picking
was incorrect, as Shmulik Ladkani spotted. This patch fixes the issue.

Reported-by: Shmulik Ladkani <>
Signed-off-by: Artem Bityutskiy <>
Reviewed-by: Shmulik Ladkani <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoUBI: fix error handling in ubi_scan()
Richard Weinberger [Mon, 30 Jan 2012 17:20:13 +0000 (18:20 +0100)]
UBI: fix error handling in ubi_scan()

commit a29852be492d61001d86c6ebf5fff9b93d7b4be9 upstream.

Two bad things can happen in ubi_scan():
1. If kmem_cache_create() fails we jump to out_si and call
   ubi_scan_destroy_si() which calls kmem_cache_destroy().
   But si->scan_leb_slab is NULL.
2. If process_eb() fails we jump to out_vidh, call
   kmem_cache_destroy() and ubi_scan_destroy_si() which calls
   again kmem_cache_destroy().

Signed-off-by: Richard Weinberger <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoCIFS: Fix a spurious error in cifs_push_posix_locks
Pavel Shilovsky [Sat, 17 Mar 2012 06:46:55 +0000 (09:46 +0300)]
CIFS: Fix a spurious error in cifs_push_posix_locks

commit ce85852b90a214cf577fc1b4f49d99fd7e98784a upstream.

Signed-off-by: Pavel Shilovsky <>
Reviewed-by: Jeff Layton <>
Reported-by: Ben Hutchings <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agocifs: fix issue mounting of DFS ROOT when redirecting from one domain controller...
Jeff Layton [Wed, 21 Mar 2012 10:30:40 +0000 (06:30 -0400)]
cifs: fix issue mounting of DFS ROOT when redirecting from one domain controller to the next

commit 1daaae8fa4afe3df78ca34e724ed7e8187e4eb32 upstream.

This patch fixes an issue when cifs_mount receives a
STATUS_BAD_NETWORK_NAME error during cifs_get_tcon but is able to
continue after an DFS ROOT referral. In this case, the return code
variable is not reset prior to trying to mount from the system referred
to. Thus, is_path_accessible is not executed and the final DFS referral
is not performed causing a mount error.

Use case: In DNS,  resolves to the secondary AD server Our primary domain controller is and has
a DFS redirection set up from \\ad1\share\Users to \\files\share\Users.
Mounting \\\share\Users fails.

Regression introduced by commit 724d9f1.

Reviewed-by: Pavel Shilovsky <
Signed-off-by: Thomas Hadig <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoCIFS: Respect negotiated MaxMpxCount
Pavel Shilovsky [Tue, 20 Mar 2012 09:55:09 +0000 (12:55 +0300)]
CIFS: Respect negotiated MaxMpxCount

commit 10b9b98e41ba248a899f6175ce96ee91431b6194 upstream.

Some servers sets this value less than 50 that was hardcoded and
we lost the connection if when we exceed this limit. Fix this by
respecting this value - not sending more than the server allows.

Reviewed-by: Jeff Layton <>
Signed-off-by: Pavel Shilovsky <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoxfs: fix inode lookup race
Dave Chinner [Wed, 7 Mar 2012 04:50:25 +0000 (04:50 +0000)]
xfs: fix inode lookup race

commit f30d500f809eca67a21704347ab14bb35877b5ee upstream.

When we get concurrent lookups of the same inode that is not in the
per-AG inode cache, there is a race condition that triggers warnings
in unlock_new_inode() indicating that we are initialising an inode
that isn't in a the correct state for a new inode.

When we do an inode lookup via a file handle or a bulkstat, we don't
serialise lookups at a higher level through the dentry cache (i.e.
pathless lookup), and so we can get concurrent lookups of the same

The race condition is between the insertion of the inode into the
cache in the case of a cache miss and a concurrently lookup:

Thread 1 Thread 2
    lock radix tree
lock inode flags
XFS_INEW not set
unlock inode flags
use uninitialised inode
    lock inode flags
    set XFS_INEW
    unlock inode flags
    unlock radix tree
    inode flags = I_NEW
      WARNING as inode flags != I_NEW

This can lead to inode corruption, inode list corruption, etc, and
is generally a bad thing to occur.

Fix this by setting XFS_INEW before inserting the inode into the
radix tree. This will ensure any concurrent lookup will find the new
inode with XFS_INEW set and that forces the lookup to wait until the
XFS_INEW flag is removed before allowing the lookup to succeed.

Signed-off-by: Dave Chinner <>
Reviewed-by: Christoph Hellwig <>
Signed-off-by: Ben Myers <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoNFSv4: Return the delegation if the server returns NFS4ERR_OPENMODE
Trond Myklebust [Wed, 7 Mar 2012 21:39:06 +0000 (16:39 -0500)]
NFSv4: Return the delegation if the server returns NFS4ERR_OPENMODE

commit 3114ea7a24d3264c090556a2444fc6d2c06176d4 upstream.

If a setattr() fails because of an NFS4ERR_OPENMODE error, it is
probably due to us holding a read delegation. Ensure that the
recovery routines return that delegation in this case.

Reported-by: Miklos Szeredi <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoNFS: Properly handle the case where the delegation is revoked
Trond Myklebust [Tue, 6 Mar 2012 00:56:44 +0000 (19:56 -0500)]
NFS: Properly handle the case where the delegation is revoked

commit a1d0b5eebc4fd6e0edb02688b35f17f67f42aea5 upstream.

If we know that the delegation stateid is bad or revoked, we need to
remove that delegation as soon as possible, and then mark all the
stateids that relied on that delegation for recovery. We cannot use
the delegation as part of the recovery process.

Also note that NFSv4.1 uses a different error code (NFS4ERR_DELEG_REVOKED)
to indicate that the delegation was revoked.

Finally, ensure that setlk() and setattr() can both recover safely from
a revoked delegation.

Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoKVM: x86: fix missing checks in syscall emulation
Stephan Bärwolf [Thu, 12 Jan 2012 15:43:04 +0000 (16:43 +0100)]
KVM: x86: fix missing checks in syscall emulation

commit c2226fc9e87ba3da060e47333657cd6616652b84 upstream.

On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following

    [bits 32]
    global _start
    SECTION .text
    _start: syscall

(I tested it with winxp and linux - both always crashed)

    Disassembly of section .text:

    00000000 <_start>:
       0:   0f 05                   syscall

The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)

Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.

Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.

[mtosatti: cleanup/beautify code]

Signed-off-by: Stephan Baerwolf <>
Signed-off-by: Marcelo Tosatti <>
Signed-off-by: Stefan Bader <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoKVM: x86: extend "struct x86_emulate_ops" with "get_cpuid"
Stephan Bärwolf [Thu, 12 Jan 2012 15:43:03 +0000 (16:43 +0100)]
KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid"

commit bdb42f5afebe208eae90406959383856ae2caf2b upstream.

In order to be able to proceed checks on CPU-specific properties
within the emulator, function "get_cpuid" is introduced.
With "get_cpuid" it is possible to virtually call the guests
"cpuid"-opcode without changing the VM's context.

[mtosatti: cleanup/beautify code]

Signed-off-by: Stephan Baerwolf <>
Signed-off-by: Marcelo Tosatti <>
Signed-off-by: Stefan Bader <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agofirewire: ohci: fix too-early completion of IR multichannel buffers
Clemens Ladisch [Mon, 12 Mar 2012 20:45:47 +0000 (21:45 +0100)]
firewire: ohci: fix too-early completion of IR multichannel buffers

commit 0c0efbacab8d70700d13301e0ae7975783c0cb0a upstream.

handle_ir_buffer_fill() assumed that a completed descriptor would be
indicated by a non-zero transfer_status (as in most other descriptors).
However, this field is written by the controller as soon as (the end of)
the first packet has been written into the buffer.  As a consequence, if
we happen to run into such a descriptor when the interrupt handler is
executed after such a packet has completed, the descriptor would be
taken out of the list of active descriptors as soon as the buffer had
been partially filled, so the event for the buffer being completely
filled would never be sent.

To fix this, handle descriptors only when they have been completely
filled, i.e., when res_count == 0.  (This also matches the condition
that is reported by the controller with an interrupt.)

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Stefan Richter <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agopata_legacy: correctly mask recovery field for HT6560B
Sergei Shtylyov [Thu, 19 Jan 2012 16:09:56 +0000 (19:09 +0300)]
pata_legacy: correctly mask recovery field for HT6560B

commit 9716387311c790de381214c03e7f1b72b91a8189 upstream.

According to the HT6560H datasheet, the recovery timing field is 4-bit wide,
with a value of 0 meaning 16 cycles. Correct obvious thinko in the recovery
field mask.

Signed-off-by: Sergei Shtylyov <>
Signed-off-by: Jeff Garzik <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: add more hotkeys in Asus AIO keyboards
Keng-Yu Lin [Mon, 30 Jan 2012 06:25:45 +0000 (14:25 +0800)]
HID: add more hotkeys in Asus AIO keyboards

commit 6c30d5a53229aad22bb675e0bd6eb518ecaa4316 upstream.

Add support for the camera key. The hotkey for
Asus S.H.E(Super Hybrid Engine) mode is mapped to KEY_KEY_PROG1
just for notifying the userspace.

Signed-off-by: Keng-Yu Lin <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoHID: add extra hotkeys in Asus AIO keyboards
Keng-Yu Lin [Thu, 2 Feb 2012 09:31:26 +0000 (10:31 +0100)]
HID: add extra hotkeys in Asus AIO keyboards

commit 3596bb929f2abd3433c2eaa5755fad48ac207af1 upstream.

The Asus All-In-One PC has a wireless keyboard with wifi toggle,
brightness up, brightness down and display off hotkeys.

This patch adds suppoort for these hotkeys.

Signed-off-by: Keng-Yu Lin <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoBluetooth: Add AR30XX device ID on Asus laptops
Keng-Yu Lin [Wed, 30 Nov 2011 10:32:37 +0000 (18:32 +0800)]
Bluetooth: Add AR30XX device ID on Asus laptops

commit 6b6ba88b5bb8779156b21bb957520a448c3642e2 upstream.

The ID is found on Asus K54HR and K53U.
Blacklist the AR3011-based device ID [0489:e03d]
and add to ath3k.c for firmware loading.

Below is the output of usb-devices script:

Before the fiwmware loading:

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e03d Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

After the fiwmware loading:

T:  Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=3005 Rev=00.01
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Keng-Yu Lin <>
Signed-off-by: Gustavo F. Padovan <>
Signed-off-by: Johan Hedberg <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Fix 16-bit target ports for SET TARGET PORT GROUPS emulation
Roland Dreier [Fri, 24 Feb 2012 01:22:12 +0000 (17:22 -0800)]
target: Fix 16-bit target ports for SET TARGET PORT GROUPS emulation

commit 33395fb8a13731c7ef7b175dbf5a4d8a6738fe6c upstream.

The old code did (MSB << 8) & 0xff, which always evaluates to 0.  Just use
get_unaligned_be16() so we don't have to worry about whether our open-coded
version is correct or not.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: prevent NULL pointer dereference in target_report_luns
Jörn Engel [Wed, 15 Feb 2012 21:52:11 +0000 (16:52 -0500)]
target: prevent NULL pointer dereference in target_report_luns

commit 47f1b8803e1e358ebbf4f82bfdb98971c912a2c3 upstream.

transport_kmap_data_sg can return NULL.  I never saw this trigger, but
returning -ENOMEM seems better than a crash.  Also removes a pointless
case while at it.

Signed-off-by: Joern Engel <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: fix use after free in target_report_luns
Jörn Engel [Wed, 15 Feb 2012 21:51:32 +0000 (16:51 -0500)]
target: fix use after free in target_report_luns

commit 382436f8804fe1cb20b9a2a811a10eb2d8554721 upstream.

Fix possible NULL pointer dereference in target_report_luns failure path.

Signed-off-by: Joern Engel <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotarget: Don't set WBUS16 or SYNC bits in INQUIRY response
Roland Dreier [Tue, 14 Feb 2012 00:18:16 +0000 (16:18 -0800)]
target: Don't set WBUS16 or SYNC bits in INQUIRY response

commit effc6cc8828257c32c37635e737f14fd6e19ecd7 upstream.

SPC-4 says about the WBUS16 and SYNC bits:

    The meanings of these fields are specific to SPI-5 (see 6.4.3).
    For SCSI transport protocols other than the SCSI Parallel
    Interface, these fields are reserved.

We don't have a SPI fabric module, so we should never set these bits.
(The comment was misleading, since it only mentioned Sync but the
actual code set WBUS16 too).

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon/kms: add connector quirk for Fujitsu D3003-S2 board
Alex Deucher [Fri, 16 Mar 2012 16:22:10 +0000 (12:22 -0400)]
drm/radeon/kms: add connector quirk for Fujitsu D3003-S2 board

commit 4c1b2d2da3451f5c8dd59bd7e05bd9729d2aee05 upstream.

vbios lists DVI-I port as VGA and DVI-D.


Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon/kms: fix analog load detection on DVI-I connectors
Alex Deucher [Fri, 16 Mar 2012 16:22:09 +0000 (12:22 -0400)]
drm/radeon/kms: fix analog load detection on DVI-I connectors

commit e00e8b5e760cbbe9067daeae5454d67c44c8d035 upstream.

We digital encoders have a detect function as well (for
DP to VGA bridges), so we make sure we choose the analog
one here.


Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agodrm/radeon: Restrict offset for legacy hardware cursor.
Michel Dänzer [Wed, 14 Mar 2012 16:12:41 +0000 (17:12 +0100)]
drm/radeon: Restrict offset for legacy hardware cursor.

commit c4353016dac10133fa5d8535af83f0c4845a2915 upstream.

The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the hardware cursor shows random bits other than the intended


Signed-off-by: Michel Dänzer <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
10 years agodrm/i915: Only clear the GPU domains upon a successful finish
Chris Wilson [Wed, 14 Dec 2011 12:57:23 +0000 (13:57 +0100)]
drm/i915: Only clear the GPU domains upon a successful finish

commit c501ae7f332cdaf42e31af30b72b4b66cbbb1604 upstream.

By clearing the GPU read domains before waiting upon the buffer, we run
the risk of the wait being interrupted and the domains prematurely
cleared. The next time we attempt to wait upon the buffer (after
userspace handles the signal), we believe that the buffer is idle and so
skip the wait.

There are a number of bugs across all generations which show signs of an
overly haste reuse of active buffers.

Such as:

A couple of those pre-date i915_gem_object_finish_gpu(), so may be
unrelated (such as a wild write from a userspace command buffer), but
this does look like a convincing cause for most of those bugs.

Signed-off-by: Chris Wilson <>
Reviewed-by: Daniel Vetter <>
Reviewed-by: Eugeni Dodonov <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomd: fix clearing of the 'changed' flags for the bad blocks list.
NeilBrown [Mon, 19 Mar 2012 01:46:41 +0000 (12:46 +1100)]
md: fix clearing of the 'changed' flags for the bad blocks list.

commit d0962936bff659d20522555b517582a2715fd23f upstream.

In super_1_sync (the first hunk) we need to clear 'changed' before
checking read_seqretry(), otherwise we might race with other code
adding a bad block and so won't retry later.

In md_update_sb (the second hunk), in the case where there is no
metadata (neither persistent nor external), we treat any bad blocks as
an error.  However we need to clear the 'changed' flag before calling
md_ack_all_badblocks, else it won't do anything.

This patch is suitable for -stable release 3.0 and later.

Signed-off-by: NeilBrown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomd/raid1,raid10: avoid deadlock during resync/recovery.
NeilBrown [Mon, 19 Mar 2012 01:46:38 +0000 (12:46 +1100)]
md/raid1,raid10: avoid deadlock during resync/recovery.

commit d6b42dcb995e6acd7cc276774e751ffc9f0ef4bf upstream.

If RAID1 or RAID10 is used under LVM or some other stacking
block device, it is possible to enter a deadlock during
resync or recovery.
This can happen if the upper level block device creates
two requests to the RAID1 or RAID10.  The first request gets
processed, blocks recovery and queue requests for underlying
requests in current->bio_list.  A resync request then starts
which will wait for those requests and block new IO.

But then the second request to the RAID1/10 will be attempted
and it cannot progress until the resync request completes,
which cannot progress until the underlying device requests complete,
which are on a queue behind that second request.

So allow that second request to proceed even though there is
a resync request about to start.

This is suitable for any -stable kernel.

Reported-by: Ray Morris <>
Tested-by: Ray Morris <>
Signed-off-by: NeilBrown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomd: don't set md arrays to readonly on shutdown.
NeilBrown [Mon, 19 Mar 2012 01:46:37 +0000 (12:46 +1100)]
md: don't set md arrays to readonly on shutdown.

commit c744a65c1e2d59acc54333ce80a5b0702a98010b upstream.

It seems that with recent kernel, writeback can still be happening
while shutdown is happening, and consequently data can be written
after the md reboot notifier switches all arrays to read-only.
This causes a BUG.

So don't switch them to read-only - just mark them clean and
set 'safemode' to '2' which mean that immediately after any
write the array will be switch back to 'clean'.

This could result in the shutdown happening when array is marked
dirty, thus forcing a resync on reboot.  However if you reboot
without performing a "sync" first, you get to keep both halves.

This is suitable for any stable kernel (though there might be some
conflicts with obvious fixes in earlier kernels).

Signed-off-by: NeilBrown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomd/bitmap: ensure to load bitmap when creating via sysfs.
NeilBrown [Mon, 19 Mar 2012 01:46:37 +0000 (12:46 +1100)]
md/bitmap: ensure to load bitmap when creating via sysfs.

commit 4474ca42e2577563a919fd3ed782e2ec55bf11a2 upstream.

When commit 69e51b449d383e (md/bitmap:  separate out loading a bitmap...)
created bitmap_load, it missed calling it after bitmap_create when a
bitmap is created through the sysfs interface.
So if a bitmap is added this way, we don't allocate memory properly
and can crash.

This is suitable for any -stable release since 2.6.35.
Signed-off-by: NeilBrown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotcm_fc: Fix fc_exch memory leak in ft_send_resp_status
Nicholas Bellinger [Sat, 10 Mar 2012 07:45:38 +0000 (23:45 -0800)]
tcm_fc: Fix fc_exch memory leak in ft_send_resp_status

commit 031ed4d565b31880a4136bb7366bc89f5b1dba7d upstream.

This patch fixes a bug in tcm_fc where fc_exch memory from fc_exch_mgr->ep_pool
is currently being leaked by ft_send_resp_status() usage.  Following current
code in ft_queue_status() response path, using lport->tt.seq_send() needs to be
followed by a lport->tt.exch_done() in order to release fc_exch memory back into
libfc_em kmem_cache.

ft_send_resp_status() code is currently used in pre submit se_cmd ft_send_work()
error exceptions, TM request setup exceptions, and main TM response callback
path in ft_queue_tm_resp().  This bugfix addresses the leak in these cases.

Cc: Mark D Rustad <>
Cc: Kiran Patil <>
Cc: Robert Love <>
Cc: Andy Grover <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoudlfb: remove sysfs framebuffer device with USB .disconnect()
Kay Sievers [Sat, 28 Jan 2012 19:57:46 +0000 (19:57 +0000)]
udlfb: remove sysfs framebuffer device with USB .disconnect()

commit ce880cb860f36694d2cdebfac9e6ae18176fe4c4 upstream.

The USB graphics card driver delays the unregistering of the framebuffer
device to a workqueue, which breaks the userspace visible remove uevent
sequence. Recent userspace tools started to support USB graphics card
hotplug out-of-the-box and rely on proper events sent by the kernel.

The framebuffer device is a direct child of the USB interface which is
removed immediately after the USB .disconnect() callback. But the fb device
in /sys stays around until its final cleanup, at a time where all the parent
devices have been removed already.

To work around that, we remove the sysfs fb device directly in the USB
.disconnect() callback and leave only the cleanup of the internal fb
data to the delayed work.

 add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
 add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
 add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics)
 remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
 remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
 remove   /2-1.2:1.0/graphics/fb0 (graphics)

 add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
 add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
 add      /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
 remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
 remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
 remove   /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)

Tested-by: Bernie Thompson <>
Acked-by: Bernie Thompson <>
Signed-off-by: Kay Sievers <>
Signed-off-by: Florian Tobias Schandinat <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agousb gadget: fix a section mismatch when compiling g_ffs with CONFIG_USB_FUNCTIONFS_ETH
Lothar Waßmann [Sun, 11 Mar 2012 14:08:46 +0000 (15:08 +0100)]
usb gadget: fix a section mismatch when compiling g_ffs with CONFIG_USB_FUNCTIONFS_ETH

commit 8d0698428822ce63f7269e7fe81fc4580807b9ac upstream.

 commit 28824b18ac4705e876a282a15ea0de8fc957551f:
 |Author: Michal Nazarewicz <>
 |Date:   Wed May 5 12:53:13 2010 +0200
 |    USB: gadget: __init and __exit tags removed
 |    __init, __initdata and __exit tags have have been removed from
 |    various files to make it possible for gadgets that do not use
 |    the __init/__exit tags to use those.
 obviously missed (at least) this case leading to a section mismatch in
 g_ffs.c when compiling with CONFIG_USB_FUNCTIONFS_ETH enabled.

Signed-off-by: Lothar Waßmann <>
Acked-by: Michal Nazarewicz <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoALSA: hda - fix printing of high HDMI sample rates
Anssi Hannula [Tue, 13 Mar 2012 15:43:02 +0000 (17:43 +0200)]
ALSA: hda - fix printing of high HDMI sample rates

commit 25dc16f69892182192b1234594fd3cf342ad4195 upstream.

A previous commit af65cbf296 (ALSA: hdmi: fix printout of SAD sampling
rates) fixed the sample rates shown in /proc/asound/cardX/eldY and
kernel log to not be entirely wrong. However, a missing rate from the
array added in the patch causes HDMI rates 88.2 kHz, 96 kHz, 176.4 kHz,
and 192 kHz to be shown as 96 kHz, 176.4 kHz, 192 kHz, and 384 kHz,

Fix the reporting by adding the ALSA rate 64 kHz into the conversion
array between 48 kHz and 88.2 kHz.

Signed-off-by: Anssi Hannula <>
Cc: Pierre-Louis Bossart <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiscsi-target: Fix dynamic -> explict NodeACL pointer reference
Nicholas Bellinger [Mon, 27 Feb 2012 06:16:07 +0000 (22:16 -0800)]
iscsi-target: Fix dynamic -> explict NodeACL pointer reference

commit d06283341aee9e48eff1b068779d340785c635ce upstream.

This patch fixes a free after use in lio_target_make_nodeacl() where
iscsi_node_acl was referenced from the original se_nacl_new allocation,
instead of from core_tpg_add_initiator_node_acl() in the case of dynamic
-> explict NodeACL conversion.

Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiscsi-target: Fix iscsit_alloc_buffs() failure cases
Nicholas Bellinger [Fri, 24 Feb 2012 01:28:43 +0000 (17:28 -0800)]
iscsi-target: Fix iscsit_alloc_buffs() failure cases

commit d335e6054db616bce3f040e659fa38440518ad1d upstream.

Make iscsit_alloc_buffs() failure case for page_alloc_failed use correct
__free_page() SGL pointer, and return -ENOMEM for iscsit_allocate_iovecs
failure to push se_cmd->t_mem_sg release into iscsit_release_cmd()
callback during iscsit_add_reject_from_cmd() connection reset.

Also drop cmd->t_mem_sg = NULL assignment from page_alloc_failed
failure case.

Reported-by: Roland Dreier <>
Cc: Andy Grover <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agotcm_loop: Set residual field for SCSI commands
Roland Dreier [Tue, 14 Feb 2012 23:30:31 +0000 (15:30 -0800)]
tcm_loop: Set residual field for SCSI commands

commit 6cf3fa6918baab0c447f1206f1cef9166ad04864 upstream.

If the target core signals an over- or under-run, tcm_loop should call
scsi_set_resid() to tell the SCSI midlayer about the residual data length.

The difference can be seen by doing something like

    strace -eioctl sg_raw -r 1024 /dev/sda 8 0 0 0 1 0 > /dev/null

and looking at the "resid=" part of the SG_IO ioctl -- after this patch,
the field is correctly reported as 512.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: pxa-ssp: atomically set stream active masks
Daniel Mack [Mon, 19 Mar 2012 08:12:53 +0000 (09:12 +0100)]
ASoC: pxa-ssp: atomically set stream active masks

commit 273b72c8ce6b28df6b49423d775c3e59072c73c5 upstream.

PXA's SSP engine fails to take its current channel phase into account
when enabling a stream while the engine is already running. This
results in randomly swapped left/right channels on either the record
or the playback side, depending on which one was enabled first.

The following patch fixes this by factoring out the bit field
modifications in question to a separate function that pauses the
engine temporarily, modifies the bits and kicks it off again
afterwards. Appearantly, a transition of SSCR0_SSE syncs both
directions properly.

The patch has been rolled out to quite a number of devices over the
last weeks and seems to fix the issue reliably.

Signed-off-by: Daniel Mack <>
Reported-and-tested-by: Sven Neumann <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoASoC: fsl: p1022ds: tell the WM8776 codec driver that it's the master
Timur Tabi [Fri, 16 Mar 2012 21:32:52 +0000 (16:32 -0500)]
ASoC: fsl: p1022ds: tell the WM8776 codec driver that it's the master

commit 70ac07bb633dee75ac554195b9a4d69adfa7803c upstream.

The WM8776 codec driver requires the machine driver to set one of the
SND_SOC_DAIFMT_CBx_xxx values.  The P1022DS machine driver should be setting
SND_SOC_DAIFMT_CBM_CFM, but since that value was zero, no one noticed.

Commit 75d9ac46 ("ASoC: Allow DAI formats to be specified in the
dai_link"), however, changed the value of SND_SOC_DAIFMT_CBM_CFM from zero
to a non-zero value, which means that it now needs to be specifically set
by the machine driver.

We also set SND_SOC_DAIFMT_NB_NF, for the same reason.

Signed-off-by: Timur Tabi <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agohugetlbfs: avoid taking i_mutex from hugetlbfs_read()
Aneesh Kumar K.V [Wed, 21 Mar 2012 23:34:08 +0000 (16:34 -0700)]
hugetlbfs: avoid taking i_mutex from hugetlbfs_read()

commit a05b0855fd15504972dba2358e5faa172a1e50ba upstream.

Taking i_mutex in hugetlbfs_read() can result in deadlock with mmap as
explained below

 Thread A:
  read() on hugetlbfs
   hugetlbfs_read() called
    i_mutex grabbed
     hugetlbfs_read_actor() called
      __copy_to_user() called
       page fault is triggered
 Thread B, sharing address space with A:
  mmap() the same file
   ->mmap_sem is grabbed on task_B->mm->mmap_sem
    hugetlbfs_file_mmap() is called
     attempt to grab ->i_mutex and block waiting for A to give it up
 Thread A:
  pagefault handled blocked on attempt to grab task_A->mm->mmap_sem,
 which happens to be the same thing as task_B->mm->mmap_sem.  Block waiting
 for B to give it up.

AFAIU the i_mutex locking was added to hugetlbfs_read() as per to take
care of the race between truncate and read.  This patch fixes this by
looking at page->mapping under lock_page() (find_lock_page()) to ensure
that the inode didn't get truncated in the range during a parallel read.

Ideally we can extend the patch to make sure we don't increase i_size in
mmap.  But that will break userspace, because applications will now have
to use truncate(2) to increase i_size in hugetlbfs.

Based on the original patch from Hillf Danton.

Signed-off-by: Aneesh Kumar K.V <>
Cc: Hillf Danton <>
Cc: KAMEZAWA Hiroyuki <>
Cc: Al Viro <>
Cc: Hugh Dickins <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agobootmem/sparsemem: remove limit constraint in alloc_bootmem_section
Nishanth Aravamudan [Wed, 21 Mar 2012 23:34:07 +0000 (16:34 -0700)]
bootmem/sparsemem: remove limit constraint in alloc_bootmem_section

commit f5bf18fa22f8c41a13eb8762c7373eb3a93a7333 upstream.

While testing AMS (Active Memory Sharing) / CMO (Cooperative Memory
Overcommit) on powerpc, we tripped the following:

  kernel BUG at mm/bootmem.c:483!
  cpu 0x0: Vector: 700 (Program Check) at [c000000000c03940]
      pc: c000000000a62bd8: .alloc_bootmem_core+0x90/0x39c
      lr: c000000000a64bcc: .sparse_early_usemaps_alloc_node+0x84/0x29c
      sp: c000000000c03bc0
     msr: 8000000000021032
    current = 0xc000000000b0cce0
    paca    = 0xc000000001d80000
      pid   = 0, comm = swapper
  kernel BUG at mm/bootmem.c:483!
  enter ? for help
  [c000000000c03d50c000000000a64f10 .sparse_init+0x12c/0x28c
  [c000000000c03e20c000000000a474f4 .setup_arch+0x20c/0x294
  [c000000000c03ee0c000000000a4079c .start_kernel+0xb4/0x460
  [c000000000c03f90c000000000009670 .start_here_common+0x1c/0x2c

This is

        BUG_ON(limit && goal + size > limit);

and after some debugging, it seems that

goal = 0x7ffff000000
limit = 0x80000000000

and sparse_early_usemaps_alloc_node ->
sparse_early_usemaps_alloc_pgdat_section calls

return alloc_bootmem_section(usemap_size() * count, section_nr);

This is on a system with 8TB available via the AMS pool, and as a quirk
of AMS in firmware, all of that memory shows up in node 0.  So, we end
up with an allocation that will fail the goal/limit constraints.

In theory, we could "fall-back" to alloc_bootmem_node() in
sparse_early_usemaps_alloc_node(), but since we actually have HOTREMOVE
defined, we'll BUG_ON() instead.  A simple solution appears to be to
unconditionally remove the limit condition in alloc_bootmem_section,
meaning allocations are allowed to cross section boundaries (necessary
for systems of this size).

Johannes Weiner pointed out that if alloc_bootmem_section() no longer
guarantees section-locality, we need check_usemap_section_nr() to print
possible cross-dependencies between node descriptors and the usemaps
allocated through it.  That makes the two loops in
sparse_early_usemaps_alloc_node() identical, so re-factor the code a

[ code simplification]
Signed-off-by: Nishanth Aravamudan <>
Cc: Dave Hansen <>
Cc: Anton Blanchard <>
Cc: Paul Mackerras <>
Cc: Ben Herrenschmidt <>
Cc: Robert Jennings <>
Acked-by: Johannes Weiner <>
Acked-by: Mel Gorman <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoPM / Domains: Fix handling of wakeup devices during system resume
Rafael J. Wysocki [Tue, 13 Mar 2012 21:39:31 +0000 (22:39 +0100)]
PM / Domains: Fix handling of wakeup devices during system resume

commit cc85b20780562d404e18a47b9b55b4a5102ae53e upstream.

During system suspend pm_genpd_suspend_noirq() checks if the given
device is in a wakeup path (i.e. it appears to be needed for one or
more wakeup devices to work or is a wakeup device itself) and if it
needs to be "active" for wakeup to work.  If that is the case, the
function returns 0 without incrementing the device domain's counter
of suspended devices and without executing genpd_stop_dev() for the
device.  In consequence, the device is not stopped (e.g. its clock
isn't disabled) and power is always supplied to its domain in the
resulting system sleep state.

However, pm_genpd_resume_noirq() doesn't repeat that check and it
runs genpd_start_dev() and decrements the domain's counter of
suspended devices even for the wakeup device that weren't stopped by
pm_genpd_suspend_noirq().  As a result, the start callback may be run
unnecessarily for them and their domains' counters of suspended
devices may become negative.  Both outcomes aren't desirable, so fix
pm_genpd_resume_noirq() to look for wakeup devices that might not be
stopped by during system suspend.

Signed-off-by: Rafael J. Wysocki <>
Tested-by: Simon Horman <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoTPM: Zero buffer whole after copying to userspace
Tim Gardner [Tue, 6 Dec 2011 18:29:20 +0000 (11:29 -0700)]
TPM: Zero buffer whole after copying to userspace

commit 3ab1aff89477dafb1aaeafe8c8669114a02b7226 upstream.

Commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 correctly clears the TPM
buffer if the user specified read length is >= the TPM buffer length. However,
if the user specified read length is < the TPM buffer length, then part of the
TPM buffer is left uncleared.

Reported-by: Seth Forshee <>
Cc: Debora Velarde <>
Cc: Rajiv Andrade <>
Cc: Marcel Selhorst <>
Signed-off-by: Tim Gardner <>
Signed-off-by: Rajiv Andrade <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read mode
Andrea Arcangeli [Wed, 21 Mar 2012 23:33:42 +0000 (16:33 -0700)]
mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read mode

commit 1a5a9906d4e8d1976b701f889d8f35d54b928f25 upstream.

In some cases it may happen that pmd_none_or_clear_bad() is called with
the mmap_sem hold in read mode.  In those cases the huge page faults can
allocate hugepmds under pmd_none_or_clear_bad() and that can trigger a
false positive from pmd_bad() that will not like to see a pmd
materializing as trans huge.

It's not khugepaged causing the problem, khugepaged holds the mmap_sem
in write mode (and all those sites must hold the mmap_sem in read mode
to prevent pagetables to go away from under them, during code review it
seems vm86 mode on 32bit kernels requires that too unless it's
restricted to 1 thread per process or UP builds).  The race is only with
the huge pagefaults that can convert a pmd_none() into a

Effectively all these pmd_none_or_clear_bad() sites running with
mmap_sem in read mode are somewhat speculative with the page faults, and
the result is always undefined when they run simultaneously.  This is
probably why it wasn't common to run into this.  For example if the
madvise(MADV_DONTNEED) runs zap_page_range() shortly before the page
fault, the hugepage will not be zapped, if the page fault runs first it
will be zapped.

Altering pmd_bad() not to error out if it finds hugepmds won't be enough
to fix this, because zap_pmd_range would then proceed to call
zap_pte_range (which would be incorrect if the pmd become a

The simplest way to fix this is to read the pmd in the local stack
(regardless of what we read, no need of actual CPU barriers, only
compiler barrier needed), and be sure it is not changing under the code
that computes its value.  Even if the real pmd is changing under the
value we hold on the stack, we don't care.  If we actually end up in
zap_pte_range it means the pmd was not none already and it was not huge,
and it can't become huge from under us (khugepaged locking explained

All we need is to enforce that there is no way anymore that in a code
path like below, pmd_trans_huge can be false, but pmd_none_or_clear_bad
can run into a hugepmd.  The overhead of a barrier() is just a compiler
tweak and should not be measurable (I only added it for THP builds).  I
don't exclude different compiler versions may have prevented the race
too by caching the value of *pmd on the stack (that hasn't been
verified, but it wouldn't be impossible considering
pmd_none_or_clear_bad, pmd_bad, pmd_trans_huge, pmd_none are all inlines
and there's no external function called in between pmd_trans_huge and

if (pmd_trans_huge(*pmd)) {
if (next-addr != HPAGE_PMD_SIZE) {
split_huge_page_pmd(vma->vm_mm, pmd);
} else if (zap_huge_pmd(tlb, vma, pmd, addr))
/* fall through */
if (pmd_none_or_clear_bad(pmd))

Because this race condition could be exercised without special
privileges this was reported in CVE-2012-1179.

The race was identified and fully explained by Ulrich who debugged it.
I'm quoting his accurate explanation below, for reference.

====== start quote =======
      mapcount 0 page_mapcount 1
      kernel BUG at mm/huge_memory.c:1384!

    At some point prior to the panic, a "bad pmd ..." message similar to the
    following is logged on the console:

      mm/memory.c:145: bad pmd ffff8800376e1f98(80000000314000e7).

    The "bad pmd ..." message is logged by pmd_clear_bad() before it clears
    the page's PMD table entry.

        143 void pmd_clear_bad(pmd_t *pmd)
        144 {
    ->  145         pmd_ERROR(*pmd);
        146         pmd_clear(pmd);
        147 }

    After the PMD table entry has been cleared, there is an inconsistency
    between the actual number of PMD table entries that are mapping the page
    and the page's map count (_mapcount field in struct page). When the page
    is subsequently reclaimed, __split_huge_page() detects this inconsistency.

       1381         if (mapcount != page_mapcount(page))
       1382                 printk(KERN_ERR "mapcount %d page_mapcount %d\n",
       1383                        mapcount, page_mapcount(page));
    -> 1384         BUG_ON(mapcount != page_mapcount(page));

    The root cause of the problem is a race of two threads in a multithreaded
    process. Thread B incurs a page fault on a virtual address that has never
    been accessed (PMD entry is zero) while Thread A is executing an madvise()
    system call on a virtual address within the same 2 MB (huge page) range.

               virtual address space
              |                     |
              |                     |
            | |                     |
            | |                     |<-- B(fault)
            | |                     |
      2 MB  | |/////////////////////|-.
      huge <  |/////////////////////|  > A(range)
      page  | |/////////////////////|-'
            | |                     |
            | |                     |
              |                     |
              |                     |

    - Thread A is executing an madvise(..., MADV_DONTNEED) system call
      on the virtual address range "A(range)" shown in the picture.

      // Acquire the semaphore in shared mode.
        switch (behavior)
        case MADV_DONTNEED:
                         // Assume that this huge page has never been accessed.
                         // I.e. content of the PMD entry is zero (not mapped).
                         if (pmd_trans_huge(*pmd)) {
                             // We don't get here due to the above assumption.
                         // Assume that Thread B incurred a page fault and
             .---------> // sneaks in here as shown below.
             |           //
             |           if (pmd_none_or_clear_bad(pmd))
             |               {
             |                 if (unlikely(pmd_bad(*pmd)))
             |                     pmd_clear_bad
             |                     {
             |                       pmd_ERROR
             |                         // Log "bad pmd ..." message here.
             |                       pmd_clear
             |                         // Clear the page's PMD entry.
             |                         // Thread B incremented the map count
             |                         // in page_add_new_anon_rmap(), but
             |                         // now the page is no longer mapped
             |                         // by a PMD entry (-> inconsistency).
             |                     }
             |               }
    - Thread B is handling a page fault on virtual address "B(fault)" shown
      in the picture.

        // Acquire the semaphore in shared mode.
          if (pmd_none(*pmd) && transparent_hugepage_enabled(vma))
              // We get here due to the above assumption (PMD entry is zero).
                  // Allocate a new transparent huge page here.
                    // Here we increment the page's map count (starts at -1).
                    atomic_set(&page->_mapcount, 0)
                    // Here we set the page's PMD entry which will be cleared
                    // when Thread A calls pmd_clear_bad().

    The mmap_sem does not prevent the race because both threads are acquiring
    it in shared mode (down_read).  Thread B holds the page_table_lock while
    the page's map count and PMD table entry are updated.  However, Thread A
    does not synchronize on that lock.

====== end quote =======

[ checkpatch fixes]
Reported-by: Ulrich Obergfell <>
Signed-off-by: Andrea Arcangeli <>
Acked-by: Johannes Weiner <>
Cc: Mel Gorman <>
Cc: Hugh Dickins <>
Cc: Dave Jones <>
Acked-by: Larry Woodman <>
Acked-by: Rik van Riel <>
Cc: Mark Salter <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agox86/ioapic: Add register level checks to detect bogus io-apic entries
Suresh Siddha [Mon, 12 Mar 2012 18:36:33 +0000 (11:36 -0700)]
x86/ioapic: Add register level checks to detect bogus io-apic entries

commit 73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream.

With the recent changes to clear_IO_APIC_pin() which tries to
clear remoteIRR bit explicitly, some of the users started to see
"Unable to reset IRR for apic .." messages.

Close look shows that these are related to bogus IO-APIC entries
which return's all 1's for their io-apic registers. And the
above mentioned error messages are benign. But kernel should
have ignored such io-apic's in the first place.

Check if register 0, 1, 2 of the listed io-apic are all 1's and
ignore such io-apic.

Reported-by: Álvaro Castillo <>
Tested-by: Jon Dufresne <>
Signed-off-by: Suresh Siddha <>
Cc: Josh Boyer <>
[ Performed minor cleanup of affected code. ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoima: fix Kconfig dependencies
Fabio Estevam [Thu, 5 Jan 2012 14:49:54 +0000 (12:49 -0200)]
ima: fix Kconfig dependencies

commit f4a0391dfa91155bd961673b31eb42d9d45c799d upstream.

Fix the following build warning:
warning: (IMA) selects TCG_TPM which has unmet direct dependencies

Suggested-by: Rajiv Andrade <>
Signed-off-by: Fabio Estevam <>
Signed-off-by: Rajiv Andrade <>
Signed-off-by: Mimi Zohar <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoIB/iser: Post initial receive buffers before sending the final login request
Or Gerlitz [Mon, 5 Mar 2012 16:21:44 +0000 (18:21 +0200)]
IB/iser: Post initial receive buffers before sending the final login request

commit 89e984e2c2cd14f77ccb26c47726ac7f13b70ae8 upstream.

An iser target may send iscsi NO-OP PDUs as soon as it marks the iSER
iSCSI session as fully operative.  This means that there is window
where there are no posted receive buffers on the initiator side, so
it's possible for the iSER RC connection to break because of RNR NAK /
retry errors.  To fix this, rely on the flags bits in the login
request to have FFP (0x3) in the lower nibble as a marker for the
final login request, and post an initial chunk of receive buffers
before sending that login request instead of after getting the login

Signed-off-by: Or Gerlitz <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agortnetlink: Fix VF IFLA policy
Greg Rose [Wed, 8 Feb 2012 00:45:00 +0000 (00:45 +0000)]
rtnetlink: Fix VF IFLA policy

commit 48752f6513012a1b078da08b145d5c40a644f058 upstream.

Add VF spoof check to IFLA policy.  The original patch I submitted to
add the spoof checking feature to rtnl failed to add the proper policy
rule that identifies the data type and len.  This patch corrects that
oversight.  No bugs have been reported against this but it may cause
some problem for the netlink message parsing that uses the policy

Signed-off-by: Greg Rose <>
Tested-by: Sibai Li <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agop54spi: Release GPIO lines and IRQ on error in p54spi_probe
Max Filippov [Wed, 29 Feb 2012 20:40:08 +0000 (00:40 +0400)]
p54spi: Release GPIO lines and IRQ on error in p54spi_probe

commit 62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream.

This makes it possible to reload driver if insmod has failed due to
missing firmware.

Signed-off-by: Max Filippov <>
Acked-by: Christian Lamparter <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agortc: Disable the alarm in the hardware (v2)
Rabin Vincent [Tue, 22 Nov 2011 10:03:14 +0000 (11:03 +0100)]
rtc: Disable the alarm in the hardware (v2)

commit 41c7f7424259ff11009449f87c95656f69f9b186 upstream.

Currently, the RTC code does not disable the alarm in the hardware.

This means that after a sequence such as the one below (the files are in the
RTC sysfs), the box will boot up after 2 minutes even though we've
asked for the alarm to be turned off.

# echo $((`cat since_epoch`)+120) > wakealarm
# echo 0 > wakealarm
# poweroff

Fix this by disabling the alarm when there are no timers to run.

The original version of this patch was reverted. This version
disables the irq directly instead of setting a disabled timer
in the future.

Cc: John Stultz <>
Signed-off-by: Rabin Vincent <>
[Merged in the second revision from Rabin]
Signed-off-by: John Stultz <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agogenirq: Fix incorrect check for forced IRQ thread handler
Alexander Gordeev [Fri, 9 Mar 2012 13:59:13 +0000 (14:59 +0100)]
genirq: Fix incorrect check for forced IRQ thread handler

commit 540b60e24f3f4781d80e47122f0c4486a03375b8 upstream.

We do not want a bitwise AND between boolean operands

Signed-off-by: Alexander Gordeev <>
Cc: Oleg Nesterov <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agogenirq: Fix long-term regression in genirq irq_set_irq_type() handling
Russell King [Mon, 5 Mar 2012 23:07:25 +0000 (15:07 -0800)]
genirq: Fix long-term regression in genirq irq_set_irq_type() handling

commit a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 upstream.

In 2008, commit 0c5d1eb77a8be ("genirq: record trigger type") modified the
way set_irq_type() handles the 'no trigger' condition.  However, this has
an adverse effect on PCMCIA support on Intel StrongARM and probably PXA

PCMCIA has several status signals on the socket which can trigger
interrupts; some of these status signals depend on the card's mode
(whether it is configured in memory or IO mode).  For example, cards have
a 'Ready/IRQ' signal: in memory mode, this provides an indication to
PCMCIA that the card has finished its power up initialization.  In IO
mode, it provides the device interrupt signal.  Other status signals
switch between on-board battery status and loud speaker output.

In classical PCMCIA implementations, where you have a specific socket
controller, the controller provides a method to mask interrupts from the
socket, and importantly ignore any state transitions on the pins which
correspond with interrupts once masked.  This masking prevents unwanted
events caused by the removal and application of socket power being

However, on platforms where there is no socket controller, the PCMCIA
status and interrupt signals are routed to standard edge-triggered GPIOs.
These GPIOs can be configured to interrupt on rising edge, falling edge,
or never.  This is where the problems start.

Edge triggered interrupts are required to record events while disabled via
the usual methods of {free,request,disable,enable}_irq() to prevent
problems with dropped interrupts (eg, the 8390 driver uses disable_irq()
to defer the delivery of interrupts).  As a result, these interfaces can
not be used to implement the desired behaviour.

The side effect of this is that if the 'Ready/IRQ' GPIO is disabled via
disable_irq() on suspend, and enabled via enable_irq() after resume, we
will record the state transitions caused by powering events as valid
interrupts, and foward them to the card driver, which may attempt to
access a card which is not powered up.

This leads delays resume while drivers spin in their interrupt handlers,
and complaints from drivers before they realize what's happened.

Moreover, in the case of the 'Ready/IRQ' signal, this is requested and
freed by the card driver itself; the PCMCIA core has no idea whether the
interrupt is requested, and, therefore, whether a call to disable_irq()
would be valid.  (We tried this around 2.4.17 / 2.5.1 kernel era, and
ended up throwing it out because of this problem.)

Therefore, it was decided back in around 2002 to disable the edge
triggering instead, resulting in all state transitions on the GPIO being
ignored.  That's what we actually need the hardware to do.

The commit above changes this behaviour; it explicitly prevents the 'no
trigger' state being selected.

The reason that request_irq() does not accept the 'no trigger' state is
for compatibility with existing drivers which do not provide their desired
triggering configuration.  The set_irq_type() function is 'new' and not
used by non-trigger aware drivers.

Therefore, revert this change, and restore previously working platforms
back to their former state.

Signed-off-by: Russell King <>
Cc: Ingo Molnar <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agouevent: send events in correct order according to seqnum (v3)
Andrew Vagin [Wed, 7 Mar 2012 10:49:56 +0000 (14:49 +0400)]
uevent: send events in correct order according to seqnum (v3)

commit 7b60a18da393ed70db043a777fd9e6d5363077c4 upstream.

The queue handling in the udev daemon assumes that the events are

Before this patch uevent_seqnum is incremented under sequence_lock,
than an event is send uner uevent_sock_mutex. I want to say that code
contained a window between incrementing seqnum and sending an event.

This patch locks uevent_sock_mutex before incrementing uevent_seqnum.

v2: delete sequence_lock, uevent_seqnum is protected by uevent_sock_mutex
v3: unlock the mutex before the goto exit

Thanks for Kay for the comments.

Signed-off-by: Andrew Vagin <>
Tested-By: Kay Sievers <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agontp: Fix integer overflow when setting time
Sasha Levin [Thu, 15 Mar 2012 16:36:14 +0000 (12:36 -0400)]
ntp: Fix integer overflow when setting time

commit a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33 upstream.

'long secs' is passed as divisor to div_s64, which accepts a 32bit
divisor. On 64bit machines that value is trimmed back from 8 bytes
back to 4, causing a divide by zero when the number is bigger than
(1 << 32) - 1 and all 32 lower bits are 0.

Use div64_long() instead.

Signed-off-by: Sasha Levin <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agomath: Introduce div64_long
Sasha Levin [Thu, 15 Mar 2012 16:36:13 +0000 (12:36 -0400)]
math: Introduce div64_long

commit f910381a55cdaa097030291f272f6e6e4380c39a upstream.

Add a div64_long macro which is used to devide a 64bit number by a long (which
can be 4 bytes on 32bit systems and 8 bytes on 64bit systems).

Suggested-by: Thomas Gleixner <>
Signed-off-by: Sasha Levin <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agoiwlwifi: always monitor for stuck queues
Johannes Berg [Sun, 4 Mar 2012 16:50:46 +0000 (08:50 -0800)]
iwlwifi: always monitor for stuck queues

commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912 upstream.

If we only monitor while associated, the following
can happen:
 - we're associated, and the queue stuck check
   runs, setting the queue "touch" time to X
 - we disassociate, stopping the monitoring,
   which leaves the time set to X
 - almost 2s later, we associate, and enqueue
   a frame
 - before the frame is transmitted, we monitor
   for stuck queues, and find the time set to
   X, although it is now later than X + 2000ms,
   so we decide that the queue is stuck and
   erroneously restart the device

It happens more with P2P because there we can
go between associated/unassociated frequently.

Reported-by: Ben Cahill <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Wey-Yi Guy <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agortlwifi: rtl8192ce: Fix loss of receive performance
Jingjun Wu [Sat, 3 Mar 2012 02:52:14 +0000 (20:52 -0600)]
rtlwifi: rtl8192ce: Fix loss of receive performance

commit a9b89e2567c743483e6354f64d7a7e3a8c101e9e upstream.

Driver rtl8192ce when used with the RTL8188CE device would start at about
20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the
symptoms is that the AP would need to retransmit each packet 4 of 5 times
before the driver would acknowledge it. Recovery is possible only by
unloading and reloading the driver. This problem was reported at

The problem is due to a missing update of the gain setting.

Signed-off-by: Jingjun Wu <>
Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agortlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu
Larry Finger [Fri, 2 Mar 2012 21:23:36 +0000 (15:23 -0600)]
rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu

commit ebecdcc12fed5d3c81853dea61a0a78a5aefab52 upstream.

When driver rtl8192cu is used with the debug level set to 3 or greater,
the result is "sleeping function called from invalid context" due to
an rcu_read_lock() call in the DM refresh routine in driver rtl8192c.
This lock is not necessary as the USB driver does not use the struct
being protected, thus the lock is set only when a PCI interface is

This bug is reported in

Reported-by: Ronald Wahl <>
Tested-by: Ronald Wahl <>
Signed-off-by: Larry Finger <>
Cc: Ronald Wahl <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agortlwifi: Handle previous allocation failures when freeing device memory
Simon Graham [Wed, 8 Feb 2012 00:07:38 +0000 (18:07 -0600)]
rtlwifi: Handle previous allocation failures when freeing device memory

commit 7f66c2f93e5779625c10d262c84537427a2673ca upstream.

Handle previous allocation failures when freeing device memory

Signed-off-by: Simon Graham <>
Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
10 years agortlwifi: rtl8192c_common: rtl8192de: Check for allocation failures
Larry Finger [Sun, 8 Jan 2012 02:46:40 +0000 (20:46 -0600)]
rtlwifi: rtl8192c_common: rtl8192de: Check for allocation failures

commit 76a92be537f1c8c259e393632301446257ca3ea9 upstream.

In, a kernel bug was
triggered due to a failed skb allocation that was not checked. This event
lead to an audit of all memory allocations in the complete rtlwifi family
of drivers. This patch fixes the rest.

Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>