9 years agolib/vsprintf.c: kptr_restrict: fix pK-error in SysRq show-all-timers(Q)
Dan Rosenberg [Mon, 30 Jul 2012 21:40:26 +0000 (14:40 -0700)]
lib/vsprintf.c: kptr_restrict: fix pK-error in SysRq show-all-timers(Q)

commit 3715c5309f6d175c3053672b73fd4f73be16fd07 upstream.

When using ALT+SysRq+Q all the pointers are replaced with "pK-error" like

[23153.208033]   .base:               pK-error

with echo h > /proc/sysrq-trigger it works:

[23107.776363]   .base:       ffff88023e60d540

The intent behind this behavior was to return "pK-error" in cases where
the %pK format specifier was used in interrupt context, because the
CAP_SYSLOG check wouldn't be meaningful.  Clearly this should only apply
when kptr_restrict is actually enabled though.

Reported-by: Stevie Trujillo <>
Signed-off-by: Dan Rosenberg <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agopcdp: use early_ioremap/early_iounmap to access pcdp table
Greg Pearson [Mon, 30 Jul 2012 21:39:05 +0000 (14:39 -0700)]
pcdp: use early_ioremap/early_iounmap to access pcdp table

commit 6c4088ac3a4d82779903433bcd5f048c58fb1aca upstream.

efi_setup_pcdp_console() is called during boot to parse the HCDP/PCDP
EFI system table and setup an early console for printk output.  The
routine uses ioremap/iounmap to setup access to the HCDP/PCDP table

The call to ioremap is happening early in the boot process which leads
to a panic on x86_64 systems:


This replaces the calls to ioremap/iounmap in efi_setup_pcdp_console()
with calls to early_ioremap/early_iounmap which can be called during
early boot.

This patch was tested on an x86_64 prototype system which uses the
HCDP/PCDP table for early console setup.

Signed-off-by: Greg Pearson <>
Acked-by: Khalid Aziz <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agomd/raid1: don't abort a resync on the first badblock.
NeilBrown [Tue, 31 Jul 2012 00:05:34 +0000 (10:05 +1000)]
md/raid1: don't abort a resync on the first badblock.

commit b7219ccb33aa0df9949a60c68b5e9f712615e56f upstream.

If a resync of a RAID1 array with 2 devices finds a known bad block
one device it will neither read from, or write to, that device for
this block offset.
So there will be one read_target (The other device) and zero write
This condition causes md/raid1 to abort the resync assuming that it
has finished - without known bad blocks this would be true.

When there are no write targets because of the presence of bad blocks
we should only skip over the area covered by the bad block.
RAID10 already gets this right, raid1 doesn't.  Or didn't.

As this can cause a 'sync' to abort early and appear to have succeeded
it could lead to some data corruption, so it suitable for -stable.

Reported-by: Alexander Lyakas <>
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
9 years agonfs: skip commit in releasepage if we're freeing memory for fs-related reasons
Jeff Layton [Mon, 23 Jul 2012 17:58:51 +0000 (13:58 -0400)]
nfs: skip commit in releasepage if we're freeing memory for fs-related reasons

commit 5cf02d09b50b1ee1c2d536c9cf64af5a7d433f56 upstream.

We've had some reports of a deadlock where rpciod ends up with a stack
trace like this:

    PID: 2507   TASK: ffff88103691ab40  CPU: 14  COMMAND: "rpciod/14"
     #0 [ffff8810343bf2f0] schedule at ffffffff814dabd9
     #1 [ffff8810343bf3b8] nfs_wait_bit_killable at ffffffffa038fc04 [nfs]
     #2 [ffff8810343bf3c8] __wait_on_bit at ffffffff814dbc2f
     #3 [ffff8810343bf418] out_of_line_wait_on_bit at ffffffff814dbcd8
     #4 [ffff8810343bf488] nfs_commit_inode at ffffffffa039e0c1 [nfs]
     #5 [ffff8810343bf4f8] nfs_release_page at ffffffffa038bef6 [nfs]
     #6 [ffff8810343bf528] try_to_release_page at ffffffff8110c670
     #7 [ffff8810343bf538] shrink_page_list.clone.0 at ffffffff81126271
     #8 [ffff8810343bf668] shrink_inactive_list at ffffffff81126638
     #9 [ffff8810343bf818] shrink_zone at ffffffff8112788f
    #10 [ffff8810343bf8c8] do_try_to_free_pages at ffffffff81127b1e
    #11 [ffff8810343bf958] try_to_free_pages at ffffffff8112812f
    #12 [ffff8810343bfa08] __alloc_pages_nodemask at ffffffff8111fdad
    #13 [ffff8810343bfb28] kmem_getpages at ffffffff81159942
    #14 [ffff8810343bfb58] fallback_alloc at ffffffff8115a55a
    #15 [ffff8810343bfbd8] ____cache_alloc_node at ffffffff8115a2d9
    #16 [ffff8810343bfc38] kmem_cache_alloc at ffffffff8115b09b
    #17 [ffff8810343bfc78] sk_prot_alloc at ffffffff81411808
    #18 [ffff8810343bfcb8] sk_alloc at ffffffff8141197c
    #19 [ffff8810343bfce8] inet_create at ffffffff81483ba6
    #20 [ffff8810343bfd38] __sock_create at ffffffff8140b4a7
    #21 [ffff8810343bfd98] xs_create_sock at ffffffffa01f649b [sunrpc]
    #22 [ffff8810343bfdd8] xs_tcp_setup_socket at ffffffffa01f6965 [sunrpc]
    #23 [ffff8810343bfe38] worker_thread at ffffffff810887d0
    #24 [ffff8810343bfee8] kthread at ffffffff8108dd96
    #25 [ffff8810343bff48] kernel_thread at ffffffff8100c1ca

rpciod is trying to allocate memory for a new socket to talk to the
server. The VM ends up calling ->releasepage to get more memory, and it
tries to do a blocking commit. That commit can't succeed however without
a connected socket, so we deadlock.

Fix this by setting PF_FSTRANS on the workqueue task prior to doing the
socket allocation, and having nfs_release_page check for that flag when
deciding whether to do a commit call. Also, set PF_FSTRANS
unconditionally in rpc_async_schedule since that function can also do
allocations sometimes.

Signed-off-by: Jeff Layton <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
9 years agos390/mm: fix fault handling for page table walk case
Heiko Carstens [Fri, 27 Jul 2012 07:45:39 +0000 (09:45 +0200)]
s390/mm: fix fault handling for page table walk case

commit 008c2e8f247f0a8db1e8e26139da12f3a3abcda0 upstream.

Make sure the kernel does not incorrectly create a SIGBUS signal during
user space accesses:

For user space accesses in the switched addressing mode case the kernel
may walk page tables and access user address space via the kernel
mapping. If a page table entry is invalid the function __handle_fault()
gets called in order to emulate a page fault and trigger all the usual
actions like paging in a missing page etc. by calling handle_mm_fault().

If handle_mm_fault() returns with an error fixup handling is necessary.
For the switched addressing mode case all errors need to be mapped to
-EFAULT, so that the calling uaccess function can return -EFAULT to
user space.

Unfortunately the __handle_fault() incorrectly calls do_sigbus() if
VM_FAULT_SIGBUS is set. This however should only happen if a page fault
was triggered by a user space instruction. For kernel mode uaccesses
the correct action is to only return -EFAULT.
So user space may incorrectly see SIGBUS signals because of this bug.

For current machines this would only be possible for the switched
addressing mode case in conjunction with futex operations.

Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: do_exception() and do_sigbus() parameters differ]
Signed-off-by: Ben Hutchings <>
9 years agovirtio-blk: Use block layer provided spinlock
Asias He [Fri, 25 May 2012 08:03:27 +0000 (16:03 +0800)]
virtio-blk: Use block layer provided spinlock

commit 2c95a3290919541b846bee3e0fbaa75860929f53 upstream.

Block layer will allocate a spinlock for the queue if the driver does
not provide one in blk_init_queue().

The reason to use the internal spinlock is that blk_cleanup_queue() will
switch to use the internal spinlock in the cleanup code path.

        if (q->queue_lock != &q->__queue_lock)
                q->queue_lock = &q->__queue_lock;

However, processes which are in D state might have taken the driver
provided spinlock, when the processes wake up, they would release the
block provided spinlock.

[ BUG: bad unlock balance detected! ]
3.4.0-rc7+ #238 Not tainted
fio/3587 is trying to release lock (&(&q->__queue_lock)->rlock) at:
[<ffffffff813274d2>] blk_queue_bio+0x2a2/0x380
but there are no more locks to release!

other info that might help us debug this:
1 lock held by fio/3587:
 #0:  (&(&vblk->lock)->rlock){......}, at:
[<ffffffff8132661a>] get_request_wait+0x19a/0x250

Other drivers use block layer provided spinlock as well, e.g. SCSI.

Switching to the block layer provided spinlock saves a bit of memory and
does not increase lock contention. Performance test shows no real
difference is observed before and after this patch.

Changes in v2: Improve commit log as Michael suggested.

Signed-off-by: Asias He <>
Acked-by: Michael S. Tsirkin <>
Signed-off-by: Rusty Russell <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoasus-wmi: use ASUS_WMI_METHODID_DSTS2 as default DSTS ID.
Alex Hung [Wed, 20 Jun 2012 03:47:35 +0000 (11:47 +0800)]
asus-wmi: use ASUS_WMI_METHODID_DSTS2 as default DSTS ID.

commit 63a78bb1051b240417daad3a3fa9c1bb10646dca upstream.

According to responses from the BIOS team, ASUS_WMI_METHODID_DSTS2
(0x53545344) will be used as future DSTS ID. In addition, calling
asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS2, 0, 0, NULL) returns
ASUS_WMI_UNSUPPORTED_METHOD in new ASUS laptop PCs. This patch fixes
no DSTS ID will be assigned in this case.

Signed-off-by: Alex Hung <>
Signed-off-by: Matthew Garrett <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: mix in architectural randomness in extract_buf()
H. Peter Anvin [Sat, 28 Jul 2012 02:26:08 +0000 (22:26 -0400)]
random: mix in architectural randomness in extract_buf()

commit d2e7c96af1e54b507ae2a6a7dd2baf588417a7e5 upstream.

Mix in any architectural randomness in extract_buf() instead of
xfer_secondary_buf().  This allows us to mix in more architectural
randomness, and it also makes xfer_secondary_buf() faster, moving a
tiny bit of additional CPU overhead to process which is extracting the

[ Commit description modified by tytso to remove an extended
  advertisement for the RDRAND instruction. ]

