7 years agoUSB: cdc-acm: fix write and suspend race
Johan Hovold [Mon, 26 May 2014 17:23:36 +0000 (19:23 +0200)]
USB: cdc-acm: fix write and suspend race

commit 5a345c20c17d87099224a4be12e69e5bd7023dca upstream.

Fix race between write() and suspend() which could lead to writes being
dropped (or I/O while suspended) if the device is runtime suspended
while a write request is being processed.

Specifically, suspend() releases the write_lock after determining the
device is idle but before incrementing the susp_count, thus leaving a
window where a concurrent write() can submit an urb.

Fixes: 11ea859d64b6 ("USB: additional power savings for cdc-acm devices
that support remote wakeup")

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: usb_wwan: fix potential blocked I/O after resume
Johan Hovold [Mon, 26 May 2014 17:23:18 +0000 (19:23 +0200)]
USB: usb_wwan: fix potential blocked I/O after resume

commit fb7ad4f93d9f0f7d49beda32f5e7becb94b29a4d upstream.

Keep trying to submit urbs rather than bail out on first read-urb
submission error, which would also prevent I/O for any further ports
from being resumed.

Instead keep an error count, for all types of failed submissions, and
let USB core know that something went wrong.

Also make sure to always clear the suspended flag. Currently a failed
read-urb submission would prevent cached writes as well as any
subsequent writes from being submitted until next suspend-resume cycle,
something which may not even necessarily happen.

Note that USB core currently only logs an error if an interface resume

Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the
option driver")

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: usb_wwan: fix urb leak at shutdown
Johan Hovold [Mon, 26 May 2014 17:23:16 +0000 (19:23 +0200)]
USB: usb_wwan: fix urb leak at shutdown

commit 79eed03e77d481b55d85d1cfe5a1636a0d3897fd upstream.

The delayed-write queue was never emptied at shutdown (close), something
which could lead to leaked urbs if the port is closed before being
runtime resumed due to a write.

When this happens the output buffer would not drain on close
(closing_wait timeout), and after consecutive opens, writes could be
corrupted with previously buffered data, transfered with reduced
throughput or completely blocked.

Note that unbusy_queued_urb() was simply moved out of CONFIG_PM.

Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the
option driver")

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust indentation]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: usb_wwan: fix write and suspend race
Johan Hovold [Mon, 26 May 2014 17:23:15 +0000 (19:23 +0200)]
USB: usb_wwan: fix write and suspend race

commit 170fad9e22df0063eba0701adb966786d7a4ec5a upstream.

Fix race between write() and suspend() which could lead to writes being
dropped (or I/O while suspended) if the device is runtime suspended
while a write request is being processed.

Specifically, suspend() releases the susp_lock after determining the
device is idle but before setting the suspended flag, thus leaving a
window where a concurrent write() can submit an urb.

Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the
option driver")

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: usb_wwan: fix race between write and resume
xiao jin [Mon, 26 May 2014 17:23:14 +0000 (19:23 +0200)]
USB: usb_wwan: fix race between write and resume

commit d9e93c08d8d985e5ef89436ebc9f4aad7e31559f upstream.

We find a race between write and resume. usb_wwan_resume run play_delayed()
and spin_unlock, but intfdata->suspended still is not set to zero.
At this time usb_wwan_write is called and anchor the urb to delay
list. Then resume keep running but the delayed urb have no chance
to be commit until next resume. If the time of next resume is far
away, tty will be blocked in tty_wait_until_sent during time. The
race also can lead to writes being reordered.

This patch put play_Delayed and intfdata->suspended together in the
spinlock, it's to avoid the write race during resume.

Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the
option driver")

Signed-off-by: xiao jin <>
Signed-off-by: Zhang, Qi1 <>
Reviewed-by: David Cohen <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: there's no need to check for portdata == NULL]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: usb_wwan: fix urb leak in write error path
xiao jin [Mon, 26 May 2014 17:23:13 +0000 (19:23 +0200)]
USB: usb_wwan: fix urb leak in write error path

commit db0904737947d509844e171c9863ecc5b4534005 upstream.

When enable usb serial for modem data, sometimes the tty is blocked
in tty_wait_until_sent because portdata->out_busy always is set and
have no chance to be cleared.

We find a bug in write error path. usb_wwan_write set portdata->out_busy
firstly, then try autopm async with error. No out urb submit and no
usb_wwan_outdat_callback to this write, portdata->out_busy can't be

This patch clear portdata->out_busy if usb_wwan_write try autopm async
with error.

Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the
option driver")

Signed-off-by: xiao jin <>
Signed-off-by: Zhang, Qi1 <>
Reviewed-by: David Cohen <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: option: fix runtime PM handling
Johan Hovold [Mon, 26 May 2014 17:23:10 +0000 (19:23 +0200)]
USB: option: fix runtime PM handling

commit acf47d4f9c39b1cba467aa9442fc2efe0b1da741 upstream.

Fix potential I/O while runtime suspended due to missing PM operations
in send_setup.

Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the
option driver")

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: sierra: fix remote wakeup
Johan Hovold [Mon, 26 May 2014 17:22:54 +0000 (19:22 +0200)]
USB: sierra: fix remote wakeup

commit 80cc0fcbdaeaf10d04ba27779a2d7ceb73d2717a upstream.

Make sure that needs_remote_wake up is always set when there are open

Currently close() would unconditionally set needs_remote_wakeup to 0
even though there might still be open ports. This could lead to blocked
input and possibly dropped data on devices that do not support remote
wakeup (and which must therefore not be runtime suspended while open).

Add an open_ports counter (protected by the susp_lock) and only clear
needs_remote_wakeup when the last port is closed.

Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust indentation]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: sierra: fix urb and memory leak on disconnect
Johan Hovold [Mon, 26 May 2014 17:22:53 +0000 (19:22 +0200)]
USB: sierra: fix urb and memory leak on disconnect

commit 014333f77c0b71123d6ef7d31a9724e0699c9548 upstream.

The delayed-write queue was never emptied on disconnect, something which
would lead to leaked urbs and transfer buffers if the device is
disconnected before being runtime resumed due to a write.

Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: sierra: fix urb and memory leak in resume error path
Johan Hovold [Mon, 26 May 2014 17:22:52 +0000 (19:22 +0200)]
USB: sierra: fix urb and memory leak in resume error path

commit 7fdd26a01eb7b6cb6855ff8f69ef4a720720dfcb upstream.

Neither the transfer buffer or the urb itself were released in the
resume error path for delayed writes. Also on errors, the remainder of
the queue was not even processed, which leads to further urb and buffer

The same error path also failed to balance the outstanding-urb counter,
something which results in degraded throughput or completely blocked

Fix this by releasing urb and buffer and balancing counters on errors,
and by always processing the whole queue even when submission of one urb

Fixes: e6929a9020ac ("USB: support for autosuspend in sierra while

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: sierra: fix AA deadlock in open error path
Johan Hovold [Mon, 26 May 2014 17:22:50 +0000 (19:22 +0200)]
USB: sierra: fix AA deadlock in open error path

commit 353fe198602e8b4d1c7bdcceb8e60955087201b1 upstream.

Fix AA deadlock in open error path that would call close() and try to
grab the already held disc_mutex.

Fixes: b9a44bc19f48 ("sierra: driver urb handling improvements")

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoIB/ipath: Translate legacy diagpkt into newer extended diagpkt
Dennis Dalessandro [Fri, 2 May 2014 15:40:17 +0000 (11:40 -0400)]
IB/ipath: Translate legacy diagpkt into newer extended diagpkt

commit 7e6d3e5c70f13874fb06e6b67696ed90ce79bd48 upstream.

This patch addresses an issue where the legacy diagpacket is sent in
from the user, but the driver operates on only the extended
diagpkt. This patch specifically initializes the extended diagpkt
based on the legacy packet.

Reported-by: Rickard Strandqvist <>
Reviewed-by: Mike Marciniszyn <>
Signed-off-by: Dennis Dalessandro <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
7 years agoIB/qib: Fix port in pkey change event
Mike Marciniszyn [Fri, 2 May 2014 15:28:04 +0000 (11:28 -0400)]
IB/qib: Fix port in pkey change event

commit 911eccd284d13d78c92ec4f1f1092c03457d732a upstream.

The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE.

As of the dual port qib QDR card, this is not necessarily correct.

Change to use the port as specified in the call.

Reported-by: Alex Estrin <>
Reviewed-by: Dennis Dalessandro <>
Signed-off-by: Mike Marciniszyn <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
7 years agoext4: fix wrong assert in ext4_mb_normalize_request()
Maurizio Lombardi [Tue, 27 May 2014 16:48:56 +0000 (12:48 -0400)]
ext4: fix wrong assert in ext4_mb_normalize_request()

commit b5b60778558cafad17bbcbf63e0310bd3c68eb17 upstream.

The variable "size" is expressed as number of blocks and not as
number of clusters, this could trigger a kernel panic when using
ext4 with the size of a cluster different from the size of a block.

Signed-off-by: Maurizio Lombardi <>
Signed-off-by: Theodore Ts'o <>
Signed-off-by: Ben Hutchings <>
7 years agoext4: fix zeroing of page during writeback
Jan Kara [Tue, 27 May 2014 16:48:55 +0000 (12:48 -0400)]
ext4: fix zeroing of page during writeback

commit eeece469dedadf3918bad50ad80f4616a0064e90 upstream.

Tail of a page straddling inode size must be zeroed when being written
out due to POSIX requirement that modifications of mmaped page beyond
inode size must not be written to the file. ext4_bio_write_page() did
this only for blocks fully beyond inode size but didn't properly zero
blocks partially beyond inode size. Fix this.

The problem has been uncovered by mmap_11-4 test in openposix test suite
(part of LTP).

Reported-by: Xiaoguang Wang <>
Fixes: 5a0dc7365c240
Fixes: bd2d0210cf22f
Signed-off-by: Jan Kara <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2:
 - Adjust context
 - block_end was used instead of block_start + blocksize]
Signed-off-by: Ben Hutchings <>
7 years agoahci: add PCI ID for Marvell 88SE91A0 SATA Controller
Andreas Schrägle [Sat, 24 May 2014 14:35:43 +0000 (16:35 +0200)]
ahci: add PCI ID for Marvell 88SE91A0 SATA Controller

commit 754a292fe6b08196cb135c03b404444e17de520a upstream.

Add support for Marvell Technology Group Ltd. 88SE91A0 SATA 6Gb/s
Controller by adding its PCI ID.

