9 years agoi2c-i801: Add device IDs for Intel Lynx Point
Seth Heasley [Mon, 26 Mar 2012 19:47:19 +0000 (21:47 +0200)]
i2c-i801: Add device IDs for Intel Lynx Point

commit 062737fb6d90c632439b1f77ad6a4965cfc84a20 upstream.

Add the SMBus controller device IDs for the Intel Lynx Point PCH.

Signed-off-by: Seth Heasley <>
Signed-off-by: Jean Delvare <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present
Will Deacon [Fri, 10 Aug 2012 16:51:18 +0000 (17:51 +0100)]
ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present

commit 47f1204329237a0f8655f5a9f14a38ac81946ca1 upstream.

Swap entries are encoding in ptes such that !pte_present(pte) and
pte_file(pte). The remaining bits of the descriptor are used to identify
the swapfile and offset within it to the swap entry.

When writing such a pte for a user virtual address, set_pte_at
unconditionally sets the nG bit, which (in the case of LPAE) will
corrupt the swapfile offset and lead to a BUG:

[  140.494067] swap_free: Unused swap offset entry 000763b4
[  140.509989] BUG: Bad page map in process rs:main Q:Reg  pte:0ec76800 pmd:8f92e003

This patch fixes the problem by only setting the nG bit for user
mappings that are actually present.

Reviewed-by: Catalin Marinas <>
Signed-off-by: Will Deacon <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
9 years agoxhci: Fix bug after deq ptr set to link TRB.
Sarah Sharp [Thu, 26 Jul 2012 19:03:59 +0000 (12:03 -0700)]
xhci: Fix bug after deq ptr set to link TRB.

This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches.  The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.

The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB.  The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added.  It assumed that the dequeue pointer could never
point to a link TRB.  It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.

This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land.  It would then read from
that memory to determine if it was a link TRB.  Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.

Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of.  inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.

The only reason the original code worked at all is because there was
only one ring segment.  With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync.  On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:

ERROR Transfer event TRB DMA ptr not part of current TD

This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),

and possibly other general protection fault bugs as well.

This patch should be backported to kernels as old as 2.6.31.  The
original upstream commit is 50d0206fcaea3e736f912fd5b00ec6233fb4ce44,
but it does not apply to kernels older than 3.4, because inc_deq was
changed in 3.3 and 3.4.  This patch should apply to the 3.2 kernel and

Signed-off-by: Sarah Sharp <>
9 years agodrm/i915: Wait for all pending operations to the fb before disabling the pipe
Chris Wilson [Tue, 17 Apr 2012 09:05:38 +0000 (10:05 +0100)]
drm/i915: Wait for all pending operations to the fb before disabling the pipe

During modeset we have to disable the pipe to reconfigure its timings
and maybe its size. Userspace may have queued up command buffers that
depend upon the pipe running in a certain configuration and so the
commands may become confused across the modeset. At the moment, we use a
less than satisfactory kick-scanline-waits should the GPU hang during
the modeset. It should be more reliable to wait for the pending
operations to complete first, even though we still have a window for
userspace to submit a broken command buffer during the modeset.

Signed-off-by: Chris Wilson <>
Signed-off-by: Daniel Vetter <>
(cherry picked from commit 0f91128d88bbb8b0a8e7bb93df2c40680871d45a)

Signed-off-by: Timo Aaltonen <>
9 years agotime: Move ktime_t overflow checking into timespec_valid_strict
John Stultz [Fri, 31 Aug 2012 17:30:06 +0000 (13:30 -0400)]
time: Move ktime_t overflow checking into timespec_valid_strict

This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936

Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with because it caused
timeouts larger then KTIME_T to be invalid.

Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.

This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.

Reported-and-tested-by: Andreas Bombe <>
Cc: Zhouping Liu <>
Cc: Ingo Molnar <>
Cc: Prarit Bhargava <>
Cc: Thomas Gleixner <>
Signed-off-by: John Stultz <>
Signed-off-by: Linus Torvalds <>
Cc: Linux Kernel <>
Signed-off-by: John Stultz <>
9 years agotime: Avoid making adjustments if we haven't accumulated anything
John Stultz [Wed, 22 Aug 2012 00:30:49 +0000 (20:30 -0400)]
time: Avoid making adjustments if we haven't accumulated anything

This is a -stable backport of bf2ac312195155511a0f79325515cbb61929898a

If update_wall_time() is called and the current offset isn't large
enough to accumulate, avoid re-calling timekeeping_adjust which may
change the clock freq and can cause 1ns inconsistencies with

Signed-off-by: John Stultz <>
Cc: Prarit Bhargava <>
Cc: Ingo Molnar <>
Signed-off-by: Thomas Gleixner <>
Cc: Linux Kernel <>
Signed-off-by: John Stultz <>
9 years agotime: Improve sanity checking of timekeeping inputs
John Stultz [Wed, 8 Aug 2012 19:36:20 +0000 (15:36 -0400)]
time: Improve sanity checking of timekeeping inputs

This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b

Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).

Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.

So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.

Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.

Reported-by: CAI Qian <>
Reported-by: Sasha Levin <>
Signed-off-by: John Stultz <>
Cc: Peter Zijlstra <>
Cc: Prarit Bhargava <>
Cc: Zhouping Liu <>
Cc: Ingo Molnar <>
Signed-off-by: Thomas Gleixner <>
Cc: Linux Kernel <>
Signed-off-by: John Stultz <>
9 years agofixing dmi match for hp t5745 and hp st5747 thin client
Marc Gariepy [Tue, 1 May 2012 17:37:57 +0000 (13:37 -0400)]
fixing dmi match for hp t5745 and hp st5747 thin client

commit 62004978df3898649e152751eb6ac264a323ec36 upstream.

Match the correct information which is DMI_PRODUCT_NAME instead of DMI_BOARD_NAME
See dmidecode information on launchpad for both thin client:

Signed-off-by: Marc Gariepy <>
Reviewed-by: Adam Jackson <>
Signed-Off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
9 years agoworkqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic
Lai Jiangshan [Sat, 1 Sep 2012 16:28:19 +0000 (00:28 +0800)]
workqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic

commit 96e65306b81351b656835c15931d1d237b252f27 upstream.

The compiler may compile the following code into TWO write/modify

worker->flags &= ~WORKER_UNBOUND;
worker->flags |= WORKER_REBIND;

so the other CPU may temporarily see worker->flags which doesn't have
either WORKER_UNBOUND or WORKER_REBIND set and perform local wakeup

Fix it by using single explicit assignment via ACCESS_ONCE().

Because idle workers have another WORKER_NOT_RUNNING flag, this bug
doesn't exist for them; however, update it to use the same pattern for

tj: Applied the change to idle workers too and updated comments and
    patch description a bit.

stable: Idle worker rebinding doesn't apply for -stable and
        WORKER_UNBOUND used to be WORKER_ROGUE.  Updated accordingly.

Signed-off-by: Lai Jiangshan <>
Signed-off-by: Tejun Heo <>
9 years agobnx2x: fix 57840_MF pci id
Yuval Mintz [Sun, 26 Aug 2012 00:35:45 +0000 (00:35 +0000)]
bnx2x: fix 57840_MF pci id

[ Upstream commit 5c879d2094946081af934739850c7260e8b25d3c ]

Commit c3def943c7117d42caaed3478731ea7c3c87190e have added support for
new pci ids of the 57840 board, while failing to change the obsolete value
in 'pci_ids.h'.
This patch does so, allowing the probe of such devices.

Signed-off-by: Yuval Mintz <>
Signed-off-by: Eilon Greenstein <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: ipv4: ipmr_expire_timer causes crash when removing net namespace
Francesco Ruggeri [Fri, 24 Aug 2012 07:38:35 +0000 (07:38 +0000)]
net: ipv4: ipmr_expire_timer causes crash when removing net namespace

[ Upstream commit acbb219d5f53821b2d0080d047800410c0420ea1 ]

When tearing down a net namespace, ipv4 mr_table structures are freed
without first deactivating their timers. This can result in a crash in
This patch mimics the corresponding behaviour in ipv6.
Locking and synchronization seem to be adequate.
We are about to kfree mrt, so existing code should already make sure that
no other references to mrt are pending or can be created by incoming traffic.
The functions invoked here do not cause new references to mrt or other
race conditions to be created.
Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive.
Both ipmr_expire_process (whose completion we may have to wait in
del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock
or other synchronizations when needed, and they both only modify mrt.

Tested in Linux 3.4.8.

Signed-off-by: Francesco Ruggeri <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agol2tp: avoid to use synchronize_rcu in tunnel free function [Fri, 24 Aug 2012 01:07:38 +0000 (01:07 +0000)]
l2tp: avoid to use synchronize_rcu in tunnel free function

[ Upstream commit 99469c32f79a32d8481f87be0d3c66dad286f4ec ]

Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be

Signed-off-by: Dmitry Kozlov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agogianfar: fix default tx vlan offload feature flag
Claudiu Manoil [Thu, 23 Aug 2012 21:46:25 +0000 (21:46 +0000)]
gianfar: fix default tx vlan offload feature flag

[ Upstream commit e2c53be223aca36cf93eb6a0f6bafa079e78f52b ]

Commit -
"b852b72 gianfar: fix bug caused by
disables by default (on mac init) the hw vlan tag insertion.
The "features" flags were not updated to reflect this, and
"ethtool -K" shows tx-vlan-offload to be "on" by default.

Cc: Sebastian Poehn <>
Signed-off-by: Claudiu Manoil <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonetlink: fix possible spoofing from non-root processes
Pablo Neira Ayuso [Thu, 23 Aug 2012 02:09:11 +0000 (02:09 +0000)]
netlink: fix possible spoofing from non-root processes

[ Upstream commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef ]

Non-root user-space processes can send Netlink messages to other
processes that are well-known for being subscribed to Netlink
asynchronous notifications. This allows ilegitimate non-root
process to send forged messages to Netlink subscribers.

The userspace process usually verifies the legitimate origin in
two ways:

a) Socket credentials. If UID != 0, then the message comes from
   some ilegitimate process and the message needs to be dropped.

b) Netlink portID. In general, portID == 0 means that the origin
   of the messages comes from the kernel. Thus, discarding any
   message not coming from the kernel.

However, ctnetlink sets the portID in event messages that has
been triggered by some user-space process, eg. conntrack utility.
So other processes subscribed to ctnetlink events, eg. conntrackd,
know that the event was triggered by some user-space action.