Signed-off-by: H. Peter Anvin <>
Acked-by: Ingo Molnar <>
Cc: DJ Johnston <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
9 years agodm thin: fix memory leak in process_prepared_mapping error paths
Joe Thornber [Fri, 27 Jul 2012 14:08:05 +0000 (15:08 +0100)]
dm thin: fix memory leak in process_prepared_mapping error paths

commit 905386f82d08f66726912f303f3e6605248c60a3 upstream.

Fix memory leak in process_prepared_mapping by always freeing
the dm_thin_new_mapping structs from the mapping_pool mempool on
the error paths.

Signed-off-by: Joe Thornber <>
Signed-off-by: Mike Snitzer <>
Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Ben Hutchings <>
9 years agodm thin: reduce endio_hook pool size
Alasdair G Kergon [Fri, 27 Jul 2012 14:07:57 +0000 (15:07 +0100)]
dm thin: reduce endio_hook pool size

commit 7768ed33ccdc02801c4483fc5682dc66ace14aea upstream.

Reduce the slab size used for the dm_thin_endio_hook mempool.

Allocation has been seen to fail on machines with smaller amounts
of memory due to fragmentation.

  lvm: page allocation failure. order:5, mode:0xd0
  device-mapper: table: 253:38: thin-pool: Error creating pool's endio_hook mempool

Signed-off-by: Alasdair G Kergon <>
Signed-off-by: Ben Hutchings <>
9 years agoRedefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
Tony Luck [Thu, 26 Jul 2012 17:55:26 +0000 (10:55 -0700)]
Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

commit a119365586b0130dfea06457f584953e0ff6481d upstream.

The following build error occured during a ia64 build with
swap-over-NFS patches applied.

net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
net/core/sock.c:274:36: error: initializer element is not constant

This is identical to a parisc build error. Fengguang Wu, Mel Gorman
and James Bottomley did all the legwork to track the root cause of
the problem. This fix and entire commit log is shamelessly copied
from them with one extra detail to change a dubious runtime use of
ATOMIC_INIT() to atomic_set() in drivers/char/mspec.c

Dave Anglin says:
> Here is the line in sock.i:
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Signed-off-by: Tony Luck <>
Signed-off-by: Ben Hutchings <>
9 years agos390/mm: downgrade page table after fork of a 31 bit process
Martin Schwidefsky [Thu, 26 Jul 2012 06:53:06 +0000 (08:53 +0200)]
s390/mm: downgrade page table after fork of a 31 bit process

commit 0f6f281b731d20bfe75c13f85d33f3f05b440222 upstream.

The downgrade of the 4 level page table created by init_new_context is
currently done only in start_thread31. If a 31 bit process forks the
new mm uses a 4 level page table, including the task size of 2<<42
that goes along with it. This is incorrect as now a 31 bit process
can map memory beyond 2GB. Define arch_dup_mmap to do the downgrade
after fork.

Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agox86, nops: Missing break resulting in incorrect selection on Intel
Alan Cox [Wed, 25 Jul 2012 15:28:19 +0000 (16:28 +0100)]
x86, nops: Missing break resulting in incorrect selection on Intel

commit d6250a3f12edb3a86db9598ffeca3de8b4a219e9 upstream.

The Intel case falls through into the generic case which then changes
the values.  For cases like the P6 it doesn't do the right thing so
this seems to be a screwup.

Signed-off-by: Alan Cox <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: mpu401: Fix missing initialization of irq field
Takashi Iwai [Mon, 23 Jul 2012 09:35:55 +0000 (11:35 +0200)]
ALSA: mpu401: Fix missing initialization of irq field

commit bc733d495267a23ef8660220d696c6e549ce30b3 upstream.

The irq field of struct snd_mpu401 is supposed to be initialized to -1.
Since it's set to zero as of now, a probing error before the irq
installation results in a kernel warning "Trying to free already-free
IRQ 0".

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: hda - Fix invalid D3 of headphone DAC on VT202x codecs
Takashi Iwai [Wed, 25 Jul 2012 11:54:55 +0000 (13:54 +0200)]
ALSA: hda - Fix invalid D3 of headphone DAC on VT202x codecs

commit 6162552b0de6ba80937c3dd53e084967851cd199 upstream.

We've got a bug report about the silent output from the headphone on a
mobo with VT2021, and spotted out that this was because of the wrong
D3 state on the DAC for the headphone output.  The bug is triggered by
the incomplete check for this DAC in set_widgets_power_state_vt1718S().
It checks only the connectivity of the primary output (0x27) but
doesn't consider the path from the headphone pin (0x28).

Now this patch fixes the problem by checking both pins for DAC 0x0b.

Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2: keep using snd_hda_codec_write() as
 update_power_state() is missing]
Signed-off-by: Ben Hutchings <>
9 years agoInput: synaptics - handle out of bounds values from the hardware
Seth Forshee [Wed, 25 Jul 2012 06:54:11 +0000 (23:54 -0700)]
Input: synaptics - handle out of bounds values from the hardware

commit c0394506e69b37c47d391c2a7bbea3ea236d8ec8 upstream.

The touchpad on the Acer Aspire One D250 will report out of range values
in the extreme lower portion of the touchpad. These appear as abrupt
changes in the values reported by the hardware from very low values to
very high values, which can cause unexpected vertical jumps in the
position of the mouse pointer.

What seems to be happening is that the value is wrapping to a two's
compliment negative value of higher resolution than the 13-bit value
reported by the hardware, with the high-order bits being truncated. This
patch adds handling for these values by converting them to the
appropriate negative values.

The only tricky part about this is deciding when to treat a number as
negative. It stands to reason that if out of range values can be
reported on the low end then it could also happen on the high end, so
not all out of range values should be treated as negative. The approach
taken here is to split the difference between the maximum legitimate
value for the axis and the maximum possible value that the hardware can
report, treating values greater than this number as negative and all
other values as positive. This can be tweaked later if hardware is found
that operates outside of these parameters.

Signed-off-by: Seth Forshee <>
Reviewed-by: Daniel Kurtz <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agovideo/smscufx: fix line counting in fb_write
Alexander Holler [Fri, 20 Apr 2012 22:11:07 +0000 (00:11 +0200)]
video/smscufx: fix line counting in fb_write

commit 2fe2d9f47cfe1a3e66e7d087368b3d7155b04c15 upstream.

Line 0 and 1 were both written to line 0 (on the display) and all subsequent
lines had an offset of -1. The result was that the last line on the display
was never overwritten by writes to /dev/fbN.

The origin of this bug seems to have been udlfb.

Signed-off-by: Alexander Holler <>
Signed-off-by: Florian Tobias Schandinat <>
Signed-off-by: Ben Hutchings <>
9 years agofutex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()
Darren Hart [Fri, 20 Jul 2012 18:53:31 +0000 (11:53 -0700)]
futex: Forbid uaddr == uaddr2 in futex_wait_requeue_pi()

commit 6f7b0a2a5c0fb03be7c25bd1745baa50582348ef upstream.

If uaddr == uaddr2, then we have broken the rule of only requeueing
from a non-pi futex to a pi futex with this call. If we attempt this,
as the trinity test suite manages to do, we miss early wakeups as
q.key is equal to key2 (because they are the same uaddr). We will then
attempt to dereference the pi_mutex (which would exist had the futex_q
been properly requeued to a pi futex) and trigger a NULL pointer

Signed-off-by: Darren Hart <>
Cc: Dave Jones <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
9 years agofutex: Fix bug in WARN_ON for NULL q.pi_state
Darren Hart [Fri, 20 Jul 2012 18:53:30 +0000 (11:53 -0700)]
futex: Fix bug in WARN_ON for NULL q.pi_state

commit f27071cb7fe3e1d37a9dbe6c0dfc5395cd40fa43 upstream.

The WARN_ON in futex_wait_requeue_pi() for a NULL q.pi_state was testing
the address (&q.pi_state) of the pointer instead of the value
(q.pi_state) of the pointer. Correct it accordingly.

Signed-off-by: Darren Hart <>
Cc: Dave Jones <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
9 years agofutex: Test for pi_mutex on fault in futex_wait_requeue_pi()
Darren Hart [Fri, 20 Jul 2012 18:53:29 +0000 (11:53 -0700)]
futex: Test for pi_mutex on fault in futex_wait_requeue_pi()

commit b6070a8d9853eda010a549fa9a09eb8d7269b929 upstream.

If fixup_pi_state_owner() faults, pi_mutex may be NULL. Test
for pi_mutex != NULL before testing the owner against current
and possibly unlocking it.

Signed-off-by: Darren Hart <>
Cc: Dave Jones <>
Cc: Dan Carpenter <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
9 years agoASoC: wm8994: Ensure there are enough BCLKs for four channels
Mark Brown [Fri, 22 Jun 2012 16:21:17 +0000 (17:21 +0100)]
ASoC: wm8994: Ensure there are enough BCLKs for four channels

commit b8edf3e5522735c8ce78b81845f7a1a2d4a08626 upstream.

Otherwise if someone tries to use all four channels on AIF1 with the
device in master mode we won't be able to clock out all the data.

Signed-off-by: Mark Brown <>
Signed-off-by: Ben Hutchings <>
9 years agomfd: wm831x: Feed the device UUID into device_add_randomness()
Mark Brown [Thu, 5 Jul 2012 20:23:21 +0000 (20:23 +0000)]
mfd: wm831x: Feed the device UUID into device_add_randomness()

commit 27130f0cc3ab97560384da437e4621fc4e94f21c upstream.

wm831x devices contain a unique ID value. Feed this into the newly added
device_add_randomness() to add some per device seed data to the pool.

Signed-off-by: Mark Brown <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
9 years agortc: wm831x: Feed the write counter into device_add_randomness()
Mark Brown [Thu, 5 Jul 2012 20:19:17 +0000 (20:19 +0000)]
rtc: wm831x: Feed the write counter into device_add_randomness()

commit 9dccf55f4cb011a7552a8a2749a580662f5ed8ed upstream.

The tamper evident features of the RTC include the "write counter" which
is a pseudo-random number regenerated whenever we set the RTC. Since this
value is unpredictable it should provide some useful seeding to the random
number generator.

Only do this on boot since the goal is to seed the pool rather than add
useful entropy.

Signed-off-by: Mark Brown <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: add new get_random_bytes_arch() function
Theodore Ts'o [Thu, 5 Jul 2012 14:35:23 +0000 (10:35 -0400)]
random: add new get_random_bytes_arch() function

commit c2557a303ab6712bb6e09447df828c557c710ac9 upstream.

Create a new function, get_random_bytes_arch() which will use the
architecture-specific hardware random number generator if it is
present.  Change get_random_bytes() to not use the HW RNG, even if it
is avaiable.