Signed-off-by: Andreas Schrägle <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
7 years agodrm/i915: Only copy back the modified fields to userspace from execbuffer
Chris Wilson [Fri, 23 May 2014 09:45:52 +0000 (10:45 +0100)]
drm/i915: Only copy back the modified fields to userspace from execbuffer

commit 9aab8bff7aa3bee567213ad3c1fdfb217bb980a2 upstream.

We only want to modifiy a single field in the userspace view of the
execbuffer command buffer, so explicitly change that rather than copy
everything back again.

This serves two purposes:

1. The single fields are much cheaper to copy (constant size so the
copy uses special case code) and much smaller than the whole array.

2. We modify the array for internal use that need to be masked from
the user.

Note: We need this backported since without it the next bugfix will
blow up when userspace recycles batchbuffers and relocations.

Signed-off-by: Chris Wilson <>
Cc: Daniel Vetter <>
Signed-off-by: Daniel Vetter <>
[bwh: Backported to 3.2: to_user_ptr() is open-coded]
Signed-off-by: Ben Hutchings <>
7 years agodrm/i915: s/DRM_ERROR/DRM_DEBUG in i915_gem_execbuffer.c
Daniel Vetter [Tue, 31 Jan 2012 20:08:14 +0000 (21:08 +0100)]
drm/i915: s/DRM_ERROR/DRM_DEBUG in i915_gem_execbuffer.c

commit ff240199b6a3b0bec5ae9b6d26403dad38e8cb19 upstream.

These are all user-trigerable, so tune down their loudness a notch.
For some of these we have i-g-t tests (because they prevent
newly-discovered bugs), without this patches running the test suite
leaves behind a dirty dmesg.

Reviewed-by: Chris Wilson <>
Signed-Off-by: Daniel Vetter <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agomac80211: fix IBSS join by initializing last_scan_completed
Krzysztof Hałasa [Mon, 26 May 2014 12:14:46 +0000 (14:14 +0200)]
mac80211: fix IBSS join by initializing last_scan_completed

commit c7d37a66e345df2fdf1aa7b2c9a6d3d53846ca5b upstream.

Without this fix, freshly rebooted Linux creates a new IBSS
instead of joining an existing one. Only when jiffies counter
overflows after 5 minutes the IBSS can be successfully joined.

Signed-off-by: Krzysztof Hałasa <>
[edit commit message slightly]
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoInput: synaptics - T540p - unify with other LEN0034 models
Hans de Goede [Tue, 20 May 2014 05:52:30 +0000 (22:52 -0700)]
Input: synaptics - T540p - unify with other LEN0034 models

commit 6d396ede224dc596d92d7cab433713536e68916c upstream.

The T540p has a touchpad with pnp-id LEN0034, all the models with this
pnp-id have the same min/max values, except the T540p where the values are
slightly off. Fix them to be identical.

This is a preparation patch for simplifying the quirk table.

Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agoARM: 8051/1: put_user: fix possible data corruption in put_user
Andrey Ryabinin [Wed, 7 May 2014 07:07:25 +0000 (08:07 +0100)]
ARM: 8051/1: put_user: fix possible data corruption in put_user

commit 537094b64b229bf3ad146042f83e74cf6abe59df upstream.

According to arm procedure call standart r2 register is call-cloberred.
So after the result of x expression was put into r2 any following
function call in p may overwrite r2. To fix this, the result of p
expression must be saved to the temporary variable before the
assigment x expression to __r2.

Signed-off-by: Andrey Ryabinin <>
Reviewed-by: Nicolas Pitre <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume
Alan Stern [Fri, 23 May 2014 14:45:54 +0000 (10:45 -0400)]
USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume

commit 8ef42ddd9a53b73e6fc3934278710c27f80f324f upstream.

Not all host controller drivers have bus-suspend and bus-resume
methods.  When one doesn't, it will cause problems if runtime PM is
enabled in the kernel.  The PM core will attempt to suspend the
controller's root hub, the suspend will fail because there is no
bus-suspend routine, and a -EBUSY error code will be returned to the
PM core.  This will cause the suspend attempt to be repeated shortly
thereafter, in a never-ending loop.

Part of the problem is that the original error code -ENOENT gets
changed to -EBUSY in usb_runtime_suspend(), on the grounds that the PM
core will interpret -ENOENT as meaning that the root hub has gotten
into a runtime-PM error state.  While this change is appropriate for
real USB devices, it's not such a good idea for a root hub.  In fact,
considering the root hub to be in a runtime-PM error state would not
be far from the truth.  Therefore this patch updates
usb_runtime_suspend() so that it adjusts error codes only for
non-root-hub devices.

Furthermore, the patch attempts to prevent the problem from occurring
in the first place by not enabling runtime PM by default for root hubs
whose host controller driver doesn't have bus_suspend and bus_resume

Signed-off-by: Alan Stern <>
Reported-by: Will Deacon <>
Tested-by: Will Deacon <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: runtime PM is also not supported for USB 3.0
 non-root hubs]
Signed-off-by: Ben Hutchings <>
7 years agomatroxfb: perform a dummy read of M_STATUS
Mikulas Patocka [Thu, 15 May 2014 10:58:24 +0000 (06:58 -0400)]
matroxfb: perform a dummy read of M_STATUS

commit 972754cfaee94d6e25acf94a497bc0a864d91b7e upstream.

I had occasional screen corruption with the matrox framebuffer driver and
I found out that the reason for the corruption is that the hardware
blitter accesses the videoram while it is being written to.

The matrox driver has a macro WaitTillIdle() that should wait until the
blitter is idle, but it sometimes doesn't work. I added a dummy read
mga_inl(M_STATUS) to WaitTillIdle() to fix the problem. The dummy read
will flush the write buffer in the PCI chipset, and the next read of
M_STATUS will return the hardware status.

Since applying this patch, I had no screen corruption at all.

Signed-off-by: Mikulas Patocka <>
Signed-off-by: Tomi Valkeinen <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agoARM: imx: fix error handling in ipu device registration
Emil Goode [Mon, 19 May 2014 07:07:54 +0000 (15:07 +0800)]
ARM: imx: fix error handling in ipu device registration

commit d1d70e5dc2cfa9047bb935c41ba808ebb8135696 upstream.

If we fail to allocate struct platform_device pdev we
dereference it after the goto label err.

This bug was found using coccinelle.

Fixes: afa77ef (ARM: mx3: dynamically allocate "ipu-core" devices)
Signed-off-by: Emil Goode <>
Acked-by: Uwe Kleine-König <>
Signed-off-by: Shawn Guo <>
Signed-off-by: Olof Johansson <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agoreiserfs: call truncate_setsize under tailpack mutex
Jeff Mahoney [Wed, 21 May 2014 17:28:07 +0000 (13:28 -0400)]
reiserfs: call truncate_setsize under tailpack mutex

commit 22e7478ddbcb670e33fab72d0bbe7c394c3a2c84 upstream.

Prior to commit 0e4f6a791b1e (Fix reiserfs_file_release()), reiserfs
truncates serialized on i_mutex. They mostly still do, with the exception
of reiserfs_file_release. That blocks out other writers via the tailpack
mutex and the inode openers counter adjusted in reiserfs_file_open.

However, NFS will call reiserfs_setattr without having called ->open, so
we end up with a race when nfs is calling ->setattr while another
process is releasing the file. Ultimately, it triggers the
BUG_ON(inode->i_size != new_file_size) check in maybe_indirect_to_direct.

The solution is to pull the lock into reiserfs_setattr to encompass the
truncate_setsize call as well.

Signed-off-by: Jeff Mahoney <>
Signed-off-by: Jan Kara <>
Signed-off-by: Ben Hutchings <>
7 years agoreiserfs: drop vmtruncate
Marco Stornelli [Sat, 15 Dec 2012 10:47:31 +0000 (11:47 +0100)]
reiserfs: drop vmtruncate

commit cfac4b47c664e207740880d6492938761c53d74b upstream.

Removed vmtruncate

Signed-off-by: Marco Stornelli <>
Reviewed-by: Jan Kara <>
Signed-off-by: Al Viro <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agoIB/srp: Fix a sporadic crash triggered by cable pulling
Bart Van Assche [Tue, 20 May 2014 13:03:49 +0000 (15:03 +0200)]
IB/srp: Fix a sporadic crash triggered by cable pulling

commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec upstream.

Avoid that the loops that iterate over the request ring can encounter
a pointer to a SCSI command in req->scmnd that is no longer associated
with that request. If the function srp_unmap_data() is invoked twice
for a SCSI command that is not in flight then that would cause
ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument,
resulting in a kernel oops.

Reported-by: Sagi Grimberg <>
Signed-off-by: Bart Van Assche <>
Reviewed-by: Sagi Grimberg <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
7 years agoHID: core: fix validation of report id 0
Kees Cook [Thu, 17 Apr 2014 20:22:09 +0000 (13:22 -0700)]
HID: core: fix validation of report id 0

commit 1b15d2e5b8077670b1e6a33250a0d9577efff4a5 upstream.

Some drivers use the first HID report in the list instead of using an
index. In these cases, validation uses ID 0, which was supposed to mean
"first known report". This fixes the problem, which was causing at least
the lgff family of devices to stop working since hid_validate_values
was being called with ID 0, but the devices used single numbered IDs
for their reports:

0x05, 0x01,         /*  Usage Page (Desktop),                   */
0x09, 0x05,         /*  Usage (Gamepad),                        */
0xA1, 0x01,         /*  Collection (Application),               */
0xA1, 0x02,         /*      Collection (Logical),               */
0x85, 0x01,         /*          Report ID (1),                  */

Reported-by: Simon Wood <>
Signed-off-by: Kees Cook <>
Reviewed-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
7 years agoACPI: Fix conflict between customized DSDT and DSDT local copy
Lv Zheng [Mon, 12 May 2014 07:50:16 +0000 (15:50 +0800)]
ACPI: Fix conflict between customized DSDT and DSDT local copy

commit 73577d1df8e1f31f6b1a5eebcdbc334eb0330e47 upstream.

This patch fixes the following issue:
If DSDT is customized, no local DSDT copy is needed.

Signed-off-by: Enrico Etxe Arte <>
Signed-off-by: Lv Zheng <>
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
7 years agoInput: synaptics - add min/max quirk for the ThinkPad W540
Hans de Goede [Wed, 14 May 2014 18:10:40 +0000 (11:10 -0700)]
Input: synaptics - add min/max quirk for the ThinkPad W540