Neither of the two ways to discard ilegitimate messages coming
from non-root processes can help for ctnetlink.

This patch adds capability validation in case that dst_pid is set
in netlink_sendmsg(). This approach is aggressive since existing
applications using any Netlink bus to deliver messages between
two user-space processes will break. Note that the exception is
NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
userspace communication.

Still, if anyone wants that his Netlink bus allows netlink-to-netlink
userspace, then they can set NL_NONROOT_SEND. However, by default,
I don't think it makes sense to allow to use NETLINK_ROUTE to
communicate two processes that are sending no matter what information
that is not related to link/neighbouring/routing. They should be using
NETLINK_USERSOCK instead for that.

Signed-off-by: Pablo Neira Ayuso <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoaf_netlink: force credentials passing [CVE-2012-3520]
Eric Dumazet [Tue, 21 Aug 2012 06:21:17 +0000 (06:21 +0000)]
af_netlink: force credentials passing [CVE-2012-3520]

[ Upstream commit e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea ]

Pablo Neira Ayuso discovered that avahi and
potentially NetworkManager accept spoofed Netlink messages because of a
kernel bug.  The kernel passes all-zero SCM_CREDENTIALS ancillary data
to the receiver if the sender did not provide such data, instead of not
including any such data at all or including the correct data from the
peer (as it is the case with AF_UNIX).

This bug was introduced in commit 16e572626961
(af_unix: dont send SCM_CREDENTIALS by default)

This patch forces passing credentials for netlink, as
before the regression.

Another fix would be to not add SCM_CREDENTIALS in
netlink messages if not provided by the sender, but it
might break some programs.

With help from Florian Weimer & Petr Matousek

This issue is designated as CVE-2012-3520

Signed-off-by: Eric Dumazet <>
Cc: Petr Matousek <>
Cc: Florian Weimer <>
Cc: Pablo Neira Ayuso <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoaf_packet: don't emit packet on orig fanout group
Eric Leblond [Thu, 16 Aug 2012 22:02:58 +0000 (22:02 +0000)]
af_packet: don't emit packet on orig fanout group

[ Upstream commit c0de08d04215031d68fa13af36f347a6cfa252ca ]

If a packet is emitted on one socket in one group of fanout sockets,
it is transmitted again. It is thus read again on one of the sockets
of the fanout group. This result in a loop for software which
generate packets when receiving one.
This retransmission is not the intended behavior: a fanout group
must behave like a single socket. The packet should not be
transmitted on a socket if it originates from a socket belonging
to the same fanout group.

This patch fixes the issue by changing the transmission check to
take fanout group info account.

Reported-by: Aleksandr Kotov <>
Signed-off-by: Eric Leblond <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: fix info leak in compat dev_ifconf()
Mathias Krause [Wed, 15 Aug 2012 11:31:57 +0000 (11:31 +0000)]
net: fix info leak in compat dev_ifconf()

[ Upstream commit 43da5f2e0d0c69ded3d51907d9552310a6b545e8 ]

The implementation of dev_ifconf() for the compat ioctl interface uses
an intermediate ifc structure allocated in userland for the duration of
the syscall. Though, it fails to initialize the padding bytes inserted
for alignment and that for leaks four bytes of kernel stack. Add an
explicit memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)
Mathias Krause [Wed, 15 Aug 2012 11:31:56 +0000 (11:31 +0000)]
ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)

[ Upstream commit 2d8a041b7bfe1097af21441cb77d6af95f4f4680 ]

not set, __ip_vs_get_timeouts() does not fully initialize the structure
that gets copied to userland and that for leaks up to 12 bytes of kernel
stack. Add an explicit memset(0) before passing the structure to
__ip_vs_get_timeouts() to avoid the info leak.

Signed-off-by: Mathias Krause <>
Cc: Wensong Zhang <>
Cc: Simon Horman <>
Cc: Julian Anastasov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agodccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)
Mathias Krause [Wed, 15 Aug 2012 11:31:55 +0000 (11:31 +0000)]
dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)

[ Upstream commit 7b07f8eb75aa3097cdfd4f6eac3da49db787381d ]

The CCID3 code fails to initialize the trailing padding bytes of struct
tfrc_tx_info added for alignment on 64 bit architectures. It that for
potentially leaks four bytes kernel stack via the getsockopt() syscall.
Add an explicit memset(0) before filling the structure to avoid the
info leak.

Signed-off-by: Mathias Krause <>
Cc: Gerrit Renker <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agollc: fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:53 +0000 (11:31 +0000)]
llc: fix info leak via getsockname()

[ Upstream commit 3592aaeb80290bda0f2cf0b5456c97bfc638b192 ]

The LLC code wrongly returns 0, i.e. "success", when the socket is
zapped. Together with the uninitialized uaddrlen pointer argument from
sys_getsockname this leads to an arbitrary memory leak of up to 128
bytes kernel stack via the getsockname() syscall.

Return an error instead when the socket is zapped to prevent the info
leak. Also remove the unnecessary memset(0). We don't directly write to
the memory pointed by uaddr but memcpy() a local structure at the end of
the function that is properly initialized.

Signed-off-by: Mathias Krause <>
Cc: Arnaldo Carvalho de Melo <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: L2CAP - Fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:51 +0000 (11:31 +0000)]
Bluetooth: L2CAP - Fix info leak via getsockname()

[ Upstream commit 792039c73cf176c8e39a6e8beef2c94ff46522ed ]

The L2CAP code fails to initialize the l2_bdaddr_type member of struct
sockaddr_l2 and the padding byte added for alignment. It that for leaks
two bytes kernel stack via the getsockname() syscall. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <>
Cc: Marcel Holtmann <>
Cc: Gustavo Padovan <>
Cc: Johan Hedberg <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: RFCOMM - Fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:50 +0000 (11:31 +0000)]
Bluetooth: RFCOMM - Fix info leak via getsockname()

[ Upstream commit 9344a972961d1a6d2c04d9008b13617bcb6ec2ef ]

The RFCOMM code fails to initialize the trailing padding byte of struct
sockaddr_rc added for alignment. It that for leaks one byte kernel stack
via the getsockname() syscall. Add an explicit memset(0) before filling
the structure to avoid the info leak.

Signed-off-by: Mathias Krause <>
Cc: Marcel Holtmann <>
Cc: Gustavo Padovan <>
Cc: Johan Hedberg <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)
Mathias Krause [Wed, 15 Aug 2012 11:31:49 +0000 (11:31 +0000)]
Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)

[ Upstream commit f9432c5ec8b1e9a09b9b0e5569e3c73db8de432a ]

The RFCOMM code fails to initialize the two padding bytes of struct
rfcomm_dev_list_req inserted for alignment before copying it to
userland. Additionally there are two padding bytes in each instance of
struct rfcomm_dev_info. The ioctl() that for disclosures two bytes plus
dev_num times two bytes uninitialized kernel heap memory.

Allocate the memory using kzalloc() to fix this issue.

Signed-off-by: Mathias Krause <>
Cc: Marcel Holtmann <>
Cc: Gustavo Padovan <>
Cc: Johan Hedberg <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)
Mathias Krause [Wed, 15 Aug 2012 11:31:48 +0000 (11:31 +0000)]
Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)

[ Upstream commit 9ad2de43f1aee7e7274a4e0d41465489299e344b ]

The RFCOMM code fails to initialize the key_size member of struct
bt_security before copying it to userland -- that for leaking one
byte kernel stack. Initialize key_size with 0 to avoid the info

Signed-off-by: Mathias Krause <>
Cc: Marcel Holtmann <>
Cc: Gustavo Padovan <>
Cc: Johan Hedberg <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: HCI - Fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:47 +0000 (11:31 +0000)]
Bluetooth: HCI - Fix info leak via getsockname()

[ Upstream commit 3f68ba07b1da811bf383b4b701b129bfcb2e4988 ]

The HCI code fails to initialize the hci_channel member of struct
sockaddr_hci and that for leaks two bytes kernel stack via the
getsockname() syscall. Initialize hci_channel with 0 to avoid the
info leak.

Signed-off-by: Mathias Krause <>
Cc: Marcel Holtmann <>
Cc: Gustavo Padovan <>
Cc: Johan Hedberg <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)
Mathias Krause [Wed, 15 Aug 2012 11:31:46 +0000 (11:31 +0000)]
Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)

[ Upstream commit e15ca9a0ef9a86f0477530b0f44a725d67f889ee ]

The HCI code fails to initialize the two padding bytes of struct
hci_ufilter before copying it to userland -- that for leaking two
bytes kernel stack. Add an explicit memset(0) before filling the
structure to avoid the info leak.

Signed-off-by: Mathias Krause <>
Cc: Marcel Holtmann <>
Cc: Gustavo Padovan <>
Cc: Johan Hedberg <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoatm: fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:45 +0000 (11:31 +0000)]
atm: fix info leak via getsockname()

[ Upstream commit 3c0c5cfdcd4d69ffc4b9c0907cec99039f30a50a ]

The ATM code fails to initialize the two padding bytes of struct
sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoatm: fix info leak in getsockopt(SO_ATMPVC)
Mathias Krause [Wed, 15 Aug 2012 11:31:44 +0000 (11:31 +0000)]
atm: fix info leak in getsockopt(SO_ATMPVC)

[ Upstream commit e862f1a9b7df4e8196ebec45ac62295138aa3fc2 ]

The ATM code fails to initialize the two padding bytes of struct
sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock
Ben Hutchings [Tue, 14 Aug 2012 08:54:51 +0000 (08:54 +0000)]
ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock

[ Upstream commit 4acd4945cd1e1f92b20d14e349c6c6a52acbd42d ]