The reason for this is that the hw random number generator is fast (if
it is present), but it requires that we trust the hardware
manufacturer to have not put in a back door.  (For example, an
increasing counter encrypted by an AES key known to the NSA.)

It's unlikely that Intel (for example) was paid off by the US
Government to do this, but it's impossible for them to prove otherwise

9 years agorandom: use the arch-specific rng in xfer_secondary_pool
Theodore Ts'o [Thu, 5 Jul 2012 14:21:01 +0000 (10:21 -0400)]
random: use the arch-specific rng in xfer_secondary_pool

commit e6d4947b12e8ad947add1032dd754803c6004824 upstream.

If the CPU supports a hardware random number generator, use it in
xfer_secondary_pool(), where it will significantly improve things and
where we can afford it.

Also, remove the use of the arch-specific rng in
add_timer_randomness(), since the call is significantly slower than
get_cycles(), and we're much better off using it in
xfer_secondary_pool() anyway.

Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agonet: feed /dev/random with the MAC address when registering a device
Theodore Ts'o [Thu, 5 Jul 2012 01:23:25 +0000 (21:23 -0400)]
net: feed /dev/random with the MAC address when registering a device

commit 7bf2357524408b97fec58344caf7397f8140c3fd upstream.

Cc: David Miller <>
Cc: Linus Torvalds <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agousb: feed USB device information to the /dev/random driver
Theodore Ts'o [Wed, 4 Jul 2012 15:22:20 +0000 (11:22 -0400)]
usb: feed USB device information to the /dev/random driver

commit b04b3156a20d395a7faa8eed98698d1e17a36000 upstream.

Send the USB device's serial, product, and manufacturer strings to the
/dev/random driver to help seed its pools.

Cc: Linus Torvalds <>
Acked-by: Greg KH <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: create add_device_randomness() interface
Linus Torvalds [Wed, 4 Jul 2012 15:16:01 +0000 (11:16 -0400)]
random: create add_device_randomness() interface

commit a2080a67abe9e314f9e9c2cc3a4a176e8a8f8793 upstream.

Add a new interface, add_device_randomness() for adding data to the
random pool that is likely to differ between two devices (or possibly
even per boot).  This would be things like MAC addresses or serial
numbers, or the read-out of the RTC. This does *not* add any actual
entropy to the pool, but it initializes the pool to different values
for devices that might otherwise be identical and have very little
entropy available to them (particularly common in the embedded world).

[ Modified by tytso to mix in a timestamp, since there may be some
  variability caused by the time needed to detect/configure the hardware
  in question. ]

Signed-off-by: Linus Torvalds <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: use lockless techniques in the interrupt path
Theodore Ts'o [Wed, 4 Jul 2012 14:38:30 +0000 (10:38 -0400)]
random: use lockless techniques in the interrupt path

commit 902c098a3663de3fa18639efbb71b6080f0bcd3c upstream.

The real-time Linux folks don't like add_interrupt_randomness() taking
a spinlock since it is called in the low-level interrupt routine.
This also allows us to reduce the overhead in the fast path, for the
random driver, which is the interrupt collection path.

Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: make 'add_interrupt_randomness()' do something sane
Theodore Ts'o [Mon, 2 Jul 2012 11:52:16 +0000 (07:52 -0400)]
random: make 'add_interrupt_randomness()' do something sane

commit 775f4b297b780601e61787b766f306ed3e1d23eb upstream.

We've been moving away from add_interrupt_randomness() for various
reasons: it's too expensive to do on every interrupt, and flooding the
CPU with interrupts could theoretically cause bogus floods of entropy
from a somewhat externally controllable source.

This solves both problems by limiting the actual randomness addition
to just once a second or after 64 interrupts, whicever comes first.
During that time, the interrupt cycle data is buffered up in a per-cpu
pool.  Also, we make sure the the nonblocking pool used by urandom is
initialized before we start feeding the normal input pool.  This
assures that /dev/urandom is returning unpredictable data as soon as