commit 0b5fe736fe923f1f5e05413878d5990e92ffbdf5 upstream.

Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agoUBIFS: fix an mmap and fsync race condition
hujianyang [Wed, 30 Apr 2014 06:06:06 +0000 (14:06 +0800)]
UBIFS: fix an mmap and fsync race condition

commit 691a7c6f28ac90cccd0dbcf81348ea90b211bdd0 upstream.

There is a race condition in UBIFS:

Thread A (mmap)                        Thread B (fsync)

->__do_fault                           ->write_cache_pages
   -> ubifs_vm_page_mkwrite
       -> budget_space
       -> lock_page
       -> release/convert_page_budget
       -> SetPagePrivate
       -> TestSetPageDirty
       -> unlock_page
                                       -> lock_page
                                           -> TestClearPageDirty
                                           -> ubifs_writepage
                                               -> do_writepage
                                                   -> release_budget
                                                   -> ClearPagePrivate
                                                   -> unlock_page
   -> !(ret & VM_FAULT_LOCKED)
   -> lock_page
   -> set_page_dirty
       -> ubifs_set_page_dirty
           -> TestSetPageDirty (set page dirty without budgeting)
   -> unlock_page

This leads to situation where we have a diry page but no budget allocated for
this page, so further write-back may fail with -ENOSPC.

In this fix we return from page_mkwrite without performing unlock_page. We
return VM_FAULT_LOCKED instead. After doing this, the race above will not

Signed-off-by: hujianyang <>
Tested-by: Laurence Withers <>
Signed-off-by: Artem Bityutskiy <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agogenirq: Sanitize spurious interrupt detection of threaded irqs
Thomas Gleixner [Thu, 7 Mar 2013 13:53:45 +0000 (14:53 +0100)]
genirq: Sanitize spurious interrupt detection of threaded irqs

commit 1e77d0a1ed7417d2a5a52a7b8d32aea1833faa6c upstream.

Till reported that the spurious interrupt detection of threaded
interrupts is broken in two ways:

- note_interrupt() is called for each action thread of a shared
  interrupt line. That's wrong as we are only interested whether none
  of the device drivers felt responsible for the interrupt, but by
  calling multiple times for a single interrupt line we account
  IRQ_NONE even if one of the drivers felt responsible.

- note_interrupt() when called from the thread handler is not
  serialized. That leaves the members of irq_desc which are used for
  the spurious detection unprotected.

To solve this we need to defer the spurious detection of a threaded
interrupt to the next hardware interrupt context where we have
implicit serialization.

If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
check whether the previous interrupt requested a deferred check. If
not, we request a deferred check for the next hardware interrupt and

If set, we check whether one of the interrupt threads signaled
success. Depending on this information we feed the result into the
spurious detector.

If one primary handler of a shared interrupt returns IRQ_HANDLED we
disable the deferred check of irq threads on the same line, as we have
found at least one device driver who cared.

Reported-by: Till Straumann <>
Signed-off-by: Thomas Gleixner <>
Tested-by: Austin Schuh <>
Cc: Oliver Hartkopp <>
Cc: Wolfgang Grandegger <>
Cc: Pavel Pisa <>
Cc: Marc Kleine-Budde <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
7 years agobluetooth: hci_ldisc: fix deadlock condition
Felipe Balbi [Wed, 23 Apr 2014 14:58:26 +0000 (09:58 -0500)]
bluetooth: hci_ldisc: fix deadlock condition

commit da64c27d3c93ee9f89956b9de86c4127eb244494 upstream.

LDISCs shouldn't call tty->ops->write() from within

->write_wakeup() is called with port lock taken and
IRQs disabled, tty->ops->write() will try to acquire
the same port lock and we will deadlock.

Acked-by: Marcel Holtmann <>
Reviewed-by: Peter Hurley <>
Reported-by: Huang Shijie <>
Signed-off-by: Felipe Balbi <>
Tested-by: Andreas Bießmann <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
7 years agomm: highmem: don't treat PKMAP_ADDR(LAST_PKMAP) as a highmem address
Will Deacon [Fri, 16 Nov 2012 22:15:00 +0000 (14:15 -0800)]
mm: highmem: don't treat PKMAP_ADDR(LAST_PKMAP) as a highmem address

commit 498c2280212327858e521e9d21345d4cc2637f54 upstream.

kmap_to_page returns the corresponding struct page for a virtual address
of an arbitrary mapping.  This works by checking whether the address
falls in the pkmap region and using the pkmap page tables instead of the
linear mapping if appropriate.

Unfortunately, the bounds checking means that PKMAP_ADDR(LAST_PKMAP) is
incorrectly treated as a highmem address and we can end up walking off
the end of pkmap_page_table and subsequently passing junk to pte_page.

This patch fixes the bound check to stay within the pkmap tables.

Signed-off-by: Will Deacon <>
Cc: Mel Gorman <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoLinux 3.2.60 v3.2.60
Ben Hutchings [Mon, 9 Jun 2014 12:29:18 +0000 (13:29 +0100)]
Linux 3.2.60

7 years agofutex: Make lookup_pi_state more robust
Thomas Gleixner [Tue, 3 Jun 2014 12:27:08 +0000 (12:27 +0000)]
futex: Make lookup_pi_state more robust

commit 54a217887a7b658e2650c3feff22756ab80c7339 upstream.

The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex.  We can get into the kernel
even if the TID value is 0, because either there is a stale waiters bit
or the owner died bit is set or we are called from the requeue_pi path
or from user space just for fun.

The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address.  This can lead to state leakage and worse under some

Handle the cases explicit:

       Waiter | pi_state | pi->owner | uTID      | uODIED | ?

  [1]  NULL   | ---      | ---       | 0         | 0/1    | Valid
  [2]  NULL   | ---      | ---       | >0        | 0/1    | Valid

  [3]  Found  | NULL     | --        | Any       | 0/1    | Invalid

  [4]  Found  | Found    | NULL      | 0         | 1      | Valid
  [5]  Found  | Found    | NULL      | >0        | 1      | Invalid

  [6]  Found  | Found    | task      | 0         | 1      | Valid

  [7]  Found  | Found    | NULL      | Any       | 0      | Invalid

  [8]  Found  | Found    | task      | ==taskTID | 0/1    | Valid
  [9]  Found  | Found    | task      | 0         | 0      | Invalid
  [10] Found  | Found    | task      | !=taskTID | 0/1    | Invalid

 [1] Indicates that the kernel can acquire the futex atomically. We
     came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.

 [2] Valid, if TID does not belong to a kernel thread. If no matching
     thread is found then it indicates that the owner TID has died.

 [3] Invalid. The waiter is queued on a non PI futex

 [4] Valid state after exit_robust_list(), which sets the user space

 [5] The user space value got manipulated between exit_robust_list()
     and exit_pi_state_list()

 [6] Valid state after exit_pi_state_list() which sets the new owner in
     the pi_state but cannot access the user space value.

 [7] pi_state->owner can only be NULL when the OWNER_DIED bit is set.

 [8] Owner and user space value match

 [9] There is no transient state which sets the user space TID to 0
     except exit_robust_list(), but this is indicated by the
     FUTEX_OWNER_DIED bit. See [4]

[10] There is no transient state which leaves owner and user space
     TID out of sync.

Signed-off-by: Thomas Gleixner <>
Cc: Kees Cook <>
Cc: Will Drewry <>
Cc: Darren Hart <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agofutex: Always cleanup owner tid in unlock_pi
Thomas Gleixner [Tue, 3 Jun 2014 12:27:07 +0000 (12:27 +0000)]
futex: Always cleanup owner tid in unlock_pi

commit 13fbca4c6ecd96ec1a1cfa2e4f2ce191fe928a5e upstream.

If the owner died bit is set at futex_unlock_pi, we currently do not
cleanup the user space futex.  So the owner TID of the current owner
(the unlocker) persists.  That's observable inconsistant state,
especially when the ownership of the pi state got transferred.

Clean it up unconditionally.

Signed-off-by: Thomas Gleixner <>
Cc: Kees Cook <>
Cc: Will Drewry <>
Cc: Darren Hart <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agofutex: Validate atomic acquisition in futex_lock_pi_atomic()
Thomas Gleixner [Tue, 3 Jun 2014 12:27:06 +0000 (12:27 +0000)]
futex: Validate atomic acquisition in futex_lock_pi_atomic()

commit b3eaa9fc5cd0a4d74b18f6b8dc617aeaf1873270 upstream.

We need to protect the atomic acquisition in the kernel against rogue
user space which sets the user space futex to 0, so the kernel side
acquisition succeeds while there is existing state in the kernel
associated to the real owner.

Verify whether the futex has waiters associated with kernel state.  If
it has, return -EINVAL.  The state is corrupted already, so no point in
cleaning it up.  Subsequent calls will fail as well.  Not our problem.

[ tglx: Use futex_top_waiter() and explain why we do not need to try
   restoring the already corrupted user space state. ]

Signed-off-by: Darren Hart <>
Cc: Kees Cook <>
Cc: Will Drewry <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agofutex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_r...
Thomas Gleixner [Tue, 3 Jun 2014 12:27:06 +0000 (12:27 +0000)]
futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == uaddr2 in futex_requeue(..., requeue_pi=1)

commit e9c243a5a6de0be8e584c604d353412584b592f8 upstream.

If uaddr == uaddr2, then we have broken the rule of only requeueing from
a non-pi futex to a pi futex with this call.  If we attempt this, then
dangling pointers may be left for rt_waiter resulting in an exploitable

