7 years agoLinux
Greg Kroah-Hartman [Sat, 9 Jul 2011 06:16:06 +0000 (23:16 -0700)]

7 years agoUSB: additional regression fix for device removal
Alan Stern [Wed, 6 Jul 2011 21:03:45 +0000 (17:03 -0400)]
USB: additional regression fix for device removal

commit ca5c485f55d326d9a23e4badd05890148aa53f74 upstream.

Commit e534c5b831c8b8e9f5edee5c8a37753c808b80dc (USB: fix regression
occurring during device removal) didn't go far enough.  It failed to
take into account that when a driver claims multiple interfaces, it may
release them all at the same time.  As a result, some interfaces can
get released before they are unregistered, and we deadlock trying to
acquire the bandwidth_mutex that we already own.

This patch (asl478) handles this case by setting the "unregistering"
flag on all the interfaces before removing any of them.

Signed-off-by: Alan Stern <>
Tested-by: Éric Piel <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrm/i915: Apply HWSTAM workaround for BSD ring on SandyBridge
Chris Wilson [Tue, 21 Jun 2011 17:37:59 +0000 (18:37 +0100)]
drm/i915: Apply HWSTAM workaround for BSD ring on SandyBridge

commit ec6a890dfed7dd245beba5e5bcdfcffbd934c284 upstream.

...we need to apply exactly the same workaround for missing interrupts
from BSD as for the BLT ring, apparently.

See also commit 498e720b96379d8ee9c294950a01534a73defcf3
(drm/i915: Fix gen6 (SNB) missed BLT ring interrupts).

Signed-off-by: Chris Wilson <>
Signed-off-by: Keith Packard <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoIPVS netns exit causes crash in conntrack
Hans Schillstrom [Mon, 13 Jun 2011 07:06:57 +0000 (09:06 +0200)]
IPVS netns exit causes crash in conntrack

commit 8f4e0a18682d91abfad72ede3d3cb5f3ebdf54b4 upstream.

Quote from Patric Mc Hardy
"This looks like nfnetlink.c excited and destroyed the nfnl socket, but
ip_vs was still holding a reference to a conntrack. When the conntrack
got destroyed it created a ctnetlink event, causing an oops in
netlink_has_listeners when trying to use the destroyed nfnetlink

If nf_conntrack_netlink is loaded before ip_vs this is not a problem.

This patch simply avoids calling ip_vs_conn_drop_conntrack()
when netns is dying as suggested by Julian.

Signed-off-by: Hans Schillstrom <>
Signed-off-by: Simon Horman <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoKVM: Fix register corruption in pvclock_scale_delta
Zachary Amsden [Thu, 23 Jun 2011 16:35:23 +0000 (13:35 -0300)]
KVM: Fix register corruption in pvclock_scale_delta

(cherry picked from commit de2d1a524e94a79078d9fe22c57c0c6009237547)

The 128-bit multiply in pvclock.h was missing an output constraint for
EDX which caused a register corruption to appear.  Thanks to Ulrich for
diagnosing the EDX corruption and Avi for providing this fix.

Signed-off-by: Zachary Amsden <>
Signed-off-by: Avi Kivity <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoRevert "KVM: Save/restore state of assigned PCI device"
Alex Williamson [Thu, 23 Jun 2011 16:35:22 +0000 (13:35 -0300)]
Revert "KVM: Save/restore state of assigned PCI device"

This reverts ed78661f2614d3c9f69c23e280db3bafdabdf5bb as it assumes
the saved PCI state will remain valid for the entire length of time
that it is attached to a guest.  This fails when userspace makes use
of the pci-sysfs reset interface, which invalidates the saved device
state, leaving nothing to be restored after the device is reset on
de-assignment.  This leaves the device in an unusable state.

3.0.0 will add an interface for KVM to save the PCI state in a
buffer unaffected by other callers of pci_reset_function(), but the
most appropriate stable fix seems to be reverting this change since
the original assumption about the device saved state persisting is

Signed-off-by: Alex Williamson <>
Acked-by: Jan Kiszka <>
Signed-off-by: Avi Kivity <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxfrm: Fix off by one in the replay advance functions
Steffen Klassert [Sun, 5 Jun 2011 20:46:03 +0000 (20:46 +0000)]
xfrm: Fix off by one in the replay advance functions

[ Upstream commit e756682c8baa47da1648c0c016e9f48ed66bc32d ]

We may write 4 byte too much when we reinitialize the anti replay
window in the replay advance functions. This patch fixes this by
adjusting the last index of the initialization loop.

Signed-off-by: Steffen Klassert <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agovlan: fix typo in vlan_dev_hard_start_xmit()
Wei Yongjun [Tue, 31 May 2011 22:53:19 +0000 (22:53 +0000)]
vlan: fix typo in vlan_dev_hard_start_xmit()

[ Upstream commit 307f73df2b9829ee5a261d1ed432ff683c426cdf ]

commit 4af429d29b341bb1735f04c2fb960178ed5d52e7 (vlan: lockless
transmit path) have a typo in vlan_dev_hard_start_xmit(), using
u64_stats_update_begin() to end the stat update, it should be

Signed-off-by: Wei Yongjun <>
Reviewed-by: WANG Cong <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agonetfilter: Fix ip_route_me_harder triggering ip_rt_bug
Julian Anastasov [Sat, 18 Jun 2011 07:53:59 +0000 (07:53 +0000)]
netfilter: Fix ip_route_me_harder triggering ip_rt_bug

[ Upstream commit ed6e4ef836d425bc35e33bf20fcec95e68203afa ]

Avoid creating input routes with ip_route_me_harder.
It does not work for locally generated packets. Instead,
restrict sockets to provide valid saddr for output route (or
unicast saddr for transparent proxy). For other traffic
allow saddr to be unicast or local but if callers forget
to check saddr type use 0 for the output route.

The resulting handling should be:

- in INPUT we can provide addr_type = RTN_LOCAL but
better allow rejecting traffic delivered with
local route (no IP address => use RTN_UNSPEC to
allow also RTN_UNICAST).
saddr, add fix to ignore RTN_BROADCAST and RTN_MULTICAST

- NAT, mangle, ip_queue, nf_ip_reroute: RTN_UNSPEC in LOCAL_OUT

to restrict saddr to be local

Signed-off-by: Julian Anastasov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoipv4: fix multicast losses
Eric Dumazet [Sat, 18 Jun 2011 18:59:18 +0000 (11:59 -0700)]
ipv4: fix multicast losses

[ Upstream commit 9aa3c94ce59066f545521033007abb6441706068 ]

Knut Tidemann found that first packet of a multicast flow was not
correctly received, and bisected the regression to commit b23dd4fe42b4
(Make output route lookup return rtable directly.)

Special thanks to Knut, who provided a very nice bug report, including
sample programs to demonstrate the bug.

Reported-and-bisectedby: Knut Tidemann <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoUSB: fix regression occurring during device removal
Alan Stern [Fri, 1 Jul 2011 20:43:02 +0000 (16:43 -0400)]
USB: fix regression occurring during device removal

commit e534c5b831c8b8e9f5edee5c8a37753c808b80dc upstream.

This patch (as1476) fixes a regression introduced by
fccf4e86200b8f5edd9a65da26f150e32ba79808 (USB: Free bandwidth when
usb_disable_device is called).  usb_disconnect() grabs the
bandwidth_mutex before calling usb_disable_device(), which calls down
indirectly to usb_set_interface(), which tries to acquire the

The fix causes usb_set_interface() to return early when it is called
for an interface that has already been unregistered, which is what
happens in usb_disable_device().

Signed-off-by: Alan Stern <>
Tested-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoUSB: don't let the hub driver prevent system sleep
Alan Stern [Wed, 15 Jun 2011 20:29:16 +0000 (16:29 -0400)]
USB: don't let the hub driver prevent system sleep

commit cbb330045e5df8f665ac60227ff898421fc8fb92 upstream.

This patch (as1465) continues implementation of the policy that errors
during suspend or hibernation should not prevent the system from going
to sleep.

In this case, failure to turn on the Suspend feature for a hub port
shouldn't be reported as an error.  There are situations where this
does actually occur (such as when the device plugged into that port
was disconnected in the recent past), and it turns out to be harmless.
There's no reason for it to prevent a system sleep.

Also, don't allow the hub driver to fail a system suspend if the
downstream ports aren't all suspended.  This is also harmless (and
should never happen, given the change mentioned above); printing a
warning message in the kernel log is all we really need to do.

Signed-off-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoUSB: don't let errors prevent system sleep
Alan Stern [Wed, 15 Jun 2011 20:27:43 +0000 (16:27 -0400)]
USB: don't let errors prevent system sleep

commit 0af212ba8f123c2eba151af7726c34a50b127962 upstream.

This patch (as1464) implements the recommended policy that most errors
during suspend or hibernation should not prevent the system from going
to sleep.  In particular, failure to suspend a USB driver or a USB
device should not prevent the sleep from succeeding:

Failure to suspend a device won't matter, because the device will
automatically go into suspend mode when the USB bus stops carrying
packets.  (This might be less true for USB-3.0 devices, but let's not
worry about them now.)

Failure of a driver to suspend might lead to trouble later on when the
system wakes up, but it isn't sufficient reason to prevent the system
from going to sleep.

Signed-off-by: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoNLM: Don't hang forever on NLM unlock requests
Trond Myklebust [Tue, 31 May 2011 19:15:34 +0000 (15:15 -0400)]
NLM: Don't hang forever on NLM unlock requests

commit 0b760113a3a155269a3fba93a409c640031dd68f upstream.

If the NLM daemon is killed on the NFS server, we can currently end up
hanging forever on an 'unlock' request, instead of aborting. Basically,
if the rpcbind request fails, or the server keeps returning garbage, we
really want to quit instead of retrying.

Tested-by: Vasily Averin <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoFix CPU spinlock lockups on secondary CPU bringup
Russell King [Wed, 22 Jun 2011 10:55:50 +0000 (11:55 +0100)]
Fix CPU spinlock lockups on secondary CPU bringup

commit 1b19ca9f0bdab7d5035821e1ec8f39df9a6e3ee0 upstream.

Secondary CPU bringup typically calls calibrate_delay() during its
initialization.  However, calibrate_delay() modifies a global variable
(loops_per_jiffy) used for udelay() and __delay().