(Based on an original patch by Linus, but significantly modified by

Tested-by: Eric Wustrow <>
Reported-by: Eric Wustrow <>
Reported-by: Nadia Heninger <>
Reported-by: Zakir Durumeric <>
Reported-by: J. Alex Halderman <>.
Signed-off-by: Linus Torvalds <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: Adjust the number of loops when initializing
H. Peter Anvin [Mon, 16 Jan 2012 19:23:29 +0000 (11:23 -0800)]
random: Adjust the number of loops when initializing

commit 2dac8e54f988ab58525505d7ef982493374433c3 upstream.

When we are initializing using arch_get_random_long() we only need to
loop enough times to touch all the bytes in the buffer; using
poolwords for that does twice the number of operations necessary on a
64-bit machine, since in the random number generator code "word" means
32 bits.

Signed-off-by: H. Peter Anvin <>
Cc: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: Use arch-specific RNG to initialize the entropy store
Theodore Ts'o [Thu, 22 Dec 2011 21:28:01 +0000 (16:28 -0500)]
random: Use arch-specific RNG to initialize the entropy store

commit 3e88bdff1c65145f7ba297ccec69c774afe4c785 upstream.

If there is an architecture-specific random number generator (such as
RDRAND for Intel architectures), use it to initialize /dev/random's
entropy stores.  Even in the worst case, if RDRAND is something like
AES(NSA_KEY, counter++), it won't hurt, and it will definitely help
against any other adversaries.

Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: Use arch_get_random_int instead of cycle counter if avail
Linus Torvalds [Thu, 22 Dec 2011 19:36:22 +0000 (11:36 -0800)]
random: Use arch_get_random_int instead of cycle counter if avail

commit cf833d0b9937874b50ef2867c4e8badfd64948ce upstream.

We still don't use rdrand in /dev/random, which just seems stupid. We
accept the *cycle*counter* as a random input, but we don't accept
rdrand? That's just broken.

Sure, people can do things in user space (write to /dev/random, use
rdrand in addition to /dev/random themselves etc etc), but that
*still* seems to be a particularly stupid reason for saying "we
shouldn't bother to try to do better in /dev/random".

And even if somebody really doesn't trust rdrand as a source of random
bytes, it seems singularly stupid to trust the cycle counter *more*.

So I'd suggest the attached patch. I'm not going to even bother
arguing that we should add more bits to the entropy estimate, because
that's not the point - I don't care if /dev/random fills up slowly or
not, I think it's just stupid to not use the bits we can get from
rdrand and mix them into the strong randomness pool.

Acked-by: "David S. Miller" <>
Acked-by: "Theodore Ts'o" <>
Acked-by: Herbert Xu <>
Cc: Matt Mackall <>
Cc: Tony Luck <>
Cc: Eric Dumazet <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
9 years agonfsd4: our filesystems are normally case sensitive
J. Bruce Fields [Tue, 5 Jun 2012 20:52:06 +0000 (16:52 -0400)]
nfsd4: our filesystems are normally case sensitive

commit 2930d381d22b9c56f40dd4c63a8fa59719ca2c3c upstream.

Actually, xfs and jfs can optionally be case insensitive; we'll handle
that case in later patches.

Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
9 years agoene_ir: Fix driver initialisation
Luis Henriques [Tue, 19 Jun 2012 14:29:49 +0000 (11:29 -0300)]
ene_ir: Fix driver initialisation

commit b31b021988fed9e3741a46918f14ba9b063811db upstream.

commit 9ef449c6b31bb6a8e6dedc24de475a3b8c79be20 ("[media] rc: Postpone ISR
registration") fixed an early ISR registration on several drivers.  It did
however also introduced a bug by moving the invocation of pnp_port_start()
to the end of the probe function.

This patch fixes this issue by moving the invocation of pnp_port_start() to
an earlier stage in the probe function.

Cc: Jarod Wilson <>
Signed-off-by: Luis Henriques <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
9 years agom68k: Correct the Atari ALLOWINT definition
Mikael Pettersson [Wed, 18 Apr 2012 22:53:36 +0000 (00:53 +0200)]
m68k: Correct the Atari ALLOWINT definition

commit c663600584a596b5e66258cc10716fb781a5c2c9 upstream.

Booting a 3.2, 3.3, or 3.4-rc4 kernel on an Atari using the
`nfeth' ethernet device triggers a WARN_ONCE() in generic irq
handling code on the first irq for that device:

WARNING: at kernel/irq/handle.c:146 handle_irq_event_percpu+0x134/0x142()
irq 3 handler nfeth_interrupt+0x0/0x194 enabled interrupts
Modules linked in:
Call Trace: [<000299b2>] warn_slowpath_common+0x48/0x6a
 [<000299c0>] warn_slowpath_common+0x56/0x6a
 [<00029a4c>] warn_slowpath_fmt+0x2a/0x32
 [<0005b34c>] handle_irq_event_percpu+0x134/0x142
 [<0005b34c>] handle_irq_event_percpu+0x134/0x142
 [<0000a584>] nfeth_interrupt+0x0/0x194
 [<001ba0a8>] schedule_preempt_disabled+0x0/0xc
 [<0005b37a>] handle_irq_event+0x20/0x2c
 [<0005add4>] generic_handle_irq+0x2c/0x3a
 [<00002ab6>] do_IRQ+0x20/0x32
 [<0000289e>] auto_irqhandler_fixup+0x4/0x6
 [<00003144>] cpu_idle+0x22/0x2e
 [<001b8a78>] printk+0x0/0x18
 [<0024d112>] start_kernel+0x37a/0x386
 [<0003021d>] __do_proc_dointvec+0xb1/0x366
 [<0003021d>] __do_proc_dointvec+0xb1/0x366
 [<0024c31e>] _sinittext+0x31e/0x9c0

After invoking the irq's handler the kernel sees !irqs_disabled()
and concludes that the handler erroneously enabled interrupts.

However, debugging shows that !irqs_disabled() is true even before
the handler is invoked, which indicates a problem in the platform
code rather than the specific driver.

The warning does not occur in 3.1 or older kernels.

It turns out that the ALLOWINT definition for Atari is incorrect.

The Atari definition of ALLOWINT is ~0x400, the stated purpose of
that is to avoid taking HSYNC interrupts.  irqs_disabled() returns
true if the 3-bit ipl & 4 is non-zero.  The nfeth interrupt runs at
ipl 3 (it's autovector 3), but 3 & 4 is zero so irqs_disabled() is
false, and the warning above is generated.

When interrupts are explicitly disabled, ipl is set to 7.  When they
are enabled, ipl is masked with ALLOWINT.  On Atari this will result
in ipl = 3, which blocks interrupts at ipl 3 and below.  So how come
nfeth interrupts at ipl 3 are received at all?  That's because ipl
is reset to 2 by Atari-specific code in default_idle(), again with
the stated purpose of blocking HSYNC interrupts.  This discrepancy
means that ipl 3 can remain blocked for longer than intended.

Both default_idle() and falcon_hblhandler() identify HSYNC with
ipl 2, and the "Atari ST/.../F030 Hardware Register Listing" agrees,
but ALLOWINT is defined as if HSYNC was ipl 3.

[As an experiment I modified default_idle() to reset ipl to 3, and
as expected that resulted in all nfeth interrupts being blocked.]

The fix is simple: define ALLOWINT as ~0x500 instead.  This makes
arch_local_irq_enable() consistent with default_idle(), and prevents
the !irqs_disabled() problems for ipl 3 interrupts.

Tested on Atari running in an Aranym VM.

Signed-off-by: Mikael Pettersson <>
Tested-by: Michael Schmitz <> (on Falcon/CT60)
[Geert Uytterhoeven: This version applies to v3.2..v3.4.]
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Ben Hutchings <>
9 years agocfg80211: fix interface combinations check for ADHOC(IBSS)
Liang Li [Thu, 2 Aug 2012 22:55:41 +0000 (18:55 -0400)]
cfg80211: fix interface combinations check for ADHOC(IBSS)

partial of commit 8e8b41f9d8c8e63fc92f899ace8da91a490ac573 upstream.

As part of commit 463454b5dbd8 ("cfg80211: fix interface
combinations check"), this extra check was introduced:

       if ((all_iftypes & used_iftypes) != used_iftypes)
               goto cont;

However, most wireless NIC drivers did not advertise ADHOC in
wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
when we bring up a ADHOC wlan with commands similar to:

 # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up

In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
combinations"), the change below fixes the issue:

       if (total == 1)
               return 0;

But it also introduces other dependencies for stable. For example,
a full cherry pick of 8e8b41f9d8c8e would introduce additional
regressions unless we also start cherry picking driver specific
fixes like the following:

  9b4760e  ath5k: add possible wiphy interface combinations
  1ae2fc2  mac80211_hwsim: advertise interface combinations
  20c8e8d  ath9k: add possible wiphy interface combinations

And the purpose of the 'if (total == 1)' is to cover the specific
use case (IBSS, adhoc) that was mentioned above. So we just pick
the specific part out from 8e8b41f9d8c8e here.

Doing so gives stable kernels a way to fix the change introduced
by 463454b5dbd8, without having to make cherry picks specific to
various NIC drivers.

Signed-off-by: Liang Li <>
Signed-off-by: Paul Gortmaker <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: hda - add dock support for Thinkpad X230 Tablet
David Henningsson [Fri, 20 Jul 2012 08:37:25 +0000 (10:37 +0200)]
ALSA: hda - add dock support for Thinkpad X230 Tablet

commit 108cc108a3bb42fe4705df1317ff98e1e29428a6 upstream.

Also add a model/fixup string "lenovo-dock", so that other Thinkpad
users will be able to test this fixup easily, to see if it enables
dock I/O for them as well.

Tested-by: John McCarron <>
Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agostable: update references to older 2.6 versions for 3.x
Paul Gortmaker [Tue, 5 Jun 2012 15:15:50 +0000 (11:15 -0400)]
stable: update references to older 2.6 versions for 3.x

commit 2584f5212d97b664be250ad5700a2d0fee31a10d upstream.

Also add information on where the respective trees are.

Signed-off-by: Paul Gortmaker <>
Acked-by: Rob Landley <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agolirc_sir: make device registration work
Jarod Wilson [Mon, 4 Jun 2012 16:05:24 +0000 (13:05 -0300)]
lirc_sir: make device registration work

commit 4b71ca6bce8fab3d08c61bf330e781f957934ae1 upstream.

For one, the driver device pointer needs to be filled in, or the lirc core
will refuse to load the driver. And we really need to wire up all the
platform_device bits. This has been tested via the lirc sourceforge tree
and verified to work, been sitting there for months, finally getting
around to sending it. :\

CC: Josh Boyer <>
Signed-off-by: Jarod Wilson <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
9 years agoxen: mark local pages as FOREIGN in the m2p_override
Stefano Stabellini [Wed, 23 May 2012 17:57:20 +0000 (18:57 +0100)]
xen: mark local pages as FOREIGN in the m2p_override

commit b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f upstream.

When the frontend and the backend reside on the same domain, even if we
add pages to the m2p_override, these pages will never be returned by
mfn_to_pfn because the check "get_phys_to_machine(pfn) != mfn" will
always fail, so the pfn of the frontend will be returned instead
(resulting in a deadlock because the frontend pages are already locked).

INFO: task qemu-system-i38:1085 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
qemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000
 ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0
 ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0
 ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0
Call Trace:
 [<ffffffff81101ee0>] ? __lock_page+0x70/0x70
 [<ffffffff81a0fdd9>] schedule+0x29/0x70
 [<ffffffff81a0fe80>] io_schedule+0x60/0x80
 [<ffffffff81101eee>] sleep_on_page+0xe/0x20
 [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0
 [<ffffffff81101ed7>] __lock_page+0x67/0x70
 [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40
 [<ffffffff811867e6>] ? bio_add_page+0x36/0x40
 [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60
 [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70
 [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0
 [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
 [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60
 [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
 [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390
 [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00
 [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0
 [<ffffffff81104027>] generic_file_aio_read+0x737/0x780
 [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0
 [<ffffffff811038f0>] ? find_get_pages+0x150/0x150
 [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0
 [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90
 [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0
 [<ffffffff811998b8>] do_io_submit+0x708/0xb90
 [<ffffffff81199d50>] sys_io_submit+0x10/0x20
 [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b

The explanation is in the comment within the code:

We need to do this because the pages shared by the frontend
(xen-blkfront) can be already locked (lock_page, called by
do_read_cache_page); when the userspace backend tries to use them
with direct_IO, mfn_to_pfn returns the pfn of the frontend, so
do_blockdev_direct_IO is going to try to lock the same pages
again resulting in a deadlock.

A simplified call graph looks like this:

pygrub                          QEMU
do_read_cache_page              io_submit
  |                              |
lock_page                       ext3_direct_IO

Internally the xen-blkback uses m2p_add_override to swizzle (temporarily)
a 'struct page' to have a different MFN (so that it can point to another
guest). It also can easily find out whether another pfn corresponding
to the mfn exists in the m2p, and can set the FOREIGN bit
in the p2m, making sure that mfn_to_pfn returns the pfn of the backend.

This allows the backend to perform direct_IO on these pages, but as a
side effect prevents the frontend from using get_user_pages_fast on
them while they are being shared with the backend.

Signed-off-by: Stefano Stabellini <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
9 years agofloppy: Cleanup disk->queue before caling put_disk() if add_disk() was never called
Vivek Goyal [Wed, 8 Feb 2012 19:03:38 +0000 (20:03 +0100)]
floppy: Cleanup disk->queue before caling put_disk() if add_disk() was never called

commit 3f9a5aabd0a9fe0e0cd308506f48963d79169aa7 upstream.

add_disk() takes gendisk reference on request queue. If driver failed during
initialization and never called add_disk() then that extra reference is not
taken. That reference is put in put_disk(). floppy driver allocates the
disk, allocates queue, sets disk->queue and then relizes that floppy
controller is not present. It tries to tear down everything and tries to
put a reference down in put_disk() which was never taken.

In such error cases cleanup disk->queue before calling put_disk() so that
we never try to put down a reference which was never taken in first place.

Reported-and-tested-by: Suresh Jayaraman <>
Tested-by: Dirk Gouders <>
Signed-off-by: Vivek Goyal <>
Acked-by: Tejun Heo <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
9 years agosched: Fix race in task_group()
Peter Zijlstra [Fri, 22 Jun 2012 11:36:05 +0000 (13:36 +0200)]
sched: Fix race in task_group()

commit 8323f26ce3425460769605a6aece7a174edaa7d1 upstream

Stefan reported a crash on a kernel before a3e5d1091c1 ("sched:
Don't call task_group() too many times in set_task_rq()"), he
found the reason to be that the multiple task_group()
invocations in set_task_rq() returned different values.

Looking at all that I found a lack of serialization and plain
wrong comments.

The below tries to fix it using an extra pointer which is
updated under the appropriate scheduler locks. Its not pretty,
but I can't really see another way given how all the cgroup
stuff works.

Reported-and-tested-by: Stefan Bader <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
(backported to previous file names and layout)
Signed-off-by: Stefan Bader <>
Signed-off-by: Ben Hutchings <>
9 years agoLinux 3.2.26 v3.2.26
Ben Hutchings [Sat, 4 Aug 2012 15:31:19 +0000 (16:31 +0100)]
Linux 3.2.26

9 years agox86: Simplify code by removing a !SMP #ifdefs from 'struct cpuinfo_x86'
Kevin Winchester [Wed, 21 Dec 2011 00:52:22 +0000 (20:52 -0400)]
x86: Simplify code by removing a !SMP #ifdefs from 'struct cpuinfo_x86'

commit 141168c36cdee3ff23d9c7700b0edc47cb65479f and
commit 3f806e50981825fa56a7f1938f24c0680816be45 upstream.

Several fields in struct cpuinfo_x86 were not defined for the
!SMP case, likely to save space.  However, those fields still
have some meaning for UP, and keeping them allows some #ifdef
removal from other files.  The additional size of the UP kernel
from this change is not significant enough to worry about
keeping up the distinction:

   text    data     bss     dec     hex filename
4737168  506459  972040 6215667  5ed7f3 vmlinux.o.before
4737444  506459  972040 6215943  5ed907 vmlinux.o.after

for a difference of 276 bytes for an example UP config.

If someone wants those 276 bytes back badly then it should
be implemented in a cleaner way.

Signed-off-by: Kevin Winchester <>
Cc: Steffen Persvold <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Borislav Petkov <>
Signed-off-by: Ben Hutchings <>
9 years agoLinux 3.2.25 v3.2.25
Ben Hutchings [Thu, 2 Aug 2012 13:38:04 +0000 (14:38 +0100)]
Linux 3.2.25

9 years agomm: fix wrong argument of migrate_huge_pages() in soft_offline_huge_page()
Joonsoo Kim [Mon, 30 Jul 2012 21:39:04 +0000 (14:39 -0700)]
mm: fix wrong argument of migrate_huge_pages() in soft_offline_huge_page()

commit dc32f63453f56d07a1073a697dcd843dd3098c09 upstream.

Commit a6bc32b89922 ("mm: compaction: introduce sync-light migration for
use by compaction") changed the declaration of migrate_pages() and

But it missed changing the argument of migrate_huge_pages() in
soft_offline_huge_page().  In this case, we should call
migrate_huge_pages() with MIGRATE_SYNC.

Additionally, there is a mismatch between type the of argument and the
function declaration for migrate_pages().

Signed-off-by: Joonsoo Kim <>
Cc: Christoph Lameter <>
Cc: Mel Gorman <>
Acked-by: David Rientjes <>
Cc: "Aneesh Kumar K.V" <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agonouveau: Fix alignment requirements on src and dst addresses
Maarten Lankhorst [Mon, 4 Jun 2012 10:00:31 +0000 (12:00 +0200)]
nouveau: Fix alignment requirements on src and dst addresses

commit ce806a30470bcd846d148bf39d46de3ad7748228 upstream.

Linear copy works by adding the offset to the buffer address,
which may end up not being 16-byte aligned.

Some tests I've written for prime_pcopy show that the engine
allows this correctly, so the restriction on lowest 4 bits of
address can be lifted safely.

The comments added were by envyas, I think because I used
a newer version.

Signed-off-by: Maarten Lankhorst <>
[bwh: Backported to 3.2: no # prefixes in nva3_copy.fuc]
Signed-off-by: Ben Hutchings <>
9 years agoBtrfs: call the ordered free operation without any locks held
Chris Mason [Wed, 25 Jul 2012 19:57:13 +0000 (15:57 -0400)]
Btrfs: call the ordered free operation without any locks held

commit e9fbcb42201c862fd6ab45c48ead4f47bb2dea9d upstream.

Each ordered operation has a free callback, and this was called with the
worker spinlock held.  Josef made the free callback also call iput,
which we can't do with the spinlock.

This drops the spinlock for the free operation and grabs it again before
moving through the rest of the list.  We'll circle back around to this
and find a cleaner way that doesn't bounce the lock around so much.

Signed-off-by: Chris Mason <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: on hotplug force link training to happen (v2)
Jerome Glisse [Thu, 19 Jul 2012 21:25:55 +0000 (17:25 -0400)]
drm/radeon: on hotplug force link training to happen (v2)

commit ca2ccde5e2f24a792caa4cca919fc5c6f65d1887 upstream.

To have DP behave like VGA/DVI we need to retrain the link
on hotplug. For this to happen we need to force link
training to happen by setting connector dpms to off
before asking it turning it on again.

v2: agd5f
- drop the dp_get_link_status() change in atombios_dp.c
  for now.  We still need the dpms OFF change.

Signed-off-by: Jerome Glisse <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)
Jerome Glisse [Thu, 19 Jul 2012 21:15:56 +0000 (17:15 -0400)]
drm/radeon: fix hotplug of DP to DVI|HDMI passive adapters (v2)

commit 266dcba541a1ef7e5d82d9e67c67fde2910636e8 upstream.

No need to retrain the link for passive adapters.

v2: agd5f
- no passive DP to VGA adapters, update comments
- assign radeon_connector_atom_dig after we are sure
  we have a digital connector as analog connectors
  have different private data.
- get new sink type before checking for retrain.  No
  need to check if it's no longer a DP connection.

Signed-off-by: Jerome Glisse <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: fix non revealent error message
Jerome Glisse [Tue, 17 Jul 2012 21:17:16 +0000 (17:17 -0400)]
drm/radeon: fix non revealent error message

commit 8d1c702aa0b2c4b22b0742b72a1149d91690674b upstream.

We want to print link status query failed only if it's
an unexepected fail. If we query to see if we need
link training it might be because there is nothing
connected and thus link status query have the right
to fail in that case.

To avoid printing failure when it's expected, move the
failure message to proper place.

Signed-off-by: Jerome Glisse <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: fix bo creation retry path
Jerome Glisse [Thu, 12 Jul 2012 22:23:05 +0000 (18:23 -0400)]
drm/radeon: fix bo creation retry path

commit d1c7871ddb1f588b8eb35affd9ee1a3d5e11cd0c upstream.

Retry label was at wrong place in function leading to memory

Signed-off-by: Jerome Glisse <>
Reviewed-by: Michel Dänzer <>
Reviewed-by: Christian König <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoACPI/AC: prevent OOPS on some boxes due to missing check power_supply_register()...
Lan Tianyu [Fri, 20 Jul 2012 05:29:16 +0000 (13:29 +0800)]
ACPI/AC: prevent OOPS on some boxes due to missing check power_supply_register() return value check

commit f197ac13f6eeb351b31250b9ab7d0da17434ea36 upstream.

In the ac.c, power_supply_register()'s return value is not checked.

As a result, the driver's add() ops may return success
even though the device failed to initialize.

For example, some BIOS may describe two ACADs in the same DSDT.
The second ACAD device will fail to register,
but ACPI driver's add() ops returns sucessfully.
The ACPI device will receive ACPI notification and cause OOPS.

Signed-off-by: Lan Tianyu <>
Signed-off-by: Len Brown <>
Signed-off-by: Ben Hutchings <>
9 years agolocks: fix checking of fcntl_setlease argument
J. Bruce Fields [Mon, 23 Jul 2012 19:17:17 +0000 (15:17 -0400)]
locks: fix checking of fcntl_setlease argument

commit 0ec4f431eb56d633da3a55da67d5c4b88886ccc7 upstream.

The only checks of the long argument passed to fcntl(fd,F_SETLEASE,.)
are done after converting the long to an int.  Thus some illegal values
may be let through and cause problems in later code.

[ They actually *don't* cause problems in mainline, as of Dave Jones's
  commit 8d657eb3b438 "Remove easily user-triggerable BUG from
  generic_setlease", but we should fix this anyway.  And this patch will
  be necessary to fix real bugs on earlier kernels. ]

Signed-off-by: J. Bruce Fields <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agoASoC: dapm: Fix _PRE and _POST events for DAPM performance improvements
Mark Brown [Fri, 20 Jul 2012 16:29:34 +0000 (17:29 +0100)]
ASoC: dapm: Fix _PRE and _POST events for DAPM performance improvements

commit 0ff97ebf0804d2e519d578fcb4db03f104d2ca8c upstream.

Ever since the DAPM performance improvements we've been marking all widgets
as not dirty after each DAPM run. Since _PRE and _POST events aren't part
of the DAPM graph this has rendered them non-functional, they will never be
marked dirty again and thus will never be run again.

Fix this by skipping them when marking widgets as not dirty.

Signed-off-by: Mark Brown <>
Acked-by: Liam Girdwood <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: undo ext4_calc_metadata_amount if we fail to claim space
Theodore Ts'o [Mon, 23 Jul 2012 04:00:20 +0000 (00:00 -0400)]
ext4: undo ext4_calc_metadata_amount if we fail to claim space

commit 03179fe92318e7934c180d96f12eff2cb36ef7b6 upstream.

The function ext4_calc_metadata_amount() has side effects, although
it's not obvious from its function name.  So if we fail to claim
space, regardless of whether we retry to claim the space again, or
return an error, we need to undo these side effects.

Otherwise we can end up incorrectly calculating the number of metadata
blocks needed for the operation, which was responsible for an xfstests
failure for test #271 when using an ext2 file system with delalloc

Reported-by: Brian Foster <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: don't let i_reserved_meta_blocks go negative
Brian Foster [Mon, 23 Jul 2012 03:59:40 +0000 (23:59 -0400)]
ext4: don't let i_reserved_meta_blocks go negative

commit 97795d2a5b8d3c8dc4365d4bd3404191840453ba upstream.

If we hit a condition where we have allocated metadata blocks that
were not appropriately reserved, we risk underflow of
ei->i_reserved_meta_blocks.  In turn, this can throw
sbi->s_dirtyclusters_counter significantly out of whack and undermine
the nondelalloc fallback logic in ext4_nonda_switch().  Warn if this
occurs and set i_allocated_meta_blocks to avoid this problem.

This condition is reproduced by xfstests 270 against ext2 with
delalloc enabled:

Mar 28 08:58:02 localhost kernel: [  171.526344] EXT4-fs (loop1): delayed block allocation failed for inode 14 at logical offset 64486 with max blocks 64 with error -28
Mar 28 08:58:02 localhost kernel: [  171.526346] EXT4-fs (loop1): This should not happen!! Data will be lost

270 ultimately fails with an inconsistent filesystem and requires an
fsck to repair.  The cause of the error is an underflow in
ext4_da_update_reserve_space() due to an unreserved meta block

Signed-off-by: Brian Foster <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agommc: sdhci-pci: CaFe has broken card detection
Daniel Drake [Tue, 3 Jul 2012 22:13:39 +0000 (23:13 +0100)]
mmc: sdhci-pci: CaFe has broken card detection

commit 55fc05b7414274f17795cd0e8a3b1546f3649d5e upstream.

At we have determined that the
Marvell CaFe SDHCI controller reports bad card presence during
resume. It reports that no card is present even when it is.
This is a regression -- resume worked back around 2.6.37.

Around 400ms after resuming, a "card inserted" interrupt is
generated, at which point it starts reporting presence.

Work around this hardware oddity by setting the
Thanks to Chris Ball for helping with diagnosis.

Signed-off-by: Daniel Drake <>
[stable@: please apply to 3.0+]
Signed-off-by: Chris Ball <>
Signed-off-by: Ben Hutchings <>
9 years agoiscsi-target: Drop bogus struct file usage for iSCSI/SCTP
Al Viro [Sat, 21 Jul 2012 07:55:18 +0000 (08:55 +0100)]
iscsi-target: Drop bogus struct file usage for iSCSI/SCTP

commit bf6932f44a7b3fa7e2246a8b18a44670e5eab6c2 upstream.

From Al Viro:

BTW, speaking of struct file treatment related to sockets -
        there's this piece of code in iscsi:
         * The SCTP stack needs struct socket->file.
        if ((np->np_network_transport == ISCSI_SCTP_TCP) ||
            (np->np_network_transport == ISCSI_SCTP_UDP)) {
                if (!new_sock->file) {
                        new_sock->file = kzalloc(
                                        sizeof(struct file), GFP_KERNEL);

For one thing, as far as I can see it'not true - sctp does *not* depend on
socket->file being non-NULL; it does, in one place, check socket->file->f_flags
for O_NONBLOCK, but there it treats NULL socket->file as "flag not set".
Which is the case here anyway - the fake struct file created in
__iscsi_target_login_thread() (and in iscsi_target_setup_login_socket(), with
the same excuse) do *not* get that flag set.

Moreover, it's a bloody serious violation of a bunch of asserts in VFS;
all struct file instances should come from filp_cachep, via get_empty_filp()
(or alloc_file(), which is a wrapper for it).  FWIW, I'm very tempted to
do this and be done with the entire mess:

Signed-off-by: Al Viro <>
Cc: Andy Grover <>
Cc: Hannes Reinecke <>
Cc: Christoph Hellwig <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agolibsas: fix sas_discover_devices return code handling
Dan Williams [Fri, 22 Jun 2012 06:36:20 +0000 (23:36 -0700)]
libsas: fix sas_discover_devices return code handling

commit b17caa174a7e1fd2e17b26e210d4ee91c4c28b37 upstream.

commit 198439e4 [SCSI] libsas: do not set res = 0 in sas_ex_discover_dev()
commit 19252de6 [SCSI] libsas: fix wide port hotplug issues

The above commits seem to have confused the return value of
sas_ex_discover_dev which is non-zero on failure and
sas_ex_join_wide_port which just indicates short circuiting discovery on
already established ports.  The result is random discovery failures
depending on configuration.

Calls to sas_ex_join_wide_port are the source of the trouble as its
return value is errantly assigned to 'res'.  Convert it to bool and stop
returning its result up the stack.

Tested-by: Dan Melnic <>
Reported-by: Dan Melnic <>
Signed-off-by: Dan Williams <>
Reviewed-by: Jack Wang <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agolibsas: continue revalidation
Dan Williams [Fri, 22 Jun 2012 06:36:15 +0000 (23:36 -0700)]
libsas: continue revalidation

commit 26f2f199ff150d8876b2641c41e60d1c92d2fb81 upstream.

Continue running revalidation until no more broadcast devices are
discovered.  Fixes cases where re-discovery completes too early in a
domain with multiple expanders with pending re-discovery events.
Servicing BCNs can get backed up behind error recovery.

Signed-off-by: Dan Williams <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agofix eh wakeup (scsi_schedule_eh vs scsi_restart_operations)
Dan Williams [Fri, 22 Jun 2012 06:25:32 +0000 (23:25 -0700)]
fix eh wakeup (scsi_schedule_eh vs scsi_restart_operations)

commit 57fc2e335fd3c2f898ee73570dc81426c28dc7b4 upstream.

Rapid ata hotplug on a libsas controller results in cases where libsas
is waiting indefinitely on eh to perform an ata probe.

A race exists between scsi_schedule_eh() and scsi_restart_operations()
in the case when scsi_restart_operations() issues i/o to other devices
in the sas domain.  When this happens the host state transitions from
SHOST_RECOVERY (set by scsi_schedule_eh) back to SHOST_RUNNING and
->host_busy is non-zero so we put the eh thread to sleep even though
->host_eh_scheduled is active.

Before putting the error handler to sleep we need to check if the
host_state needs to return to SHOST_RECOVERY for another trip through
eh.  Since i/o that is released by scsi_restart_operations has been
blocked for at least one eh cycle, this implementation allows those
i/o's to run before another eh cycle starts to discourage hung task

Reported-by: Tom Jackson <>
Tested-by: Tom Jackson <>
Signed-off-by: Dan Williams <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agofix hot unplug vs async scan race
Dan Williams [Fri, 22 Jun 2012 06:47:28 +0000 (23:47 -0700)]
fix hot unplug vs async scan race

commit 3b661a92e869ebe2358de8f4b3230ad84f7fce51 upstream.

The following crash results from cases where the end_device has been
removed before scsi_sysfs_add_sdev has had a chance to run.

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000098
 IP: [<ffffffff8115e100>] sysfs_create_dir+0x32/0xb6
 Call Trace:
  [<ffffffff8125e4a8>] kobject_add_internal+0x120/0x1e3
  [<ffffffff81075149>] ? trace_hardirqs_on+0xd/0xf
  [<ffffffff8125e641>] kobject_add_varg+0x41/0x50
  [<ffffffff8125e70b>] kobject_add+0x64/0x66
  [<ffffffff8131122b>] device_add+0x12d/0x63a
  [<ffffffff814b65ea>] ? _raw_spin_unlock_irqrestore+0x47/0x56
  [<ffffffff8107de15>] ? module_refcount+0x89/0xa0
  [<ffffffff8132f348>] scsi_sysfs_add_sdev+0x4e/0x28a
  [<ffffffff8132dcbb>] do_scan_async+0x9c/0x145

...teach scsi_sysfs_add_devices() to check for deleted devices() before
trying to add them, and teach scsi_remove_target() how to remove targets
that have not been added via device_add().

Reported-by: Dariusz Majchrzak <>
Signed-off-by: Dan Williams <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoAvoid dangling pointer in scsi_requeue_command()
Bart Van Assche [Fri, 29 Jun 2012 15:34:26 +0000 (15:34 +0000)]
Avoid dangling pointer in scsi_requeue_command()

commit 940f5d47e2f2e1fa00443921a0abf4822335b54d upstream.

When we call scsi_unprep_request() the command associated with the request
gets destroyed and therefore drops its reference on the device.  If this was
the only reference, the device may get released and we end up with a NULL
pointer deref when we call blk_requeue_request.

Reported-by: Mike Christie <>
Signed-off-by: Bart Van Assche <>
Reviewed-by: Mike Christie <>
Reviewed-by: Tejun Heo <>
[jejb: enhance commend and add commit log for stable]
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoFix device removal NULL pointer dereference
Bart Van Assche [Fri, 29 Jun 2012 15:33:22 +0000 (15:33 +0000)]
Fix device removal NULL pointer dereference

commit 67bd94130015c507011af37858989b199c52e1de upstream.

Use blk_queue_dead() to test whether the queue is dead instead
of !sdev. Since scsi_prep_fn() may be invoked concurrently with
__scsi_remove_device(), keep the queuedata (sdev) pointer in
__scsi_remove_device(). This patch fixes a kernel oops that
can be triggered by USB device removal. See also

Other changes included in this patch:
- Swap the blk_cleanup_queue() and kfree() calls in
  scsi_host_dev_release() to make that code easier to grasp.
- Remove the queue dead check from scsi_run_queue() since the
  queue state can change anyway at any point in that function
  where the queue lock is not held.
- Remove the queue dead check from the start of scsi_request_fn()
  since it is redundant with the scsi_device_online() check.

Reported-by: Jun'ichi Nomura <>
Signed-off-by: Bart Van Assche <>
Reviewed-by: Mike Christie <>
Reviewed-by: Tejun Heo <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoblock: add blk_queue_dead()
Tejun Heo [Tue, 13 Dec 2011 23:33:37 +0000 (00:33 +0100)]
block: add blk_queue_dead()

commit 34f6055c80285e4efb3f602a9119db75239744dc upstream.

There are a number of QUEUE_FLAG_DEAD tests.  Add blk_queue_dead()
macro and use it.

This patch doesn't introduce any functional difference.

Signed-off-by: Tejun Heo <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: hda - Turn on PIN_OUT from hdmi playback prepare.
Dylan Reid [Fri, 20 Jul 2012 00:52:58 +0000 (17:52 -0700)]
ALSA: hda - Turn on PIN_OUT from hdmi playback prepare.

commit 9e76e6d031482194a5b24d8e9ab88063fbd6b4b5 upstream.

Turn on the pin widget's PIN_OUT bit from playback prepare. The pin is
enabled in open, but is disabled in hdmi_init_pin which is called during
system resume.  This causes a system suspend/resume during playback to
mute HDMI/DP. Enabling the pin in prepare instead of open allows calling
snd_pcm_prepare after a system resume to restore audio.

Signed-off-by: Dylan Reid <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.
Michel Dänzer [Tue, 17 Jul 2012 17:02:09 +0000 (19:02 +0200)]
drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.

commit f60ec4c7df043df81e62891ac45383d012afe0da upstream.

This could previously fail if either of the enabled displays was using a
horizontal resolution that is a multiple of 128, and only the leftmost column
of the cursor was (supposed to be) visible at the right edge of that display.

The solution is to move the cursor one pixel to the left in that case.


Signed-off-by: Michel Dänzer <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agoiommu/amd: Fix hotplug with iommu=pt
Joerg Roedel [Thu, 19 Jul 2012 11:42:54 +0000 (13:42 +0200)]
iommu/amd: Fix hotplug with iommu=pt

commit 2c9195e990297068d0f1f1bd8e2f1d09538009da upstream.

This did not work because devices are not put into the
pt_domain. Fix this.

Signed-off-by: Joerg Roedel <>
[bwh: Backported to 3.2: do not use iommu_dev_data::passthrough]
Signed-off-by: Ben Hutchings <>
9 years agoALSA: hda - Add support for Realtek ALC282
David Henningsson [Wed, 18 Jul 2012 05:38:46 +0000 (07:38 +0200)]
ALSA: hda - Add support for Realtek ALC282

commit 4e01ec636e64707d202a1ca21a47bbc6d53085b7 upstream.

This codec has a separate dmic path (separate dmic only ADC),
and thus it looks mostly like ALC275.

Tested-by: Ray Chen <>
Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoworkqueue: perform cpu down operations from low priority cpu_notifier()
Tejun Heo [Tue, 17 Jul 2012 19:39:26 +0000 (12:39 -0700)]
workqueue: perform cpu down operations from low priority cpu_notifier()

commit 6575820221f7a4dd6eadecf7bf83cdd154335eda upstream.

Currently, all workqueue cpu hotplug operations run off
CPU_PRI_WORKQUEUE which is higher than normal notifiers.  This is to
ensure that workqueue is up and running while bringing up a CPU before
other notifiers try to use workqueue on the CPU.

Per-cpu workqueues are supposed to remain working and bound to the CPU
for normal CPU_DOWN_PREPARE notifiers.  This holds mostly true even
with workqueue offlining running with higher priority because
workqueue CPU_DOWN_PREPARE only creates a bound trustee thread which
runs the per-cpu workqueue without concurrency management without
explicitly detaching the existing workers.

However, if the trustee needs to create new workers, it creates
unbound workers which may wander off to other CPUs while
CPU_DOWN_PREPARE notifiers are in progress.  Furthermore, if the CPU
down is cancelled, the per-CPU workqueue may end up with workers which
aren't bound to the CPU.

While reliably reproducible with a convoluted artificial test-case
involving scheduling and flushing CPU burning work items from CPU down
notifiers, this isn't very likely to happen in the wild, and, even
when it happens, the effects are likely to be hidden by the following
successful CPU down.

Fix it by using different priorities for up and down notifiers - high
priority for up operations and low priority for down operations.

Workqueue cpu hotplug operations will soon go through further cleanup.

Signed-off-by: Tejun Heo <>
Acked-by: "Rafael J. Wysocki" <>
Signed-off-by: Ben Hutchings <>
9 years agortlwifi: rtl8192de: Fix phy-based version calculation
Forest Bond [Fri, 13 Jul 2012 16:26:06 +0000 (12:26 -0400)]
rtlwifi: rtl8192de: Fix phy-based version calculation

commit f1b00f4dab29b57bdf1bc03ef12020b280fd2a72 upstream.

Commit d83579e2a50ac68389e6b4c58b845c702cf37516 incorporated some
changes from the vendor driver that made it newly important that the
calculated hardware version correctly include the CHIP_92D bit, as all
of the IS_92D_* macros were changed to depend on it.  However, this bit
was being unset for dual-mac, dual-phy devices.  The vendor driver
behavior was modified to not do this, but unfortunately this change was
not picked up along with the others.  This caused scanning in the 2.4GHz
band to be broken, and possibly other bugs as well.

This patch brings the version calculation logic in parity with the
vendor driver in this regard, and in doing so fixes the regression.
However, the version calculation code in general continues to be largely
incoherent and messy, and needs to be cleaned up.

Signed-off-by: Forest Bond <>
Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agos390/idle: fix sequence handling vs cpu hotplug
Heiko Carstens [Fri, 13 Jul 2012 13:45:33 +0000 (15:45 +0200)]
s390/idle: fix sequence handling vs cpu hotplug

commit 0008204ffe85d23382d6fd0f971f3f0fbe70bae2 upstream.

The s390 idle accounting code uses a sequence counter which gets used
when the per cpu idle statistics get updated and read.

One assumption on read access is that only when the sequence counter is
even and did not change while reading all values the result is valid.
On cpu hotplug however the per cpu data structure gets initialized via
a cpu hotplug notifier on CPU_ONLINE.
CPU_ONLINE however is too late, since the onlined cpu is already running
and might access the per cpu data. Worst case is that the data structure
gets initialized while an idle thread is updating its idle statistics.
This will result in an uneven sequence counter after an update.

As a result user space tools like top, which access /proc/stat in order
to get idle stats, will busy loop waiting for the sequence counter to
become even again, which will never happen until the queried cpu will
update its idle statistics again. And even then the sequence counter
will only have an even value for a couple of cpu cycles.

Fix this by moving the initialization of the per cpu idle statistics
to cpu_init(). I prefer that solution in favor of changing the
notifier to CPU_UP_PREPARE, which would be a different solution to
the problem.

Signed-off-by: Heiko Carstens <>
Signed-off-by: Martin Schwidefsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agotarget: Check number of unmap descriptors against our limit
Roland Dreier [Mon, 16 Jul 2012 22:34:25 +0000 (15:34 -0700)]
target: Check number of unmap descriptors against our limit

commit 7409a6657aebf8be74c21d0eded80709b27275cb upstream.

Fail UNMAP commands that have more than our reported limit on unmap

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agotarget: Fix possible integer underflow in UNMAP emulation
Roland Dreier [Mon, 16 Jul 2012 22:34:24 +0000 (15:34 -0700)]
target: Fix possible integer underflow in UNMAP emulation

commit b7fc7f3777582dea85156a821d78a522a0c083aa upstream.

It's possible for an initiator to send us an UNMAP command with a
descriptor that is less than 8 bytes; in that case it's really bad for
us to set an unsigned int to that value, subtract 8 from it, and then
use that as a limit for our loop (since the value will wrap around to
a huge positive value).

Fix this by making size be signed and only looping if size >= 16 (ie
if we have at least a full descriptor available).

Also remove offset as an obfuscated name for the constant 8.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
9 years agotarget: Fix reading of data length fields for UNMAP commands
Roland Dreier [Mon, 16 Jul 2012 22:34:23 +0000 (15:34 -0700)]
target: Fix reading of data length fields for UNMAP commands

commit 1a5fa4576ec8a462313c7516b31d7453481ddbe8 upstream.

are in the unmap descriptor (the payload transferred to our data out
buffer), not in the CDB itself.  Read them from the correct place in

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
9 years agotarget: Add range checking to UNMAP emulation
Roland Dreier [Mon, 16 Jul 2012 22:34:22 +0000 (15:34 -0700)]
target: Add range checking to UNMAP emulation

commit 2594e29865c291db162313187612cd9f14538f33 upstream.

When processing an UNMAP command, we need to make sure that the number
of blocks we're asked to UNMAP does not exceed our reported maximum
number of blocks per UNMAP, and that the range of blocks we're
unmapping doesn't go past the end of the device.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
9 years agotarget: Add generation of LOGICAL BLOCK ADDRESS OUT OF RANGE
Roland Dreier [Mon, 16 Jul 2012 22:34:21 +0000 (15:34 -0700)]
target: Add generation of LOGICAL BLOCK ADDRESS OUT OF RANGE

commit e2397c704429025bc6b331a970f699e52f34283e upstream.

Many SCSI commands are defined to return a CHECK CONDITION / ILLEGAL
initiator sends a command that accesses a too-big LBA.  Add an enum
value and case entries so that target code can return this status.

Signed-off-by: Roland Dreier <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: option: add ZTE MF821D
Bjørn Mork [Thu, 12 Jul 2012 10:37:32 +0000 (12:37 +0200)]
USB: option: add ZTE MF821D

commit 09110529780890804b22e997ae6b4fe3f0b3b158 upstream.

Sold by O2 (telefonica germany) under the name "LTE4G"

Tested-by: Thomas Schäfer <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: option: Ignore ZTE (Vodafone) K3570/71 net interfaces
Andrew Bird (Sphere Systems) [Sun, 25 Mar 2012 00:10:28 +0000 (00:10 +0000)]
USB: option: Ignore ZTE (Vodafone) K3570/71 net interfaces

commit f264ddea0109bf7ce8aab920d64a637e830ace5b upstream.

These interfaces need to be handled by QMI/WWAN driver

Signed-off-by: Andrew Bird <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agomwifiex: correction in mcs index check
Amitkumar Karwar [Thu, 12 Jul 2012 01:12:57 +0000 (18:12 -0700)]
mwifiex: correction in mcs index check

commit fe020120cb863ba918c6d603345342a880272c4d upstream.

mwifiex driver supports 2x2 chips as well. Hence valid mcs values
are 0 to 15. The check for mcs index is corrected in this patch.

For example: if 40MHz is enabled and mcs index is 11, "iw link"
command would show "tx bitrate: 108.0 MBit/s" without this patch.
Now it shows "tx bitrate: 108.0 MBit/s MCS 11 40Mhz" with the patch.

Signed-off-by: Amitkumar Karwar <>
Signed-off-by: Bing Zhao <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc: Add "memory" attribute for mfmsr()
Tiejun Chen [Wed, 11 Jul 2012 04:22:46 +0000 (14:22 +1000)]
powerpc: Add "memory" attribute for mfmsr()

commit b416c9a10baae6a177b4f9ee858b8d309542fbef upstream.

Add "memory" attribute in inline assembly language as a compiler
barrier to make sure 4.6.x GCC don't reorder mfmsr().

Signed-off-by: Tiejun Chen <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
9 years agoudf: Improve table length check to avoid possible overflow
Jan Kara [Tue, 10 Jul 2012 15:58:04 +0000 (17:58 +0200)]
udf: Improve table length check to avoid possible overflow

commit 57b9655d01ef057a523e810d29c37ac09b80eead upstream.

When a partition table length is corrupted to be close to 1 << 32, the
check for its length may overflow on 32-bit systems and we will think
the length is valid. Later on the kernel can crash trying to read beyond
end of buffer. Fix the check to avoid possible overflow.

Reported-by: Ben Hutchings <>
Signed-off-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: fix overhead calculation used by ext4_statfs()
Theodore Ts'o [Mon, 9 Jul 2012 20:27:05 +0000 (16:27 -0400)]
ext4: fix overhead calculation used by ext4_statfs()

commit 952fc18ef9ec707ebdc16c0786ec360295e5ff15 upstream.

Commit f975d6bcc7a introduced bug which caused ext4_statfs() to
miscalculate the number of file system overhead blocks.  This causes
the f_blocks field in the statfs structure to be larger than it should
be.  This would in turn cause the "df" output to show the number of
data blocks in the file system and the number of data blocks used to
be larger than they should be.

Signed-off-by: "Theodore Ts'o" <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agousbdevfs: Correct amount of data copied to user in processcompl_compat
Hans de Goede [Wed, 4 Jul 2012 07:18:01 +0000 (09:18 +0200)]
usbdevfs: Correct amount of data copied to user in processcompl_compat

commit 2102e06a5f2e414694921f23591f072a5ba7db9f upstream.

iso data buffers may have holes in them if some packets were short, so for
iso urbs we should always copy the entire buffer, just like the regular
processcompl does.

Signed-off-by: Hans de Goede <>
Acked-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agox86, microcode: Sanitize per-cpu microcode reloading interface
Borislav Petkov [Thu, 21 Jun 2012 12:07:16 +0000 (14:07 +0200)]
x86, microcode: Sanitize per-cpu microcode reloading interface

commit c9fc3f778a6a215ace14ee556067c73982b6d40f upstream.

Microcode reloading in a per-core manner is a very bad idea for both
major x86 vendors. And the thing is, we have such interface with which
we can end up with different microcode versions applied on different
cores of an otherwise homogeneous wrt (family,model,stepping) system.

So turn off the possibility of doing that per core and allow it only

This is a minimal fix which we'd like to see in stable too thus the
more-or-less arbitrary decision to allow system-wide reloading only on
the BSP:

$ echo 1 > /sys/devices/system/cpu/cpu0/microcode/reload

and disable the interface on the other cores:

$ echo 1 > /sys/devices/system/cpu/cpu23/microcode/reload
-bash: echo: write error: Invalid argument

Also, allowing the reload only from one CPU (the BSP in
that case) doesn't allow the reload procedure to degenerate
into an O(n^2) deal when triggering reloads from all
/sys/devices/system/cpu/cpuX/microcode/reload sysfs nodes

A more generic fix will follow.

Cc: Henrique de Moraes Holschuh <>
Cc: Peter Zijlstra <>
Signed-off-by: Borislav Petkov <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
9 years agox86, microcode: microcode_core.c simple_strtoul cleanup
Shuah Khan [Sun, 6 May 2012 17:11:04 +0000 (11:11 -0600)]
x86, microcode: microcode_core.c simple_strtoul cleanup

commit e826abd523913f63eb03b59746ffb16153c53dc4 upstream.

Change reload_for_cpu() in kernel/microcode_core.c to call kstrtoul()
instead of calling obsoleted simple_strtoul().

Signed-off-by: Shuah Khan <>
Reviewed-by: Borislav Petkov <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
9 years agoftrace: Disable function tracing during suspend/resume and hibernation, again
Srivatsa S. Bhat [Sat, 16 Jun 2012 13:30:45 +0000 (15:30 +0200)]
ftrace: Disable function tracing during suspend/resume and hibernation, again

commit 443772d408a25af62498793f6f805ce3c559309a upstream.

If function tracing is enabled for some of the low-level suspend/resume
functions, it leads to triple fault during resume from suspend, ultimately
ending up in a reboot instead of a resume (or a total refusal to come out
of suspended state, on some machines).

This issue was explained in more detail in commit f42ac38c59e0a03d (ftrace:
disable tracing for suspend to ram). However, the changes made by that commit
got reverted by commit cbe2f5a6e84eebb (tracing: allow tracing of
suspend/resume & hibernation code again). So, unfortunately since things are
not yet robust enough to allow tracing of low-level suspend/resume functions,
suspend/resume is still broken when ftrace is enabled.

So fix this by disabling function tracing during suspend/resume & hibernation.

Signed-off-by: Srivatsa S. Bhat <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: pass a char * to ext4_count_free() instead of a buffer_head ptr
Theodore Ts'o [Sat, 30 Jun 2012 23:14:57 +0000 (19:14 -0400)]
ext4: pass a char * to ext4_count_free() instead of a buffer_head ptr

commit f6fb99cadcd44660c68e13f6eab28333653621e6 upstream.

Make it possible for ext4_count_free to operate on buffers and not
just data in buffer_heads.

Signed-off-by: "Theodore Ts'o" <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agousb: gadget: Fix g_ether interface link status
Kevin Cernekee [Mon, 25 Jun 2012 04:11:22 +0000 (21:11 -0700)]
usb: gadget: Fix g_ether interface link status

commit 31bde1ceaa873bcaecd49e829bfabceacc4c512d upstream.

A "usb0" interface that has never been connected to a host has an unknown
operstate, and therefore the IFF_RUNNING flag is (incorrectly) asserted
when queried by ifconfig, ifplugd, etc.  This is a result of calling
netif_carrier_off() too early in the probe function; it should be called
after register_netdev().

Similar problems have been fixed in many other drivers, e.g.:

    e826eafa6 (bonding: Call netif_carrier_off after register_netdevice)
    0d672e9f8 (drivers/net: Call netif_carrier_off at the end of the probe)
    6a3c869a6 (cxgb4: fix reported state of interfaces without link)

Fix is to move netif_carrier_off() to the end of the function.

Signed-off-by: Kevin Cernekee <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
9 years agort2800usb: 2001:3c17 is an RT3370 device
Albert Pool [Mon, 14 May 2012 16:08:32 +0000 (18:08 +0200)]
rt2800usb: 2001:3c17 is an RT3370 device

commit 8fd9d059af12786341dec5a688e607bcdb372238 upstream.

D-Link DWA-123 rev A1

Signed-off-by: Albert Pool<>
Acked-by: Gertjan van Wingerde <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agowireless: rt2x00: rt2800usb more devices were identified
Xose Vazquez Perez [Tue, 17 Apr 2012 14:28:05 +0000 (16:28 +0200)]
wireless: rt2x00: rt2800usb more devices were identified

commit e828b9fb4f6c3513950759d5fb902db5bd054048 upstream.

found in 2012_03_22_RT5572_Linux_STA_v2.6.0.0_DPO

(0x2019,0x5201)  Planex Communications, Inc. RT8070
(0x7392,0x4085)  2L Central Europe BV 8070
7392 is Edimax

(0x1690,0x0761) Askey
was Fujitsu Stylistic 550, but 1690 is Askey

Signed-off-by: Xose Vazquez Perez <>
Acked-by: Gertjan van Wingerde <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agowireless: rt2x00: rt2800usb add more devices ids
Xose Vazquez Perez [Mon, 16 Apr 2012 23:50:32 +0000 (01:50 +0200)]
wireless: rt2x00: rt2800usb add more devices ids

commit 63b376411173c343bbcb450f95539da91f079e0c upstream.

They were taken from ralink drivers:

0x1eda,0x2210 RT3070 Airties

0x083a,0xb511 RT3370 Panasonic
0x0471,0x20dd RT3370 Philips

0x1690,0x0764 RT35xx Askey
0x0df6,0x0065 RT35xx Sitecom
0x0df6,0x0066 RT35xx Sitecom
0x0df6,0x0068 RT35xx Sitecom

0x2001,0x3c1c RT5370 DLink
0x2001,0x3c1d RT5370 DLink

2001 is D-Link not Alpha

Signed-off-by: Xose Vazquez Perez <>
Acked-by: Gertjan van Wingerde <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: drop the 5372 devices]
Signed-off-by: Ben Hutchings <>
9 years agocifs: when CONFIG_HIGHMEM is set, serialize the read/write kmaps
Jeff Layton [Wed, 11 Jul 2012 13:09:36 +0000 (09:09 -0400)]
cifs: when CONFIG_HIGHMEM is set, serialize the read/write kmaps

commit 3cf003c08be785af4bee9ac05891a15bcbff856a upstream.

Jian found that when he ran fsx on a 32 bit arch with a large wsize the
process and one of the bdi writeback kthreads would sometimes deadlock
with a stack trace like this:

crash> bt
PID: 2789   TASK: f02edaa0  CPU: 3   COMMAND: "fsx"
 #0 [eed63cbc] schedule at c083c5b3
 #1 [eed63d80] kmap_high at c0500ec8
 #2 [eed63db0] cifs_async_writev at f7fabcd7 [cifs]
 #3 [eed63df0] cifs_writepages at f7fb7f5c [cifs]
 #4 [eed63e50] do_writepages at c04f3e32
 #5 [eed63e54] __filemap_fdatawrite_range at c04e152a
 #6 [eed63ea4] filemap_fdatawrite at c04e1b3e
 #7 [eed63eb4] cifs_file_aio_write at f7fa111a [cifs]
 #8 [eed63ecc] do_sync_write at c052d202
 #9 [eed63f74] vfs_write at c052d4ee
#10 [eed63f94] sys_write at c052df4c
#11 [eed63fb0] ia32_sysenter_target at c0409a98
    EAX: 00000004  EBX: 00000003  ECX: abd73b73  EDX: 012a65c6
    DS:  007b      ESI: 012a65c6  ES:  007b      EDI: 00000000
    SS:  007b      ESP: bf8db178  EBP: bf8db1f8  GS:  0033
    CS:  0073      EIP: 40000424  ERR: 00000004  EFLAGS: 00000246

Each task would kmap part of its address array before getting stuck, but
not enough to actually issue the write.

This patch fixes this by serializing the marshal_iov operations for
async reads and writes. The idea here is to ensure that cifs
aggressively tries to populate a request before attempting to fulfill
another one. As soon as all of the pages are kmapped for a request, then
we can unlock and allow another one to proceed.

There's no need to do this serialization on non-CONFIG_HIGHMEM arches
however, so optimize all of this out when CONFIG_HIGHMEM isn't set.

Reported-by: Jian Li <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agor8169: RxConfig hack for the 8168evl.
françois romieu [Wed, 20 Jun 2012 12:09:18 +0000 (12:09 +0000)]
r8169: RxConfig hack for the 8168evl.

commit eb2dc35d99028b698cdedba4f5522bc43e576bd2 upstream.

The 8168evl (RTL_GIGA_MAC_VER_34) based Gigabyte GA-990FXA motherboards
are very prone to NETDEV watchdog problems without this change. See for instance.

I don't know why it *works*. It's depressingly effective though.

For the record:
- the problem may go along IOMMU (AMD-Vi) errors but it really looks
  like a red herring.
- the patch sets the RX_MULTI_EN bit. If the 8168c doc is any guide,
  the chipset now fetches several Rx descriptors at a time.
- long ago the driver ignored the RX_MULTI_EN bit.
  e542a2269f232d61270ceddd42b73a4348dee2bb changed the RxConfig
  settings. Whatever the problem it's now labeled a regression.
- Realtek's own driver can identify two different 8168evl devices
  (CFG_METHOD_16 and CFG_METHOD_17) where the r8169 driver only
  sees one. It sucks.

Signed-off-by: Francois Romieu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agox86: Fix boot on Twinhead H12Y
Alan Cox [Tue, 15 May 2012 17:44:15 +0000 (18:44 +0100)]
x86: Fix boot on Twinhead H12Y

commit 80b3e557371205566a71e569fbfcce5b11f92dbe upstream.

Despite lots of investigation into why this is needed we don't
know or have an elegant cure. The only answer found on this
laptop is to mark a problem region as used so that Linux doesn't
put anything there.

Currently all the users add reserve= command lines and anyone
not knowing this needs to find the magic page that documents it.
Automate it instead.

Signed-off-by: Alan Cox <>
Tested-and-bugfixed-by: Arne Fitzenreiter <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
9 years agocx25821: Remove bad strcpy to read-only char*
Ezequiel Garcia [Wed, 18 Jul 2012 13:05:26 +0000 (10:05 -0300)]
cx25821: Remove bad strcpy to read-only char*

commit 380e99fc44d79bc35af9ff1d3316ef4027ce775e upstream.

The strcpy was being used to set the name of the board.  Since the
destination char* was read-only and the name is set statically at
compile time; this was both wrong and redundant.

The type of char* is changed to const char* to prevent future errors.

Reported-by: Radek Masin <>
Signed-off-by: Ezequiel Garcia <>
[ Taking directly due to vacations   - Linus ]
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc/ftrace: Fix assembly trampoline register usage
roger blofeld [Thu, 21 Jun 2012 05:27:14 +0000 (05:27 +0000)]
powerpc/ftrace: Fix assembly trampoline register usage

commit fd5a42980e1cf327b7240adf5e7b51ea41c23437 upstream.

Just like the module loader, ftrace needs to be updated to use r12
instead of r11 with newer gcc's.

Signed-off-by: Roger Blofeld <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
9 years agosched/nohz: Fix rq->cpu_load calculations some more
Peter Zijlstra [Thu, 17 May 2012 15:15:29 +0000 (17:15 +0200)]
sched/nohz: Fix rq->cpu_load calculations some more

commit 5aaa0b7a2ed5b12692c9ffb5222182bd558d3146 upstream.

Follow up on commit 556061b00 ("sched/nohz: Fix rq->cpu_load[]
calculations") since while that fixed the busy case it regressed the
mostly idle case.

Add a callback from the nohz exit to also age the rq->cpu_load[]
array. This closes the hole where either there was no nohz load
balance pass during the nohz, or there was a 'significant' amount of
idle time between the last nohz balance and the nohz exit.

So we'll update unconditionally from the tick to not insert any
accidental 0 load periods while busy, and we try and catch up from
nohz idle balance and nohz exit. Both these are still prone to missing
a jiffy, but that has always been the case.

Signed-off-by: Peter Zijlstra <>
Cc: Venkatesh Pallipadi <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filenames and context]
Signed-off-by: Ben Hutchings <>