This change brings futex_requeue() in line with futex_wait_requeue_pi()
which performs the same check as per commit 6f7b0a2a5c0f ("futex: Forbid
uaddr == uaddr2 in futex_wait_requeue_pi()")

[ tglx: Compare the resulting keys as well, as uaddrs might be
   different depending on the mapping ]

Fixes CVE-2014-3153.

Reported-by: Pinkie Pie
Signed-off-by: Will Drewry <>
Signed-off-by: Kees Cook <>
Signed-off-by: Thomas Gleixner <>
Reviewed-by: Darren Hart <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agofutex: Prevent attaching to kernel threads
Thomas Gleixner [Mon, 12 May 2014 20:45:35 +0000 (20:45 +0000)]
futex: Prevent attaching to kernel threads

commit f0d71b3dcb8332f7971b5f2363632573e6d9486a upstream.

We happily allow userspace to declare a random kernel thread to be the
owner of a user space PI futex.

Found while analysing the fallout of Dave Jones syscall fuzzer.

We also should validate the thread group for private futexes and find
some fast way to validate whether the "alleged" owner has RW access on
the file which backs the SHM, but that's a separate issue.

Signed-off-by: Thomas Gleixner <>
Cc: Dave Jones <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Darren Hart <>
Cc: Davidlohr Bueso <>
Cc: Steven Rostedt <>
Cc: Clark Williams <>
Cc: Paul McKenney <>
Cc: Lai Jiangshan <>
Cc: Roland McGrath <>
Cc: Carlos ODonell <>
Cc: Jakub Jelinek <>
Cc: Michael Kerrisk <>
Cc: Sebastian Andrzej Siewior <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agofutex: Add another early deadlock detection check
Thomas Gleixner [Mon, 12 May 2014 20:45:34 +0000 (20:45 +0000)]
futex: Add another early deadlock detection check

commit 866293ee54227584ffcb4a42f69c1f365974ba7f upstream.

Dave Jones trinity syscall fuzzer exposed an issue in the deadlock
detection code of rtmutex:

That underlying issue has been fixed with a patch to the rtmutex code,
but the futex code must not call into rtmutex in that case because
    - it can detect that issue early
    - it avoids a different and more complex fixup for backing out

If the user space variable got manipulated to 0x80000000 which means
no lock holder, but the waiters bit set and an active pi_state in the
kernel is found we can figure out the recursive locking issue by
looking at the pi_state owner. If that is the current task, then we
can safely return -EDEADLK.

The check should have been added in commit 59fa62451 (futex: Handle
futex_pi OWNER_DIED take over correctly) already, but I did not see
the above issue caused by user space manipulation back then.

Signed-off-by: Thomas Gleixner <>
Cc: Dave Jones <>
Cc: Linus Torvalds <>
Cc: Peter Zijlstra <>
Cc: Darren Hart <>
Cc: Davidlohr Bueso <>
Cc: Steven Rostedt <>
Cc: Clark Williams <>
Cc: Paul McKenney <>
Cc: Lai Jiangshan <>
Cc: Roland McGrath <>
Cc: Carlos ODonell <>
Cc: Jakub Jelinek <>
Cc: Michael Kerrisk <>
Cc: Sebastian Andrzej Siewior <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agomm/memory-failure.c: fix memory leak by race between poison and unpoison
Naoya Horiguchi [Thu, 22 May 2014 18:54:21 +0000 (11:54 -0700)]
mm/memory-failure.c: fix memory leak by race between poison and unpoison

commit 3e030ecc0fc7de10fd0da10c1c19939872a31717 upstream.

When a memory error happens on an in-use page or (free and in-use)
hugepage, the victim page is isolated with its refcount set to one.

When you try to unpoison it later, unpoison_memory() calls put_page()
for it twice in order to bring the page back to free page pool (buddy or
free hugepage list).  However, if another memory error occurs on the
page which we are unpoisoning, memory_failure() returns without
releasing the refcount which was incremented in the same call at first,
which results in memory leak and unconsistent num_poisoned_pages
statistics.  This patch fixes it.

Signed-off-by: Naoya Horiguchi <>
Cc: Andi Kleen <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: s/num_poisoned_pages/bad_mce_pages/]
Signed-off-by: Ben Hutchings <>
7 years agohwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage
Chen Yucong [Thu, 22 May 2014 18:54:15 +0000 (11:54 -0700)]
hwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage

commit b985194c8c0a130ed155b71662e39f7eaea4876f upstream.

For handling a free hugepage in memory failure, the race will happen if
another thread hwpoisoned this hugepage concurrently.  So we need to
check PageHWPoison instead of !PageHWPoison.

If hwpoison_filter(p) returns true or a race happens, then we need to

Signed-off-by: Chen Yucong <>
Reviewed-by: Naoya Horiguchi <>
Tested-by: Naoya Horiguchi <>
Reviewed-by: Andi Kleen <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: s/num_poisoned_pages/bad_mce_pages/]
Signed-off-by: Ben Hutchings <>
7 years agodma: mv_xor: Flush descriptors before activating a channel
Ezequiel Garcia [Wed, 21 May 2014 21:02:35 +0000 (14:02 -0700)]
dma: mv_xor: Flush descriptors before activating a channel

commit 5a9a55bf9157d3490b0c8c4c81d4708602c26e07 upstream.

We need to use writel() instead of writel_relaxed() when starting
a channel, to ensure all the descriptors have been flushed before
the activation.

While at it, remove the unneeded read-modify-write and make the
code simpler.

Signed-off-by: Lior Amsalem <>
Signed-off-by: Ezequiel Garcia <>
Signed-off-by: Dan Williams <>
[bwh: Backported to 3.2: it was using __raw_readl() and __raw_writel()
 which are just as wrong]
Signed-off-by: Ben Hutchings <>
7 years agonfsd4: warn on finding lockowner without stateid's
J. Bruce Fields [Thu, 8 May 2014 15:19:41 +0000 (11:19 -0400)]
nfsd4: warn on finding lockowner without stateid's

commit 27b11428b7de097c42f205beabb1764f4365443b upstream.

The current code assumes a one-to-one lockowner<->lock stateid

Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
7 years agonfsd4: remove lockowner when removing lock stateid
J. Bruce Fields [Tue, 20 May 2014 19:55:21 +0000 (15:55 -0400)]
nfsd4: remove lockowner when removing lock stateid

commit a1b8ff4c97b4375d21b6d6c45d75877303f61b3b upstream.

The nfsv4 state code has always assumed a one-to-one correspondance
between lock stateid's and lockowners even if it appears not to in some

We may actually change that, but for now when FREE_STATEID releases a
lock stateid it also needs to release the parent lockowner.

Symptoms were a subsequent LOCK crashing in find_lockowner_str when it
calls same_lockowner_ino on a lockowner that unexpectedly has an empty
so_stateids list.

Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
7 years agocan: peak_pci: prevent use after free at netdev removal
Stephane Grosjean [Tue, 20 May 2014 09:38:56 +0000 (11:38 +0200)]
can: peak_pci: prevent use after free at netdev removal

commit 0b5a958cf4df3a5cd578b861471e62138f55c85e upstream.

As remarked by Christopher R. Baker in his post at

there's a possibility for an use after free condition at device removal.

This simplified patch introduces an additional variable to prevent the issue.
Thanks for catching this.

Reported-by: Christopher R. Baker <>
Signed-off-by: Stephane Grosjean <>
Signed-off-by: Marc Kleine-Budde <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agocan: peak_pci: Fix the way channels are linked together
Stephane Grosjean [Wed, 1 Feb 2012 10:05:48 +0000 (11:05 +0100)]
can: peak_pci: Fix the way channels are linked together

commit 29830406415c227a54af429d7b300aabd4754237 upstream.

Change the way channels objects are linked together by peak_pci_probe()
avoiding any kernel oops when driver is removed. Side effect is that
the list is now browsed from last to first channel.

Signed-off-by: Stephane Grosjean <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
7 years agodrm/radeon: handle non-VGA class pci devices with ATRM
Alex Deucher [Fri, 9 May 2014 00:04:03 +0000 (20:04 -0400)]
drm/radeon: handle non-VGA class pci devices with ATRM

commit d8ade3526b2aa0505132c404c05a38b73ea15490 upstream.

Newer PX systems have non-VGA pci class dGPUs.  Update
the ATRM fetch method to handle those cases.


Signed-off-by: Alex Deucher <>
Signed-off-by: Christian König <>
[bwh: Backported to 3.2: s/ACPI_HANDLE()/DEVICE_ACPI_HANDLE()/]
Signed-off-by: Ben Hutchings <>
7 years agodrm/radeon: also try GART for CPU accessed buffers
Christian König [Mon, 5 May 2014 16:40:12 +0000 (18:40 +0200)]
drm/radeon: also try GART for CPU accessed buffers

commit 544092596e8ac269f70e70961b5e9381909c9b1e upstream.

Placing them exclusively into VRAM might not work all the time.


Signed-off-by: Christian König <>
Reviewed-by: Alex Deucher <>
[bwh: Backported to 3.2: ttm_bo_validate() takes an extra no_wait_reserve
 parameter; keep passing true]
Signed-off-by: Ben Hutchings <>
7 years agoperf: Prevent false warning in perf_swevent_add
Jiri Olsa [Mon, 7 Apr 2014 09:04:08 +0000 (11:04 +0200)]
perf: Prevent false warning in perf_swevent_add

commit 39af6b1678afa5880dda7e375cf3f9d395087f6d upstream.

The perf cpu offline callback takes down all cpu context
events and releases swhash->swevent_hlist.

This could race with task context software event being just
scheduled on this cpu via perf_swevent_add while cpu hotplug
code already cleaned up event's data.

The race happens in the gap between the cpu notifier code
and the cpu being actually taken down. Note that only cpu
ctx events are terminated in the perf cpu hotplug code.

It's easily reproduced with:
  $ perf record -e faults perf bench sched pipe

while putting one of the cpus offline:
  # echo 0 > /sys/devices/system/cpu/cpu1/online