A side effect of 71c696b1 ("calibrate: extract fall-back calculation
into own helper") introduced in the 2.6.39 merge window means that we
end up with a substantial period where loops_per_jiffy is zero.  This
causes the spinlock debugging code to malfunction:

u64 loops = loops_per_jiffy * HZ;
for (;;) {
for (i = 0; i < loops; i++) {
if (arch_spin_trylock(&lock->raw_lock))

by never calling arch_spin_trylock() - resulting in the CPU locking
up in an infinite loop inside __spin_lock_debug().

Work around this by only writing to loops_per_jiffy only once we have
completed all the calibration decisions.

Tested-by: Santosh Shilimkar <>
Signed-off-by: Russell King <>
Better solutions (such as omitting the calibration for secondary CPUs,
or arranging for calibrate_delay() to return the LPJ value and leave
it to the caller to decide where to store it) are a possibility, but
would be much more invasive into each architecture.

I think this is the best solution for -rc and stable, but it should be
revisited for the next merge window.

Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agotaskstats: don't allow duplicate entries in listener mode
Vasiliy Kulikov [Mon, 27 Jun 2011 23:18:11 +0000 (16:18 -0700)]
taskstats: don't allow duplicate entries in listener mode

commit 26c4caea9d697043cc5a458b96411b86d7f6babd upstream.

Currently a single process may register exit handlers unlimited times.
It may lead to a bloated listeners chain and very slow process

kernel memory is stolen for the handlers chain and "time id" shows 2-7
seconds instead of normal 0.003.  It makes it possible to exhaust all
kernel memory and to eat much of CPU time by triggerring numerous exits
on a single CPU.

The patch limits the number of times a single process may register
itself on a single CPU to one.

One little issue is kept unfixed - as taskstats_exit() is called before
exit_files() in do_exit(), the orphaned listener entry (if it was not
explicitly deregistered) is kept until the next someone's exit() and
implicit deregistration in send_cpu_listeners().  So, if a process
registered itself as a listener exits and the next spawned process gets
the same pid, it would inherit taskstats attributes.

Signed-off-by: Vasiliy Kulikov <>
Cc: Balbir Singh <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrivers/misc/lkdtm.c: fix race when crashpoint is hit multiple times before checking...
Josh Hunt [Mon, 27 Jun 2011 23:18:08 +0000 (16:18 -0700)]
drivers/misc/lkdtm.c: fix race when crashpoint is hit multiple times before checking count

commit aa2c96d6f329e66cc59352b0f12e8f04e6a9593b upstream.

We observed the crash point count going negative in cases where the
crash point is hit multiple times before the check of "count == 0" is
done.  Because of this we never call lkdtm_do_action().  This patch just
adds a spinlock to protect count.

Reported-by: Tapan Dhimant <>
Signed-off-by: Josh Hunt <>
Acked-by: Ankita Garg <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoiwlagn: fix change_interface for P2P types
Johannes Berg [Tue, 21 Jun 2011 15:28:31 +0000 (08:28 -0700)]
iwlagn: fix change_interface for P2P types

commit 5306c0807491e891125f4fb08b04340c91530f57 upstream.

When an interface changes type to a P2P type,
iwlagn will erroneously set vif->type to the
P2P type and not the reduced/split type. Fix
this by keeping "newtype" in another variable
for the assignment to vif->type.

Signed-off-by: Johannes Berg <>
Signed-off-by: Wey-Yi Guy <>
Signed-off-by: Greg Kroah-Hartman <>
7 years ago6pack,mkiss: fix lock inconsistency
Arnd Bergmann [Sat, 2 Jul 2011 00:30:00 +0000 (17:30 -0700)]
6pack,mkiss: fix lock inconsistency

commit 6e4e2f811bade330126d4029c88c831784a7efd9 upstream.

Lockdep found a locking inconsistency in the mkiss_close function:

> kernel: [ INFO: inconsistent lock state ]
> kernel: #3
> kernel: ---------------------------------
> kernel: inconsistent {IN-SOFTIRQ-R} -> {SOFTIRQ-ON-W} usage.
> kernel: ax25ipd/2813 [HC0[0]:SC0[0]:HE1:SE1] takes:
> kernel: (disc_data_lock){+++?.-}, at: [<ffffffffa018552b>] mkiss_close+0x1b/0x90 [mkiss]
> kernel: {IN-SOFTIRQ-R} state was registered at:

The message hints that disc_data_lock is aquired with softirqs disabled,
but does not itself disable softirqs, which can in rare circumstances
lead to a deadlock.
The same problem is present in the 6pack driver, this patch fixes both
by using write_lock_bh instead of write_lock.

Reported-by: Bernard F6BVP <>
Tested-by: Bernard F6BVP <>
Signed-off-by: Arnd Bergmann <>
Acked-by: Ralf Baechle<>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoFS-Cache: Add a helper to bulk uncache pages on an inode
David Howells [Thu, 7 Jul 2011 11:19:48 +0000 (12:19 +0100)]
FS-Cache: Add a helper to bulk uncache pages on an inode

commit c902ce1bfb40d8b049bd2319b388b4b68b04bc27 upstream.

Add an FS-Cache helper to bulk uncache pages on an inode.  This will
only work for the circumstance where the pages in the cache correspond
1:1 with the pages attached to an inode's page cache.

This is required for CIFS and NFS: When disabling inode cookie, we were
returning the cookie and setting cifsi->fscache to NULL but failed to
invalidate any previously mapped pages.  This resulted in "Bad page
state" errors and manifested in other kind of errors when running
fsstress.  Fix it by uncaching mapped pages when we disable the inode

This patch should fix the following oops and "Bad page state" errors
seen during fsstress testing.

  ------------[ cut here ]------------
  kernel BUG at fs/cachefiles/namei.c:201!
  invalid opcode: 0000 [#1] SMP
  Pid: 5, comm: kworker/u:0 Not tainted #1 Bochs Bochs
  RIP: 0010: cachefiles_walk_to_object+0x436/0x745 [cachefiles]
  RSP: 0018:ffff88002ce6dd00  EFLAGS: 00010282
  RAX: ffff88002ef165f0 RBX: ffff88001811f500 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: 0000000000000100 RDI: 0000000000000282
  RBP: ffff88002ce6dda0 R08: 0000000000000100 R09: ffffffff81b3a300
  R10: 0000ffff00066c0a R11: 0000000000000003 R12: ffff88002ae54840
  R13: ffff88002ae54840 R14: ffff880029c29c00 R15: ffff88001811f4b0
  FS:  00007f394dd32720(0000) GS:ffff88002ef00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
  CR2: 00007fffcb62ddf8 CR3: 000000001825f000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
  Process kworker/u:0 (pid: 5, threadinfo ffff88002ce6c000, task ffff88002ce55cc0)
   0000000000000246 ffff88002ce55cc0 ffff88002ce6dd58 ffff88001815dc00
   ffff8800185246c0 ffff88001811f618 ffff880029c29d18 ffff88001811f380
   ffff88002ce6dd50 ffffffff814757e4 ffff88002ce6dda0 ffffffff8106ac56
  Call Trace:
   cachefiles_lookup_object+0x78/0xd4 [cachefiles]
   fscache_lookup_object+0x131/0x16d [fscache]
   fscache_object_work_func+0x1bc/0x669 [fscache]
  RIP  cachefiles_walk_to_object+0x436/0x745 [cachefiles]
  ---[ end trace 1d481c9af1804caa ]---

I tested the uncaching by the following means:

 (1) Create a big file on my NFS server (104857600 bytes).

 (2) Read the file into the cache with md5sum on the NFS client.  Look in

Pages  : mrk=25601 unc=0

 (3) Open the file for read/write ("bash 5<>/warthog/bigfile").  Look in proc

Pages  : mrk=25601 unc=25601

Reported-by: Jeff Layton <>
Signed-off-by: David Howells <>
Reviewed-and-Tested-by: Suresh Jayaraman <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agofs: fix lock initialization
Miklos Szeredi [Wed, 6 Jul 2011 10:33:55 +0000 (12:33 +0200)]
fs: fix lock initialization

commit a51cb91d81f8e6fc4e5e08b772cc3ceb13ac9d37 upstream.

locks_alloc_lock() assumed that the allocated struct file_lock is
already initialized to zero members.  This is only true for the first
allocation of the structure, after reuse some of the members will have
random values.

This will for example result in passing random fl_start values to
userspace in fuse for FL_FLOCK locks, which is an information leak at

Fix by reinitializing those members which may be non-zero after freeing.

Signed-off-by: Miklos Szeredi <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrivers/base/platform.c: don't mark platform_device_register_resndata() as __init_or_...
Andrew Morton [Mon, 23 May 2011 21:44:19 +0000 (14:44 -0700)]
drivers/base/platform.c: don't mark platform_device_register_resndata() as __init_or_module

commit bb2b43fefab723f4a0760146e7bed59d41a50e53 upstream.

This reverts 737a3bb9416ce2a7c7a4 ("Driver core: move platform device
creation helpers to .init.text (if MODULE=n)").  That patch assumed that
platform_device_register_resndata() is only ever called from __init code
but that isn't true in the case ioctl->drm_ioctl->radeon_cp_init().


Acked-by: Uwe Kleine-König <>
Reported-by: Anthony Basile <>
Cc: Greg KH <>
Cc: David Airlie <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoASoC: pxa-ssp: Correct check for stream presence
Daniel Mack [Wed, 22 Jun 2011 18:48:25 +0000 (20:48 +0200)]
ASoC: pxa-ssp: Correct check for stream presence

commit 53dea36c70c1857149a8c447224e3936eb8b5339 upstream.

Don't rely on the codec's channels_min information to decide wheter or
not allocate a substream's DMA buffer. Rather check if the substream
itself was allocated previously.

Signed-off-by: Daniel Mack <>
Acked-by: Liam Girdwood <>
Signed-off-by: Mark Brown <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoSUNRPC: Ensure the RPC client only quits on fatal signals
Trond Myklebust [Fri, 17 Jun 2011 14:14:59 +0000 (10:14 -0400)]
SUNRPC: Ensure the RPC client only quits on fatal signals

commit 5afa9133cfe67f1bfead6049a9640c9262a7101c upstream.

Fix a couple of instances where we were exiting the RPC client on
arbitrary signals. We should only do so on fatal signals.

Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agomd: avoid endless recovery loop when waiting for fail device to complete.
NeilBrown [Tue, 28 Jun 2011 06:59:42 +0000 (16:59 +1000)]
md: avoid endless recovery loop when waiting for fail device to complete.

commit 4274215d24633df7302069e51426659d4759c5ed upstream.

If a device fails in a way that causes pending request to take a while
to complete, md will not be able to immediately remove it from the
array in remove_and_add_spares.
It will then incorrectly look like a spare device and md will try to
recover it even though it is failed.
This leads to a recovery process starting and instantly aborting over
and over again.

We should check if the device is faulty before considering it to be a
spare.  This will avoid trying to start a recovery that cannot

This bug was introduced in 2.6.26 so that patch is suitable for any
kernel since then.

Reported-by: Jim Paradis <>
Signed-off-by: NeilBrown <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agohfsplus: add missing call to bio_put()
Seth Forshee [Tue, 31 May 2011 21:35:50 +0000 (16:35 -0500)]
hfsplus: add missing call to bio_put()

commit 50176ddefa4a942419cb693dd2d8345bfdcde67c upstream.

hfsplus leaks bio objects by failing to call bio_put() on the bios
it allocates. Add the missing call to fix the leak.

Signed-off-by: Seth Forshee <>
Signed-off-by: Christoph Hellwig <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoi2c/pca954x: Initialize the mux to disconnected state
Petri Gynther [Wed, 29 Jun 2011 09:36:11 +0000 (11:36 +0200)]
i2c/pca954x: Initialize the mux to disconnected state

commit cd823db8b1161ef0d756514d280715a576d65cc3 upstream.

pca954x power-on default is channel 0 connected. If multiple pca954x
muxes are connected to the same physical I2C bus, the parent bus will
see channel 0 devices behind both muxes by default. This is bad.

            -- pca954x @ 0x70 -- ch 0 (I2C-bus-101) -- EEPROM @ 0x50
I2C-bus-1 ---
            -- pca954x @ 0x71 -- ch 0 (I2C-bus-111) -- EEPROM @ 0x50

1. Load I2C bus driver: creates I2C-bus-1
2. Load pca954x driver: creates virtual I2C-bus-101 and I2C-bus-111
3. Load eeprom driver
4. Try to read EEPROM @ 0x50 on I2C-bus-101. The transaction will also bleed
   onto I2C-bus-111 because pca954x @ 0x71 channel 0 is connected by default.

Fix: Initialize pca954x to disconnected state in pca954x_probe()

Signed-off-by: Petri Gynther <>
Signed-off-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoi2c-taos-evm: Fix log messages
Jean Delvare [Wed, 29 Jun 2011 09:36:10 +0000 (11:36 +0200)]
i2c-taos-evm: Fix log messages

commit 9b640f2e154268cb516efcaf9c434f2e73c6783e upstream.

* Print all error and information messages even when debugging is
* Don't use adapter device to log messages before it is ready.

Signed-off-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoKEYS: Fix error handling in construct_key_and_link()
David Howells [Tue, 21 Jun 2011 13:32:05 +0000 (14:32 +0100)]
KEYS: Fix error handling in construct_key_and_link()

commit b1d7dd80aadb9042e83f9778b484a2f92e0b04d4 upstream.

Fix error handling in construct_key_and_link().

If construct_alloc_key() returns an error, it shouldn't pass out through
the normal path as the key_serial() called by the kleave() statement
will oops when it gets an error code in the pointer:

  BUG: unable to handle kernel paging request at ffffffffffffff84
  IP: [<ffffffff8120b401>] request_key_and_link+0x4d7/0x52f
  Call Trace:
   [<ffffffff8120b52c>] request_key+0x41/0x75
   [<ffffffffa00ed6e8>] cifs_get_spnego_key+0x206/0x226 [cifs]
   [<ffffffffa00eb0c9>] CIFS_SessSetup+0x511/0x1234 [cifs]
   [<ffffffffa00d9799>] cifs_setup_session+0x90/0x1ae [cifs]
   [<ffffffffa00d9c02>] cifs_get_smb_ses+0x34b/0x40f [cifs]
   [<ffffffffa00d9e05>] cifs_mount+0x13f/0x504 [cifs]
   [<ffffffffa00caabb>] cifs_do_mount+0xc4/0x672 [cifs]
   [<ffffffff8113ae8c>] mount_fs+0x69/0x155
   [<ffffffff8114ff0e>] vfs_kern_mount+0x63/0xa0
   [<ffffffff81150be2>] do_kern_mount+0x4d/0xdf
   [<ffffffff81152278>] do_mount+0x63c/0x69f
   [<ffffffff8115255c>] sys_mount+0x88/0xc2
   [<ffffffff814fbdc2>] system_call_fastpath+0x16/0x1b

Signed-off-by: David Howells <>
Acked-by: Jeff Layton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoPM / Hibernate: Fix free_unnecessary_pages()
Rafael J. Wysocki [Wed, 6 Jul 2011 18:15:23 +0000 (20:15 +0200)]
PM / Hibernate: Fix free_unnecessary_pages()

commit 4d4cf23cdde2f8f9324f5684a7f349e182039529 upstream.

There is a bug in free_unnecessary_pages() that causes it to
attempt to free too many pages in some cases, which triggers the
BUG_ON() in memory_bm_clear_bit() for copy_bm.  Namely, if
count_data_pages() is initially greater than alloc_normal, we get
to_free_normal equal to 0 and "save" greater from 0.  In that case,
if the sum of "save" and count_highmem_pages() is greater than
alloc_highmem, we subtract a positive number from to_free_normal.
Hence, since to_free_normal was 0 before the subtraction and is
an unsigned int, the result is converted to a huge positive number
that is used as the number of pages to free.

Fix this bug by checking if to_free_normal is actually greater
than or equal to the number we're going to subtract from it.

Signed-off-by: Rafael J. Wysocki <>
Reported-and-tested-by: Matthew Garrett <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoPM: Fix async resume following suspend failure
Alan Stern [Sat, 18 Jun 2011 20:42:09 +0000 (22:42 +0200)]
PM: Fix async resume following suspend failure

commit 6d0e0e84f66d32c33511984dd3badd32364b863c upstream.

The PM core doesn't handle suspend failures correctly when it comes to
asynchronously suspended devices.  These devices are moved onto the
dpm_suspended_list as soon as the corresponding async thread is
started up, and they remain on the list even if they fail to suspend
or the sleep transition is cancelled before they get suspended.  As a
result, when the PM core unwinds the transition, it tries to resume
the devices even though they were never suspended.

This patch (as1474) fixes the problem by adding a new "is_suspended"
flag to dev_pm_info.  Devices are resumed only if the flag is set.

 * Moved the dev->power.is_suspended check into device_resume(),
   because we need to complete dev->power.completion and clear
   dev->power.is_prepared too for devices whose
   dev->power.is_suspended flags are unset.
 * Fixed __device_suspend() to avoid setting dev->power.is_suspended
   if async_error is different from zero.]

Signed-off-by: Alan Stern <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoPM: Rename dev_pm_info.in_suspend to is_prepared
Alan Stern [Sat, 18 Jun 2011 18:22:23 +0000 (20:22 +0200)]
PM: Rename dev_pm_info.in_suspend to is_prepared

commit f76b168b6f117a49d36307053e1acbe30580ea5b upstream.

This patch (as1473) renames the "in_suspend" field in struct
dev_pm_info to "is_prepared", in preparation for an upcoming change.
The new name is more descriptive of what the field really means.

Signed-off-by: Alan Stern <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoPCI / PM: Block races between runtime PM and system sleep
Rafael J. Wysocki [Tue, 21 Jun 2011 21:47:15 +0000 (23:47 +0200)]
PCI / PM: Block races between runtime PM and system sleep

commit a5f76d5eba157bf637beb2dd18026db2917c512e upstream.

After commit e8665002477f0278f84f898145b1f141ba26ee26
(PM: Allow pm_runtime_suspend() to succeed during system suspend) it
is possible that a device resumed by the pm_runtime_resume(dev) in
pci_pm_prepare() will be suspended immediately from a work item,
timer function or otherwise, defeating the very purpose of calling
pm_runtime_resume(dev) from there.  To prevent that from happening
it is necessary to increment the runtime PM usage counter of the
device by replacing pm_runtime_resume() with pm_runtime_get_sync().
Moreover, the incremented runtime PM usage counter has to be
decremented by the corresponding pci_pm_complete(), via

Signed-off-by: Rafael J. Wysocki <>
Acked-by: Jesse Barnes <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoblock: use the passed in @bdev when claiming if partno is zero
Tejun Heo [Mon, 13 Jun 2011 10:45:48 +0000 (12:45 +0200)]
block: use the passed in @bdev when claiming if partno is zero

commit d4c208b86b8be4254eba0e74071496e599f94639 upstream.

6b4517a791 (block: implement bd_claiming and claiming block)
introduced claiming block to support O_EXCL blkdev opens properly.

bd_start_claiming() looks up the part 0 bdev and starts claiming
block.  The function assumed that there is only one part 0 bdev and
always used bdget_disk(disk, 0) to look it up; unfortunately, this
isn't true for some drivers (floppy) which use multiple block devices
to denote different operating parameters for the same physical device.
There can be multiple part 0 bdev's for the same device number.

This incorrect assumption caused the wrong bdev to be used during
claiming leading to unbalanced bd_holders as reported in the following

This patch updates bd_start_claiming() such that it uses the bdev
specified as argument if its partno is zero.

Note that this means that different bdev's can be used for the same
device and O_EXCL check can be effectively bypassed.  It has always
been broken that way and floppy is fortunately on its way out.  Leave
that breakage alone.

Signed-off-by: Tejun Heo <>
Reported-by: Alex Villacis Lasso <>
Tested-by: Alex Villacis Lasso <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agocfq-iosched: make code consistent
Shaohua Li [Mon, 27 Jun 2011 07:03:48 +0000 (09:03 +0200)]
cfq-iosched: make code consistent

commit 726e99ab88db059fe1422e15376ae404f8c66eb4 upstream.

ioc->ioc_data is rcu protectd, so uses correct API to access it.
This doesn't change any behavior, but just make code consistent.

Signed-off-by: Shaohua Li <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agocfq-iosched: fix a rcu warning
Shaohua Li [Mon, 27 Jun 2011 07:03:47 +0000 (09:03 +0200)]
cfq-iosched: fix a rcu warning

commit 3181faa85bda3dc3f5e630a1846526c9caaa38e3 upstream.

I got a rcu warnning at boot. the ioc->ioc_data is rcu_deferenced, but
doesn't hold rcu_read_lock.

Signed-off-by: Shaohua Li <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agocfq-iosched: fix locking around ioc->ioc_data assignment
Jens Axboe [Sun, 5 Jun 2011 04:01:13 +0000 (06:01 +0200)]
cfq-iosched: fix locking around ioc->ioc_data assignment

commit ab4bd22d3cce6977dc039664cc2d052e3147d662 upstream.

Since we are modifying this RCU pointer, we need to hold
the lock protecting it around it.

This fixes a potential reuse and double free of a cfq
io_context structure. The bug has been in CFQ for a long
time, it hit very few people but those it did hit seemed
to see it a lot.

Tracked in RH bugzilla here:

Credit goes to Paul Bolle for figuring out that the issue
was around the one-hit ioc->ioc_data cache. Thanks to his
hard work the issue is now fixed.

Signed-off-by: Jens Axboe <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodebugobjects: Fix boot crash when kmemleak and debugobjects enabled
Marcin Slusarz [Sat, 28 May 2011 11:23:42 +0000 (13:23 +0200)]
debugobjects: Fix boot crash when kmemleak and debugobjects enabled

commit 161b6ae0e067e421b20bb35caf66bdb405c929ac upstream.

Order of initialization look like this:
...(lots of other subsystems)...
workqueues (through early initcall)

debugobjects use schedule_work for batch freeing of its data and kmemleak
heavily use debugobjects, so when it comes to freeing and workqueues were
not initialized yet, kernel crashes:

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff810854d1>] __queue_work+0x29/0x41a
 [<ffffffff81085910>] queue_work_on+0x16/0x1d
 [<ffffffff81085abc>] queue_work+0x29/0x55
 [<ffffffff81085afb>] schedule_work+0x13/0x15
 [<ffffffff81242de1>] free_object+0x90/0x95
 [<ffffffff81242f6d>] debug_check_no_obj_freed+0x187/0x1d3
 [<ffffffff814b6504>] ? _raw_spin_unlock_irqrestore+0x30/0x4d
 [<ffffffff8110bd14>] ? free_object_rcu+0x68/0x6d
 [<ffffffff8110890c>] kmem_cache_free+0x64/0x12c
 [<ffffffff8110bd14>] free_object_rcu+0x68/0x6d
 [<ffffffff810b58bc>] __rcu_process_callbacks+0x1b6/0x2d9

because system_wq is NULL.

Fix it by checking if workqueues susbystem was initialized before using.

Signed-off-by: Marcin Slusarz <>
Cc: Catalin Marinas <>
Cc: Tejun Heo <>
Cc: Dipankar Sarma <>
Cc: Paul E. McKenney <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoInput: properly assign return value of clamp() macro.
Hans Petter Selasky [Wed, 25 May 2011 16:24:32 +0000 (09:24 -0700)]
Input: properly assign return value of clamp() macro.

commit 8c127f0717b438e6abc3d92d4ae248c4224b9dcb upstream.

[ added mousedev changes]
Signed-off-by: Hans Petter Selasky <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoNFSv4: Fix a readdir regression
Trond Myklebust [Thu, 16 Jun 2011 17:15:41 +0000 (13:15 -0400)]
NFSv4: Fix a readdir regression

commit ee7b75fc4f3ae49e1f25bf56219bb5de3c29afaf upstream.

Commit 7ebb9315 (NFS: use secinfo when crossing mountpoints) introduces
a regression when decoding an NFSv4 readdir entry that sets the
rdattr_error field.
By treating the resulting value as if it is a decoding error, the current
code may cause us to skip valid readdir entries.

Reported-by: Andy Adamson <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoNFSv4.1: allow zero fh array in filelayout decode layout
Andy Adamson [Mon, 13 Jun 2011 22:36:17 +0000 (18:36 -0400)]
NFSv4.1: allow zero fh array in filelayout decode layout

commit cec765cf5891c7fc3d905832b481bfb6fd55825d upstream.

Signed-off-by: Andy Adamson <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoNFSv4.1: allow nfs_fhget to succeed with mounted on fileid
Andy Adamson [Mon, 13 Jun 2011 22:25:56 +0000 (18:25 -0400)]
NFSv4.1: allow nfs_fhget to succeed with mounted on fileid

commit 533eb4611c9eea53072eb6a61d5a6393b6a77ed7 upstream.

Commit 28331a46d88459788c8fca72dbb0415cd7f514c9 "Ensure we request the
ordinary fileid when doing readdirplus"
changed the meaning of NFS_ATTR_FATTR_FILEID which used to be set when

Allow nfs_fhget to succeed with only a mounted on fileid when crossing
a mountpoint or a referral.

Ask for the fileid of the absent file system if mounted_on_fileid is not

Signed-off-by: Andy Adamson <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agonfsd4: fix break_lease flags on nfsd open
J. Bruce Fields [Tue, 7 Jun 2011 15:50:23 +0000 (11:50 -0400)]
nfsd4: fix break_lease flags on nfsd open

commit 105f4622104848ff1ee1f644d661bef9dec3eb27 upstream.

Thanks to Casey Bodley for pointing out that on a read open we pass 0,
instead of O_RDONLY, to break_lease, with the result that a read open is
treated like a write open for the purposes of lease breaking!

Reported-by: Casey Bodley <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agonfsd: link returns nfserr_delay when breaking lease
Casey Bodley [Fri, 3 Jun 2011 16:21:23 +0000 (12:21 -0400)]
nfsd: link returns nfserr_delay when breaking lease

commit 7d751f6f8c679f51b73d01a1b5269347a929004c upstream.

fix for commit 4795bb37effb7b8fe77e2d2034545d062d3788a8, nfsd: break
lease on unlink, link, and rename

if the LINK operation breaks a delegation, it returns NFS4ERR_NOENT
(which is not a valid error in rfc 5661) instead of NFS4ERR_DELAY.
the return value of nfsd_break_lease() in nfsd_link() must be
converted from host_err to err

Signed-off-by: Casey Bodley <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agonfsd: fix dependency of nfsd on auth_rpcgss
J. Bruce Fields [Tue, 31 May 2011 16:24:58 +0000 (12:24 -0400)]
nfsd: fix dependency of nfsd on auth_rpcgss

commit b084f598df36b62dfae83c10ed17f0b66b50f442 upstream.

Commit b0b0c0a26e84 "nfsd: add proc file listing kernel's gss_krb5
enctypes" added an nunnecessary dependency of nfsd on the auth_rpcgss

It's a little ad hoc, but since the only piece of information nfsd needs
from rpcsec_gss_krb5 is a single static string, one solution is just to
share it with an include file.

Reported-by: Michael Guntsche <>
Cc: Kevin Coffman <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agonfsd: v4 support requires CRYPTO
Randy Dunlap [Mon, 6 Jun 2011 18:22:17 +0000 (11:22 -0700)]
nfsd: v4 support requires CRYPTO

commit be1f4084b4824301e640e81d63b6275cd99ee6a1 upstream.

nfsd V4 support uses crypto interfaces, so select CRYPTO
to fix build errors in 2.6.39:

ERROR: "crypto_destroy_tfm" [fs/nfsd/nfsd.ko] undefined!
ERROR: "crypto_alloc_base" [fs/nfsd/nfsd.ko] undefined!

Reported-by: Wakko Warner <>
Signed-off-by: Randy Dunlap <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agowatchdog: mtx1-wdt: request gpio before using it
Florian Fainelli [Wed, 15 Jun 2011 17:15:23 +0000 (19:15 +0200)]
watchdog: mtx1-wdt: request gpio before using it

commit 9b19d40aa3ebaf1078779da10555da2ab8512422 upstream.

Otherwise, the gpiolib autorequest feature will produce a WARN_ON():

WARNING: at drivers/gpio/gpiolib.c:101 0x8020ec6c()
autorequest GPIO-215

Signed-off-by: Florian Fainelli <>
Signed-off-by: Wim Van Sebroeck <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoite-cir: 8709 needs to use pnp resource 2
Jarod Wilson [Tue, 7 Jun 2011 21:45:17 +0000 (18:45 -0300)]
ite-cir: 8709 needs to use pnp resource 2

commit 35d136c8dab034ee14aa00d6082229b4b74607da upstream.

Thanks to the intrepid testing and debugging of Matthijs van Drunen, it
was uncovered that at least some variants of the ITE8709 need to use pnp
resource 2, rather than 0, for things to function properly. Resource 0
has a length of only 1, and if you try to bypass the pnp_port_len check
and use it anyway (with either a length of 1 or 2), the system in
question's trackpad ceased to function.

The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value
was (amusingly) changed to 0 by way of a patch from ITE themselves, so I
don't know if there may be variants where 0 actually *is* correct, but
at least in this case and in the original lirc_ite8709 driver author's
case, it sure looks like 2 is the right value.

This fix should probably be applied to all stable kernels with the
ite-cir driver, lest we nuke more people's trackpads.

Tested-by: Matthijs van Drunen
Acked-by: Juan Jesús García de Soria <>
Signed-off-by: Jarod Wilson <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agouvcvideo: Remove buffers from the queues when freeing
Sjoerd Simons [Tue, 24 May 2011 15:22:03 +0000 (12:22 -0300)]
uvcvideo: Remove buffers from the queues when freeing

commit 8ca2c80b170c47eeb55f0c2a0f2b8edf85f35d49 upstream.

When freeing memory for the video buffers also remove them from the
irq & main queues.

This fixes an oops when doing the following:

open ("/dev/video", ..)
close ()

As the second VIDIOC_REQBUFS will cause the list entries of the buffers
to be cleared while they still hang around on the main and irc queues

Signed-off-by: Sjoerd Simons <>
Acked-by: Laurent Pinchart <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agokeymaps: fix table for pinnacle pctv hd devices
Jarod Wilson [Wed, 8 Jun 2011 18:00:01 +0000 (15:00 -0300)]
keymaps: fix table for pinnacle pctv hd devices

commit 1ba9268c2bfeebfd70193145685e12faeae92882 upstream.

Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5
scancodes, so this update makes this keymap actually *have* full
scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box
remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and
PCTV HD Pro 801e (em28xx usb stick).

Signed-off-by: Jarod Wilson <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agolirc_zilog: fix spinning rx thread
Jarod Wilson [Wed, 8 Jun 2011 21:56:56 +0000 (18:56 -0300)]
lirc_zilog: fix spinning rx thread

commit 6a8c97ac92461ec57e36b10572e78d4221e8faa8 upstream.

We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b0464b68d429bc8a3fe6595d19c39dfc4d95, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...

Acked-by: Andy Walls <>
Signed-off-by: Jarod Wilson <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agorc: fix ghost keypresses with certain hw
Jarod Wilson [Thu, 16 Jun 2011 19:18:37 +0000 (16:18 -0300)]
rc: fix ghost keypresses with certain hw

commit 3f5c4c73322e4d6f3d40b697dac3073d2adffe41 upstream.

With hardware that has to use ir_raw_event_store_edge to collect IR
sample durations, we were not doing an event reset unless
IR_MAX_DURATION had passed. That's around 4 seconds. So if someone
presses up, then down, with less than 4 seconds in between, they'd get
the initial up, then up and down upon pressing down.

To fix this, I've lowered the "send a reset event" logic's threshold to
the input device's REP_DELAY (defaults to 500ms), and with an
saa7134-based GPIO-driven IR receiver in a Hauppauge HVR-1150, I get
*much* better behavior out of the remote now. Special thanks to Devin
for providing the hardware to investigate this issue.

CC: Devin Heitmueller <>
Signed-off-by: Jarod Wilson <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoALSA: HDA: Add a new Conexant codec ID (506c)
David Henningsson [Tue, 21 Jun 2011 18:51:34 +0000 (20:51 +0200)]
ALSA: HDA: Add a new Conexant codec ID (506c)

commit f0ca89b031d327b80b612a0608d31b8e13e6dc33 upstream.

Conexant ID 506c was found on Acer Aspire 3830TG. As users report
no playback, sending to stable should be safe.

Reported-by: andROOM
Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoALSA: HDA: Remove quirk for an HP device
David Henningsson [Mon, 20 Jun 2011 08:27:07 +0000 (10:27 +0200)]
ALSA: HDA: Remove quirk for an HP device

commit 6f2e810ad5d162c2bfa063c1811087277b299e4e upstream.

The reporter, who is running kernel 2.6.38, reports that
he needs to set model=auto for the headphone output to work

Reported-by: Jo
Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agomm, hotplug: fix error handling in mem_online_node()
David Rientjes [Thu, 23 Jun 2011 01:13:01 +0000 (18:13 -0700)]
mm, hotplug: fix error handling in mem_online_node()

commit 7553e8f2d5161a2b7a9b7a9f37be1b77e735552f upstream.

The error handling in mem_online_node() is incorrect: hotadd_new_pgdat()
returns NULL if the new pgdat could not have been allocated and a pointer
to it otherwise.

mem_online_node() should fail if hotadd_new_pgdat() fails, not the
inverse.  This fixes an issue when memoryless nodes are not onlined and
their sysfs interface is not registered when their first cpu is brought

The bug was introduced by commit cf23422b9d76 ("cpu/mem hotplug: enable
CPUs online before local memory online") iow v2.6.35.

Signed-off-by: David Rientjes <>
Reviewed-by: KOSAKI Motohiro <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoNFS41: do not update isize if inode needs layoutcommit
Peng Tao [Sun, 17 Oct 2010 05:07:46 +0000 (22:07 -0700)]
NFS41: do not update isize if inode needs layoutcommit

commit 0f66b5984df2fe1617c05900a39a7ef493ca9de9 upstream.

nfs_update_inode will update isize if there is no queued pages. For pNFS,
layoutcommit is supposed to change file size on server, the same effect as queued
pages. nfs_update_inode may be called when dirty pages are written back (nfsi->npages==0)
but layoutcommit is not sent, and it will change client file size according to server
file size. Then client ends up losing what it just writes back in pNFS path.
So we should skip updating client file size if file needs layoutcommit.

Signed-off-by: Peng Tao <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoblock: add REQ_SECURE to REQ_COMMON_MASK
Namhyung Kim [Mon, 20 Jun 2011 11:23:14 +0000 (13:23 +0200)]

commit 155d109b5f52ffd749219b27702462dcd9cf4f8d upstream.

Add REQ_SECURE flag to REQ_COMMON_MASK so that
init_request_from_bio() can pass it to @req->cmd_flags.

Signed-off-by: Namhyung Kim <>
Acked-by: Adrian Hunter <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agomm: fix negative commitlimit when gigantic hugepages are allocated
Rafael Aquini [Wed, 15 Jun 2011 22:08:39 +0000 (15:08 -0700)]
mm: fix negative commitlimit when gigantic hugepages are allocated

commit b0320c7b7d1ac1bd5c2d9dff3258524ab39bad32 upstream.

When 1GB hugepages are allocated on a system, free(1) reports less
available memory than what really is installed in the box.  Also, if the
total size of hugepages allocated on a system is over half of the total
memory size, CommitLimit becomes a negative number.

The problem is that gigantic hugepages (order > MAX_ORDER) can only be
allocated at boot with bootmem, thus its frames are not accounted to
'totalram_pages'.  However, they are accounted to hugetlb_total_pages()

What happens to turn CommitLimit into a negative number is this
calculation, in fs/proc/meminfo.c:

        allowed = ((totalram_pages - hugetlb_total_pages())
                * sysctl_overcommit_ratio / 100) + total_swap_pages;

A similar calculation occurs in __vm_enough_memory() in mm/mmap.c.

Also, every vm statistic which depends on 'totalram_pages' will render
confusing values, as if system were 'missing' some part of its memory.

Impact of this bug:

When gigantic hugepages are allocated and sysctl_overcommit_memory ==
OVERCOMMIT_NEVER.  In a such situation, __vm_enough_memory() goes through
the mentioned 'allowed' calculation and might end up mistakenly returning
-ENOMEM, thus forcing the system to start reclaiming pages earlier than it
would be ususal, and this could cause detrimental impact to overall
system's performance, depending on the workload.

Besides the aforementioned scenario, I can only think of this causing
annoyances with memory reports from /proc/meminfo and free(1).

[ standardize comment layout]
Reported-by: Russ Anderson <>
Signed-off-by: Rafael Aquini <>
Acked-by: Russ Anderson <>
Cc: Andrea Arcangeli <>
Cc: Christoph Lameter <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agommc: Add PCI fixup quirks for Ricoh 1180:e823 reader
Manoj Iyer [Thu, 26 May 2011 16:19:05 +0000 (11:19 -0500)]
mmc: Add PCI fixup quirks for Ricoh 1180:e823 reader

commit be98ca652faa6468916a9b7608befff215a8ca70 upstream.

Signed-off-by: Manoj Iyer <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agommc: tmio: fix regression in TMIO_MMC_WRPROTECT_DISABLE handling
Guennadi Liakhovetski [Mon, 20 Jun 2011 14:51:10 +0000 (16:51 +0200)]
mmc: tmio: fix regression in TMIO_MMC_WRPROTECT_DISABLE handling

commit 7d8b4c2a4b73da8e3632603691838ca5b2a8c26d upstream.

Commit b6147490e6aac82 ("mmc: tmio: split core functionality, DMA and
MFD glue") broke handling of the TMIO_MMC_WRPROTECT_DISABLE flag by
the tmio-mmc driver. This patch restores the original behaviour.

Signed-off-by: Guennadi Liakhovetski <>
Signed-off-by: Chris Ball <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agooprofile, x86: Fix race in nmi handler while starting counters
Robert Richter [Wed, 1 Jun 2011 13:31:44 +0000 (15:31 +0200)]
oprofile, x86: Fix race in nmi handler while starting counters

commit 8fe7e94eb71430cf63a742f3c19739d82a662758 upstream.

In some rare cases, nmis are generated immediately after the nmi
handler of the cpu was started. This causes the counter not to be
enabled. Before enabling the nmi handlers we need to set variable
ctr_running first and make sure its value is written to memory.

Also, the patch makes all existing barriers a memory barrier instead
of a compiler barrier only.

Reported-by: Suravee Suthikulpanit <>
Signed-off-by: Robert Richter <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agox86, suspend: Restore MISC_ENABLE MSR in realmode wakeup
Kees Cook [Thu, 7 Jul 2011 01:10:34 +0000 (18:10 -0700)]
x86, suspend: Restore MISC_ENABLE MSR in realmode wakeup

commit 7a3136666bc0f0419f7aaa7b1fabb4b0e0a7fb76 upstream.

Some BIOSes will reset the Intel MISC_ENABLE MSR (specifically the
XD_DISABLE bit) when resuming from S3, which can interact poorly with
ebba638ae723d8a8fc2f7abce5ec18b688b791d7. In 32bit PAE mode, this can
lead to a fault when EFER is restored by the kernel wakeup routines,
due to it setting the NX bit for a CPU that (thanks to the BIOS reset)
now incorrectly thinks it lacks the NX feature. (64bit is not affected
because it uses a common CPU bring-up that specifically handles the

The need for MISC_ENABLE being restored so early is specific to the S3
resume path. Normally, MISC_ENABLE is saved in save_processor_state(),
but this happens after the resume header is created, so just reproduce
the logic here. (acpi_suspend_lowlevel() creates the header, calls
do_suspend_lowlevel, which calls save_processor_state(), so the saved
processor context isn't available during resume header creation.)

[ hpa: Consider for stable if OK in mainline ]

Signed-off-by: Kees Cook <>
Signed-off-by: H. Peter Anvin <>
Cc: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoath9k: Fix suspend/resume when no interface is UP
Rajkumar Manoharan [Tue, 28 Jun 2011 12:51:19 +0000 (18:21 +0530)]
ath9k: Fix suspend/resume when no interface is UP

commit c31eb8e926835582cd186b33a7a864880a4c0c79 upstream.

When no interface has been brought up, the chip's power
state continued as AWAKE. So during resume, the chip never
been powered up.

Signed-off-by: Rajkumar Manoharan <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agopxa168_eth: fix race in transmit path.
Richard Cochran [Sun, 19 Jun 2011 21:48:06 +0000 (21:48 +0000)]
pxa168_eth: fix race in transmit path.

commit 384420409d9b5d4443940abace49363d26135412 upstream.

Because the socket buffer is freed in the completion interrupt, it is not
safe to access it after submitting it to the hardware.

Acked-by: Sachin Sanap <>
Cc: Zhangfei Gao <>
Cc: Philip Rakity <>
Signed-off-by: Richard Cochran <>
Acked-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoath5k: Disable fast channel switching by default
Nick Kossifidis [Thu, 2 Jun 2011 00:09:48 +0000 (03:09 +0300)]
ath5k: Disable fast channel switching by default

commit a99168eece601d2a79ecfcb968ce226f2f30cf98 upstream.

Disable fast channel change by default on AR2413/AR5413 due to
some bug reports (it still works for me but it's better to be safe).
Add a module parameter "fastchanswitch" in case anyone wants to enable
it and play with it.

Signed-off-by: Nick Kossifidis <>
Tested-by: Sedat Dilek <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoath5k: fix memory leak when fewer than N_PD_CURVES are in use
Eugene A. Shatokhin [Wed, 29 Jun 2011 03:04:51 +0000 (23:04 -0400)]
ath5k: fix memory leak when fewer than N_PD_CURVES are in use

commit a0b8de350be458b33248e48b2174d9af8a4c4798 upstream.

We would free the proper number of curves, but in the wrong
slots, due to a missing level of indirection through
the pdgain_idx table.

It's simpler just to try to free all four slots, so do that.

Signed-off-by: Bob Copeland <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoPM: Free memory bitmaps if opening /dev/snapshot fails
Michal Kubecek [Sat, 18 Jun 2011 18:34:01 +0000 (20:34 +0200)]
PM: Free memory bitmaps if opening /dev/snapshot fails

commit 8440f4b19494467883f8541b7aa28c7bbf6ac92b upstream.

When opening /dev/snapshot device, snapshot_open() creates memory
bitmaps which are freed in snapshot_release(). But if any of the
callbacks called by pm_notifier_call_chain() returns NOTIFY_BAD, open()
fails, snapshot_release() is never called and bitmaps are not freed.
Next attempt to open /dev/snapshot then triggers BUG_ON() check in
create_basic_memory_bitmaps(). This happens e.g. when vmwatchdog module
is active on s390x.

Signed-off-by: Michal Kubecek <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agomm/memory-failure.c: fix page isolated count mismatch
Minchan Kim [Wed, 15 Jun 2011 22:08:48 +0000 (15:08 -0700)]
mm/memory-failure.c: fix page isolated count mismatch

commit 5db8a73a8d7cc6a66afbf25ed7fda338caa8f5f9 upstream.

Pages isolated for migration are accounted with the vmstat counters
NR_ISOLATE_[ANON|FILE].  Callers of migrate_pages() are expected to
increment these counters when pages are isolated from the LRU.  Once the
pages have been migrated, they are put back on the LRU or freed and the
isolated count is decremented.

Memory failure is not properly accounting for pages it isolates causing
the NR_ISOLATED counters to be negative.  On SMP builds, this goes
unnoticed as negative counters are treated as 0 due to expected per-cpu
drift.  On UP builds, the counter is treated by too_many_isolated() as a
large value causing processes to enter D state during page reclaim or
compaction.  This patch accounts for pages isolated by memory failure

[ rewrote changelog]
Reviewed-by: Andrea Arcangeli <>
Signed-off-by: Minchan Kim <>
Cc: Andi Kleen <>
Acked-by: Mel Gorman <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoUSB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c
Uwe Bonnes [Fri, 17 Jun 2011 15:30:23 +0000 (17:30 +0200)]
USB: Add new FT232H chip to drivers/usb/serial/ftdi_sio.c

commit 309427b6351b763917caac3e4b2ab5651df99823 upstream.

appended patch adds support for the new FTDI FT232H chip. This chip is a
single channel version of the dual FT2232H/quad FT4232H, coming with it's
own default PID 0x6014 (FT2232H uses the same PID 0x6010 like FT2232C,
FT4232H has also it's own PID).

The patch was checked on an UM232H module and a terminal program with TX/RX
shorted to that typing in the terminal reproduced the characters.

Signed-off-by: Uwe Bonnes <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoUSB: Free bandwidth when usb_disable_device is called.
Sarah Sharp [Mon, 6 Jun 2011 06:22:22 +0000 (23:22 -0700)]
USB: Free bandwidth when usb_disable_device is called.

commit fccf4e86200b8f5edd9a65da26f150e32ba79808 upstream.

Tanya ran into an issue when trying to switch a UAS device from the BOT
configuration to the UAS configuration via the bConfigurationValue sysfs
file.  Before installing the UAS configuration, set_bConfigurationValue()
calls usb_disable_device().  That function is supposed to remove all host
controller resources associated with that device, but it leaves some state
in the xHCI host controller.

Commit 0791971ba8fbc44e4f476079f856335ed45e6324
usb: allow drivers to use allocated bandwidth until unbound
added a call to usb_disable_device() in usb_set_configuration(), before
the xHCI bandwidth functions were invoked.  That commit fixed a bug, but
also introduced a bug that is triggered when a configured device is
switched to a new configuration.

usb_disable_device() goes through all the motions of unbinding the drivers
attached to active interfaces and removing the USB core structures
associated with those interfaces, but it doesn't actually remove the
endpoints from the internal xHCI host controller bandwidth structures.

When usb_disable_device() calls usb_disable_endpoint() with reset_hardware
set to true, the entries in udev->ep_out and udev->ep_in will be set to
NULL.  Usually, when the USB core installs a new configuration,
usb_hcd_alloc_bandwidth() will drop all non-NULL endpoints in udev->ep_out
and udev->ep_in before adding any new endpoints.  However, when the new
UAS configuration was added, all those entries were null, so none of the
old endpoints in the BOT configuration were dropped.

The xHCI driver blindly added the UAS configuration endpoints, and some of
the endpoint addresses overlapped with the old BOT configuration
endpoints.  This caused the xHCI host to reject the Configure Endpoint
command.  Now that the xHCI driver code is cleaned up to reject a
double-add of active endpoints, we need to fix the USB core to properly
drop old endpoints in usb_disable_device().

If the host controller driver needs bandwidth checking support, make
usb_disable_device() call usb_disable_endpoint() with
reset_hardware set to false, drop the endpoints from the xHCI host
controller, and then call usb_disable_endpoint() again with
reset_hardware set to true.

The first call to usb_disable_endpoint() will cancel any pending URBs and
wait on them to be freed in usb_hcd_disable_endpoint(), but will keep the
pointers in udev->ep_out and udev->ep in intact.  Then
usb_hcd_alloc_bandwidth() will use those pointers to know which endpoints
to drop.

The final call to usb_disable_endpoint() will do two things:

1. It will call usb_hcd_disable_endpoint() again, which should be harmless
since the ep->urb_list should be empty after the first call to
usb_disable_endpoint() returns.

2. It will set the entries in udev->ep_out and udev->ep in to NULL, and call
usb_hcd_disable_endpoint().  That call will have no effect, since the xHCI
driver doesn't set the endpoint_disable function pointer.

Note that usb_disable_device() will now need to be called with
hcd->bandwidth_mutex held.

This should be backported to kernels as old as 2.6.32.

Signed-off-by: Sarah Sharp <>
Reported-by: Tanya Brokhman <>
Cc: Alan Stern <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxhci: Always set urb->status to zero for isoc endpoints.
Sarah Sharp [Thu, 16 Jun 2011 02:57:46 +0000 (19:57 -0700)]
xhci: Always set urb->status to zero for isoc endpoints.

commit b3df3f9c7df9a8d85e03e158d35487618a160901 upstream.

When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs.  For TD that is skipped, skip_isoc_td() is
called.  This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.

If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core.  That means drivers will see urb->status as -EXDEV.

It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is.  See
itd_complete() in ehci-sched.c:

                } else {
                        /* URB was too late */
                        desc->status = -EXDEV;

        /* handle completion now? */
        if (likely ((urb_index + 1) != urb->number_of_packets))
                goto done;

        /* ASSERT: it's really the last itd for this urb
        list_for_each_entry (itd, &stream->td_list, itd_list)
                BUG_ON (itd->urb == urb);

        /* give urb back to the driver; completion often (re)submits */
        dev = urb->dev;
        ehci_urb_done(ehci, urb, 0);

ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.

It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value.  They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen

Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.

This patch should be backported to kernels as old as 2.6.36

Signed-off-by: Sarah Sharp <>
Cc: Andiry Xu <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxhci: Add reset on resume quirk for asrock p67 host
Maarten Lankhorst [Wed, 15 Jun 2011 21:47:21 +0000 (23:47 +0200)]
xhci: Add reset on resume quirk for asrock p67 host

commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9 upstream.

The asrock p67 xhci controller completely dies on resume, add a
quirk for this, to bring the host back online after a suspend.

This should be backported to stable kernels as old as 2.6.37.

Signed-off-by: Maarten Lankhorst <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxhci: Reject double add of active endpoints.
Sarah Sharp [Mon, 6 Jun 2011 06:10:04 +0000 (23:10 -0700)]
xhci: Reject double add of active endpoints.

commit fa75ac379e63c2864e9049b5e8615e40f65c1e70 upstream.

While trying to switch a UAS device from the BOT configuration to the UAS
configuration via the bConfigurationValue file, Tanya ran into an issue in
the USB core.  usb_disable_device() sets entries in udev->ep_out and
udev->ep_out to NULL, but doesn't call into the xHCI bandwidth management
functions to remove the BOT configuration endpoints from the xHCI host's
internal structures.

The USB core would then attempt to add endpoints for the UAS
configuration, and some of the endpoints had the same address as endpoints
in the BOT configuration.  The xHCI driver blindly added the endpoints
again, but the xHCI host controller rejected the Configure Endpoint
command because active endpoints were added without being dropped.

Make the xHCI driver reject calls to xhci_add_endpoint() that attempt to
add active endpoints without first calling xhci_drop_endpoint().

This should be backported to kernels as old as 2.6.31.

Signed-off-by: Sarah Sharp <>
Reported-by: Tanya Brokhman <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoConnector: Correctly set the error code in case of success when dispatching receive...
K. Y. Srinivasan [Tue, 17 May 2011 22:25:38 +0000 (15:25 -0700)]
Connector: Correctly set the error code in case of success when dispatching receive callbacks

commit 663dd6dcaf7e95526e469e91f41972a9c0cca30c upstream.

The recent changes to the connector code introduced this bug where even
when a callback was invoked, we would return an error resulting in
double freeing of the skb. This patch fixes this bug.

Signed-off-by: K. Y. Srinivasan <>
Acked-by: Evgeniy Polyakov <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoConnector: Set the CN_NETLINK_USERS correctly
K. Y. Srinivasan [Tue, 17 May 2011 22:25:37 +0000 (15:25 -0700)]
Connector: Set the CN_NETLINK_USERS correctly

commit ea2c00095c022846dd8dfd211de05154d3e4e1b8 upstream.

The CN_NETLINK_USERS must be set to the highest valid index +1.
Thanks to Evgeniy for pointing this out.

Signed-off-by: K. Y. Srinivasan <>
Acked-by: Evgeniy Polyakov <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoTTY: ldisc, do not close until there are readers
Jiri Slaby [Sun, 5 Jun 2011 12:16:16 +0000 (14:16 +0200)]
TTY: ldisc, do not close until there are readers

commit 92f6fa09bd453ffe3351fa1f1377a1b7cfa911e6 upstream.

We restored tty_ldisc_wait_idle in 100eeae2c5c (TTY: restore
tty_ldisc_wait_idle). We used it in the ldisc changing path to fix the
case where there are tasks in n_tty_read waiting for data and somebody
tries to change ldisc.

Similar to the case above, there may be also tasks waiting in
n_tty_read while hangup is performed. As 65b770468e98 (tty-ldisc: turn
ldisc user count into a proper refcount) removed the wait-until-idle
from all paths, hangup path won't wait for them to disappear either
now. So add it back even to the hangup path.

There is a difference, we need uninterruptible sleep as there is
obviously HUP signal pending. So tty_ldisc_wait_idle now sleeps
without possibility to be interrupted. This is what original
tty_ldisc_wait_idle did. After the wait idle reintroduction
(100eeae2c5c), we have had interruptible sleeps for the ldisc changing
path. But as there is a 5s timeout anyway, we don't allow it to be
interrupted from now on. It's not worth the added complexity of
deciding what kind of sleep we want.

Before 65b770468e98 tty_ldisc_release was called also from
tty_ldisc_release. It is called from tty_release, so I don't think we
need to restore that one.

This is nicely reproducible after constifying the timing when
drivers/tty/n_tty.c is patched as follows ("TTY: ntty, add one more
sanity check" patch is needed to actually see it explode):
%% -1548,6 +1549,7 @@ static int n_tty_open(struct tty_struct *tty)

        /* These are ugly. Currently a malloc failure here can panic */
        if (!tty->read_buf) {
+               msleep(100);
                tty->read_buf = kzalloc(N_TTY_BUF_SIZE, GFP_KERNEL);
                if (!tty->read_buf)
                        return -ENOMEM;
%% -1785,6 +1788,7 @@ do_it_again:
                        timeout = schedule_timeout(timeout);
+                       msleep(20);
===== With a process: =====
    while (1) {
        int fd = open(argv[1], O_RDWR);
        read(fd, buf, sizeof(buf));
===== and its child: =====
        while (1) {
                int fd = open(tty, O_RDWR|O_NOCTTY);
                ioctl(fd, TIOCSCTTY, 1);
                usleep(100 * (10 + random() % 1000));
===== EOF =====

Signed-off-by: Jiri Slaby <>
Cc: Alan Cox <>
Cc: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoARM: SAMSUNG: serial: Fix on handling of one clock source for UART
Boojin Kim [Sat, 28 May 2011 02:04:03 +0000 (19:04 -0700)]
ARM: SAMSUNG: serial: Fix on handling of one clock source for UART

commit 470f22975448a65a1084a6f0721fa5df15323f02 upstream.

This patch fixes the way of comparison for handling of two or more
clock sources for UART.

For example, if just only one clock source is defined even though
there are two clock sources for UART, the serial driver does not
set proper clock up. Of course, it is problem.

So this patch changes the condition of comparison to avoid useless
setup clock and adds a flag 'NO_NEED_CHECK_CLKSRC' which means
selection of source clock is not required.

In addition, since the Exynos4210 has only one clock source for UART
this patch adds the flag into its common_init_uarts().

Signed-off-by: Boojin Kim <>
Signed-off-by: Kukjin Kim <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoclocksource: Make watchdog robust vs. interruption
Thomas Gleixner [Thu, 16 Jun 2011 14:22:08 +0000 (16:22 +0200)]
clocksource: Make watchdog robust vs. interruption

commit b5199515c25cca622495eb9c6a8a1d275e775088 upstream.

The clocksource watchdog code is interruptible and it has been
observed that this can trigger false positives which disable the TSC.

The reason is that an interrupt storm or a long running interrupt
handler between the read of the watchdog source and the read of the
TSC brings the two far enough apart that the delta is larger than the
unstable treshold. Move both reads into a short interrupt disabled
region to avoid that.

Reported-and-tested-by: Vernon Mauery <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxen/pci: Move check for acpi_sci_override_gsi to xen_setup_acpi_sci.
Konrad Rzeszutek Wilk [Wed, 6 Jul 2011 13:43:16 +0000 (09:43 -0400)]
xen/pci: Move check for acpi_sci_override_gsi to xen_setup_acpi_sci.

commit ee339fe63ac408e4604c1c88b1f9a428f2511b70 upstream.

Previously we would check for acpi_sci_override_gsi == gsi every time
a PCI device was enabled. That works during early bootup, but later
on it could lead to triggering unnecessarily the acpi_gsi_to_irq(..) lookup.
The reason is that acpi_sci_override_gsi was declared in __initdata and
after early bootup could contain bogus values.

This patch moves the check for acpi_sci_override_gsi to the
site where the ACPI SCI is preset.

Reported-by: Raghavendra D Prabhu <>
Tested-by: Raghavendra D Prabhu <>
Suggested-by: Ian Campbell <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxen/mmu: Fix for linker errors when CONFIG_SMP is not defined.
Konrad Rzeszutek Wilk [Thu, 30 Jun 2011 13:12:40 +0000 (09:12 -0400)]
xen/mmu: Fix for linker errors when CONFIG_SMP is not defined.

commit 32dd11942aeb47f91209a446d6b10063c5b69389 upstream.

Simple enough - we use an extern defined symbol which is not
defined when CONFIG_SMP is not defined. This fixes the linker

Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI IRQ.
Konrad Rzeszutek Wilk [Thu, 30 Jun 2011 13:18:27 +0000 (09:18 -0400)]
xen/pci: Use the INT_SRC_OVR IRQ (instead of GSI) to preset the ACPI SCI IRQ.

commit 155a16f21923bc2f04161ac92acca986371ef27b upstream.

In the past we would use the GSI value to preset the ACPI SCI
IRQ which worked great as GSI == IRQ:

ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)

While that is most often seen, there are some oddities:

ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low level)

which means that GSI 20 (or pin 20) is to be overriden for IRQ 9.
Our code that presets the interrupt for ACPI SCI however would
use the GSI 20 instead of IRQ 9 ending up with:

xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=20
xen: acpi sci 20
.. snip..
calling  acpi_init+0x0/0xbc @ 1
ACPI: SCI (IRQ9) allocation failed
ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20110413/evevent-119)
ACPI: Unable to start the ACPI Interpreter

as the ACPI interpreter made a call to 'acpi_gsi_to_irq' which got nine.
It used that value to request an IRQ (request_irq) and since that was not
present it failed.

The fix is to recognize that for interrupts that are overriden (in our
case we only care about the ACPI SCI) we should use the IRQ number
to present the IRQ instead of the using GSI. End result is that we get:

xen: sci override: global_irq=20 trigger=0 polarity=1
xen: registering gsi 20 triggering 0 polarity 1
xen: --> pirq=20 -> irq=9 (gsi=9)
xen: acpi sci 9

which fixes the ACPI interpreter failing on startup.

Reported-by: Liwei <>
Tested-by: Liwei <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxen: partially revert "xen: set max_pfn_mapped to the last pfn mapped"
Stefano Stabellini [Fri, 3 Jun 2011 09:51:34 +0000 (09:51 +0000)]
xen: partially revert "xen: set max_pfn_mapped to the last pfn mapped"

commit a91d92875ee94e4703fd017ccaadb48cfb344994 upstream.

We only need to set max_pfn_mapped to the last pfn mapped on x86_64 to
make sure that cleanup_highmap doesn't remove important mappings at

We don't need to do this on x86_32 because cleanup_highmap is not called
on x86_32. Besides lowering max_pfn_mapped on x86_32 has the unwanted
side effect of limiting the amount of memory available for the 1:1
kernel pagetable allocation.

This patch reverts the x86_32 part of the original patch.

Signed-off-by: Stefano Stabellini <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoxen: support CONFIG_MAXSMP
Andrew Jones [Fri, 18 Dec 2009 09:31:31 +0000 (10:31 +0100)]
xen: support CONFIG_MAXSMP

commit 900cba8881b39dfbc7c8062098504ab93f5387a8 upstream.

The MAXSMP config option requires CPUMASK_OFFSTACK, which in turn
requires we init the memory for the maps while we bring up the cpus.
MAXSMP also increases NR_CPUS to 4096. This increase in size exposed an
issue in the argument construction for multicalls from
xen_flush_tlb_others. The args should only need space for the actual
number of cpus.

Also in 2.6.39 it exposes a bootup problem.

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff8157a1d3>] set_cpu_sibling_map+0x123/0x30d
Call Trace:
[<ffffffff81039a3f>] ? xen_restore_fl_direct_reloc+0x4/0x4
[<ffffffff819dc4db>] xen_smp_prepare_cpus+0x36/0x135

Signed-off-by: Andrew Jones <>
[v2: Updated to compile on 3.0]
[v3: Updated to compile when CONFIG_SMP is not defined]
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrm: populate irq_by_busid-member for pci
Wolfram Sang [Wed, 15 Jun 2011 09:26:47 +0000 (11:26 +0200)]
drm: populate irq_by_busid-member for pci

commit 45e97ab65026a3391cb2c938f834ca5db4d2e5b3 upstream.

Commit 8410ea (drm: rework PCI/platform driver interface) implemented
drm_pci_irq_by_busid() but forgot to make it available in the

This caused a freeze on my Radeon9600-equipped laptop when executing glxgears.
Thanks to Michel for noticing the flaw.

[airlied: made function static also]

Reported-by: Michel Dänzer <>
Signed-off-by: Wolfram Sang <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrm/i915: Fix gen6 (SNB) missed BLT ring interrupts.
Daniel J Blueman [Fri, 17 Jun 2011 18:32:19 +0000 (11:32 -0700)]
drm/i915: Fix gen6 (SNB) missed BLT ring interrupts.

commit 498e720b96379d8ee9c294950a01534a73defcf3 upstream.

The failure appeared in dmesg as:

[drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt
ring idle [waiting on 35064155, at 35064155], missed IRQ?

This works around that problem on by making the blitter command
streamer write interrupt state to the Hardware Status Page when a
MI_USER_INTERRUPT command is decoded, which appears to force the seqno
out to memory before the interrupt happens.

v1->v2: Moved to prior interrupt handler installation and RMW flags as
per feedback.
v2->v3: Removed RMW of flags (by anholt)

Signed-off-by: Daniel J Blueman <>
Signed-off-by: Eric Anholt <>
Tested-by: Chris Wilson <> [v1]
Tested-by: Eric Anholt <> [v1,v3]
   (incidence of the bug with a testcase went from avg 2/1000 to
   0/12651 in the latest test run (plus more for v1))
Tested-by: Kenneth Graunke <> [v1]
Tested-by: Robert Hooker <> [v1]
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrm/radeon/kms: Fix chremap setup on RV770 CE
Alex Deucher [Thu, 30 Jun 2011 12:59:55 +0000 (08:59 -0400)]
drm/radeon/kms: Fix chremap setup on RV770 CE

commit daf54f1f363a61c618662ef66d4bf09d2b090941 upstream.

CE variant requires a different chremap setup.


Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrm/radeon/kms/atom: fix duallink on some early DCE3.2 cards
Alex Deucher [Fri, 17 Jun 2011 17:13:52 +0000 (13:13 -0400)]
drm/radeon/kms/atom: fix duallink on some early DCE3.2 cards

commit 8323fa6ba313ae2664420ec34d56a7fb0bbbe525 upstream.

Certain revisions of the vbios on DCE3.2 cards have a bug
in the transmitter control table which prevents duallink from
being enabled properly on some cards.  The action switch statement
jumps to the wrong offset for the OUTPUT_ENABLE action.  The fix
is to use the ENABLE action rather than the OUTPUT_ENABLE action
on the affected cards.  In fixed version of the vbios, both
actions jump to the same offset, so the change should be safe.

Reported-and-tested-by: Dave Airlie <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoRevert "drm/i915: Enable GMBUS for post-gen2 chipsets"
Jean Delvare [Sat, 4 Jun 2011 19:34:56 +0000 (19:34 +0000)]
Revert "drm/i915: Enable GMBUS for post-gen2 chipsets"

commit 826c7e4147f902737b281e8a5a7d7aa33fd63316 upstream.

Revert commit 8f9a3f9b63b8cd3f03be9dc53533f90bd4120e5f. This fixes a
hang when loading the eeprom driver (see bug #35572.) GMBUS will be
re-enabled later, differently.

Signed-off-by: Jean Delvare <>
Reported-by: Marek Otahal <>
Tested-by: Yermandu Patapitafious <>
Tested-by: Andrew Lutomirski <>
Acked-by: Chris Wilson <>
Signed-off-by: Dave Airlie <>
Cc: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agohwmon: (ibmpex) Initialize sysfs attributes
Guenter Roeck [Tue, 24 May 2011 19:34:12 +0000 (12:34 -0700)]
hwmon: (ibmpex) Initialize sysfs attributes

commit fb794e0f7153918c33f2300986d995524ab711cf upstream.

Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.

Signed-off-by: Guenter Roeck <>
Acked-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agohwmon: (s3c) Initialize sysfs attributes
Guenter Roeck [Tue, 24 May 2011 19:34:55 +0000 (12:34 -0700)]
hwmon: (s3c) Initialize sysfs attributes

commit b1e698db0939b04602ded2a2196ff69c92b49378 upstream.

Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.

Signed-off-by: Guenter Roeck <>
Acked-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agohwmon: (ibmaem) Initialize sysfs attributes
Guenter Roeck [Tue, 24 May 2011 19:33:26 +0000 (12:33 -0700)]
hwmon: (ibmaem) Initialize sysfs attributes

commit 3cdb2052a6e365ad56202874e6a8a05a2bb336fc upstream.

Initialize dynamically allocated sysfs attributes before device_create_file()
call to suppress lockdep_init_map() warning if lockdep debugging is enabled.

Signed-off-by: Guenter Roeck <>
Acked-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agomigrate: don't account swapcache as shmem
Andrea Arcangeli [Thu, 16 Jun 2011 19:56:19 +0000 (12:56 -0700)]
migrate: don't account swapcache as shmem

commit 99a15e21d96f6857dafab1e5167e5e8183215c9c upstream.

swapcache will reach the below code path in migrate_page_move_mapping,
and swapcache is accounted as NR_FILE_PAGES but it's not accounted as

Hugh pointed out we must use PageSwapCache instead of comparing
mapping to &swapper_space, to avoid build failure with CONFIG_SWAP=n.

Signed-off-by: Andrea Arcangeli <>
Acked-by: Hugh Dickins <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agodrivers/tty/serial/pch_uart.c: don't oops if dmi_get_system_info returns NULL
Alexander Stein [Wed, 15 Jun 2011 22:08:55 +0000 (15:08 -0700)]
drivers/tty/serial/pch_uart.c: don't oops if dmi_get_system_info returns NULL

commit fb139dfeef9558a12ffdbf9e26951fd1a9304f3b upstream.

If dmi_get_system_info() returns NULL, pch_uart_init_port() will
dereferencea a zero pointer.

This oops was observed on an Atom based board which has no BIOS, but
a bootloder which doesn't provide DMI data.

Signed-off-by: Alexander Stein <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoksm: fix NULL pointer dereference in scan_get_next_rmap_item()
Hugh Dickins [Wed, 15 Jun 2011 22:08:58 +0000 (15:08 -0700)]
ksm: fix NULL pointer dereference in scan_get_next_rmap_item()

commit 2b472611a32a72f4a118c069c2d62a1a3f087afd upstream.

Andrea Righi reported a case where an exiting task can race against
ksmd::scan_get_next_rmap_item ( easily
triggering a NULL pointer dereference in ksmd.

ksm_scan.mm_slot == &ksm_mm_head with only one registered mm

CPU 1 (__ksm_exit) CPU 2 (scan_get_next_rmap_item)
  list_empty() is false
lock slot == &ksm_mm_head
(list now empty)
slot = list_entry(slot->
(list is empty, so slot is still ksm_mm_head)
slot->mm == NULL ... Oops

Close this race by revalidating that the new slot is not simply the list
head again.

Andrea's test case:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>

#define BUFSIZE getpagesize()

int main(int argc, char **argv)
void *ptr;

if (posix_memalign(&ptr, getpagesize(), BUFSIZE) < 0) {
if (madvise(ptr, BUFSIZE, MADV_MERGEABLE) < 0) {
*(char *)NULL = 0;

return 0;

Reported-by: Andrea Righi <>
Tested-by: Andrea Righi <>
Cc: Andrea Arcangeli <>
Signed-off-by: Hugh Dickins <>
Signed-off-by: Chris Wright <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoudp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet
Xufeng Zhang [Tue, 21 Jun 2011 10:43:40 +0000 (10:43 +0000)]
udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet

[ Upstream commit 9cfaa8def1c795a512bc04f2aec333b03724ca2e ]

Consider this scenario: When the size of the first received udp packet
is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
However, if checksum error happens and this is a blocking socket, it will
goto try_again loop to receive the next packet.  But if the size of the
next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
receive the next packet, MSG_TRUNC is still set, which is wrong.

Fix this problem by clearing MSG_TRUNC flag when starting over for a
new packet.

Signed-off-by: Xufeng Zhang <>
Signed-off-by: Paul Gortmaker <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoipv6/udp: Use the correct variable to determine non-blocking condition
Xufeng Zhang [Tue, 21 Jun 2011 10:43:39 +0000 (10:43 +0000)]
ipv6/udp: Use the correct variable to determine non-blocking condition

[ Upstream commit 32c90254ed4a0c698caa0794ebb4de63fcc69631 ]

udpv6_recvmsg() function is not using the correct variable to determine
whether or not the socket is in non-blocking operation, this will lead
to unexpected behavior when a UDP checksum error occurs.

Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:

    err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
                   flags & ~MSG_DONTWAIT, &addr_len);

i.e. with udpv6_recvmsg() getting these values:

int noblock = flags & MSG_DONTWAIT
int flags = flags & ~MSG_DONTWAIT

So, when udp checksum error occurs, the execution will go to
csum_copy_err, and then the problem happens:

            if (flags & MSG_DONTWAIT)
                    return -EAGAIN;
            goto try_again;

But it will always go to try_again as MSG_DONTWAIT has been cleared
from flags at call time -- only noblock contains the original value
of MSG_DONTWAIT, so the test should be:

            if (noblock)
                    return -EAGAIN;

This is also consistent with what the ipv4/udp code does.

Signed-off-by: Xufeng Zhang <>
Signed-off-by: Paul Gortmaker <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agonet/ipv4: Check for mistakenly passed in non-IPv4 address
Marcus Meissner [Thu, 2 Jun 2011 04:05:22 +0000 (21:05 -0700)]
net/ipv4: Check for mistakenly passed in non-IPv4 address

[ Upstream commit d0733d2e29b652b2e7b1438ececa732e4eed98eb ]

Check against mistakenly passing in IPv6 addresses (which would result
in an INADDR_ANY bind) or similar incompatible sockaddrs.

Signed-off-by: Marcus Meissner <>
Cc: Reinhard Max <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoinet_diag: fix inet_diag_bc_audit()
Eric Dumazet [Fri, 17 Jun 2011 20:25:39 +0000 (16:25 -0400)]
inet_diag: fix inet_diag_bc_audit()

[ Upstream commit eeb1497277d6b1a0a34ed36b97e18f2bd7d6de0d ]

A malicious user or buggy application can inject code and trigger an
infinite loop in inet_diag_bc_audit()

Also make sure each instruction is aligned on 4 bytes boundary, to avoid
unaligned accesses.

Reported-by: Dan Rosenberg <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agoaf_packet: prevent information leak
Eric Dumazet [Tue, 7 Jun 2011 05:42:06 +0000 (22:42 -0700)]
af_packet: prevent information leak

[ Upstream commit 13fcb7bd322164c67926ffe272846d4860196dc6 ]

In 2.6.27, commit 393e52e33c6c2 (packet: deliver VLAN TCI to userspace)
added a small information leak.

Add padding field and make sure its zeroed before copy to user.

Signed-off-by: Eric Dumazet <>
CC: Patrick McHardy <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
7 years agobridge: provide a cow_metrics method for fake_ops
Alexander Holler [Tue, 7 Jun 2011 07:51:35 +0000 (00:51 -0700)]
bridge: provide a cow_metrics method for fake_ops

[ Upstream commit 6407d74c5106bb362b4087693688afd34942b094 ]

Like in commit 0972ddb237 (provide cow_metrics() methods to blackhole
dst_ops), we must provide a cow_metrics for bridges fake_dst_ops as

This fixes a regression coming from commits 62fa8a846d7d (net: Implement
read-only protection and COW'ing of metrics.) and 33eb9873a28 (bridge:
initialize fake_rtable metrics)

ip link set mybridge mtu 1234
[  136.546243] Pid: 8415, comm: ip Tainted: P #103 ASUSTeK Computer Inc.         V1Sn
[  136.546256] EIP: 0060:[<00000000>] EFLAGS: 00010202 CPU: 0
[  136.546268] EIP is at 0x0
[  136.546273] EAX: f14a389c EBX: 000005d4 ECX: f80d32c0 EDX: f80d1da1
[  136.546279] ESI: f14a3000 EDI: f255bf10 EBP: f15c3b54 ESP: f15c3b48
[  136.546285]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  136.546293] Process ip (pid: 8415, ti=f15c2000 task=f4741f80
[  136.546297] Stack:
[  136.546301]  f80c658f f14a3000 ffffffed f15c3b64 c12cb9c8 f80d1b80
ffffffa1 f15c3bbc
[  136.546315]  c12da347 c12d9c7d 00000000 f7670b00 00000000 f80d1b80
ffffffa6 f15c3be4
[  136.546329]  00000004 f14a3000 f255bf20 00000008 f15c3bbc c11d6cae
00000000 00000000
[  136.546343] Call Trace:
[  136.546359]  [<f80c658f>] ? br_change_mtu+0x5f/0x80 [bridge]
[  136.546372]  [<c12cb9c8>] dev_set_mtu+0x38/0x80
[  136.546381]  [<c12da347>] do_setlink+0x1a7/0x860
[  136.546390]  [<c12d9c7d>] ? rtnl_fill_ifinfo+0x9bd/0xc70
[  136.546400]  [<c11d6cae>] ? nla_parse+0x6e/0xb0
[  136.546409]  [<c12db931>] rtnl_newlink+0x361/0x510
[  136.546420]  [<c1023240>] ? vmalloc_sync_all+0x100/0x100
[  136.546429]  [<c1362762>] ? error_code+0x5a/0x60
[  136.546438]  [<c12db5d0>] ? rtnl_configure_link+0x80/0x80
[  136.546446]  [<c12db27a>] rtnetlink_rcv_msg+0xfa/0x210
[  136.546454]  [<c12db180>] ? __rtnl_unlock+0x20/0x20
[  136.546463]  [<c12ee0fe>] netlink_rcv_skb+0x8e/0xb0
[  136.546471]  [<c12daf1c>] rtnetlink_rcv+0x1c/0x30
[  136.546479]  [<c12edafa>] netlink_unicast+0x23a/0x280
[  136.546487]  [<c12ede6b>] netlink_sendmsg+0x26b/0x2f0
[  136.546497]  [<c12bb828>] sock_sendmsg+0xc8/0x100
[  136.546508]  [<c10adf61>] ? __alloc_pages_nodemask+0xe1/0x750
[  136.546517]  [<c11d0602>] ? _copy_from_user+0x42/0x60
[  136.546525]  [<c12c5e4c>] ? verify_iovec+0x4c/0xc0
[  136.546534]  [<c12bd805>] sys_sendmsg+0x1c5/0x200
[  136.546542]  [<c10c2150>] ? __do_fault+0x310/0x410
[  136.546549]  [<c10c2c46>] ? do_wp_page+0x1d6/0x6b0
[  136.546557]  [<c10c47d1>] ? handle_pte_fault+0xe1/0x720
[  136.546565]  [<c12bd1af>] ? sys_getsockname+0x7f/0x90
[  136.546574]  [<c10c4ec1>] ? handle_mm_fault+0xb1/0x180
[  136.546582]  [<c1023240>] ? vmalloc_sync_all+0x100/0x100
[  136.546589]  [<c10233b3>] ? do_page_fault+0x173/0x3d0
[  136.546596]  [<c12bd87b>] ? sys_recvmsg+0x3b/0x60
[  136.546605]  [<c12bdd83>] sys_socketcall+0x293/0x2d0
[  136.546614]  [<c13629d0>] sysenter_do_call+0x12/0x26
[  136.546619] Code:  Bad EIP value.
[  136.546627] EIP: [<00000000>] 0x0 SS:ESP 0068:f15c3b48
[  136.546645] CR2: 0000000000000000
[  136.546652] ---[ end trace 6909b560e78934fa ]---

Signed-off-by: Alexander Holler <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>