Cong Wang reports that lockdep detected suspicious RCU usage while
enabling IPV6 forwarding:

 [ 1123.310275] ===============================
 [ 1123.442202] [ INFO: suspicious RCU usage. ]
 [ 1123.558207] 3.6.0-rc1+ #109 Not tainted
 [ 1123.665204] -------------------------------
 [ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section!
 [ 1123.992320]
 [ 1123.992320] other info that might help us debug this:
 [ 1123.992320]
 [ 1124.307382]
 [ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0
 [ 1124.522220] 2 locks held by sysctl/5710:
 [ 1124.648364]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81768498>] rtnl_trylock+0x15/0x17
 [ 1124.882211]  #1:  (rcu_read_lock){.+.+.+}, at: [<ffffffff81871df8>] rcu_lock_acquire+0x0/0x29
 [ 1125.085209]
 [ 1125.085209] stack backtrace:
 [ 1125.332213] Pid: 5710, comm: sysctl Not tainted 3.6.0-rc1+ #109
 [ 1125.441291] Call Trace:
 [ 1125.545281]  [<ffffffff8109d915>] lockdep_rcu_suspicious+0x109/0x112
 [ 1125.667212]  [<ffffffff8107c240>] rcu_preempt_sleep_check+0x45/0x47
 [ 1125.781838]  [<ffffffff8107c260>] __might_sleep+0x1e/0x19b
 [ 1127.445223]  [<ffffffff81757ac5>] call_netdevice_notifiers+0x4a/0x4f
 [ 1127.772188]  [<ffffffff8175e125>] dev_disable_lro+0x32/0x6b
 [ 1127.885174]  [<ffffffff81872d26>] dev_forward_change+0x30/0xcb
 [ 1128.013214]  [<ffffffff818738c4>] addrconf_forward_change+0x85/0xc5

addrconf_forward_change() uses RCU iteration over the netdev list,
which is unnecessary since it already holds the RTNL lock.  We also
cannot reasonably require netdevice notifier functions not to sleep.

Reported-by: Cong Wang <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoaf_packet: remove BUG statement in tpacket_destruct_skb [Fri, 10 Aug 2012 22:48:54 +0000 (22:48 +0000)]
af_packet: remove BUG statement in tpacket_destruct_skb

[ Upstream commit 7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 ]

Here's a quote of the comment about the BUG macro from asm-generic/bug.h:

 Don't use BUG() or BUG_ON() unless there's really no way out; one
 example might be detecting data structure corruption in the middle
 of an operation that can't be backed out of.  If the (sub)system
 can somehow continue operating, perhaps with reduced functionality,
 it's probably not BUG-worthy.

 If you're tempted to BUG(), think again:  is completely giving up
 really the *only* solution?  There are usually better options, where
 users don't need to reboot ASAP and can mostly shut down cleanly.

In our case, the status flag of a ring buffer slot is managed from both sides,
the kernel space and the user space. This means that even though the kernel
side might work as expected, the user space screws up and changes this flag
right between the send(2) is triggered when the flag is changed to
TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
will hit the BUG macro. As David suggested, the best solution is to simply
remove this statement since it cannot be used for kernel side internal
consistency checks. I've tested it and the system still behaves /stable/ in
this case, so in accordance with the above comment, we should rather remove it.

Signed-off-by: Daniel Borkmann <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet/core: Fix potential memory leak in dev_set_alias()
Alexey Khoroshilov [Wed, 8 Aug 2012 00:33:25 +0000 (00:33 +0000)]
net/core: Fix potential memory leak in dev_set_alias()

[ Upstream commit 7364e445f62825758fa61195d237a5b8ecdd06ec ]

Do not leak memory by updating pointer with potentially NULL realloc return value.

Found by Linux Driver Verification project (

Signed-off-by: Alexey Khoroshilov <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agopptp: lookup route with the proper net namespace
Gao feng [Tue, 7 Aug 2012 00:23:11 +0000 (00:23 +0000)]
pptp: lookup route with the proper net namespace

[ Upstream commit 08252b32311c3fa84219ad794d640af7399b5485 ]

pptp always use init_net as the net namespace to lookup
route, this will cause route lookup failed in container.

because we already set the correct net namespace to struct
sock in pptp_create,so fix this by using sock_net(sk) to
replace &init_net.

Signed-off-by: Gao feng <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoisdnloop: fix and simplify isdnloop_init()
Wu Fengguang [Thu, 2 Aug 2012 23:10:01 +0000 (23:10 +0000)]
isdnloop: fix and simplify isdnloop_init()

[ Upstream commit 77f00f6324cb97cf1df6f9c4aaeea6ada23abdb2 ]

Fix a buffer overflow bug by removing the revision and printk.

[   22.016214] isdnloop-ISDN-driver Rev
[   22.097508] isdnloop: (loop0) virtual card added
[   22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
[   22.174400]
[   22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
[   22.624071] Call Trace:
[   22.720558]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[   22.815248]  [<ffffffff8222b623>] panic+0x110/0x329
[   22.914330]  [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
[   23.014800]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[   23.090763]  [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
[   23.185748]  [<ffffffff83244972>] isdnloop_init+0xaf/0xb1

Signed-off-by: Fengguang Wu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet_sched: gact: Fix potential panic in tcf_gact().
Hiroaki SHIMODA [Fri, 3 Aug 2012 10:57:52 +0000 (19:57 +0900)]
net_sched: gact: Fix potential panic in tcf_gact().

[ Upstream commit 696ecdc10622d86541f2e35cc16e15b6b3b1b67e ]

gact_rand array is accessed by gact->tcfg_ptype whose value
is assumed to less than MAX_RAND, but any range checks are
not performed.

So add a check in tcf_gact_init(). And in tcf_gact(), we can
reduce a branch.

Signed-off-by: Hiroaki SHIMODA <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agotcp: Apply device TSO segment limit earlier
Ben Hutchings [Mon, 30 Jul 2012 16:11:42 +0000 (16:11 +0000)]
tcp: Apply device TSO segment limit earlier

[ Upstream commit 1485348d2424e1131ea42efc033cbd9366462b01 ]

Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
limit the size of TSO skbs.  This avoids the need to fall back to
software GSO for local TCP senders.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agosfc: Fix maximum number of TSO segments and minimum TX queue size
Ben Hutchings [Mon, 30 Jul 2012 15:57:44 +0000 (15:57 +0000)]
sfc: Fix maximum number of TSO segments and minimum TX queue size

[ Upstream commit 7e6d06f0de3f74ca929441add094518ae332257c ]

Currently an skb requiring TSO may not fit within a minimum-size TX
queue.  The TX queue selected for the skb may stall and trigger the TX
watchdog repeatedly (since the problem skb will be retried after the
TX reset).  This issue is designated as CVE-2012-3412.

Set the maximum number of TSO segments for our devices to 100.  This
should make no difference to behaviour unless the actual MSS is less
than about 700.  Increase the minimum TX queue size accordingly to
allow for 2 worst-case skbs, so that there will definitely be space
to add an skb after we wake a queue.

To avoid invalidating existing configurations, change
efx_ethtool_set_ringparam() to fix up values that are too small rather
than returning -EINVAL.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: Allow driver to limit number of GSO segments per skb
Ben Hutchings [Mon, 30 Jul 2012 15:57:00 +0000 (15:57 +0000)]
net: Allow driver to limit number of GSO segments per skb

[ Upstream commit 30b678d844af3305cda5953467005cebb5d7b687 ]

A peer (or local user) may cause TCP to use a nominal MSS of as little
as 88 (actual MSS of 76 with timestamps).  Given that we have a
sufficiently prodigious local sender and the peer ACKs quickly enough,
it is nevertheless possible to grow the window for such a connection
to the point that we will try to send just under 64K at once.  This
results in a single skb that expands to 861 segments.

In some drivers with TSO support, such an skb will require hundreds of
DMA descriptors; a substantial fraction of a TX ring or even more than
a full ring.  The TX queue selected for the skb may stall and trigger
the TX watchdog repeatedly (since the problem skb will be retried
after the TX reset).  This particularly affects sfc, for which the
issue is designated as CVE-2012-3412.

1. Add the field net_device::gso_max_segs holding the device-specific
2. In netif_skb_features(), if the number of segments is too high then
   mask out GSO features to force fall back to software GSO.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoi2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DES...
Axel Lin [Mon, 10 Sep 2012 08:14:02 +0000 (10:14 +0200)]
i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y

commit e68bb91baa0bb9817567bd45d560919e8e26373b upstream.

This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let

Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as
built-in or module, we also need to export the functions in i2c-designware-core.

This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y &&

  LD      drivers/i2c/busses/built-in.o
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int':
i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init':
i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl':
i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr':
i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer':
i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled':
i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel':
i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg':
i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable':
i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param':
i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable':
i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func':
i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int':
i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here
make[3]: *** [drivers/i2c/busses/built-in.o] Error 1
make[2]: *** [drivers/i2c/busses] Error 2
make[1]: *** [drivers/i2c] Error 2
make: *** [drivers] Error 2

Signed-off-by: Axel Lin <>
Signed-off-by: Jean Delvare <>
Tested-by: Jiri Slaby <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot
Dave Airlie [Wed, 29 Aug 2012 01:40:51 +0000 (21:40 -0400)]
drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot

commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.

This will cause udev to load vmwgfx instead of waiting for X
to do it.

Reviewed-by: Jakob Bornecrantz <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agoCIFS: Fix error handling in cifs_push_mandatory_locks
Pavel Shilovsky [Wed, 29 Aug 2012 17:13:38 +0000 (21:13 +0400)]
CIFS: Fix error handling in cifs_push_mandatory_locks

commit e2f2886a824ff0a56da1eaa13019fde86aa89fa6 upstream.

Signed-off-by: Pavel Shilovsky <>
Signed-off-by: Steve French <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoRemove user-triggerable BUG from mpol_to_str
Dave Jones [Thu, 6 Sep 2012 16:01:00 +0000 (12:01 -0400)]
Remove user-triggerable BUG from mpol_to_str

commit 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a upstream.

Trivially triggerable, found by trinity:

  kernel BUG at mm/mempolicy.c:2546!
  Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670)
  Call Trace:
  RIP: mpol_to_str+0x156/0x360

Signed-off-by: Dave Jones <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agoxen: Use correct masking in xen_swiotlb_alloc_coherent.
Ronny Hegewald [Fri, 31 Aug 2012 09:57:52 +0000 (09:57 +0000)]
xen: Use correct masking in xen_swiotlb_alloc_coherent.

commit b5031ed1be0aa419250557123633453753181643 upstream.

When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.

The underlaying reason is that if the supplied driver passes in a
DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff)
our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
By using the dma_alloc_coherent_mask function - it does the proper casting
and we get 0xfffffffff.

This caused not working sound on a system with 4 GB and a 64-bit
compatible sound-card with sets the DMA-mask to 64bit.

On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
DMA-memory is always allocated inside the 32-bit address-range by calling

This patch adds the same functionality to xen swiotlb and is a rebase of the
original patch from Ronny Hegewald which never got upstream b/c the
underlaying reason was not understood until now.

The original email with the original patch is in:
the original thread from where the discussion started is in:

Signed-off-by: Ronny Hegewald <>
Signed-off-by: Stefano Panella <>
Acked-By: David Vrabel <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
9 years agoudf: Fix data corruption for files in ICB
Jan Kara [Wed, 5 Sep 2012 13:48:23 +0000 (15:48 +0200)]
udf: Fix data corruption for files in ICB

commit 9c2fc0de1a6e638fe58c354a463f544f42a90a09 upstream.

When a file is stored in ICB (inode), we overwrite part of the file, and
the page containing file's data is not in page cache, we end up corrupting
file's data by overwriting them with zeros. The problem is we use
simple_write_begin() which simply zeroes parts of the page which are not
written to. The problem has been introduced by be021ee4 (udf: convert to
new aops).

Fix the problem by providing a ->write_begin function which makes the page
properly uptodate.

Reported-by: Ian Abbott <>
Signed-off-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc: Make sure IPI handlers see data written by IPI senders
Paul Mackerras [Tue, 4 Sep 2012 18:33:08 +0000 (18:33 +0000)]
powerpc: Make sure IPI handlers see data written by IPI senders

commit 9fb1b36ca1234e64a5d1cc573175303395e3354d upstream.

We have been observing hangs, both of KVM guest vcpu tasks and more
generally, where a process that is woken doesn't properly wake up and
continue to run, but instead sticks in TASK_WAKING state.  This
happens because the update of rq->wake_list in ttwu_queue_remote()
is not ordered with the update of ipi_message in
smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
scheduler_ipi() is not ordered with the reading of ipi_message in
smp_ipi_demux().  Thus it is possible for the IPI receiver not to see
the updated rq->wake_list and therefore conclude that there is nothing
for it to do.

In order to make sure that anything done before smp_send_reschedule()
is ordered before anything done in the resulting call to scheduler_ipi(),
this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
The barrier in smp_muxed_message_pass() is a full barrier to ensure that
there is a full ordering between the smp_send_reschedule() caller and
scheduler_ipi().  In smp_ipi_demux(), we use xchg() rather than
xchg_local() because xchg() includes release and acquire barriers.
Using xchg() rather than xchg_local() makes sense given that
ipi_message is not just accessed locally.

This moves the barrier between setting the message and calling the
cause_ipi() function into the individual cause_ipi implementations.
Most of them -- those that used outb, out_8 or similar -- already had
a full barrier because out_8 etc. include a sync before the MMIO
store.  This adds an explicit barrier in the two remaining cases.

These changes made no measurable difference to the speed of IPIs as
measured using a simple ping-pong latency test across two CPUs on
different cores of a POWER7 machine.

The analysis of the reason why processes were not waking up properly
is due to Milton Miller.

Reported-by: Milton Miller <>
Signed-off-by: Paul Mackerras <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc/xics: Harden xics hypervisor backend
Anton Blanchard [Thu, 24 Nov 2011 19:39:36 +0000 (19:39 +0000)]
powerpc/xics: Harden xics hypervisor backend

commit 3ce21cdfe93efffa4ffba9cf3ca2576d3d60d6dc upstream.

During kdump stress testing I sometimes see the kdump kernel panic

  Interrupt 0x306 (real) is invalid, disabling it.
  Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306

Instead of panicing print the error message, dump the stack the first
time it happens and continue on. Add some more information to the
debug messages as well.

Signed-off-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc: Restore correct DSCR in context switch
Anton Blanchard [Mon, 3 Sep 2012 16:51:10 +0000 (16:51 +0000)]
powerpc: Restore correct DSCR in context switch

commit 714332858bfd40dcf8f741498336d93875c23aa7 upstream.

During a context switch we always restore the per thread DSCR value.
If we aren't doing explicit DSCR management
(ie thread.dscr_inherit == 0) and the default DSCR changed while
the process has been sleeping we end up with the wrong value.

Check thread.dscr_inherit and select the default DSCR or per thread
DSCR as required.

This was found with the following test case, when running with
more threads than CPUs (ie forcing context switching):

With the four patches applied I can run a combination of all
test cases successfully at the same time:

Signed-off-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc: Fix DSCR inheritance in copy_thread()
Anton Blanchard [Mon, 3 Sep 2012 16:49:47 +0000 (16:49 +0000)]
powerpc: Fix DSCR inheritance in copy_thread()

commit 1021cb268b3025573c4811f1dee4a11260c4507b upstream.

If the default DSCR is non zero we set thread.dscr_inherit in
copy_thread() meaning the new thread and all its children will ignore
future updates to the default DSCR. This is not intended and is
a change in behaviour that a number of our users have hit.

We just need to inherit thread.dscr and thread.dscr_inherit from
the parent which ends up being much simpler.

This was found with the following test case:

Signed-off-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc: Keep thread.dscr and thread.dscr_inherit in sync
Anton Blanchard [Mon, 3 Sep 2012 16:48:46 +0000 (16:48 +0000)]
powerpc: Keep thread.dscr and thread.dscr_inherit in sync

commit 00ca0de02f80924dfff6b4f630e1dff3db005e35 upstream.

When we update the DSCR either via emulation of mtspr(DSCR) or via
a change to dscr_default in sysfs we don't update thread.dscr.
We will eventually update it at context switch time but there is
a period where thread.dscr is incorrect.

If we fork at this point we will copy the old value of thread.dscr
into the child. To avoid this, always keep thread.dscr in sync with

This issue was found with the following testcase:

Signed-off-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Ben Hutchings <>
9 years agopowerpc: Update DSCR on all CPUs when writing sysfs dscr_default
Anton Blanchard [Mon, 3 Sep 2012 16:47:56 +0000 (16:47 +0000)]
powerpc: Update DSCR on all CPUs when writing sysfs dscr_default

commit 1b6ca2a6fe56e7697d57348646e07df08f43b1bb upstream.

Writing to dscr_default in sysfs doesn't actually change the DSCR -
we rely on a context switch on each CPU to do the work. There is no
guarantee we will get a context switch in a reasonable amount of time
so fire off an IPI to force an immediate change.

This issue was found with the following test case:

Signed-off-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agommc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.
Ian Chen [Wed, 29 Aug 2012 06:05:36 +0000 (15:05 +0900)]
mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.

commit 3550ccdb9d8d350e526b809bf3dd92b550a74fe1 upstream.

For several MoviNAND eMMC parts, there are known issues with secure
erase and secure trim.  For these specific MoviNAND devices, we skip
these operations.

Specifically, there is a bug in the eMMC firmware that causes
unrecoverable corruption when the MMC is erased with MMC_CAP_ERASE


Signed-off-by: Ian Chen <>
Reviewed-by: Namjae Jeon <>
Acked-by: Jaehoon Chung <>
Reviewed-by: Linus Walleij <>
Signed-off-by: Chris Ball <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agommc: sdhci-esdhc: break out early if clock is 0
Shawn Guo [Wed, 22 Aug 2012 15:10:01 +0000 (23:10 +0800)]
mmc: sdhci-esdhc: break out early if clock is 0

commit 74f330bceaa7b88d06062e1cac3d519a3dfc041e upstream.

Since commit 30832ab56 ("mmc: sdhci: Always pass clock request value
zero to set_clock host op") was merged, esdhc_set_clock starts hitting
"if (clock == 0)" where ESDHC_SYSTEM_CONTROL has been operated.  This
causes SDHCI card-detection function being broken.  Fix the regression
by moving "if (clock == 0)" above ESDHC_SYSTEM_CONTROL operation.

Signed-off-by: Shawn Guo <>
Signed-off-by: Chris Ball <>
Signed-off-by: Ben Hutchings <>
9 years agommc: mxs-mmc: fix deadlock caused by recursion loop
Lauri Hintsala [Tue, 17 Jul 2012 14:16:10 +0000 (17:16 +0300)]
mmc: mxs-mmc: fix deadlock caused by recursion loop

commit fc108d24d3a6da63576a460e122fa1df0cbdea20 upstream.

Release the lock before mmc_signal_sdio_irq is called by

[   65.470000] =============================================
[   65.470000] [ INFO: possible recursive locking detected ]
[   65.470000] 3.5.0-rc5 #2 Not tainted
[   65.470000] ---------------------------------------------
[   65.470000] ksdioirqd/mmc0/73 is trying to acquire lock:
[   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
[   65.470000]
[   65.470000] but task is already holding lock:
[   65.470000]  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
[   65.470000]
[   65.470000] other info that might help us debug this:
[   65.470000]  Possible unsafe locking scenario:
[   65.470000]
[   65.470000]        CPU0
[   65.470000]        ----
[   65.470000]   lock(&(&host->lock)->rlock#2);
[   65.470000]   lock(&(&host->lock)->rlock#2);
[   65.470000]
[   65.470000]  *** DEADLOCK ***
[   65.470000]
[   65.470000]  May be due to missing lock nesting notation
[   65.470000]
[   65.470000] 1 lock held by ksdioirqd/mmc0/73:
[   65.470000]  #0:  (&(&host->lock)->rlock#2){-.-...}, at: [<bf054120>] mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]
[   65.470000]
[   65.470000] stack backtrace:
[   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98)
[   65.470000] [<c005ccb8>] (__lock_acquire+0x14f8/0x1b98) from [<c005d3f8>] (lock_acquire+0xa0/0x108)
[   65.470000] [<c005d3f8>] (lock_acquire+0xa0/0x108) from [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c)
[   65.470000] [<c02f671c>] (_raw_spin_lock_irqsave+0x48/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
[   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
[   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
[   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
[   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)
[   65.470000] BUG: spinlock lockup suspected on CPU#0, ksdioirqd/mmc0/73
[   65.470000]  lock: 0xc3358724, .magic: dead4ead, .owner: ksdioirqd/mmc0/73, .owner_cpu: 0
[   65.470000] [<c0014990>] (unwind_backtrace+0x0/0xf4) from [<c01b46b0>] (do_raw_spin_lock+0x100/0x144)
[   65.470000] [<c01b46b0>] (do_raw_spin_lock+0x100/0x144) from [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c)
[   65.470000] [<c02f6724>] (_raw_spin_lock_irqsave+0x50/0x5c) from [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc])
[   65.470000] [<bf054120>] (mxs_mmc_enable_sdio_irq+0x18/0xdc [mxs_mmc]) from [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc])
[   65.470000] [<bf0541d0>] (mxs_mmc_enable_sdio_irq+0xc8/0xdc [mxs_mmc]) from [<c0219b38>] (sdio_irq_thread+0x1bc/0x274)
[   65.470000] [<c0219b38>] (sdio_irq_thread+0x1bc/0x274) from [<c003c324>] (kthread+0x8c/0x98)
[   65.470000] [<c003c324>] (kthread+0x8c/0x98) from [<c00101ac>] (kernel_thread_exit+0x0/0x8)

Reported-by: Attila Kinali <>
Signed-off-by: Lauri Hintsala <>
Acked-by: Shawn Guo <>
Signed-off-by: Chris Ball <>
[bwh: Backported to 3.2:
 - Adjust context
 - HW_SSP_STATUS is a simple rather than function-like macro]
Signed-off-by: Ben Hutchings <>
9 years agommc: mxs-mmc: fix deadlock in SDIO IRQ case
Lauri Hintsala [Tue, 17 Jul 2012 14:16:09 +0000 (17:16 +0300)]
mmc: mxs-mmc: fix deadlock in SDIO IRQ case

commit 1af36b2a993dddfa3d6860ec4879c9e8abc9b976 upstream.

Release the lock before mmc_signal_sdio_irq is called by mxs_mmc_irq_handler.

[   79.660000] =============================================
[   79.660000] [ INFO: possible recursive locking detected ]
[   79.660000] 3.4.0-00009-g3e96082-dirty #11 Not tainted
[   79.660000] ---------------------------------------------
[   79.660000] swapper/0 is trying to acquire lock:
[   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026ea3c>] mxs_mmc_enable_sdio_irq+0x18/0xd4
[   79.660000]
[   79.660000] but task is already holding lock:
[   79.660000]  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
[   79.660000]
[   79.660000] other info that might help us debug this:
[   79.660000]  Possible unsafe locking scenario:
[   79.660000]
[   79.660000]        CPU0
[   79.660000]        ----
[   79.660000]   lock(&(&host->lock)->rlock#2);
[   79.660000]   lock(&(&host->lock)->rlock#2);
[   79.660000]
[   79.660000]  *** DEADLOCK ***
[   79.660000]
[   79.660000]  May be due to missing lock nesting notation
[   79.660000]
[   79.660000] 1 lock held by swapper/0:
[   79.660000]  #0:  (&(&host->lock)->rlock#2){-.....}, at: [<c026f744>] mxs_mmc_irq_handler+0x1c/0xe8
[   79.660000]
[   79.660000] stack backtrace:
[   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c005f9c0>] (__lock_acquire+0x1948/0x1d48)
[   79.660000] [<c005f9c0>] (__lock_acquire+0x1948/0x1d48) from [<c005fea0>] (lock_acquire+0xe0/0xf8)
[   79.660000] [<c005fea0>] (lock_acquire+0xe0/0xf8) from [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58)
[   79.660000] [<c03a8460>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
[   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
[   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
[   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
[   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
[   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
[   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
[   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
[   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
[   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
[   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)
[   79.660000] BUG: spinlock lockup on CPU#0, swapper/0
[   79.660000]  lock: c398cb2c, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
[   79.660000] [<c0014bd0>] (unwind_backtrace+0x0/0xf4) from [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144)
[   79.660000] [<c01ddb1c>] (do_raw_spin_lock+0xf0/0x144) from [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58)
[   79.660000] [<c03a8468>] (_raw_spin_lock_irqsave+0x4c/0x58) from [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4)
[   79.660000] [<c026ea3c>] (mxs_mmc_enable_sdio_irq+0x18/0xd4) from [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8)
[   79.660000] [<c026f7fc>] (mxs_mmc_irq_handler+0xd4/0xe8) from [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254)
[   79.660000] [<c006bdd8>] (handle_irq_event_percpu+0x70/0x254) from [<c006bff8>] (handle_irq_event+0x3c/0x5c)
[   79.660000] [<c006bff8>] (handle_irq_event+0x3c/0x5c) from [<c006e6d0>] (handle_level_irq+0x90/0x110)
[   79.660000] [<c006e6d0>] (handle_level_irq+0x90/0x110) from [<c006b930>] (generic_handle_irq+0x38/0x50)
[   79.660000] [<c006b930>] (generic_handle_irq+0x38/0x50) from [<c00102fc>] (handle_IRQ+0x30/0x84)
[   79.660000] [<c00102fc>] (handle_IRQ+0x30/0x84) from [<c000f058>] (__irq_svc+0x38/0x60)
[   79.660000] [<c000f058>] (__irq_svc+0x38/0x60) from [<c0010520>] (default_idle+0x2c/0x40)
[   79.660000] [<c0010520>] (default_idle+0x2c/0x40) from [<c0010a90>] (cpu_idle+0x64/0xcc)
[   79.660000] [<c0010a90>] (cpu_idle+0x64/0xcc) from [<c04ff858>] (start_kernel+0x244/0x2c8)

Signed-off-by: Lauri Hintsala <>
Acked-by: Shawn Guo <>
Signed-off-by: Chris Ball <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agofuse: fix retrieve length
Miklos Szeredi [Tue, 4 Sep 2012 16:45:54 +0000 (18:45 +0200)]
fuse: fix retrieve length

commit c9e67d483776d8d2a5f3f70491161b205930ffe1 upstream.

In some cases fuse_retrieve() would return a short byte count if offset was
non-zero.  The data returned was correct, though.

Signed-off-by: Miklos Szeredi <>
Signed-off-by: Ben Hutchings <>
9 years agoUBI: fix a horrible memory deallocation bug
Artem Bityutskiy [Mon, 3 Sep 2012 14:12:29 +0000 (17:12 +0300)]
UBI: fix a horrible memory deallocation bug

commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream.

UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when
freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened
only when we were doing auto-format, so many systems were unaffected. However,
there are still many users affected.

It is strange, but the system did not crash and nothing bad happened when
the SLUB memory allocator was used. However, in case of SLOB we observed an
crash right away.

This problem was introduced in 2.6.39 by commit
"6c1e875 UBI: add slab cache for ubi_scan_leb objects"

A note for stable trees:
  Because variable were renamed, this won't cleanly apply to older kernels.
  Changing names like this should help:
1. ai -> si
2. aeb_slab_cache -> seb_slab_cache
3. new_aeb -> new_seb

Reported-by: Richard Genoud <>
Tested-by: Richard Genoud <>
Tested-by: Artem Bityutskiy <>
Signed-off-by: Artem Bityutskiy <>
[bwh: Backported to 3.2: aeb_slab_cache was actually named scan_leb_slab]
Signed-off-by: Ben Hutchings <>
9 years agoext3: Fix fdatasync() for files with only i_size changes
Jan Kara [Mon, 3 Sep 2012 14:50:42 +0000 (16:50 +0200)]
ext3: Fix fdatasync() for files with only i_size changes

commit 156bddd8e505b295540f3ca0e27dda68cb0d49aa upstream.

Code tracking when transaction needs to be committed on fdatasync(2) forgets
to handle a situation when only inode's i_size is changed. Thus in such
situations fdatasync(2) doesn't force transaction with new i_size to disk
and that can result in wrong i_size after a crash.

Fix the issue by updating inode's i_datasync_tid whenever its size is

Reported-by: Kristian Nielsen <>
Signed-off-by: Jan Kara <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoe1000e: DoS while TSO enabled caused by link partner with small MSS
Bruce Allan [Fri, 24 Aug 2012 20:38:11 +0000 (20:38 +0000)]
e1000e: DoS while TSO enabled caused by link partner with small MSS

commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings <>
Signed-off-by: Bruce Allan <>
Tested-by: Aaron Brown <>
Signed-off-by: Jeff Kirsher <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2:
 - Adjust context
 - Adjust for use of net_device vs e1000_ring parameter]
Signed-off-by: Ben Hutchings <>
Paul Menzel [Wed, 8 Aug 2012 21:12:19 +0000 (23:12 +0200)]

commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b upstream.

Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with
vertical stripes in the top half.

In commit bc42aabc [2]

        commit bc42aabc6a01b92b0f961d65671564e0e1cd7592
        Author: Adam Jackson <>
        Date:   Wed May 23 16:26:54 2012 -0400

            drm/edid/quirks: ViewSonic VA2026w

Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which
is also needed for this ASUS monitor.

All log files and output from `xrandr` is included in the referenced
Bugzilla report #17629.

Please note that this monitor only has a VGA (D-Sub) connector [1].


Signed-off-by: Paul Menzel <>
Cc: <>
Cc: Adam Jackson <>
Cc: Ian Pilcher <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/edid/quirks: ViewSonic VA2026w
Adam Jackson [Wed, 23 May 2012 20:26:54 +0000 (16:26 -0400)]
drm/edid/quirks: ViewSonic VA2026w

commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 upstream.

Entirely new class of fail for this one.  The detailed timings are for
normal CVT but the monitor really wanted CVT-R.

Bugzilla: http://bugzilla.redhat/com/516471
Signed-off-by: Adam Jackson <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
Jerome Glisse [Tue, 28 Aug 2012 20:50:22 +0000 (16:50 -0400)]
drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740

commit 4a2b6662c3632176b4fdf012243dd3751367bf1f upstream.

It seems some of those IGP dislike non dma32 page despite what
documentation says. Fix regression since we allowed non dma32
pages. It seems it only affect some revision of those IGP chips
as we don't know which one just force dma32 for all of them.

Signed-off-by: Jerome Glisse <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon/atom: rework DIG modesetting on DCE3+
Alex Deucher [Wed, 22 Aug 2012 13:54:56 +0000 (09:54 -0400)]
drm/radeon/atom: rework DIG modesetting on DCE3+

commit 8d1af57ae3c4458ed0de93ef97f388dd1b3239c7 upstream.

The ordering is important and the current drm code
wasn't cutting it for modern DIG encoders.  We need
to have information about crtc before setting up
the encoders so I've shifted the ordering a bit.
Probably we'll need a full rework akin to danvet's
recent intel patchs.  This patch fixes numerous
issues with DP bridge chips and makes link training
much more reliable.

Signed-off-by: Alex Deucher <>
[bwh: Backported to 3.2: drop DCE6 cases]
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: don't disable plls that are in use by other crtcs
Alex Deucher [Tue, 21 Aug 2012 23:06:21 +0000 (19:06 -0400)]
drm/radeon: don't disable plls that are in use by other crtcs

commit 4e58591c8961b3e31709313f75819f2eec06e322 upstream.

Some plls are shared for DP.

Signed-off-by: Alex Deucher <>
Reviewed-by: Michel Dänzer <>
[bwh: Backported to 3.2: add the dev and rdev variables, previously added
 upstream to support DCE6.1 which isn't supported in this version]
Signed-off-by: Ben Hutchings <>
9 years agoHID: add NOGET quirk for Eaton Ellipse MAX UPS
Alan Stern [Thu, 23 Aug 2012 14:51:55 +0000 (10:51 -0400)]
HID: add NOGET quirk for Eaton Ellipse MAX UPS

commit 67ddbb3e6568fb1820b2cc45b00c50702b114801 upstream.

This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS
device.  (The USB IDs were already present in hid-ids.h, apparently
under a different name.)

Signed-off-by: Alan Stern <>
Reported-by: Laurent Bigonville <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
9 years agoHID: multitouch: support PixArt optical touch screen
Aaron Tian [Thu, 15 Dec 2011 03:09:06 +0000 (11:09 +0800)]
HID: multitouch: support PixArt optical touch screen

commit b7ea95ff9baab144dacdc30d752307938c5ab6bf upstream.

This patch modifies hid-multitouch driver for supporting PixArt optical touch
screen.  Because of the device does not have to set initial report, we apply
"HID_QUIRK_NO_INIT_REPORTS" quirk and add the device into hid_blacklist[]

Signed-off-by: Aaron Tian <>
Signed-off-by: Jiri Kosina <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agodrm: Check for invalid cursor flags
Jakob Bornecrantz [Thu, 16 Aug 2012 08:29:03 +0000 (08:29 +0000)]
drm: Check for invalid cursor flags

commit 7c4eaca4162d0b5ad4fb39f974d7ffd71b9daa09 upstream.

Signed-off-by: Jakob Bornecrantz <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agodrm: remove some potentially dangerous DRM_ERRORs
Jesse Barnes [Mon, 7 Nov 2011 20:03:23 +0000 (12:03 -0800)]
drm: remove some potentially dangerous DRM_ERRORs

commit acb4b992d8a13728044f430b47b9199aa45993e9 upstream.

Each of these error messages can be caused by a broken or malicious
userspace wanting to spam the dmesg with useless info.  They're really
not worthy of DRM_DEBUG statements either; those are generally only
useful during bringup of new hardware or versions, and ought to be
removed before going upstream anyway.

Signed-off-by: Jesse Barnes <>
Reviewed-by: Alex Deucher <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2: s/r\./r->/ in drm_mode_addfb()]
Signed-off-by: Ben Hutchings <>
9 years agoARM: imx: select CPU_FREQ_TABLE when needed
Arnd Bergmann [Thu, 16 Aug 2012 10:40:40 +0000 (10:40 +0000)]
ARM: imx: select CPU_FREQ_TABLE when needed

commit f637c4c9405e21f44cf0045eaf77eddd3a79ca5a upstream.

The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
so it needs to select that code to be built. This problem has
apparently existed since the i.MX cpufreq code was first merged
in v2.6.37.

Building IMX without CPU_FREQ_TABLE results in:

arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'

Signed-off-by: Arnd Bergmann <>
Acked-by: Shawn Guo <>
Cc: Sascha Hauer <>
Cc: Yong Shen <>
Signed-off-by: Ben Hutchings <>
9 years agoxen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
Konrad Rzeszutek Wilk [Fri, 17 Aug 2012 20:43:28 +0000 (16:43 -0400)]
xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.

commit c96aae1f7f393387d160211f60398d58463a7e65 upstream.

When we are finished with return PFNs to the hypervisor, then
populate it back, and also mark the E820 MMIO and E820 gaps
as IDENTITY_FRAMEs, we then call P2M to set areas that can
be used for ballooning. We were off by one, and ended up
over-writting a P2M entry that most likely was an IDENTITY_FRAME.
For example:

1-1 mapping on 40000->40200
1-1 mapping on bc558->bc5ac
1-1 mapping on bc5b4->bc8c5
1-1 mapping on bc8c6->bcb7c
1-1 mapping on bcd00->100000
Released 614 pages of unused memory
Set 277889 page(s) to 1-1 mapping
Populating 40200-40466 pfn range: 614 pages added

=> here we set from 40466 up to bc559 P2M tree to be
INVALID_P2M_ENTRY. We should have done it up to bc558.

The end result is that if anybody is trying to construct
a PTE for PFN bc558 they end up with ~PAGE_PRESENT.

Reported-by-and-Tested-by: Andre Przywara <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: dts: imx51-babbage: fix esdhc cd/wp properties
Shawn Guo [Wed, 22 Aug 2012 13:46:39 +0000 (21:46 +0800)]
ARM: dts: imx51-babbage: fix esdhc cd/wp properties

commit a46d2619d7180bda12bad2bf15bbd0731dfc2dcf upstream.

The binding doc and dts use properties "fsl,{cd,wp}-internal" while
esdhc driver uses "fsl,{cd,wp}-controller".  Fix binding doc and dts
to get them match driver code.

Reported-by: Chris Ball <>
Signed-off-by: Shawn Guo <>
Acked-by: Chris Ball <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: imx6: spin the cpu until hardware takes it down
Shawn Guo [Sat, 18 Aug 2012 06:27:32 +0000 (14:27 +0800)]
ARM: imx6: spin the cpu until hardware takes it down

commit c944b0b9354ea06ffb0c8a7178949f1185f9f499 upstream.

Though commit 602bf40 (ARM: imx6: exit coherency when shutting down
a cpu) improves the stability of imx6q cpu hotplug a lot, there are
still hangs seen with a more stressful hotplug testing.

It's expected that once imx_enable_cpu(cpu, false) is called, the cpu
will be taken down by hardware immediately, and the code after that
will not get any chance to execute.  However, this is not always the
case from the testing.  The cpu could possibly be alive for a few
cycles before hardware actually takes it down.  So rather than letting
cpu execute some code that could cause a hang in these cycles, let's
make the cpu spin there and wait for hardware to take it down.

Signed-off-by: Shawn Guo <>
Signed-off-by: Ben Hutchings <>
9 years agoOMAPFB: fix framebuffer console colors
Grazvydas Ignotas [Tue, 21 Aug 2012 06:09:48 +0000 (09:09 +0300)]
OMAPFB: fix framebuffer console colors

commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream.

omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
  echo -e '\e[0;31mRED' > /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.

Signed-off-by: Grazvydas Ignotas <>
Signed-off-by: Tomi Valkeinen <>
Signed-off-by: Florian Tobias Schandinat <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: fix wrong order of parameters in port checking functions
Xu, Anhua [Mon, 13 Aug 2012 03:08:33 +0000 (03:08 +0000)]
drm/i915: fix wrong order of parameters in port checking functions

commit b70ad586162609141f0aa9eb34790f31a8954f89 upstream.

Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.

This bug was indroduced by

commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard <>
Date:   Sat Aug 6 10:35:34 2011 -0700

    drm/i915: Fix PCH port pipe select in CPT disable paths

The reachable tag for this commit is v3.1-rc1-3-g1519b99

Signed-off-by: Anhua Xu <>
Reviewed-by: Chris Wilson <>
Tested-by: Daniel Schroeder <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP)
Adam Jackson [Fri, 7 Oct 2011 18:38:43 +0000 (14:38 -0400)]
drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP)

commit 23c99e775d14f01ba45a5affd2fb51af4328359c upstream.

Signed-off-by: Adam Jackson <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
9 years agohwmon: (asus_atk0110) Add quirk for Asus M5A78L
Luca Tettamanti [Tue, 21 Aug 2012 15:36:28 +0000 (17:36 +0200)]
hwmon: (asus_atk0110) Add quirk for Asus M5A78L

commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream.

The old interface is bugged and reads the wrong sensor when retrieving
the reading for the chassis fan (it reads the CPU sensor); the new
interface works fine.

Reported-by: Göran Uddeborg <>
Tested-by: Göran Uddeborg <>
Signed-off-by: Luca Tettamanti <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
9 years agoFix 'Device not ready' issue on mpt2sas
James Bottomley [Wed, 25 Jul 2012 19:55:55 +0000 (23:55 +0400)]
Fix 'Device not ready' issue on mpt2sas

commit 14216561e164671ce147458653b1fea06a4ada1e upstream.

This is a particularly nasty SCSI ATA Translation Layer (SATL) problem.

SAT-2 says (section 8.12.2)

        if the device is in the stopped state as the result of
        processing a START STOP UNIT command (see 9.11), then the SATL
        shall terminate the TEST UNIT READY command with CHECK CONDITION
        status with the sense key set to NOT READY and the additional

mpt2sas internal SATL seems to implement this.  The result is very confusing
standby behaviour (using hdparm -y).  If you suspend a drive and then send
another command, usually it wakes up.  However, if the next command is a TEST
UNIT READY, the SATL sees that the drive is suspended and proceeds to follow
the SATL rules for this, returning NOT READY to all subsequent commands.  This
means that the ordering of TEST UNIT READY is crucial: if you send TUR and
then a command, you get a NOT READY to both back.  If you send a command and
then a TUR, you get GOOD status because the preceeding command woke the drive.

This bit us badly because

commit 85ef06d1d252f6a2e73b678591ab71caad4667bb
Author: Tejun Heo <>
Date:   Fri Jul 1 16:17:47 2011 +0200

    block: flush MEDIA_CHANGE from drivers on close(2)

Changed our ordering on TEST UNIT READY commands meaning that SATA drives
connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas
SATL sees the suspend *before* the drives get awoken by the next ATA command)
resulting in lots of failed commands.

The standard is completely nuts forcing this inconsistent behaviour, but we
have to work around it.

The fix for this is twofold:

   1. Set the allow_restart flag so we wake the drive when we see it has been

   2. Return all TEST UNIT READY status directly to the mid layer without any
      further error handling which prevents us causing error handling which
      may offline the device just because of a media check TUR.

Reported-by: Matthias Prager <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agomegaraid_sas: Move poll_aen_lock initializer
Kashyap Desai [Wed, 18 Jul 2012 01:20:44 +0000 (18:20 -0700)]
megaraid_sas: Move poll_aen_lock initializer

commit bd8d6dd43a77bfd2b8fef5b094b9d6095e169dee upstream.

The following patch moves the poll_aen_lock initializer from
megasas_probe_one() to megasas_init().  This prevents a crash when a user
loads the driver and tries to issue a poll() system call on the ioctl
interface with no adapters present.

Signed-off-by: Kashyap Desai <>
Signed-off-by: Adam Radford <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agompt2sas: Fix for Driver oops, when loading driver with max_queue_depth command line... [Tue, 17 Jul 2012 10:27:05 +0000 (15:57 +0530)]
mpt2sas: Fix for Driver oops, when loading driver with max_queue_depth command line option to a very small value

commit 338b131a3269881c7431234855c93c219b0979b6 upstream.

If the specified max_queue_depth setting is less than the
expected number of internal commands, then driver will calculate
the queue depth size to a negitive number. This negitive number
is actually a very large number because variable is unsigned
16bit integer. So, the driver will ask for a very large amount of
memory for message frames and resulting into oops as memory
allocation routines will not able to handle such a large request.

So, in order to limit this kind of oops, The driver need to set
the max_queue_depth to a scsi mid layer's can_queue value. Then
the overall message frames required for IO is minimum of either
(max_queue_depth plus internal commands) or the IOC global

Signed-off-by: Sreekanth Reddy <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoInput: i8042 - add Gigabyte T1005 series netbooks to noloop table
Dmitry Torokhov [Wed, 22 Aug 2012 04:57:15 +0000 (21:57 -0700)]
Input: i8042 - add Gigabyte T1005 series netbooks to noloop table

commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream.

They all define their chassis type as "Other" and therefore are not
categorized as "laptops" by the driver, which tries to perform AUX IRQ
delivery test which fails and causes touchpad not working.

Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: protect SRAM debugfs
Johannes Berg [Tue, 21 Aug 2012 16:57:11 +0000 (18:57 +0200)]
iwlwifi: protect SRAM debugfs

commit 4fc79db178f0a0ede479b4713e00df2d106028b3 upstream.

If the device is not started, we can't read its
SRAM and attempting to do so will cause issues.
Protect the debugfs read.

Signed-off-by: Johannes Berg <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2:
 - Adjust context
 - Pass iwl_shared not iwl_priv pointer to iwl_is_ready_rf()]
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: fix flow handler debug code
Johannes Berg [Tue, 21 Aug 2012 16:57:10 +0000 (18:57 +0200)]
iwlwifi: fix flow handler debug code

commit 94543a8d4fb302817014981489f15cb3b92ec3c2 upstream.

iwl_dbgfs_fh_reg_read() can cause crashes and/or
BUG_ON in slub because the ifdefs are wrong, the
code in iwl_dump_fh() should use DEBUGFS, not
DEBUG to protect the buffer writing code.

Also, while at it, clean up the arguments to the
function, some code and make it generally safer.

Reported-by: Benjamin Herrenschmidt <>
Signed-off-by: Johannes Berg <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: adjust filenames and context]
Signed-off-by: Ben Hutchings <>
9 years agoARM: Orion: Set eth packet size csum offload limit
Arnaud Patard (Rtp) [Thu, 26 Jul 2012 10:15:46 +0000 (12:15 +0200)]
ARM: Orion: Set eth packet size csum offload limit

commit 58569aee5a1a5dcc25c34a0a2ed9a377874e6b05 upstream.

The mv643xx ethernet controller limits the packet size for the TX
checksum offloading. This patch sets this limits for Kirkwood and
Dove which have smaller limits that the default.

As a side note, this patch is an updated version of a patch sent some years
which seems to have been lost.

Signed-off-by: Arnaud Patard <>
Signed-off-by: Jason Cooper <>
[bwh: Backported to 3.2: adjust for the extra two parameters of
Signed-off-by: Ben Hutchings <>
9 years agoARM: OMAP2+: Fix dmtimer set source clock failure
Jon Hunter [Fri, 13 Jul 2012 20:12:03 +0000 (15:12 -0500)]
ARM: OMAP2+: Fix dmtimer set source clock failure

commit 54f32a35f4d3a653a18a2c8c239f19ae060bd803 upstream.

Calling the dmtimer function omap_dm_timer_set_source() fails if following a
call to pm_runtime_put() to disable the timer. For example the following
sequence would fail to set the parent clock ...

omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);

The following error message would be seen ...

omap_dm_timer_set_source: failed to set timer_32k_ck as parent

The problem is that, by design, pm_runtime_put() simply decrements the usage
count and returns before the timer has actually been disabled. Therefore,
setting the parent clock failed because the timer was still active when the
trying to set the parent clock. Setting a parent clock will fail if the clock
you are setting the parent of has a non-zero usage count. To ensure that this
does not fail use pm_runtime_put_sync() when disabling the timer.

Note that this will not be seen on OMAP1 devices, because these devices do
not use the clock framework for dmtimers.

Signed-off-by: Jon Hunter <>
Acked-by: Kevin Hilman <>
Signed-off-by: Tony Lindgren <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: S3C24XX: Fix s3c2410_dma_enqueue parameters
Heiko Stuebner [Tue, 7 Aug 2012 10:12:05 +0000 (19:12 +0900)]
ARM: S3C24XX: Fix s3c2410_dma_enqueue parameters

commit b01858c7806e7e6f6121da2e51c9222fc4d21dc6 upstream.

Commit d670ac019f60 (ARM: SAMSUNG: DMA Cleanup as per sparse) changed the
prototype of the s3c2410_dma_* functions to use the enum dma_ch instead
of an generic unsigned int.

In the s3c24xx dma.c s3c2410_dma_enqueue seems to have been forgotten,
the other functions there were changed correctly.

Signed-off-by: Heiko Stuebner <>
Signed-off-by: Kukjin Kim <>
Signed-off-by: Ben Hutchings <>
9 years agoRedefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
Mel Gorman [Mon, 23 Jul 2012 11:16:19 +0000 (12:16 +0100)]
Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

commit bba3d8c3b3c0f2123be5bc687d1cddc13437c923 upstream.

The following build error occured during a parisc 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

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.

Reported-by: Fengguang Wu <>
Signed-off-by: Mel Gorman <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoLinux 3.2.29 v3.2.29
Ben Hutchings [Wed, 12 Sep 2012 02:37:38 +0000 (03:37 +0100)]
Linux 3.2.29

9 years agomm: avoid swapping out with swappiness==0
Satoru Moriya [Tue, 29 May 2012 22:06:47 +0000 (15:06 -0700)]
mm: avoid swapping out with swappiness==0

commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd upstream.

Sometimes we'd like to avoid swapping out anonymous memory.  In
particular, avoid swapping out pages of important process or process
groups while there is a reasonable amount of pagecache on RAM so that we
can satisfy our customers' requirements.

OTOH, we can control how aggressive the kernel will swap memory pages with
/proc/sys/vm/swappiness for global and
/sys/fs/cgroup/memory/memory.swappiness for each memcg.

But with current reclaim implementation, the kernel may swap out even if
we set swappiness=0 and there is pagecache in RAM.

This patch changes the behavior with swappiness==0.  If we set
swappiness==0, the kernel does not swap out completely (for global reclaim
until the amount of free pages and filebacked pages in a zone has been
reduced to something very very small (nr_free + nr_filebacked < high

Signed-off-by: Satoru Moriya <>
Acked-by: Minchan Kim <>
Reviewed-by: Rik van Riel <>
Acked-by: Jerome Marchand <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 - Adjust context
 - vmscan_swappiness() does not have a zone parameter]
Signed-off-by: Ben Hutchings <>
9 years agoSquashfs: fix mount time sanity check for corrupted superblock
Phillip Lougher [Mon, 2 Jan 2012 17:47:14 +0000 (17:47 +0000)]
Squashfs: fix mount time sanity check for corrupted superblock

commit cc37f75a9ffbbfcb1c3297534f293c8284e3c5a6 upstream.

A Squashfs filesystem containing nothing but an empty directory,
although unusual and ultimately pointless, is still valid.

The directory_table >= next_table sanity check rejects these
filesystems as invalid because the directory_table is empty and
equal to next_table.

Signed-off-by: Phillip Lougher <>
Signed-off-by: Ben Hutchings <>
9 years agoasus-nb-wmi: add some video toggle keys
AceLan Kao [Wed, 4 Jul 2012 07:20:14 +0000 (15:20 +0800)]
asus-nb-wmi: add some video toggle keys

commit 3766054fff4af1b58a1440a284907887f4d2e8be upstream.

There are some new video switch keys that used by newer machines.
0xA0 - SDSP HDMI only
But in Linux, there is no suitable userspace application to handle this,
so, mapping them all to KEY_SWITCHVIDEOMODE.

Signed-off-by: AceLan Kao <>
Signed-off-by: Matthew Garrett <>
Signed-off-by: Ben Hutchings <>
9 years agoNFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate
Trond Myklebust [Wed, 22 Aug 2012 20:08:17 +0000 (16:08 -0400)]
NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate

Fix the following Oops in 3.5.1:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
 IP: [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
 PGD 337c63067 PUD 0
 Oops: 0000 [#1] SMP
 CPU 5
 Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss sunrpc af_packet binfmt_misc cpufreq_conservative cpufreq_userspace cpufreq_powersave dm_mod acpi_cpufreq mperf coretemp gpio_ich kvm_intel joydev kvm ioatdma hid_generic igb lpc_ich i7core_edac edac_core ptp serio_raw dca pcspkr i2c_i801 mfd_core sg pps_core usbhid crc32c_intel microcode button autofs4 uhci_hcd ttm drm_kms_helper drm i2c_algo_bit sysimgblt sysfillrect syscopyarea ehci_hcd usbcore usb_common scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh edd fan ata_piix thermal processor thermal_sys

 Pid: 30431, comm: java Not tainted 3.5.1-2-default #1 Supermicro X8DTT/X8DTT
 RIP: 0010:[<ffffffffa03789cd>]  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
 RSP: 0018:ffff8801b418bd38  EFLAGS: 00010292
 RAX: 00000000fffffff6 RBX: ffff88032016d800 RCX: 0000000000000020
 RDX: ffffffff00000000 RSI: 0000000000000000 RDI: ffff8801824a7b00
 RBP: ffff8801b418bdf8 R08: 7fffff0034323030 R09: fffffffff04c03ed
 R10: ffff8801824a7b00 R11: 0000000000000002 R12: ffff8801824a7b00
 R13: ffff8801824a7b00 R14: 0000000000000000 R15: ffff8803201725d0
 FS:  00002b53a46cb700(0000) GS:ffff88033fc20000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000038 CR3: 000000020a426000 CR4: 00000000000007e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process java (pid: 30431, threadinfo ffff8801b418a000, task ffff8801b5d20600)
  ffff8801b418be44 ffff88032016d800 ffff8801b418bdf8 0000000000000000
  ffff8801824a7b00 ffff8801b418bdd7 ffff8803201725d0 ffffffff8116a9c0
  ffff8801b5c38dc0 0000000000000007 ffff88032016d800 0000000000000000
 Call Trace:
  [<ffffffff8116a9c0>] lookup_dcache+0x80/0xe0
  [<ffffffff8116aa43>] __lookup_hash+0x23/0x90
  [<ffffffff8116b4a5>] lookup_one_len+0xc5/0x100
  [<ffffffffa03869a3>] nfs_sillyrename+0xe3/0x210 [nfs]
  [<ffffffff8116cadf>] vfs_unlink.part.25+0x7f/0xe0
  [<ffffffff8116f22c>] do_unlinkat+0x1ac/0x1d0
  [<ffffffff815717b9>] system_call_fastpath+0x16/0x1b
  [<00002b5348b5f527>] 0x2b5348b5f526
 Code: ec 38 b8 f6 ff ff ff 4c 89 64 24 18 4c 89 74 24 28 49 89 fc 48 89 5c 24 08 48 89 6c 24 10 49 89 f6 4c 89 6c 24 20 4c 89 7c 24 30 <f6> 46 38 40 0f 85 d1 00 00 00 e8 c4 c4 df e0 48 8b 58 30 49 89
 RIP  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
  RSP <ffff8801b418bd38>
 CR2: 0000000000000038
 ---[ end trace 845113ed191985dd ]---

This Oops affects 3.5 kernels and older, and is due to lookup_one_len()
calling down to the dentry revalidation code with a NULL pointer
to struct nameidata.

It is fixed upstream by commit 0b728e1911c (stop passing nameidata *
to ->d_revalidate())

Reported-by: Richard Ems <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
9 years agoStaging: speakup: fix an improperly-declared variable.
Christopher Brannon [Sat, 16 Jun 2012 21:55:20 +0000 (16:55 -0500)]
Staging: speakup: fix an improperly-declared variable.

commit 4ea418b8b2fa8a70d0fcc8231b65e67b3a72984b upstream.

A local static variable was declared as a pointer to a string
constant.  We're assigning to the underlying memory, so it
needs to be an array instead.

Signed-off-by: Christopher Brannon <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agopmac_zilog,kdb: Fix console poll hook to return instead of loop
Jason Wessel [Sun, 12 Aug 2012 12:16:43 +0000 (07:16 -0500)]
pmac_zilog,kdb: Fix console poll hook to return instead of loop

commit 38f8eefccf3a23c4058a570fa2938a4f553cf8e0 upstream.

kdb <-> kgdb transitioning does not work properly with this UART
driver because the get character routine loops indefinitely as opposed
to returning NO_POLL_CHAR per the expectation of the KDB I/O driver

The symptom is a kernel hang when trying to switch debug modes.

Cc: Alan Cox <>
Signed-off-by: Jason Wessel <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoHID: add support for Cypress barcode scanner 04B4:ED81
Lionel Vaux [Sun, 22 Jul 2012 09:32:20 +0000 (11:32 +0200)]
HID: add support for Cypress barcode scanner 04B4:ED81

commit 76c9d8fe2c7fc34ffc387d8022c5828d6ff9df48 upstream.

Add yet another device to the list of Cypress barcode scanners
needing the CP_RDESC_SWAPPED_MIN_MAX quirk.

Signed-off-by: Lionel Vaux (iouri) <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
9 years agovirtio-blk: Reset device after blk_cleanup_queue()
Asias He [Fri, 25 May 2012 02:34:48 +0000 (10:34 +0800)]
virtio-blk: Reset device after blk_cleanup_queue()

commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream.

blk_cleanup_queue() will call blk_drian_queue() to drain all the
requests before queue DEAD marking. If we reset the device before
blk_cleanup_queue() the drain would fail.

1) if the queue is stopped in do_virtblk_request() because device is
full, the q->request_fn() will not be called.

blk_drain_queue() {
   while(true) {
      if (!list_empty(&q->queue_head))
        __blk_run_queue(q) {
    if (queue is not stoped)

Do no reset the device before blk_cleanup_queue() gives the chance to
start the queue in interrupt handler blk_done().

2) In commit b79d866c8b7014a51f611a64c40546109beaf24a, We abort requests
dispatched to driver before blk_cleanup_queue(). There is a race if
requests are dispatched to driver after the abort and before the queue
DEAD mark. To fix this, instead of aborting the requests explicitly, we
can just reset the device after after blk_cleanup_queue so that the
device can complete all the requests before queue DEAD marking in the
drain process.

Cc: Rusty Russell <>
Signed-off-by: Asias He <>
Acked-by: Michael S. Tsirkin <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Ben Hutchings <>
9 years agovirtio-blk: Call del_gendisk() before disable guest kick
Asias He [Fri, 25 May 2012 02:34:47 +0000 (10:34 +0800)]
virtio-blk: Call del_gendisk() before disable guest kick

commit 02e2b124943648fba0a2ccee5c3656a5653e0151 upstream.

del_gendisk() might not return due to failing to remove the
/sys/block/vda/serial sysfs entry when another thread (udev) is
trying to read it.

  vdev->config->reset() : guest will not kick us through interrupt
        kobject_del(): got stuck, sysfs entry ref count non zero

sysfs_open_file(): user space process read /sys/block/vda/serial
   sysfs_get_active() : got sysfs entry ref count
           blk_execute_rq() : got stuck, interrupt is disabled
                              request cannot be finished

This patch fixes it by calling del_gendisk() before we disable guest's
interrupt so that the request sent in virtblk_serial_show() will be
finished and del_gendisk() will success.

This fixes another race in hot-unplug process.

It is save to call del_gendisk(vblk->disk) before
flush_work(&vblk->config_work) which might access vblk->disk, because
vblk->disk is not freed until put_disk(vblk->disk).

Signed-off-by: Asias He <>
Acked-by: Michael S. Tsirkin <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Ben Hutchings <>
9 years agovirtio-blk: Fix hot-unplug race in remove method
Asias He [Fri, 4 May 2012 12:22:04 +0000 (20:22 +0800)]
virtio-blk: Fix hot-unplug race in remove method

commit b79d866c8b7014a51f611a64c40546109beaf24a upstream.

If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will fail.

blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
before DEAD marking. However it will never success if the device is
already stopped. We'll have q->in_flight[] > 0, so the drain will not

How to reproduce the race:
1. hot-plug a virtio-blk device
2. keep reading/writing the device in guest
3. hot-unplug while the device is busy serving I/O

~1000 rounds of hot-plug/hot-unplug test passed with this patch.

Changes in v3:
- Drop blk_abort_queue and blk_abort_request
- Use __blk_end_request_all to complete request dispatched to driver

Changes in v2:
- Drop req_in_flight
- Use virtqueue_detach_unused_buf to get request dispatched to driver

Signed-off-by: Asias He <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Ben Hutchings <>
9 years agovirtio_blk: Drop unused request tracking list
Asias He [Fri, 30 Mar 2012 03:24:10 +0000 (11:24 +0800)]
virtio_blk: Drop unused request tracking list

commit f65ca1dc6a8c81c6bd72297d4399ec5f4c1f3a01 upstream.

Benchmark shows small performance improvement on fusion io device.

  seq-read : io=1,024MB, bw=19,982KB/s, iops=39,964, runt= 52475msec
  seq-write: io=1,024MB, bw=20,321KB/s, iops=40,641, runt= 51601msec
  rnd-read : io=1,024MB, bw=15,404KB/s, iops=30,808, runt= 68070msec
  rnd-write: io=1,024MB, bw=14,776KB/s, iops=29,552, runt= 70963msec

  seq-read : io=1,024MB, bw=20,343KB/s, iops=40,685, runt= 51546msec
  seq-write: io=1,024MB, bw=20,803KB/s, iops=41,606, runt= 50404msec
  rnd-read : io=1,024MB, bw=16,221KB/s, iops=32,442, runt= 64642msec
  rnd-write: io=1,024MB, bw=15,199KB/s, iops=30,397, runt= 68991msec

Signed-off-by: Asias He <>
Signed-off-by: Rusty Russell <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agovirtio_blk: fix config handler race
Michael S. Tsirkin [Thu, 12 Jan 2012 05:14:44 +0000 (15:44 +1030)]
virtio_blk: fix config handler race

commit 4678d6f970c2f7c0cbfefc0cc666432d153b321b upstream.

Fix a theoretical race related to config work
handler: a config interrupt might happen
after we flush config work but before we
reset the device. It will then cause the
config work to run during or after reset.

Two problems with this:
- if this runs after device is gone we will get use after free
- access of config while reset is in progress is racy
(as layout is changing).

As a solution
1. flush after reset when we know there will be no more interrupts
2. add a flag to disable config access before reset

Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: Rusty Russell <>
Signed-off-by: Ben Hutchings <>
9 years agodmi: Feed DMI table to /dev/random driver
Tony Luck [Fri, 20 Jul 2012 20:15:20 +0000 (13:15 -0700)]
dmi: Feed DMI table to /dev/random driver

commit d114a33387472555188f142ed8e98acdb8181c6d upstream.

Send the entire DMI (SMBIOS) table to the /dev/random driver to
help seed its pools.

Signed-off-by: Tony Luck <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
9 years agorandom: Add comment to random_initialize()
Tony Luck [Mon, 23 Jul 2012 16:47:57 +0000 (09:47 -0700)]
random: Add comment to random_initialize()

commit cbc96b7594b5691d61eba2db8b2ea723645be9ca upstream.

Many platforms have per-machine instance data (serial numbers,
asset tags, etc.) squirreled away in areas that are accessed
during early system bringup. Mixing this data into the random
pools has a very high value in providing better random data,
so we should allow (and even encourage) architecture code to
call add_device_randomness() from the setup_arch() paths.

However, this limits our options for internal structure of
the random driver since random_initialize() is not called
until long after setup_arch().

Add a big fat comment to rand_initialize() spelling out
this requirement.

Suggested-by: Theodore Ts'o <>
Signed-off-by: Tony Luck <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
9 years agoMAINTAINERS: Theodore Ts'o is taking over the random driver
Theodore Ts'o [Wed, 4 Jul 2012 15:32:48 +0000 (11:32 -0400)]
MAINTAINERS: Theodore Ts'o is taking over the random driver

commit 330e0a01d54c2b8606c56816f99af6ebc58ec92c upstream.

Matt Mackall stepped down as the /dev/random driver maintainer last
year, so Theodore Ts'o is taking back the /dev/random driver.

Cc: Matt Mackall <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>