Console emits following warning:
  WARNING: CPU: 1 PID: 2845 at kernel/events/core.c:5672 perf_swevent_add+0x18d/0x1a0()
  Modules linked in:
  CPU: 1 PID: 2845 Comm: sched-pipe Tainted: G        W    3.14.0+ #256
  Hardware name: Intel Corporation Montevina platform/To be filled by O.E.M., BIOS AMVACRB1.86C.0066.B00.0805070703 05/07/2008
   0000000000000009 ffff880077233ab8 ffffffff81665a23 0000000000200005
   0000000000000000 ffff880077233af8 ffffffff8104732c 0000000000000046
   ffff88007467c800 0000000000000002 ffff88007a9cf2a0 0000000000000001
  Call Trace:
   [<ffffffff81665a23>] dump_stack+0x4f/0x7c
   [<ffffffff8104732c>] warn_slowpath_common+0x8c/0xc0
   [<ffffffff8104737a>] warn_slowpath_null+0x1a/0x20
   [<ffffffff8110fb3d>] perf_swevent_add+0x18d/0x1a0
   [<ffffffff811162ae>] event_sched_in.isra.75+0x9e/0x1f0
   [<ffffffff8111646a>] group_sched_in+0x6a/0x1f0
   [<ffffffff81083dd5>] ? sched_clock_local+0x25/0xa0
   [<ffffffff811167e6>] ctx_sched_in+0x1f6/0x450
   [<ffffffff8111757b>] perf_event_sched_in+0x6b/0xa0
   [<ffffffff81117a4b>] perf_event_context_sched_in+0x7b/0xc0
   [<ffffffff81117ece>] __perf_event_task_sched_in+0x43e/0x460
   [<ffffffff81096f1e>] ? put_lock_stats.isra.18+0xe/0x30
   [<ffffffff8107b3c8>] finish_task_switch+0xb8/0x100
   [<ffffffff8166a7de>] __schedule+0x30e/0xad0
   [<ffffffff81172dd2>] ? pipe_read+0x3e2/0x560
   [<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
   [<ffffffff8166b45e>] ? preempt_schedule_irq+0x3e/0x70
   [<ffffffff8166b464>] preempt_schedule_irq+0x44/0x70
   [<ffffffff816707f0>] retint_kernel+0x20/0x30
   [<ffffffff8109e60a>] ? lockdep_sys_exit+0x1a/0x90
   [<ffffffff812a4234>] lockdep_sys_exit_thunk+0x35/0x67
   [<ffffffff81679321>] ? sysret_check+0x5/0x56

Fixing this by tracking the cpu hotplug state and displaying
the WARN only if current cpu is initialized properly.

Cc: Corey Ashford <>
Cc: Frederic Weisbecker <>
Cc: Ingo Molnar <>
Cc: Paul Mackerras <>
Cc: Arnaldo Carvalho de Melo <>
Reported-by: Fengguang Wu <>
Signed-off-by: Jiri Olsa <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agoperf: Limit perf_event_attr::sample_period to 63 bits
Peter Zijlstra [Thu, 15 May 2014 18:23:48 +0000 (20:23 +0200)]
perf: Limit perf_event_attr::sample_period to 63 bits

commit 0819b2e30ccb93edf04876237b6205eef84ec8d2 upstream.

Vince reported that using a large sample_period (one with bit 63 set)
results in wreckage since while the sample_period is fundamentally
unsigned (negative periods don't make sense) the way we implement
things very much rely on signed logic.

So limit sample_period to 63 bits to avoid tripping over this.

Reported-by: Vince Weaver <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agolibceph: fix corruption when using page_count 0 page in rbd
Chunwei Chen [Wed, 23 Apr 2014 04:35:09 +0000 (12:35 +0800)]
libceph: fix corruption when using page_count 0 page in rbd

commit 178eda29ca721842f2146378e73d43e0044c4166 upstream.

It has been reported that using ZFSonLinux on rbd will result in memory
corruption. The bug report can be found here:

The reason is that ZFS will send pages with page_count 0 into rbd, which in
turns send them to tcp_sendpage. However, tcp_sendpage cannot deal with
page_count 0, as it will do get_page and put_page, and erroneously free the

This type of issue has been noted before, and handled in iscsi, drbd,
etc. So, rbd should also handle this. This fix address this issue by fall back
to slower sendmsg when page_count 0 detected.

Cc: Sage Weil <>
Cc: Yehuda Sadeh <>
Signed-off-by: Chunwei Chen <>
Reviewed-by: Ilya Dryomov <>
Signed-off-by: Ben Hutchings <>
7 years agolibceph: only call kernel_sendpage() via helper
Alex Elder [Wed, 7 Mar 2012 17:40:08 +0000 (11:40 -0600)]
libceph: only call kernel_sendpage() via helper

commit e36b13cceb46136d849aeee06b4907ad3570ba78 upstream.

Make ceph_tcp_sendpage() be the only place kernel_sendpage() is
used, by using this helper in write_partial_msg_pages().

Signed-off-by: Alex Elder <>
Reviewed-by: Sage Weil <>
[bwh: Backported to 3.2:
 - Add ceph_tcp_sendpage(), from commit 31739139f3ed ('libceph: use
   kernel_sendpage() for sending zeroes'), the rest of which is not
 - Adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoPCI: shpchp: Check bridge's secondary (not primary) bus speed
Marcel Apfelbaum [Thu, 15 May 2014 18:42:49 +0000 (12:42 -0600)]
PCI: shpchp: Check bridge's secondary (not primary) bus speed

commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream.

When a new device is added below a hotplug bridge, the bridge's secondary
bus speed and the device's bus speed must match.  The shpchp driver
previously checked the bridge's *primary* bus speed, not the secondary bus

This caused hot-add errors like:

  shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch

Check the secondary bus speed instead.

[bhelgaas: changelog]
Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core")
Signed-off-by: Marcel Apfelbaum <>
Signed-off-by: Bjorn Helgaas <>
Acked-by: Michael S. Tsirkin <>
Signed-off-by: Ben Hutchings <>
7 years agox86-64, modify_ldt: Make support for 16-bit segments a runtime option
Linus Torvalds [Wed, 14 May 2014 23:33:54 +0000 (16:33 -0700)]
x86-64, modify_ldt: Make support for 16-bit segments a runtime option

commit fa81511bb0bbb2b1aace3695ce869da9762624ff upstream.


b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

disabled 16-bit segments on 64-bit kernels due to an information
leak.  However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.

A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.

It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do

   echo 1 > /proc/sys/abi/ldt16

as root (add it to your startup scripts), and you should be ok.

The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that ;)

Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
7 years agoi2c: s3c2410: resume race fix
Olof Johansson [Fri, 11 Apr 2014 22:19:41 +0000 (15:19 -0700)]
i2c: s3c2410: resume race fix

commit ce78cc071f5f541480e381cc0241d37590041a9d upstream.

Don't unmark the device as suspended until after it's been re-setup.

The main race would be w.r.t. an i2c driver that gets resumed at the same
time (asyncronously), that is allowed to do a transfer since suspended
is set to 0 before reinit, but really should have seen the -EIO return

Signed-off-by: Olof Johansson <>
Signed-off-by: Doug Anderson <>
Acked-by: Kukjin Kim <>
Signed-off-by: Wolfram Sang <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoi2c: designware: Mask all interrupts during i2c controller enable
Du, Wenkai [Thu, 10 Apr 2014 23:03:19 +0000 (23:03 +0000)]
i2c: designware: Mask all interrupts during i2c controller enable

commit 47bb27e78867997040a228328f2a631c3c7f2c82 upstream.

There have been "i2c_designware 80860F41:00: controller timed out" errors
on a number of Baytrail platforms. The issue is caused by incorrect value in
Interrupt Mask Register (DW_IC_INTR_MASK)  when i2c core is being enabled.
This causes call to __i2c_dw_enable() to immediately start the transfer which
leads to timeout. There are 3 failure modes observed:

1. Failure in S0 to S3 resume path

The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start
the first transaction after resuming from system sleep, TX_EMPTY interrupt
is already unmasked because of the hardware default.

2. Failure in normal operational path

This failure happens rarely and is hard to reproduce. Debug trace showed that
DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant
TX_EMPTY was unmasked.

3. Failure in S3 to S0 suspend path

This failure also happens rarely and is hard to reproduce. Adding debug trace
that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR
call trace we could conclude TX_EMPTY was unmasked when problem occurred.

The patch masks all interrupts before the controller is enabled to resolve the
faulty DW_IC_INTR_MASK conditions.

Signed-off-by: Wenkai Du <>
Acked-by: Mika Westerberg <>
[wsa: improved the comment and removed typo in commit msg]
Signed-off-by: Wolfram Sang <>
Signed-off-by: Ben Hutchings <>
7 years agox86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
Anthony Iliopoulos [Wed, 14 May 2014 09:29:48 +0000 (11:29 +0200)]
x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()

commit 9844f5462392b53824e8b86726e7c33b5ecbb676 upstream.

The invalidation is required in order to maintain proper semantics
under CoW conditions. In scenarios where a process clones several
threads, a thread operating on a core whose DTLB entry for a
particular hugepage has not been invalidated, will be reading from
the hugepage that belongs to the forked child process, even after

The thread will not see the updated page as long as the stale DTLB
entry remains cached, the thread attempts to write into the page,
the child process exits, or the thread gets migrated to a different

Signed-off-by: Anthony Iliopoulos <>
Suggested-by: Shay Goikhman <>
Acked-by: Dave Hansen <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
7 years agoV4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode
Guennadi Liakhovetski [Sat, 26 Apr 2014 15:51:31 +0000 (12:51 -0300)]
V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility mode

commit 97d9d23dda6f37d90aefeec4ed619d52df525382 upstream.

If a struct contains 64-bit fields, it is aligned on 64-bit boundaries
within containing structs in 64-bit compilations. This is the case with
struct v4l2_window, which contains pointers and is embedded into struct
v4l2_format, and that one is embedded into struct v4l2_create_buffers.
Unlike some other structs, used as a part of the kernel ABI as ioctl()
arguments, that are packed, these structs aren't packed. This isn't a
problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains
a bug, that triggers in such 64-bit builds. That code wrongly assumes,
that in struct v4l2_create_buffers, struct v4l2_format immediately follows
the __u32 memory field, which in fact isn't the case. This bug wasn't
visible until now, because until recently hardly any applications used
this ioctl() and mostly embedded 32-bit only drivers implemented it. This
is changing now with addition of this ioctl() to some USB drivers, e.g.
UVC. This patch fixes the bug by copying parts of struct
v4l2_create_buffers separately.

Signed-off-by: Guennadi Liakhovetski <>
Acked-by: Laurent Pinchart <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agoV4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space
Guennadi Liakhovetski [Mon, 14 Apr 2014 13:49:34 +0000 (10:49 -0300)]
V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-space

commit cfece5857ca51d1dcdb157017aba226f594e9dcf upstream.

Commit 75e2bdad8901a0b599e01a96229be922eef1e488 "ov7670: allow
configuration of image size, clock speed, and I/O method" uses a wrong
index to iterate an array. Apart from being wrong, it also uses an
unchecked value from user-space, which can cause access to unmapped
memory in the kernel, triggered by a normal desktop user with rights to
use V4L2 devices.

Signed-off-by: Guennadi Liakhovetski <>
Acked-by: Jonathan Corbet <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2:
 - Adjust filename
 - win_sizes array is static, not per-device]
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (emc1403) Support full range of known chip revision numbers
Josef Gajdusek [Mon, 12 May 2014 11:48:26 +0000 (13:48 +0200)]
hwmon: (emc1403) Support full range of known chip revision numbers

commit 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 upstream.

The datasheet for EMC1413/EMC1414, which is fully compatible to
EMC1403/1404 and uses the same chip identification, references revision
numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers
from 0x01 to 0x04 to make sure none are missed.

Signed-off-by: Josef Gajdusek <>
[Guenter Roeck: Updated headline and description]
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (emc1403) fix inverted store_hyst()
Josef Gajdusek [Sun, 11 May 2014 12:40:44 +0000 (14:40 +0200)]
hwmon: (emc1403) fix inverted store_hyst()

commit 17c048fc4bd95efea208a1920f169547d8588f1f upstream.

Attempts to set the hysteresis value to a temperature below the target
limit fails with "write error: Numerical result out of range" due to
an inverted comparison.

Signed-off-by: Josef Gajdusek <>
Reviewed-by: Jean Delvare <>
[Guenter Roeck: Updated headline and description]
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
7 years agohrtimer: Set expiry time before switch_hrtimer_base()
Viresh Kumar [Mon, 12 May 2014 08:12:29 +0000 (13:42 +0530)]
hrtimer: Set expiry time before switch_hrtimer_base()

commit 84ea7fe37908254c3bd90910921f6e1045c1747a upstream.

switch_hrtimer_base() calls hrtimer_check_target() which ensures that
we do not migrate a timer to a remote cpu if the timer expires before
the current programmed expiry time on that remote cpu.

But __hrtimer_start_range_ns() calls switch_hrtimer_base() before the
new expiry time is set. So the sanity check in hrtimer_check_target()
is operating on stale or even uninitialized data.

Update expiry time before calling switch_hrtimer_base().

[ tglx: Rewrote changelog once again ]

Signed-off-by: Viresh Kumar <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agoNFSD: Call ->set_acl with a NULL ACL structure if no entries
Kinglong Mee [Fri, 18 Apr 2014 12:49:04 +0000 (20:49 +0800)]
NFSD: Call ->set_acl with a NULL ACL structure if no entries

commit aa07c713ecfc0522916f3cd57ac628ea6127c0ec upstream.

After setting ACL for directory, I got two problems that caused
by the cached zero-length default posix acl.

This patch make sure nfsd4_set_nfs4_acl calls ->set_acl
with a NULL ACL structure if there are no entries.

Thanks for Christoph Hellwig's advice.

First problem:
............ hang ...........

Second problem:
[ 1610.167668] ------------[ cut here ]------------
[ 1610.168320] kernel BUG at /root/nfs/linux/fs/nfsd/nfs4acl.c:239!
[ 1610.168320] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 1610.168320] Modules linked in: nfsv4(OE) nfs(OE) nfsd(OE)
rpcsec_gss_krb5 fscache ip6t_rpfilter ip6t_REJECT cfg80211 xt_conntrack
rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw
auth_rpcgss nfs_acl snd_intel8x0 ppdev lockd snd_ac97_codec ac97_bus
snd_pcm snd_timer e1000 pcspkr parport_pc snd parport serio_raw joydev
i2c_piix4 sunrpc(OE) microcode soundcore i2c_core ata_generic pata_acpi
[last unloaded: nfsd]
[ 1610.168320] CPU: 0 PID: 27397 Comm: nfsd Tainted: G           OE
3.15.0-rc1+ #15
[ 1610.168320] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[ 1610.168320] task: ffff88005ab653d0 ti: ffff88005a944000 task.ti:
[ 1610.168320] RIP: 0010:[<ffffffffa034d5ed>]  [<ffffffffa034d5ed>]
_posix_to_nfsv4_one+0x3cd/0x3d0 [nfsd]
[ 1610.168320] RSP: 0018:ffff88005a945b00  EFLAGS: 00010293
[ 1610.168320] RAX: 0000000000000001 RBX: ffff88006700bac0 RCX:
[ 1610.168320] RDX: 0000000000000000 RSI: ffff880067c83f00 RDI:
[ 1610.168320] RBP: ffff88005a945b48 R08: ffffffff81c64830 R09:
[ 1610.168320] R10: ffff88004ea85be0 R11: 000000000000f475 R12:
[ 1610.168320] R13: 0000000000000003 R14: 0000000000000002 R15:
[ 1610.168320] FS:  0000000000000000(0000) GS:ffff880077800000(0000)
[ 1610.168320] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1610.168320] CR2: 00007f5bcbd3b0b9 CR3: 0000000001c0f000 CR4:
[ 1610.168320] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
[ 1610.168320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
[ 1610.168320] Stack:
[ 1610.168320]  ffffffff00000000 0000000b67c83500 000000076700bac0
[ 1610.168320]  ffff88006700bac0 ffff880068233300 ffff88005a945c08
[ 1610.168320]  0000000000000000 ffff88005a945b88 ffffffffa034e2d5
[ 1610.168320] Call Trace:
[ 1610.168320]  [<ffffffffa034e2d5>] nfsd4_get_nfs4_acl+0x95/0x150 [nfsd]
[ 1610.168320]  [<ffffffffa03400d6>] nfsd4_encode_fattr+0x646/0x1e70 [nfsd]
[ 1610.168320]  [<ffffffff816a6e6e>] ? kmemleak_alloc+0x4e/0xb0
[ 1610.168320]  [<ffffffffa0327962>] ?
nfsd_setuser_and_check_port+0x52/0x80 [nfsd]
[ 1610.168320]  [<ffffffff812cd4bb>] ? selinux_cred_prepare+0x1b/0x30
[ 1610.168320]  [<ffffffffa0341caa>] nfsd4_encode_getattr+0x5a/0x60 [nfsd]
[ 1610.168320]  [<ffffffffa0341e07>] nfsd4_encode_operation+0x67/0x110
[ 1610.168320]  [<ffffffffa033844d>] nfsd4_proc_compound+0x21d/0x810 [nfsd]
[ 1610.168320]  [<ffffffffa0324d9b>] nfsd_dispatch+0xbb/0x200 [nfsd]
[ 1610.168320]  [<ffffffffa00850cd>] svc_process_common+0x46d/0x6d0 [sunrpc]
[ 1610.168320]  [<ffffffffa0085433>] svc_process+0x103/0x170 [sunrpc]
[ 1610.168320]  [<ffffffffa032472f>] nfsd+0xbf/0x130 [nfsd]
[ 1610.168320]  [<ffffffffa0324670>] ? nfsd_destroy+0x80/0x80 [nfsd]
[ 1610.168320]  [<ffffffff810a5202>] kthread+0xd2/0xf0
[ 1610.168320]  [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40
[ 1610.168320]  [<ffffffff816c1ebc>] ret_from_fork+0x7c/0xb0
[ 1610.168320]  [<ffffffff810a5130>] ? insert_kthread_work+0x40/0x40
[ 1610.168320] Code: 78 02 e9 e7 fc ff ff 31 c0 31 d2 31 c9 66 89 45 ce
41 8b 04 24 66 89 55 d0 66 89 4d d2 48 8d 04 80 49 8d 5c 84 04 e9 37 fd
ff ff <0f> 0b 90 0f 1f 44 00 00 55 8b 56 08 c7 07 00 00 00 00 8b 46 0c
[ 1610.168320] RIP  [<ffffffffa034d5ed>] _posix_to_nfsv4_one+0x3cd/0x3d0
[ 1610.168320]  RSP <ffff88005a945b00>
[ 1610.257313] ---[ end trace 838254e3e352285b ]---

Signed-off-by: Kinglong Mee <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
7 years agotrace: module: Maintain a valid user count
Romain Izard [Tue, 4 Mar 2014 09:09:39 +0000 (10:09 +0100)]
trace: module: Maintain a valid user count

commit 098507ae3ec2331476fb52e85d4040c1cc6d0ef4 upstream.

The replacement of the 'count' variable by two variables 'incs' and
'decs' to resolve some race conditions during module unloading was done
in parallel with some cleanup in the trace subsystem, and was integrated
as a merge.

Unfortunately, the formula for this replacement was wrong in the tracing
code, and the refcount in the traces was not usable as a result.

Use 'count = incs - decs' to compute the user count.

Acked-by: Ingo Molnar <>
Cc: Rusty Russell <>
Cc: Frederic Weisbecker <>
Fixes: c1ab9cab7509 "merge conflict resolution"
Signed-off-by: Romain Izard <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
7 years agosched: Use CPUPRI_NR_PRIORITIES instead of MAX_RT_PRIO in cpupri check
Steven Rostedt (Red Hat) [Sun, 13 Apr 2014 13:34:53 +0000 (09:34 -0400)]
sched: Use CPUPRI_NR_PRIORITIES instead of MAX_RT_PRIO in cpupri check

commit 6227cb00cc120f9a43ce8313bb0475ddabcb7d01 upstream.

The check at the beginning of cpupri_find() makes sure that the task_pri
variable does not exceed the cp->pri_to_cpu array length. But that length
is CPUPRI_NR_PRIORITIES not MAX_RT_PRIO, where it will miss the last two
priorities in that array.

As task_pri is computed from convert_prio() which should never be bigger
than CPUPRI_NR_PRIORITIES, if the check should cause a panic if it is

Reported-by: Mike Galbraith <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agomm/page-writeback.c: fix divide by zero in pos_ratio_polynom
Rik van Riel [Tue, 6 May 2014 19:50:01 +0000 (12:50 -0700)]
mm/page-writeback.c: fix divide by zero in pos_ratio_polynom

commit d5c9fde3dae750889168807038243ff36431d276 upstream.

It is possible for "limit - setpoint + 1" to equal zero, after getting
truncated to a 32 bit variable, and resulting in a divide by zero error.

Using the fully 64 bit divide functions avoids this problem.  It also
will cause pos_ratio_polynom() to return the correct value when
(setpoint - limit) exceeds 2^32.

Also uninline pos_ratio_polynom, at Andrew's request.

Signed-off-by: Rik van Riel <>
Reviewed-by: Michal Hocko <>
Cc: Aneesh Kumar K.V <>
Cc: Mel Gorman <>
Cc: Nishanth Aravamudan <>
Cc: Luiz Capitulino <>
Cc: Masayoshi Mizuma <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 Adjust context - pos_ratio_polynom() is not a separate function]
Signed-off-by: Ben Hutchings <>
7 years agoNegative (setpoint-dirty) in bdi_position_ratio() [Sun, 20 Jan 2013 00:02:10 +0000 (11:02 +1100)]
Negative (setpoint-dirty) in bdi_position_ratio()

commit ed84825b785ceb932af7dd5aa08614801721320b upstream.

In bdi_position_ratio(), get difference (setpoint-dirty) right even when
negative. Both setpoint and dirty are unsigned long, the difference was
zero-padded thus wrongly sign-extended to s64. This issue affects all
32-bit architectures, does not affect 64-bit architectures where long
and s64 are equivalent.

In this function, dirty is between freerun and limit, the pseudo-float x
is between [-1,1], expected to be negative about half the time. With
zero-padding, instead of a small negative x we obtained a large positive
one so bdi_position_ratio() returned garbage.

Casting the difference to s64 also prevents overflow with left-shift;
though normally these numbers are small and I never observed a 32-bit
overflow there.

(This patch does not solve the PAE OOM issue.)

Paul Szabo
School of Mathematics and Statistics   University of Sydney    Australia

Reviewed-by: Jan Kara <>
Reported-by: Paul Szabo <>
Signed-off-by: Paul Szabo <>
Signed-off-by: Fengguang Wu <>
Signed-off-by: Ben Hutchings <>
7 years agoposix_acl: handle NULL ACL in posix_acl_equiv_mode
Christoph Hellwig [Sun, 4 May 2014 11:03:32 +0000 (13:03 +0200)]
posix_acl: handle NULL ACL in posix_acl_equiv_mode

commit 50c6e282bdf5e8dabf8d7cf7b162545a55645fd9 upstream.

Various filesystems don't bother checking for a NULL ACL in
posix_acl_equiv_mode, and thus can dereference a NULL pointer when it
gets passed one. This usually happens from the NFS server, as the ACL tools
never pass a NULL ACL, but instead of one representing the mode bits.

Instead of adding boilerplat to all filesystems put this check into one place,
which will allow us to remove the check from other filesystems as well later

Signed-off-by: Christoph Hellwig <>
Reported-by: Ben Greear <>
Reported-by: Marco Munderloh <>,
Cc: Chuck Lever <>
Signed-off-by: Al Viro <>
Signed-off-by: Ben Hutchings <>
7 years agoNFSd: call rpc_destroy_wait_queue() from free_client()
Trond Myklebust [Fri, 18 Apr 2014 18:43:57 +0000 (14:43 -0400)]
NFSd: call rpc_destroy_wait_queue() from free_client()

commit 4cb57e3032d4e4bf5e97780e9907da7282b02b0c upstream.

Mainly to ensure that we don't leave any hanging timers.

Signed-off-by: Trond Myklebust <>
Signed-off-by: J. Bruce Fields <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoNFSd: Move default initialisers from create_client() to alloc_client()
Trond Myklebust [Fri, 18 Apr 2014 18:43:56 +0000 (14:43 -0400)]
NFSd: Move default initialisers from create_client() to alloc_client()

commit 5694c93e6c4954fa9424c215f75eeb919bddad64 upstream.

Aside from making it clearer what is non-trivial in create_client(), it
also fixes a bug whereby we can call free_client() before idr_init()
has been called.

Signed-off-by: Trond Myklebust <>
Signed-off-by: J. Bruce Fields <>
[bwh: Backported to 3.2:
 - Adjust context
 - Also move initialisation of nfs4_client::cl_strhash, but
   not nfs4_client::cl_revoked]
Signed-off-by: Ben Hutchings <>
7 years agomd: avoid possible spinning md thread at shutdown.
NeilBrown [Mon, 5 May 2014 23:36:08 +0000 (09:36 +1000)]
md: avoid possible spinning md thread at shutdown.

commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream.

If an md array with externally managed metadata (e.g. DDF or IMSM)
is in use, then we should not set safemode==2 at shutdown because:

1/ this is ineffective: user-space need to be involved in any 'safemode' handling,
2/ The safemode management code doesn't cope with safemode==2 on external metadata
   and md_check_recover enters an infinite loop.

Even at shutdown, an infinite-looping process can be problematic, so this
could cause shutdown to hang.

Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
7 years agoInput: elantech - fix touchpad initialization on Gigabyte U2442
Hans de Goede [Mon, 5 May 2014 16:36:43 +0000 (09:36 -0700)]
Input: elantech - fix touchpad initialization on Gigabyte U2442

commit 36189cc3cd57ab0f1cd75241f93fe01de928ac06 upstream.

The hw_version 3 Elantech touchpad on the Gigabyte U2442 does not accept
0x0b as initialization value for r10, this stand-alone version of the

Uses 0x03 which does work, so this means not setting bit 3 of r10 which
sets: "Enable Real H/W Resolution In Absolute mode"

Which will result in half the x and y resolution we get with that bit set,
so simply not setting it everywhere is not a solution. We've been unable to
find a way to identify touchpads where setting the bit will fail, so this
patch uses a dmi based blacklist for this.

Reported-by: Philipp Wolfer <>
Tested-by: Philipp Wolfer <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoHID: add NO_INIT_REPORTS quirk for Synaptics Touch Pad V 103S
Hans de Goede [Fri, 2 May 2014 17:48:13 +0000 (19:48 +0200)]
HID: add NO_INIT_REPORTS quirk for Synaptics Touch Pad V 103S

commit 2f433083e854ec72c19dc9b0e1cebcc8e230fd75 upstream.

This touchpad seriously dislikes init reports, not only timeing out, but
also refusing to work after this.

Reported-and-tested-by: Vincent Fortier <>
Signed-off-by: Hans de Goede <>
Reviewed-by: Benjamin Tissoires <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
7 years agoHID: usbhid: quirk for Synaptics Quad HD touchscreen
AceLan Kao [Wed, 27 Nov 2013 02:05:58 +0000 (10:05 +0800)]
HID: usbhid: quirk for Synaptics Quad HD touchscreen

commit 12f508aede4bda5d20a2dd3ff3deb16ef47a97e9 upstream.

Add Synaptics HD touchscreen(06cb:1ac3) to no init report quirk

Signed-off-by: AceLan Kao <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
7 years agoHID: usbhid: quirk for Synaptics HD touchscreen
AceLan Kao [Wed, 27 Nov 2013 02:05:57 +0000 (10:05 +0800)]
HID: usbhid: quirk for Synaptics HD touchscreen

commit d8e2e7581d2521910398c4c80d7a3b78e84da7d5 upstream.

Add Synaptics HD touchscreen(06cb:0ac3) to no init report quirk.

Signed-off-by: AceLan Kao <>
Signed-off-by: Jiri Kosina <>
Signed-off-by: Ben Hutchings <>
7 years agoHID: usbhid: quirk for Synaptics Large Touchccreen
AceLan Kao [Wed, 2 Oct 2013 09:35:26 +0000 (17:35 +0800)]
HID: usbhid: quirk for Synaptics Large Touchccreen

commit 8171a67d587a09e14a4949a81e070345fedcf410 upstream.

Synaptics large touchscreen doesn't support some of the report request
while initializing. The unspoorted request will make the device unreachable,
and will lead to the following usb_submit_urb() function call timeout.
So, add the IDs into HID_QUIRK_NO_INIT_REPORTS quirk.

Signed-off-by: AceLan Kao <>
Signed-off-by: Jiri Kosina <>
[bwh: Backported to 3.2:
 - Adjust context
 - Add definition of USB_VENDOR_ID_SYNAPTICS]
Signed-off-by: Ben Hutchings <>
7 years agoUSB: Nokia 5300 should be treated as unusual dev
Daniele Forsi [Mon, 28 Apr 2014 15:09:11 +0000 (17:09 +0200)]
USB: Nokia 5300 should be treated as unusual dev

commit 6ed07d45d09bc2aa60e27b845543db9972e22a38 upstream.

Signed-off-by: Daniele Forsi <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: Nokia 305 should be treated as unusual dev
Victor A. Santos [Sun, 27 Apr 2014 02:20:14 +0000 (23:20 -0300)]
USB: Nokia 305 should be treated as unusual dev

commit f0ef5d41792a46a1085dead9dfb0bdb2c574638e upstream.

Signed-off-by: Victor A. Santos <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agodrivers/tty/hvc: don't free hvc_console_setup after init
Tomoki Sekiyama [Fri, 2 May 2014 22:58:24 +0000 (18:58 -0400)]
drivers/tty/hvc: don't free hvc_console_setup after init

commit 501fed45b7e8836ee9373f4d31e2d85e3db6103a upstream.

When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest,
hvc console is setup within a kthread. However, that will cause SEGV
and the boot will fail when the driver is builtin to the kernel,
because currently hvc_console_setup() is annotated with '__init'. This
patch removes '__init' to boot the guest successfully with 'console=hvc0'.

Signed-off-by: Tomoki Sekiyama <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agousb: storage: shuttle_usbat: fix discs being detected twice
Daniele Forsi [Tue, 29 Apr 2014 09:44:03 +0000 (11:44 +0200)]
usb: storage: shuttle_usbat: fix discs being detected twice

commit df602c2d2358f02c6e49cffc5b49b9daa16db033 upstream.

Even if the USB-to-ATAPI converter supported multiple LUNs, this
driver would always detect the same physical device or media because
it doesn't use srb->device->lun in any way.
Tested with an Hewlett-Packard CD-Writer Plus 8200e.

Signed-off-by: Daniele Forsi <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agodrm/nouveau/acpi: allow non-optimus setups to load vbios from acpi
Ilia Mirkin [Wed, 26 Mar 2014 23:37:21 +0000 (19:37 -0400)]
drm/nouveau/acpi: allow non-optimus setups to load vbios from acpi

commit a3d0b1218d351c6e6f3cea36abe22236a08cb246 upstream.

There appear to be a crop of new hardware where the vbios is not
available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
The data read from PCIROM almost invariably contains invalid
instructions (still has the x86 opcodes), which makes this a low-risk
way to try to obtain a valid vbios image.

Signed-off-by: Ilia Mirkin <>
Signed-off-by: Ben Skeggs <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agomedia-device: fix infoleak in ioctl media_enum_entities()
Salva Peiró [Wed, 30 Apr 2014 17:48:02 +0000 (19:48 +0200)]
media-device: fix infoleak in ioctl media_enum_entities()

commit e6a623460e5fc960ac3ee9f946d3106233fd28d8 upstream.

This fixes CVE-2014-1739.

Signed-off-by: Salva Peiró <>
Acked-by: Laurent Pinchart <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
7 years agortl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()
Ben Hutchings [Sat, 26 Apr 2014 20:59:04 +0000 (21:59 +0100)]
rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()

commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream.

Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Signed-off-by: Ben Hutchings <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: adjust context]

7 years agortlwifi: rtl8192cu: Fix too long disable of IRQs
Larry Finger [Tue, 4 Mar 2014 22:53:50 +0000 (16:53 -0600)]
rtlwifi: rtl8192cu: Fix too long disable of IRQs

commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream.

In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi:
rtl8192ce: Fix too long disable of IRQs", Olivier Langlois
<> fixed a problem caused by an extra long disabling
of interrupts. This patch makes the same fix for rtl8192cu.

Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agotimer: Prevent overflow in apply_slack
Jiri Bohac [Fri, 18 Apr 2014 15:23:11 +0000 (17:23 +0200)]
timer: Prevent overflow in apply_slack

commit 98a01e779f3c66b0b11cd7e64d531c0e41c95762 upstream.

On architectures with sizeof(int) < sizeof (long), the
computation of mask inside apply_slack() can be undefined if the
computed bit is > 32.

E.g. with: expires = 0xffffe6f5 and slack = 25, we get:

expires_limit = 0x20000000e
bit = 33
mask = (1 << 33) - 1  /* undefined */

On x86, mask becomes 1 and and the slack is not applied properly.
On s390, mask is -1, expires is set to 0 and the timer fires immediately.

Use 1UL << bit to solve that issue.

Suggested-by: Deborah Townsend <>
Signed-off-by: Jiri Bohac <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agohrtimer: Prevent remote enqueue of leftmost timers
Leon Ma [Wed, 30 Apr 2014 08:43:10 +0000 (16:43 +0800)]
hrtimer: Prevent remote enqueue of leftmost timers

commit 012a45e3f4af68e86d85cce060c6c2fed56498b2 upstream.

If a cpu is idle and starts an hrtimer which is not pinned on that
same cpu, the nohz code might target the timer to a different cpu.

In the case that we switch the cpu base of the timer we already have a
sanity check in place, which determines whether the timer is earlier
than the current leftmost timer on the target cpu. In that case we
enqueue the timer on the current cpu because we cannot reprogram the
clock event device on the target.

If the timers base is already the target CPU we do not have this
sanity check in place so we enqueue the timer as the leftmost timer in
the target cpus rb tree, but we cannot reprogram the clock event
device on the target cpu. So the timer expires late and subsequently
prevents the reprogramming of the target cpu clock event device until
the previously programmed event fires or a timer with an earlier
expiry time gets enqueued on the target cpu itself.

Add the same target check as we have for the switch base case and
start the timer on the current cpu if it would become the leftmost
timer on the target.

[ tglx: Rewrote subject and changelog ]

Signed-off-by: Leon Ma <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agohrtimer: Prevent all reprogramming if hang detected
Stuart Hayes [Tue, 29 Apr 2014 22:55:02 +0000 (17:55 -0500)]
hrtimer: Prevent all reprogramming if hang detected

commit 6c6c0d5a1c949d2e084706f9e5fb1fccc175b265 upstream.

If the last hrtimer interrupt detected a hang it sets hang_detected=1
and programs the clock event device with a delay to let the system
make progress.

If hang_detected == 1, we prevent reprogramming of the clock event
device in hrtimer_reprogram() but not in hrtimer_force_reprogram().

This can lead to the following situation:

   hang_detected = 1;
   program ce device to Xms from now (hang delay)

We have two timers pending:
   T1 expires 50ms from now
   T2 expires 5s from now

Now T1 gets canceled, which causes hrtimer_force_reprogram() to be
invoked, which in turn programs the clock event device to T2 (5
seconds from now).

Any hrtimer_start after that will not reprogram the hardware due to
hang_detected still being set. So we effectivly block all timers until
the T2 event fires and cleans up the hang situation.

Add a check for hang_detected to hrtimer_force_reprogram() which
prevents the reprogramming of the hang delay in the hardware
timer. The subsequent hrtimer_interrupt will resolve all outstanding

[ tglx: Rewrote subject and changelog and fixed up the comment in
   hrtimer_force_reprogram() ]

Signed-off-by: Stuart Hayes <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agompt2sas: Don't disable device twice at suspend.
Tyler Stachecki [Fri, 25 Apr 2014 20:41:04 +0000 (16:41 -0400)]
mpt2sas: Don't disable device twice at suspend.

commit af61e27c3f77c7623b5335590ae24b6a5c323e22 upstream.

On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which
in turn calls pci_disable_device if the device is enabled prior to
suspending. However, _scsih_suspend also calls pci_disable_device

Thus, in the event that the device is enabled prior to suspending,
pci_disable_device will be called twice. This patch removes the
duplicate call to pci_disable_device in _scsi_suspend as it is both
unnecessary and results in a kernel oops.

Signed-off-by: Tyler Stachecki <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
7 years agoftrace/module: Hardcode ftrace_module_init() call into load_module()
Steven Rostedt (Red Hat) [Thu, 24 Apr 2014 14:40:12 +0000 (10:40 -0400)]
ftrace/module: Hardcode ftrace_module_init() call into load_module()

commit a949ae560a511fe4e3adf48fa44fefded93e5c2b upstream.

A race exists between module loading and enabling of function tracer.

----- -----
   module->state = MODULE_STATE_COMING


[ here all module text is set to RO,
  including the module that is
  loading!! ]


     [ tries to modify code, but it's RO, and fails!
       ftrace_bug() is called]

When this race happens, ftrace_bug() will produces a nasty warning and
all of the function tracing features will be disabled until reboot.

The simple solution is to treate module load the same way the core
kernel is treated at boot. To hardcode the ftrace function modification
of converting calls to mcount into nops. This is done in init/main.c
there's no reason it could not be done in load_module(). This gives
a better control of the changes and doesn't tie the state of the
module to its notifiers as much. Ftrace is special, it needs to be
treated as such.

The reason this would work, is that the ftrace_module_init() would be
called while the module is in MODULE_STATE_UNFORMED, which is ignored
by the set_all_module_text_ro() call.

Reported-by: Takao Indoh <>
Acked-by: Rusty Russell <>
Signed-off-by: Steven Rostedt <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoKVM: async_pf: mm->mm_users can not pin apf->mm
Oleg Nesterov [Mon, 21 Apr 2014 13:26:01 +0000 (15:26 +0200)]
KVM: async_pf: mm->mm_users can not pin apf->mm

commit 41c22f626254b9dc0376928cae009e73d1b6a49a upstream.

get_user_pages(mm) is simply wrong if mm->mm_users == 0 and exit_mmap/etc
was already called (or is in progress), mm->mm_count can only pin mm->pgd
and mm_struct itself.

Change kvm_setup_async_pf/async_pf_execute to inc/dec mm->mm_users.

kvm_create_vm/kvm_destroy_vm play with ->mm_count too but this case looks
fine at first glance, it seems that this ->mm is only used to verify that
current->mm == kvm->mm.

Signed-off-by: Oleg Nesterov <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agokvm: remove .done from struct kvm_async_pf
Radim Krčmář [Wed, 4 Sep 2013 20:32:24 +0000 (22:32 +0200)]
kvm: remove .done from struct kvm_async_pf

commit 98fda169290b3b28c0f2db2b8f02290c13da50ef upstream.

'.done' is used to mark the completion of 'async_pf_execute()', but
'cancel_work_sync()' returns true when the work was canceled, so we
use it instead.

Signed-off-by: Radim Krčmář <>
Reviewed-by: Paolo Bonzini <>
Reviewed-by: Gleb Natapov <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agokvm: free resources after canceling async_pf
Radim Krčmář [Wed, 4 Sep 2013 20:32:23 +0000 (22:32 +0200)]
kvm: free resources after canceling async_pf

commit 28b441e24088081c1e213139d1303b451a34a4f4 upstream.

When we cancel 'async_pf_execute()', we should behave as if the work was
never scheduled in 'kvm_setup_async_pf()'.
Fixes a bug when we can't unload module because the vm wasn't destroyed.

Signed-off-by: Radim Krčmář <>
Reviewed-by: Paolo Bonzini <>
Reviewed-by: Gleb Natapov <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agocrypto: caam - add allocation failure handling in SPRINTFCAT macro
Horia Geanta [Fri, 18 Apr 2014 10:01:42 +0000 (13:01 +0300)]
crypto: caam - add allocation failure handling in SPRINTFCAT macro

commit 27c5fb7a84242b66bf1e0b2fe6bf40d19bcc5c04 upstream.

GFP_ATOMIC memory allocation could fail.
In this case, avoid NULL pointer dereference and notify user.

Cc: Kim Phillips <>
Signed-off-by: Horia Geanta <>
Signed-off-by: Herbert Xu <>
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: Add support for Lite-on [04ca:3007]
Mohammed Habibulla [Thu, 17 Apr 2014 18:37:13 +0000 (11:37 -0700)]
Bluetooth: Add support for Lite-on [04ca:3007]

commit 1fb4e09a7e780b915dbd172592ae7e2a4c071065 upstream.

Add support for the AR9462 chip

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=04ca ProdID=3007 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Signed-off-by: Mohammed Habibulla <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: Fix redundant encryption request for reauthentication
Johan Hedberg [Fri, 11 Apr 2014 19:02:32 +0000 (12:02 -0700)]
Bluetooth: Fix redundant encryption request for reauthentication

commit 09da1f3463eb81d59685df723b1c5950b7570340 upstream.

When we're performing reauthentication (in order to elevate the
security level from an unauthenticated key to an authenticated one) we
do not need to issue any encryption command once authentication
completes. Since the trigger for the encryption HCI command is the
ENCRYPT_PEND flag this flag should not be set in this scenario.
Instead, the REAUTH_PEND flag takes care of all necessary steps for

Signed-off-by: Johan Hedberg <>
Signed-off-by: Marcel Holtmann <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/conn->flags/conn->pend/]
Signed-off-by: Ben Hutchings <>
7 years agodrm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2
Thomas Hellstrom [Tue, 15 Apr 2014 16:25:48 +0000 (18:25 +0200)]
drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2

commit cbd75e97a525e3819c02dc18bc2d67aa544c9e45 upstream.

We already check that the buffer object we're accessing is registered with
the file. Now also make sure that we can't DMA across buffer object boundaries.

v2: Code commenting update.

Signed-off-by: Thomas Hellstrom <>
Reviewed-by: Jakob Bornecrantz <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoInput: synaptics - add min/max quirk for ThinkPad Edge E431
Hans de Goede [Wed, 23 Apr 2014 20:02:35 +0000 (13:02 -0700)]
Input: synaptics - add min/max quirk for ThinkPad Edge E431

commit 27a38856a948c3e8de30dc71647ff9e1778c99fc upstream.

Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
7 years agort2x00: fix beaconing on USB
Stanislaw Gruszka [Thu, 17 Apr 2014 09:08:47 +0000 (11:08 +0200)]
rt2x00: fix beaconing on USB

commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream.

When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.

Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>