7 years agoalarmtimer: Fix bug where relative alarm timers were treated as absolute
John Stultz [Mon, 7 Jul 2014 21:06:11 +0000 (14:06 -0700)]
alarmtimer: Fix bug where relative alarm timers were treated as absolute

commit 16927776ae757d0d132bdbfabbfe2c498342bd59 upstream.

Sharvil noticed with the posix timer_settime interface, using the
tried to specify a relative time timer, it would incorrectly be
treated as absolute regardless of the state of the flags argument.

This patch corrects this, properly checking the absolute/relative flag,
as well as adds further error checking that no invalid flag bits are set.

Reported-by: Sharvil Nanavati <>
Signed-off-by: John Stultz <>
Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Prarit Bhargava <>
Cc: Sharvil Nanavati <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (emc2103) Clamp limits instead of bailing out
Guenter Roeck [Sun, 6 Jul 2014 18:39:24 +0000 (11:39 -0700)]
hwmon: (emc2103) Clamp limits instead of bailing out

commit f6c2dd20108c35e30e2c1f3c6142d189451a626b upstream.

It is customary to clamp limits instead of bailing out with an error
if a configured limit is out of the range supported by the driver.
This simplifies limit configuration, since the user will not typically
know chip and/or driver specific limits.

Reviewed-by: Jean Delvare <>
Signed-off-by: Guenter Roeck <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agofuse: handle large user and group ID
Miklos Szeredi [Mon, 7 Jul 2014 13:28:51 +0000 (15:28 +0200)]
fuse: handle large user and group ID

commit 233a01fa9c4c7c41238537e8db8434667ff28a2f upstream.

If the number in "user_id=N" or "group_id=N" mount options was larger than
INT_MAX then fuse returned EINVAL.

Fix this to handle all valid uid/gid values.

Signed-off-by: Miklos Szeredi <>
[bwh: Backported to 3.2: no user namespace conversion]
Signed-off-by: Ben Hutchings <>
7 years agofuse: timeout comparison fix
Miklos Szeredi [Mon, 7 Jul 2014 13:28:50 +0000 (15:28 +0200)]
fuse: timeout comparison fix

commit 126b9d4365b110c157bc4cbc32540dfa66c9c85a upstream.

As suggested by, use time_before64() instead of direct
comparison of jiffies64 values.

Signed-off-by: Miklos Szeredi <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (adm1031) Fix writes to limit registers
Guenter Roeck [Thu, 3 Jul 2014 20:44:23 +0000 (13:44 -0700)]
hwmon: (adm1031) Fix writes to limit registers

commit 145e74a4e5022225adb84f4e5d4fff7938475c35 upstream.

Upper limit for write operations to temperature limit registers
was clamped to a fractional value. However, limit registers do
not support fractional values. As a result, upper limits of 127.5
degrees C or higher resulted in a rounded limit of 128 degrees C.
Since limit registers are signed, this was stored as -128 degrees C.
Clamp limits to (-55, +127) degrees C to solve the problem.

Value on writes to auto_temp[12]_min and auto_temp[12]_max were not
clamped at all, but masked. As a result, out-of-range writes resulted
in a more or less arbitrary limit. Clamp those attributes to (0, 127)
degrees C for more predictable results.

Cc: Axel Lin <>
Reviewed-by: Jean Delvare <>
Signed-off-by: Guenter Roeck <>
[bwh: Backported to 3.2:
 - Adjust context
 - Driver was using SENSORS_LIMIT(), which we can replace with clamp_val()]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / battery: Retry to get battery information if failed during probing
Lan Tianyu [Mon, 7 Jul 2014 07:47:12 +0000 (15:47 +0800)]
ACPI / battery: Retry to get battery information if failed during probing

commit 75646e758a0ecbed5024454507d5be5b9ea9dcbf upstream.

Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.

Reported-and-tested-by: naszar <>
Signed-off-by: Lan Tianyu <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: acpi_battery_update() doesn't take a second parameter]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Fix race condition in ec_transaction_completed()
Lv Zheng [Sun, 15 Jun 2014 00:42:07 +0000 (08:42 +0800)]
ACPI / EC: Fix race condition in ec_transaction_completed()

commit c0d653412fc8450370167a3268b78fc772ff9c87 upstream.

There is a race condition in ec_transaction_completed().

When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec->curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, the IBF=0 waiter race need
not be handled any more. It's now safe to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.

The ec_transaction_completed() is now only invoked by the ec_poll() where
the ec->curr is ensured to be different from NULL.

After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a
QR_SC command.

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Remove duplicated ec_wait_ibf0() waiter
Lv Zheng [Sun, 15 Jun 2014 00:41:48 +0000 (08:41 +0800)]
ACPI / EC: Remove duplicated ec_wait_ibf0() waiter

commit 9b80f0f73ae1583c22325ede341c74195847618c upstream.

After we've added the first command byte write into advance_transaction(),
the IBF=0 waiter is duplicated with the command completion waiter
implemented in the ec_poll() because:
   If IBF=1 blocked the first command byte write invoked in the task
   context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
   out and retried again in the task context.

Remove this seperate and duplicate IBF=0 waiter.  By doing so we can
reduce the overall number of times to access the EC_SC(R) status

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Add asynchronous command byte write support
Lv Zheng [Sun, 15 Jun 2014 00:41:35 +0000 (08:41 +0800)]
ACPI / EC: Add asynchronous command byte write support

commit f92fca0060fc4dc9227342d0072d75df98c1e5a5 upstream.

Move the first command byte write into advance_transaction() so that all
EC register accesses that can affect the command processing state machine
can happen in this asynchronous state machine advancement function.

The advance_transaction() function then can be a complete implementation
of an asyncrhonous transaction for a single command so that:
 1. The first command byte can be written in the interrupt context;
 2. The command completion waiter can also be used to wait the first command
    byte's timeout;
 3. In BURST mode, the follow-up command bytes can be written in the
    interrupt context directly, so that it doesn't need to return to the
    task context. Returning to the task context reduces the throughput of
    the BURST mode and in the worst cases where the system workload is very
    high, this leads to the hardware driven automatic BURST mode exit.

In order not to increase memory consumption, convert 'done' into 'flags'
to contain multiple indications:
 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition,
    indicating the completion of the command transaction.
 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first
    command byte. A new command can utilize this flag to compete for the
    right of accessing the underlying hardware. There is a follow-up bug
    fix that has utilized this new flag.

The 2 flags are important because it also reflects a key concept of IO
programs' design used in the system softwares. Normally an IO program
running in the kernel should first be implemented in the asynchronous way.
And the 2 flags are the most common way to implement its synchronous
operations on top of the asynchronous operations:
1. POLL: This flag can be used to block until the asynchronous operations
         can happen.
2. COMPLETE: This flag can be used to block until the asynchronous
             operations have completed.
By constructing code cleanly in this way, many difficult problems can be
solved smoothly.

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2:
 - Adjust context
 - s/ec->lock/ec->curr_lock/]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Don't count a SCI interrupt as a false one
Feng Tang [Mon, 22 Oct 2012 23:30:12 +0000 (01:30 +0200)]
ACPI / EC: Don't count a SCI interrupt as a false one

commit a3cd8d2789c2e265e09377f260e7d2ac9cec81bb upstream.

Currently when advance_transaction() is called in EC interrupt handler,
if there is nothing driver can do with the interrupt, it will be taken
as a false one.

But this is not always true, as there may be a SCI EC interrupt fired
during normal read/write operation, which should not be counted as a
false one. This patch fixes the problem.

Signed-off-by: Feng Tang <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Avoid race condition related to advance_transaction()
Lv Zheng [Sun, 15 Jun 2014 00:41:17 +0000 (08:41 +0800)]
ACPI / EC: Avoid race condition related to advance_transaction()

commit 66b42b78bc1e816f92b662e8888c89195e4199e1 upstream.

The advance_transaction() will be invoked from the IRQ context GPE handler
and the task context ec_poll(). The handling of this function is locked so
that the EC state machine are ensured to be advanced sequentially.

But there is a problem. Before invoking advance_transaction(), EC_SC(R) is
read. Then for advance_transaction(), there could be race condition around
the lock from both contexts. The first one reading the register could fail
this race and when it passes the stale register value to the state machine
advancement code, the hardware condition is totally different from when
the register is read. And the hardware accesses determined from the wrong
hardware status can break the EC state machine. And there could be cases
that the functionalities of the platform firmware are seriously affected.
For example:
 1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may
    be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the
    hardware will either refuse to respond a next EC_SC(W) write of the next
    command or discard the current WR_EC command when it receives a EC_SC(W)
    write of the next command.
 2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the
    EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write.
    The next EC_DATA(R) could never be responded by the hardware. This is
    the root cause of the reported issue.

Fix this issue by moving the EC_SC(R) access into the lock so that we can
ensure that the state machine is advanced consistently.

Reported-and-tested-by: Gareth Williams <>
Reported-and-tested-by: Hans de Goede <>
Reported-by: Barton Xu <>
Tested-by: Steffen Weber <>
Tested-by: Arthur Chen <>
Signed-off-by: Lv Zheng <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use PREFIX in log message]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Ensure lock is acquired before accessing ec struct members
Puneet Kumar [Fri, 15 Nov 2013 19:41:29 +0000 (11:41 -0800)]
ACPI / EC: Ensure lock is acquired before accessing ec struct members

commit 36b15875a7819a2ec4cb5748ff7096ad7bd86cbb upstream.

A bug was introduced by commit b76b51ba0cef ('ACPI / EC: Add more debug
info and trivial code cleanup') that erroneously caused the struct member
to be accessed before acquiring the required lock.  This change fixes
it by ensuring the lock acquisition is done first.

Found by Aaron Durbin <>

Fixes: b76b51ba0cef ('ACPI / EC: Add more debug info and trivial code cleanup')
Signed-off-by: Puneet Kumar <>
Reviewed-by: Aaron Durbin <>
[olof: Commit message reworded a bit]
Signed-off-by: Olof Johansson <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoACPI / EC: Add more debug info and trivial code cleanup
Feng Tang [Mon, 22 Oct 2012 23:29:38 +0000 (01:29 +0200)]
ACPI / EC: Add more debug info and trivial code cleanup

commit b76b51ba0cef13980813373a548a12206e3cd3c9 upstream.

Add more debug info for EC transaction debugging, like the interrupt
status register value, the detail info of a EC transaction.

Signed-off-by: Feng Tang <>
Signed-off-by: Rafael J. Wysocki <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agousb: option: Add ID for Telewell TW-LTE 4G v2
Bernd Wachter [Wed, 2 Jul 2014 09:36:48 +0000 (12:36 +0300)]
usb: option: Add ID for Telewell TW-LTE 4G v2

commit 3d28bd840b2d3981cd28caf5fe1df38f1344dd60 upstream.

Add ID of the Telewell 4G v2 hardware to option driver to get legacy
serial interface working

Signed-off-by: Bernd Wachter <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: cp210x: add support for Corsair usb dongle
Andras Kovacs [Fri, 27 Jun 2014 12:50:11 +0000 (14:50 +0200)]
USB: cp210x: add support for Corsair usb dongle

commit b9326057a3d8447f5d2e74a7b521ccf21add2ec0 upstream.

Corsair USB Dongles are shipped with Corsair AXi series PSUs.
These are cp210x serial usb devices, so make driver detect these.
I have a program, that can get information from these PSUs.

Tested with 2 different dongles shipped with Corsair AX860i and
AX1200i units.

Signed-off-by: Andras Kovacs <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agoext4: disable synchronous transaction batching if max_batch_time==0
Eric Sandeen [Sat, 5 Jul 2014 23:18:22 +0000 (19:18 -0400)]
ext4: disable synchronous transaction batching if max_batch_time==0

commit 5dd214248f94d430d70e9230bda72f2654ac88a8 upstream.

The mount manpage says of the max_batch_time option,

This optimization can be turned off entirely
by setting max_batch_time to 0.

But the code doesn't do that.  So fix the code to do

Signed-off-by: Eric Sandeen <>
Signed-off-by: Theodore Ts'o <>
[bwh: Backported to 3.2: option parsing looks different]
Signed-off-by: Ben Hutchings <>
7 years agoext4: clarify error count warning messages
Theodore Ts'o [Sat, 5 Jul 2014 22:40:52 +0000 (18:40 -0400)]
ext4: clarify error count warning messages

commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream.

Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.

Signed-off-by: Pavel Machek <>
Signed-off-by: Theodore Ts'o <>
Reviewed-by: Andreas Dilger <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div
Axel Lin [Wed, 2 Jul 2014 00:29:55 +0000 (08:29 +0800)]
hwmon: (adm1029) Ensure the fan_div cache is updated in set_fan_div

commit 1035a9e3e9c76b64a860a774f5b867d28d34acc2 upstream.

Writing to fanX_div does not clear the cache. As a result, reading
from fanX_div may return the old value for up to two seconds
after writing a new value.

This patch ensures the fan_div cache is updated in set_fan_div().

Reported-by: Guenter Roeck <>
Signed-off-by: Axel Lin <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
7 years agohwmon: (amc6821) Fix permissions for temp2_input
Axel Lin [Tue, 1 Jul 2014 23:44:44 +0000 (07:44 +0800)]
hwmon: (amc6821) Fix permissions for temp2_input

commit df86754b746e9a0ff6f863f690b1c01d408e3cdc upstream.

temp2_input should not be writable, fix it.

Reported-by: Guenter Roeck <>
Signed-off-by: Axel Lin <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Ben Hutchings <>
7 years agodrm/vmwgfx: Fix incorrect write to read-only register v2:
Thomas Hellstrom [Wed, 2 Jul 2014 13:47:04 +0000 (15:47 +0200)]
drm/vmwgfx: Fix incorrect write to read-only register v2:

commit 4e578080ed3262ed2c3985868539bc66218d25c0 upstream.

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: Christopher Friedt <>
Tested-by: Christopher Friedt <>
Signed-off-by: Thomas Hellstrom <>
Reviewed-by: Jakob Bornecrantz <>
Signed-off-by: Ben Hutchings <>
7 years agoiwlwifi: dvm: don't enable CTS to self
Emmanuel Grumbach [Wed, 25 Jun 2014 06:12:30 +0000 (09:12 +0300)]
iwlwifi: dvm: don't enable CTS to self

commit 43d826ca5979927131685cc2092c7ce862cb91cd upstream.

We should always prefer to use full RTS protection. Using
CTS to self gives a meaningless improvement, but this flow
is much harder for the firmware which is likely to have
issues with it.

Signed-off-by: Emmanuel Grumbach <>
[bwh: Backported to 3.2:
 - Adjust filename
 - Condition for RXON_FLG_SELF_CTS_EN in iwlagn_commit_rxon() was different]
Signed-off-by: Ben Hutchings <>
7 years agoxen/manage: fix potential deadlock when resuming the console
David Vrabel [Wed, 2 Jul 2014 16:25:23 +0000 (17:25 +0100)]
xen/manage: fix potential deadlock when resuming the console

commit 1b6478231c6f5f844185acb32045cf195028cfce upstream.

Calling xen_console_resume() in xen_suspend() causes a warning because
it locks irq_mapping_update_lock (a mutex) and this may sleep.  If a
userspace process is using the evtchn device then this mutex may be
locked at the point of the stop_machine() call and
xen_console_resume() would then deadlock.

Resuming the console after stop_machine() returns avoids this

Signed-off-by: David Vrabel <>
Reviewed-by: Boris Ostrovsky <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agomd: flush writes before starting a recovery.
NeilBrown [Wed, 2 Jul 2014 02:04:14 +0000 (12:04 +1000)]
md: flush writes before starting a recovery.

commit 133d4527eab8d199a62eee6bd433f0776842df2e upstream.

When we write to a degraded array which has a bitmap, we
make sure the relevant bit in the bitmap remains set when
the write completes (so a 're-add' can quickly rebuilt a
temporarily-missing device).

If, immediately after such a write starts, we incorporate a spare,
commence recovery, and skip over the region where the write is
happening (because the 'needs recovery' flag isn't set yet),
then that write will not get to the new device.

Once the recovery finishes the new device will be trusted, but will
have incorrect data, leading to possible corruption.

We cannot set the 'needs recovery' flag when we start the write as we
do not know easily if the write will be "degraded" or not.  That
depends on details of the particular raid level and particular write

This patch fixes a corruption issue of long standing and so it
suitable for any -stable kernel.  It applied correctly to 3.0 at
least and will minor editing to earlier kernels.

Reported-by: Bill <>
Tested-by: Bill <>
Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
7 years agoperf/x86/intel: ignore CondChgd bit to avoid false NMI handling
HATAYAMA Daisuke [Wed, 25 Jun 2014 01:09:07 +0000 (10:09 +0900)]
perf/x86/intel: ignore CondChgd bit to avoid false NMI handling

commit b292d7a10487aee6e74b1c18b8d95b92f40d4a4f upstream.

Currently, any NMI is falsely handled by a NMI handler of NMI watchdog
if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set.

For example, we use external NMI to make system panic to get crash
dump, but in this case, the external NMI is falsely handled do to the

This commit deals with the issue simply by ignoring CondChgd bit.

Here is explanation in detail.

On x86 NMI watchdog uses performance monitoring feature to
periodically signal NMI each time performance counter gets overflowed.

intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI
handler of NMI watchdog, perf_event_nmi_handler(). It identifies an
owner of a given NMI by looking at overflow status bits in
MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it
handles the given NMI as its own NMI.

The problem is that the intel_pmu_handle_irq() doesn't distinguish
CondChgd bit from other bits. Unlike the other status bits, CondChgd
bit doesn't represent overflow status for performance counters. Thus,
CondChgd bit cannot be thought of as a mark indicating a given NMI is
NMI watchdog's.

As a result, if CondChgd bit is set, any NMI is falsely handled by the
NMI handler of NMI watchdog. Also, if type of the falsely handled NMI
is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding
action is never performed until CondChgd bit is cleared.

I noticed this behavior on systems with Ivy Bridge processors: Intel
Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems,
CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set
in the beginning at boot. Then the CondChgd bit is immediately cleared
by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain

On the other hand, on older processors such as Nehalem, Xeon E7540,
CondChgd bit is not set in the beginning at boot.

I'm not sure about exact behavior of CondChgd bit, in particular when
this bit is set. Although I read Intel System Programmer's Manual to
figure out that, the descriptions I found are:

  In 18.9.1:

  "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to
   indicate changes to the state of performancmonitoring hardware"

  In Table 35-2 IA-32 Architectural MSRs

  63 CondChg: status bits of this register has changed.

These are different from the bahviour I see on the actual system as I
explained above.

At least, I think ignoring CondChgd bit should be enough for NMI
watchdog perspective.

Signed-off-by: HATAYAMA Daisuke <>
Acked-by: Don Zickus <>
Signed-off-by: Peter Zijlstra <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Linus Torvalds <>
Signed-off-by: Ingo Molnar <>
Signed-off-by: Ben Hutchings <>
7 years agousb-storage/SCSI: Add broken_fua blacklist flag
Alan Stern [Mon, 30 Jun 2014 15:04:21 +0000 (11:04 -0400)]
usb-storage/SCSI: Add broken_fua blacklist flag

commit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream.

Some buggy JMicron USB-ATA bridges don't know how to translate the FUA
bit in READs or WRITEs.  This patch adds an entry in unusual_devs.h
and a blacklist flag to tell the sd driver not to use FUA.

Signed-off-by: Alan Stern <>
Reported-by: Michael Büsch <>
Tested-by: Michael Büsch <>
Acked-by: James Bottomley <>
CC: Matthew Dharm <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use sd_printk() not sd_first_printk()]
Signed-off-by: Ben Hutchings <>
7 years agotools: ffs-test: fix header values endianess
Michal Nazarewicz [Fri, 13 Jun 2014 13:38:05 +0000 (15:38 +0200)]
tools: ffs-test: fix header values endianess

commit f35f71244da6e51db4e1f2c7e318581f498ececf upstream.

It appears that no one ever run ffs-test on a big-endian machine,
since it used cpu-endianess for fs_count and hs_count fields which
should be in little-endian format.  Fix by wrapping the numbers in

Signed-off-by: Michal Nazarewicz <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
7 years agonfsd: fix rare symlink decoding bug
J. Bruce Fields [Thu, 19 Jun 2014 20:44:48 +0000 (16:44 -0400)]
nfsd: fix rare symlink decoding bug

commit 76f47128f9b33af1e96819746550d789054c9664 upstream.

An NFS operation that creates a new symlink includes the symlink data,
which is xdr-encoded as a length followed by the data plus 0 to 3 bytes
of zero-padding as required to reach a 4-byte boundary.

The vfs, on the other hand, wants null-terminated data.

The simple way to handle this would be by copying the data into a newly
allocated buffer with space for the final null.

The current nfsd_symlink code tries to be more clever by skipping that
step in the (likely) case where the byte following the string is already

But that assumes that the byte following the string is ours to look at.
In fact, it might be the first byte of a page that we can't read, or of
some object that another task might modify.

Worse, the NFSv4 code tries to fix the problem by actually writing to
that byte.

In the NFSv2/v3 cases this actually appears to be safe:

- nfs3svc_decode_symlinkargs explicitly null-terminates the data
  (after first checking its length and copying it to a new
- NFSv2 limits symlinks to 1k.  The buffer holding the rpc
  request is always at least a page, and the link data (and
  previous fields) have maximum lengths that prevent the request
  from reaching the end of a page.

In the NFSv4 case the CREATE op is potentially just one part of a long
compound so can end up on the end of a page if you're unlucky.

The minimal fix here is to copy and null-terminate in the NFSv4 case.
The nfsd_symlink() interface here seems too fragile, though.  It should
really either do the copy itself every time or just require a
null-terminated string.

Reported-by: Jeff Layton <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
7 years agomwifiex: fix Tx timeout issue
Amitkumar Karwar [Fri, 20 Jun 2014 18:45:25 +0000 (11:45 -0700)]
mwifiex: fix Tx timeout issue

commit d76744a93246eccdca1106037e8ee29debf48277 upstream.

It is observed that sometimes Tx packet is downloaded without
adding driver's txpd header. This results in firmware parsing
garbage data as packet length. Sometimes firmware is unable
to read the packet if length comes out as invalid. This stops
further traffic and timeout occurs.

The root cause is uninitialized fields in tx_info(skb->cb) of
packet used to get garbage values. In this case if
MWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd
header was skipped. This patch makes sure that tx_info is
correctly initialized to fix the problem.

Reported-by: Andrew Wiley <>
Reported-by: Linus Gasser <>
Reported-by: Michael Hirsch <>
Tested-by: Xinming Hu <>
Signed-off-by: Amitkumar Karwar <>
Signed-off-by: Maithili Hinge <>
Signed-off-by: Avinash Patil <>
Signed-off-by: Bing Zhao <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agocpuset,mempolicy: fix sleeping function called from invalid context
Gu Zheng [Wed, 25 Jun 2014 01:57:18 +0000 (09:57 +0800)]
cpuset,mempolicy: fix sleeping function called from invalid context

commit 391acf970d21219a2a5446282d3b20eace0c0d7a upstream.

When runing with the kernel(3.15-rc7+), the follow bug occurs:
[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python
[ 9969.441175] INFO: lockdep is turned off.
[ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G       A      3.15.0-rc7+ #85
[ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012
[ 9969.706052]  ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18
[ 9969.795323]  ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c
[ 9969.884710]  ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000
[ 9969.974071] Call Trace:
[ 9970.003403]  [<ffffffff8162f523>] dump_stack+0x4d/0x66
[ 9970.065074]  [<ffffffff8109995a>] __might_sleep+0xfa/0x130
[ 9970.130743]  [<ffffffff81633e6c>] mutex_lock_nested+0x3c/0x4f0
[ 9970.200638]  [<ffffffff811ba5dc>] ? kmem_cache_alloc+0x1bc/0x210
[ 9970.272610]  [<ffffffff81105807>] cpuset_mems_allowed+0x27/0x140
[ 9970.344584]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.409282]  [<ffffffff811b1385>] __mpol_dup+0xe5/0x150
[ 9970.471897]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150
[ 9970.536585]  [<ffffffff81068c86>] ? copy_process.part.23+0x606/0x1d40
[ 9970.613763]  [<ffffffff810bf28d>] ? trace_hardirqs_on+0xd/0x10
[ 9970.683660]  [<ffffffff810ddddf>] ? monotonic_to_bootbased+0x2f/0x50
[ 9970.759795]  [<ffffffff81068cf0>] copy_process.part.23+0x670/0x1d40
[ 9970.834885]  [<ffffffff8106a598>] do_fork+0xd8/0x380
[ 9970.894375]  [<ffffffff81110e4c>] ? __audit_syscall_entry+0x9c/0xf0
[ 9970.969470]  [<ffffffff8106a8c6>] SyS_clone+0x16/0x20
[ 9971.030011]  [<ffffffff81642009>] stub_clone+0x69/0x90
[ 9971.091573]  [<ffffffff81641c29>] ? system_call_fastpath+0x16/0x1b

The cause is that cpuset_mems_allowed() try to take
mutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in
__mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is
under rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock
protection region to protect the access to cpuset only in
current_cpuset_is_being_rebound(). So that we can avoid this bug.

This patch is a temporary solution that just addresses the bug
mentioned above, can not fix the long-standing issue about cpuset.mems
rebinding on fork():

"When the forker's task_struct is duplicated (which includes
 ->mems_allowed) and it races with an update to cpuset_being_rebound
 in update_tasks_nodemask() then the task's mems_allowed doesn't get
 updated. And the child task's mems_allowed can be wrong if the
 cpuset's nodemask changes before the child has been added to the
 cgroup's tasklist."

Signed-off-by: Gu Zheng <>
Acked-by: Li Zefan <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
7 years agoibmvscsi: Add memory barriers for send / receive
Brian King [Fri, 23 May 2014 15:52:11 +0000 (10:52 -0500)]
ibmvscsi: Add memory barriers for send / receive

commit 7114aae02742d6b5c5a0d39a41deb61d415d3717 upstream.

Add a memory barrier prior to sending a new command to the VIOS
to ensure the VIOS does not receive stale data in the command buffer.
Also add a memory barrier when processing the CRQ for completed commands.

Signed-off-by: Brian King <>
Acked-by: Nathan Fontenot <>
Signed-off-by: Christoph Hellwig <>
[bwh: Backported to 3.2: as the iSeries code is still present, these
 functions have different names and live in rpa_vscsi.c.]
Signed-off-by: Ben Hutchings <>
7 years agoibmvscsi: Abort init sequence during error recovery
Brian King [Fri, 23 May 2014 15:52:10 +0000 (10:52 -0500)]
ibmvscsi: Abort init sequence during error recovery

commit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream.

If a CRQ reset is triggered for some reason while in the middle
of performing VSCSI adapter initialization, we don't want to
call the done function for the initialization MAD commands as
this will only result in two threads attempting initialization
at the same time, resulting in failures.

Signed-off-by: Brian King <>
Acked-by: Nathan Fontenot <>
Signed-off-by: Christoph Hellwig <>
Signed-off-by: Ben Hutchings <>
7 years agoxhci: Fix runtime suspended xhci from blocking system suspend.
Wang, Yu [Tue, 24 Jun 2014 14:14:44 +0000 (17:14 +0300)]
xhci: Fix runtime suspended xhci from blocking system suspend.

commit d6236f6d1d885aa19d1cd7317346fe795227a3cc upstream.

The system suspend flow as following:
1, Freeze all user processes and kenrel threads.

2, Try to suspend all devices.

2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.

2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2&usb3 roothub devices.

2.3, Call suspend callbacks of devices.

2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.

2.3.2, Finally, hcd_pci_suspend callback is called.

Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.

The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.

For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.

xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.

This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
"USB: XHCI: resume root hubs when the controller resumes"

Signed-off-by: Wang, Yu <>
Acked-by: Alan Stern <>
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoxhci: clear root port wake on bits if controller isn't wake-up capable
Lu Baolu [Tue, 24 Jun 2014 14:14:43 +0000 (17:14 +0300)]
xhci: clear root port wake on bits if controller isn't wake-up capable

commit ff8cbf250b448aac35589f6075082c3fcad8a8fe upstream.

When xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,
xhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel
platforms may get a spurious wakeup, even if PCI PME# is disabled.

This patch should be back-ported to kernels as old as 2.6.37, that
contains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569
"USB: xHCI: bus power management implementation".

Signed-off-by: Lu Baolu <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoxhci: correct burst count field for isoc transfers on 1.0 xhci hosts
Mathias Nyman [Tue, 24 Jun 2014 14:14:41 +0000 (17:14 +0300)]
xhci: correct burst count field for isoc transfers on 1.0 xhci hosts

commit 3213b151387df0b95f4eada104f68eb1c1409cb3 upstream.

The transfer burst count (TBC) field in xhci 1.0 hosts should be set
to the number of bursts needed to transfer all packets in a isoc TD.
Supported values are 0-2 (1 to 3 bursts per service interval).

Formula for TBC calculation is given in xhci spec section
TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1

This patch should be applied to stable kernels since 3.0 that contain
the commit 5cd43e33b9519143f06f507dd7cbee6b7a621885
"xhci 1.0: Set transfer burst count field."

Suggested-by: ShiChun Ma <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agousb: option: add/modify Olivetti Olicard modems
Bjørn Mork [Fri, 6 Jun 2014 15:25:56 +0000 (17:25 +0200)]
usb: option: add/modify Olivetti Olicard modems

commit b0ebef36e93703e59003ad6a1a20227e47714417 upstream.

Adding a couple of Olivetti modems and blacklisting the net
function on a couple which are already supported.

Reported-by: Lars Melin <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: ftdi_sio: fix null deref at port probe
Johan Hovold [Thu, 5 Jun 2014 14:05:52 +0000 (16:05 +0200)]
USB: ftdi_sio: fix null deref at port probe

commit aea1ae8760314e072bf1b773521e9de5d5dda10d upstream.

Fix NULL-pointer dereference when probing an interface with no

These devices have two bulk endpoints per interface, but this avoids
crashing the kernel if a user forces a non-FTDI device to be probed.

Note that the iterator variable was made unsigned in order to avoid
a maybe-uninitialized compiler warning for ep_desc after the loop.

Fixes: 895f28badce9 ("USB: ftdi_sio: fix hi-speed device packet size

Reported-by: Mike Remski <>
Tested-by: Mike Remski <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Ben Hutchings <>
7 years agousb: gadget: f_fs: fix NULL pointer dereference when there are no strings
Michal Nazarewicz [Tue, 17 Jun 2014 15:47:41 +0000 (17:47 +0200)]
usb: gadget: f_fs: fix NULL pointer dereference when there are no strings

commit f0688c8b81d2ea239c3fb0b848f623b579238d99 upstream.

If the descriptors do not need any strings and user space sends empty
set of strings, the ffs->stringtabs field remains NULL.  Thus
*ffs->stringtabs in functionfs_bind leads to a NULL pointer

The bug was introduced by commit [fd7c9a007f: “use usb_string_ids_n()”].

While at it, remove double initialisation of lang local variable in
that function.

ffs->strings_count does not need to be checked in any way since in
the above scenario it will remain zero and usb_string_ids_n() is
a no-operation when colled with 0 argument.

Signed-off-by: Michal Nazarewicz <>
Signed-off-by: Felipe Balbi <>
Signed-off-by: Ben Hutchings <>
7 years agoKVM: x86: preserve the high 32-bits of the PAT register
Paolo Bonzini [Thu, 19 Jun 2014 09:40:18 +0000 (11:40 +0200)]
KVM: x86: preserve the high 32-bits of the PAT register

commit 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 upstream.

KVM does not really do much with the PAT, so this went unnoticed for a
long time.  It is exposed however if you try to do rdmsr on the PAT

Reported-by: Valentine Sinitsyn <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agoKVM: x86: Increase the number of fixed MTRR regs to 10
Nadav Amit [Wed, 18 Jun 2014 14:21:19 +0000 (17:21 +0300)]
KVM: x86: Increase the number of fixed MTRR regs to 10

commit 682367c494869008eb89ef733f196e99415ae862 upstream.

Recent Intel CPUs have 10 variable range MTRRs. Since operating systems
sometime make assumptions on CPUs while they ignore capability MSRs, it is
better for KVM to be consistent with recent CPUs. Reporting more MTRRs than
actually supported has no functional implications.

Signed-off-by: Nadav Amit <>
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
7 years agoARM: OMAP2+: Fix parser-bug in platform muxing code
David R. Piegdon [Mon, 16 Jun 2014 23:42:51 +0000 (23:42 +0000)]
ARM: OMAP2+: Fix parser-bug in platform muxing code

commit c021f241f4fab2bb4fc4120a38a828a03dd3f970 upstream.

Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.

For example muxing of "dss_data2.dss_data2" on omap32xx will fail
because the prefix "dss_data2" will match the mux-entries "dss_data2" as
well as "dss_data20", with the suffix "dss_data2" matching m0 (for
dss_data2) and m4 (for dss_data20). Thus both are recognized as signal
path candidates:

Relevant muxentries from mux34xx.c:
        _OMAP3_MUXENTRY(DSS_DATA20, 90,
                "dss_data20", NULL, "mcspi3_somi", "dss_data2",
                "gpio_90", NULL, NULL, "safe_mode"),
        _OMAP3_MUXENTRY(DSS_DATA2, 72,
                "dss_data2", NULL, NULL, NULL,
                "gpio_72", NULL, NULL, "safe_mode"),

This will result in a failure to mux the pin at all:

 _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2

Patch should apply to linus' latest master down to rather old linux-2.6

Signed-off-by: David R. Piegdon <>
[ updated description to include full description]
Signed-off-by: Tony Lindgren <>
Signed-off-by: Ben Hutchings <>
7 years agoRevert "net: ip, ipv6: handle gso skbs in forwarding path"
Ben Hutchings [Sat, 12 Jul 2014 20:00:54 +0000 (21:00 +0100)]
Revert "net: ip, ipv6: handle gso skbs in forwarding path"

This reverts commit caa5344994778a2b4725b2d75c74430f76925e4a, which
was commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.  In 3.2,
the transport header length is not calculated in the forwarding path,
so skb_gso_network_seglen() returns an incorrect result.  We also have
problems due to the local_df flag not being set correctly.

Signed-off-by: Ben Hutchings <>
7 years agoRevert "net: ipv4: ip_forward: fix inverted local_df test"
Ben Hutchings [Fri, 11 Jul 2014 19:01:52 +0000 (20:01 +0100)]
Revert "net: ipv4: ip_forward: fix inverted local_df test"

This reverts commit 59d9f389df3cdf72833d5ee17c3fe959b6bdc792, which
was commit ca6c5d4ad216d5942ae544bbf02503041bd802aa upstream.  It is a
valid fix, but depends on sk_buff::local_df being set in all the right
cases, which it wasn't in 3.2.  We need to defer it unless and until
the other fixes are also backported to 3.2.y.

Signed-off-by: Ben Hutchings <>
7 years agoLinux 3.2.61 v3.2.61
Ben Hutchings [Fri, 11 Jul 2014 12:34:01 +0000 (13:34 +0100)]
Linux 3.2.61

7 years agoskbuff: skb_segment: orphan frags before copying
Michael S. Tsirkin [Mon, 10 Mar 2014 17:28:08 +0000 (19:28 +0200)]
skbuff: skb_segment: orphan frags before copying

commit 1fd819ecb90cc9b822cd84d3056ddba315d3340f upstream.

skb_segment copies frags around, so we need
to copy them carefully to avoid accessing
user memory after reporting completion to userspace
through a callback.

skb_segment doesn't normally happen on datapath:
TSO needs to be disabled - so disabling zero copy
in this case does not look like a big deal.

Signed-off-by: Michael S. Tsirkin <>
Acked-by: Herbert Xu <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2.  As skb_segment() only supports page-frags *or* a
 frag list, there is no need for the additional frag_skb pointer or the
 preparatory renaming.]
Signed-off-by: Ben Hutchings <>
7 years agoskbuff: export skb_copy_ubufs
Michael S. Tsirkin [Fri, 20 Jul 2012 09:23:20 +0000 (09:23 +0000)]
skbuff: export skb_copy_ubufs

commit dcc0fb782b3a6e2abfeaaeb45dd88ed09596be0f upstream.

Export skb_copy_ubufs so that modules can orphan frags.

Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoskbuff: add an api to orphan frags
Michael S. Tsirkin [Fri, 20 Jul 2012 09:23:07 +0000 (09:23 +0000)]
skbuff: add an api to orphan frags

commit a353e0ce0fd42d8859260666d1e9b10f2abd4698 upstream.

Many places do
       if ((skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY))
skb_copy_ubufs(skb, gfp_mask);
to copy and invoke frag destructors if necessary.
Add an inline helper for this.

Signed-off-by: Michael S. Tsirkin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agoptrace,x86: force IRET path after a ptrace_stop()
Tejun Heo [Thu, 3 Jul 2014 19:43:15 +0000 (15:43 -0400)]
ptrace,x86: force IRET path after a ptrace_stop()

commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.

The 'sysret' fastpath does not correctly restore even all regular
registers, much less any segment registers or reflags values.  That is
very much part of why it's faster than 'iret'.

Normally that isn't a problem, because the normal ptrace() interface
catches the process using the signal handler infrastructure, which
always returns with an iret.

However, some paths can get caught using ptrace_event() instead of the
signal path, and for those we need to make sure that we aren't going to
return to user space using 'sysret'.  Otherwise the modifications that
may have been done to the register set by the tracer wouldn't
necessarily take effect.

Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
arch_ptrace_stop_needed() which is invoked from ptrace_stop().

Signed-off-by: Tejun Heo <>
Reported-by: Andy Lutomirski <>
Acked-by: Oleg Nesterov <>
Suggested-by: Linus Torvalds <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoDocumentation: Update stable address in Chinese and Japanese translations
Geert Uytterhoeven [Mon, 14 Apr 2014 16:52:14 +0000 (18:52 +0200)]
Documentation: Update stable address in Chinese and Japanese translations

commit 98b0f811aade1b7c6e7806c86aa0befd5919d65f upstream.

The English and Korean translations were updated, the Chinese and Japanese

Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agoARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr
Liu Hua [Thu, 27 Mar 2014 05:56:18 +0000 (06:56 +0100)]
ARM: 8012/1: kdump: Avoid overflow when converting pfn to physaddr

commit 8fad87bca7ac9737e413ba5f1656f1114a8c314d upstream.

When we configure CONFIG_ARM_LPAE=y, pfn << PAGE_SHIFT will
overflow if pfn >= 0x100000 in copy_oldmem_page.
So use __pfn_to_phys for converting.

Signed-off-by: Liu Hua <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
7 years agoiommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap()
David Woodhouse [Mon, 9 Jun 2014 13:09:53 +0000 (14:09 +0100)]
iommu/vt-d: Fix missing IOTLB flush in intel_iommu_unmap()

Part of commit ea8ea460c9ace60bbb5ac6e5521d637d5c15293d upstream.

This missing IOTLB flush was added as a minor, inconsequential bug-fix
in commit ea8ea460c ("iommu/vt-d: Clean up and fix page table clear/free
behaviour") in 3.15. It wasn't originally intended for -stable but a
couple of users have reported issues which turn out to be fixed by
adding the missing flush.

Signed-off-by: David Woodhouse <>
[bwh: Backported to 3.2:
 - Adjust context
 - Use &dmar_domain->iommu_bmp, as it is a single word not an array]
Signed-off-by: Ben Hutchings <>
7 years agomegaraid: Use resource_size_t for PCI resources, not long
Ben Collins [Fri, 13 Sep 2013 16:46:44 +0000 (12:46 -0400)]
megaraid: Use resource_size_t for PCI resources, not long

commit 11f8a7b31f2140b0dc164bb484281235ffbe51d3 upstream.

The assumption that sizeof(long) >= sizeof(resource_size_t) can lead to
truncation of the PCI resource address, meaning this driver didn't work
on 32-bit systems with 64-bit PCI adressing ranges.

Signed-off-by: Ben Collins <>
Acked-by: Sumit Saxena <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoFix spurious request sense in error handling
James Bottomley [Fri, 28 Mar 2014 17:50:17 +0000 (10:50 -0700)]
Fix spurious request sense in error handling

commit d555a2abf3481f81303d835046a5ec2c4fb3ca8e upstream.

We unconditionally execute scsi_eh_get_sense() to make sure all failed
commands that should have sense attached, do.  However, the routine forgets
that some commands, because of the way they fail, will not have any sense code
... we should not bother them with a REQUEST_SENSE command.  Fix this by
testing to see if we actually got a CHECK_CONDITION return and skip asking for
sense if we don't.

Tested-by: Alan Stern <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agotarget: Explicitly clear ramdisk_mcp backend pages
Nicholas Bellinger [Mon, 16 Jun 2014 20:59:52 +0000 (20:59 +0000)]
target: Explicitly clear ramdisk_mcp backend pages

Part of commit 4442dc8a92b8f9ad8ee9e7f8438f4c04c03a22dc upstream.

This patch changes rd_allocate_sgl_table() to explicitly clear
ramdisk_mcp backend memory pages by passing __GFP_ZERO into

This addresses a potential security issue where reading from a
ramdisk_mcp could return sensitive information, and follows what
>= v3.15 does to explicitly clear ramdisk_mcp memory at backend
device initialization time.

Reported-by: Jorge Daniel Sequeira Matias <>
Cc: Jorge Daniel Sequeira Matias <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
7 years agonet/mlx4_core: Preserve pci_dev_data after __mlx4_remove_one()
Wei Yang [Sun, 1 Jun 2014 07:25:41 +0000 (15:25 +0800)]
net/mlx4_core: Preserve pci_dev_data after __mlx4_remove_one()

[ Upstream commit befdf8978accecac2e0739e6b5075afc62db37fe ]

This patch wrap up a helper function __mlx4_remove_one() which does the tear
down function but preserve the drv_data. Functions like
mlx4_pci_err_detected() and mlx4_restart_one() will call this one with out
releasing drvdata.

Signed-off-by: Wei Yang <>
Signed-off-by: Ben Hutchings <>
7 years agomlx4_core: Stash PCI ID driver_data in mlx4_priv structure
Wei Yang [Sun, 1 Jun 2014 07:25:40 +0000 (15:25 +0800)]
mlx4_core: Stash PCI ID driver_data in mlx4_priv structure

[ No upstream commit, this is a cherry picked backport enabler. ]

That way we can check flags later on, when we've finished with the
pci_device_id structure.

This is a backport.

Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
7 years agosctp: Fix sk_ack_backlog wrap-around problem
Xufeng Zhang [Thu, 12 Jun 2014 02:53:36 +0000 (10:53 +0800)]
sctp: Fix sk_ack_backlog wrap-around problem

[ Upstream commit d3217b15a19a4779c39b212358a5c71d725822ee ]

Consider the scenario:
For a TCP-style socket, while processing the COOKIE_ECHO chunk in
sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check,
a new association would be created in sctp_unpack_cookie(), but afterwards,
some processing maybe failed, and sctp_association_free() will be called to
free the previously allocated association, in sctp_association_free(),
sk_ack_backlog value is decremented for this socket, since the initial
value for sk_ack_backlog is 0, after the decrement, it will be 65535,
a wrap-around problem happens, and if we want to establish new associations
afterward in the same socket, ABORT would be triggered since sctp deem the
accept queue as full.
Fix this issue by only decrementing sk_ack_backlog for associations in
the endpoint's list.

Fix-suggested-by: Neil Horman <>
Signed-off-by: Xufeng Zhang <>
Acked-by: Daniel Borkmann <>
Acked-by: Vlad Yasevich <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: fix inet_getid() and ipv6_select_ident() bugs
Eric Dumazet [Thu, 29 May 2014 15:45:14 +0000 (08:45 -0700)]
net: fix inet_getid() and ipv6_select_ident() bugs

[ Upstream commit 39c36094d78c39e038c1e499b2364e13bce36f54 ]

I noticed we were sending wrong IPv4 ID in TCP flows when MTU discovery
is disabled.
Note how GSO/TSO packets do not have monotonically incrementing ID.

06:37:41.575531 IP (id 14227, proto: TCP (6), length: 4396)
06:37:41.575534 IP (id 14272, proto: TCP (6), length: 65212)
06:37:41.575544 IP (id 14312, proto: TCP (6), length: 57972)
06:37:41.575678 IP (id 14317, proto: TCP (6), length: 7292)
06:37:41.575683 IP (id 14361, proto: TCP (6), length: 63764)

It appears I introduced this bug in linux-3.1.

inet_getid() must return the old value of peer->ip_id_count,
not the new one.

Lets revert this part, and remove the prevention of
a null identification field in IPv6 Fragment Extension Header,
which is dubious and not even done properly.

Fixes: 87c48fa3b463 ("ipv6: make fragment identifications less predictable")
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonet: tunnels - enable module autoloading
Tom Gundersen [Thu, 15 May 2014 21:21:30 +0000 (23:21 +0200)]
net: tunnels - enable module autoloading

[ Upstream commit f98f89a0104454f35a62d681683c844f6dbf4043 ]

Enable the module alias hookup to allow tunnel modules to be autoloaded on demand.

This is in line with how most other netdev kinds work, and will allow userspace
to create tunnels without having CAP_SYS_MODULE.

Signed-off-by: Tom Gundersen <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
7 years agonetlink: rate-limit leftover bytes warning and print process name
Michal Schmidt [Mon, 2 Jun 2014 16:25:02 +0000 (18:25 +0200)]
netlink: rate-limit leftover bytes warning and print process name

[ Upstream commit bfc5184b69cf9eeb286137640351c650c27f118a ]

Any process is able to send netlink messages with leftover bytes.
Make the warning rate-limited to prevent too much log spam.

The warning is supposed to help find userspace bugs, so print the
triggering command name to implicate the buggy program.

[v2: Use pr_warn_ratelimited instead of printk_ratelimited.]

Signed-off-by: Michal Schmidt <>
Signed-off-by: David S. Miller <>
[bwh: Add #include of <linux/sched.h> for definition of struct task_struct,
 as in 3.2 it doesn't get included indirectly on all architectures.  Thanks
 to Guenter Roeck for debugging this.]
Signed-off-by: Ben Hutchings <>
7 years agoMIPS: asm: thread_info: Add _TIF_SECCOMP flag
Markos Chandras [Wed, 22 Jan 2014 14:40:00 +0000 (14:40 +0000)]
MIPS: asm: thread_info: Add _TIF_SECCOMP flag

commit 137f7df8cead00688524c82360930845396b8a21 upstream.

Add _TIF_SECCOMP flag to _TIF_WORK_SYSCALL_ENTRY to indicate
that the system call needs to be checked against a seccomp filter.

Signed-off-by: Markos Chandras <>
Reviewed-by: Paul Burton <>
Reviewed-by: James Hogan <>
Signed-off-by: Ralf Baechle <>
[bwh: Backported to 3.2: various other flags are not included in
Signed-off-by: Ben Hutchings <>
7 years agoMIPS: Cleanup flags in syscall flags handlers.
Ralf Baechle [Tue, 28 May 2013 23:02:18 +0000 (01:02 +0200)]
MIPS: Cleanup flags in syscall flags handlers.

commit e7f3b48af7be9f8007a224663a5b91340626fed5 upstream.

This will simplify further modifications.

Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
7 years agoperf: Fix race in removing an event
Peter Zijlstra [Fri, 2 May 2014 14:56:01 +0000 (16:56 +0200)]
perf: Fix race in removing an event

commit 46ce0fe97a6be7532ce6126bb26ce89fed81528c upstream.

When removing a (sibling) event we do:




Now, assuming the event is a sibling, it will be 'unreachable' for
things like ctx_sched_out() because that iterates the
groups->siblings, and we just unhooked the sibling.

So, if during <hole> we get ctx_sched_out(), it will miss the event
and not call event_sched_out() on it, leaving it programmed on the

The subsequent perf_remove_from_context() call will find the ctx is
inactive and only call list_del_event() to remove the event from all
other lists.

Hereafter we can proceed to free the event; while still programmed!

Close this hole by moving perf_group_detach() inside the same
ctx->lock region(s) perf_remove_from_context() has.

The condition on inherited events only in __perf_event_exit_task() is
likely complete crap because non-inherited events are part of groups
too and we're tearing down just the same. But leave that for another

Most-likely-Fixes: e03a9a55b4e ("perf: Change close() semantics for group events")
Reported-by: Vince Weaver <>
Tested-by: Vince Weaver <>
Much-staring-at-traces-by: Vince Weaver <>
Much-staring-at-traces-by: Thomas Gleixner <>
Cc: Arnaldo Carvalho de Melo <>
Cc: Linus Torvalds <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
[bwh: Backported to 3.2: drop change in perf_pmu_migrate_context()]
Signed-off-by: Ben Hutchings <>
7 years agodual scan thread bug fix
James Bottomley [Tue, 21 Jan 2014 15:01:41 +0000 (07:01 -0800)]
dual scan thread bug fix

commit f2495e228fce9f9cec84367547813cbb0d6db15a upstream.

In the highly unusual case where two threads are running concurrently through
the scanning code scanning the same target, we run into the situation where
one may allocate the target while the other is still using it.  In this case,
because the reap checks for STARGET_CREATED and kills the target without
reference counting, the second thread will do the wrong thing on reap.

Fix this by reference counting even creates and doing the STARGET_CREATED
check in the final put.

Tested-by: Sarah Sharp <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
7 years agofix our current target reap infrastructure
James Bottomley [Tue, 21 Jan 2014 15:00:50 +0000 (07:00 -0800)]
fix our current target reap infrastructure

commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59 upstream.

This patch eliminates the reap_ref and replaces it with a proper kref.
On last put of this kref, the target is removed from visibility in
sysfs.  The final call to scsi_target_reap() for the device is done from
__scsi_remove_device() and only if the device was made visible.  This
ensures that the target disappears as soon as the last device is gone
rather than waiting until final release of the device (which is often
too long).

Reviewed-by: Alan Stern <>
Tested-by: Sarah Sharp <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
7 years agoStop accepting SCSI requests before removing a device
Bart Van Assche [Fri, 29 Jun 2012 15:36:07 +0000 (15:36 +0000)]
Stop accepting SCSI requests before removing a device

commit b485462aca7df4e32bcf7efb6f84a69e8b640243 upstream.

Avoid that the code for requeueing SCSI requests triggers a
crash by making sure that that code isn't scheduled anymore
after a device has been removed.

Also, source code inspection of __scsi_remove_device() revealed
a race condition in this function: no new SCSI requests must be
accepted for a SCSI device after device removal started.

Signed-off-by: Bart Van Assche <>
Reviewed-by: Mike Christie <>
Acked-by: Tejun Heo <>
Signed-off-by: James Bottomley <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agotarget: Fix left-over se_lun->lun_sep pointer OOPs
Nicholas Bellinger [Mon, 16 Jun 2014 20:25:54 +0000 (20:25 +0000)]
target: Fix left-over se_lun->lun_sep pointer OOPs

commit 83ff42fcce070801a3aa1cd6a3269d7426271a8d upstream.

This patch fixes a left-over se_lun->lun_sep pointer OOPs when one
of the /sys/kernel/config/target/$FABRIC/$WWPN/$TPGT/lun/$LUN/alua*
attributes is accessed after the $DEVICE symlink has been removed.

To address this bug, go ahead and clear se_lun->lun_sep memory in
core_dev_unexport(), so that the existing checks for show/store
ALUA attributes in target_core_fabric_configfs.c work as expected.

Reported-by: Sebastian Herbszt <>
Tested-by: Sebastian Herbszt <>
Signed-off-by: Nicholas Bellinger <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoMIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region
Markos Chandras [Mon, 23 Jun 2014 08:48:51 +0000 (09:48 +0100)]
MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region

commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.

Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:

CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
Call Trace:
[<8058dba4>] init_msc_irqs+0x104/0x154
[<8058b5bc>] arch_init_irq+0xd8/0x154
[<805897b0>] start_kernel+0x220/0x36c

Kernel panic - not syncing: Attempted to kill the idle task!

This patch fixes the problem

Signed-off-by: Markos Chandras <>
Reviewed-by: James Hogan <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
7 years agorecordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules
Alex Smith [Tue, 17 Jun 2014 09:39:53 +0000 (10:39 +0100)]
recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules

commit 91ad11d7cc6f4472ebf177a6252fbf0fd100d798 upstream.

On MIPS calls to _mcount in modules generate 2 instructions to load
the _mcount address (and therefore 2 relocations). The mcount_loc
table should only reference the first of these, so the second is
filtered out by checking the relocation offset and ignoring ones that
immediately follow the previous one seen.

However if a module has an _mcount call at offset 0, the second
relocation would not be filtered out due to old_r_offset == 0
being taken to mean that the current relocation is the first one
seen, and both would end up in the mcount_loc table.

This results in ftrace_make_nop() patching both (adjacent)
instructions to branches over the _mcount call sequence like so:

  0xffffffffc08a8000:  04 00 00 10     b       0xffffffffc08a8014
  0xffffffffc08a8004:  04 00 00 10     b       0xffffffffc08a8018
  0xffffffffc08a8008:  2d 08 e0 03     move    at,ra

The second branch is in the delay slot of the first, which is
defined to be unpredictable - on the platform on which this bug was
encountered, it triggers a reserved instruction exception.

Fix by initializing old_r_offset to ~0 and using that instead of 0
to determine whether the current relocation is the first seen.

Signed-off-by: Alex Smith <>
Signed-off-by: Ralf Baechle <>
Signed-off-by: Ben Hutchings <>
7 years agodrm: fix NULL pointer access by wrong ioctl
Zhaowei Yuan [Wed, 18 Jun 2014 06:33:59 +0000 (14:33 +0800)]
drm: fix NULL pointer access by wrong ioctl

commit 1539fb9bd405ee32282ea0a38404f9e008ac5b7a upstream.

If user uses wrong ioctl command with _IOC_NONE and argument size
greater than 0, it can cause NULL pointer access from memset of line
463. If _IOC_NONE, don't memset to 0 for kdata.

Signed-off-by: Zhaowei Yuan <>
Reviewed-by: David Herrmann <>
Signed-off-by: Dave Airlie <>
[bwh: Backported to 3.2: adjust indentation]
Signed-off-by: Ben Hutchings <>
7 years agomm: fix crashes from mbind() merging vmas
Hugh Dickins [Mon, 23 Jun 2014 20:22:07 +0000 (13:22 -0700)]
mm: fix crashes from mbind() merging vmas

commit d05f0cdcbe6388723f1900c549b4850360545201 upstream.

In v2.6.34 commit 9d8cebd4bcd7 ("mm: fix mbind vma merge problem")
introduced vma merging to mbind(), but it should have also changed the
convention of passing start vma from queue_pages_range() (formerly
check_range()) to new_vma_page(): vma merging may have already freed
that structure, resulting in BUG at mm/mempolicy.c:1738 and probably
worse crashes.

Fixes: 9d8cebd4bcd7 ("mm: fix mbind vma merge problem")
Reported-by: Naoya Horiguchi <>
Tested-by: Naoya Horiguchi <>
Signed-off-by: Hugh Dickins <>
Acked-by: Christoph Lameter <>
Cc: KOSAKI Motohiro <>
Cc: Minchan Kim <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 - Adjust context
 - Keep the same arguments to migrate_pages() except for private=start]
Signed-off-by: Ben Hutchings <>
7 years agomm: revert 0def08e3 ("mm/mempolicy.c: check return code of check_range")
Minchan Kim [Mon, 8 Oct 2012 23:33:38 +0000 (16:33 -0700)]
mm: revert 0def08e3 ("mm/mempolicy.c: check return code of check_range")

commit 082708072a4250f5c4dbc62065e7af93f5e45646 upstream.

Revert commit 0def08e3acc2 because check_range can't fail in
migrate_to_node with considering current usecases.

Quote from Johannes

: I think it makes sense to revert.  Not because of the semantics, but I
: just don't see how check_range() could even fail for this callsite:
: 1. we pass mm->mmap->vm_start in there, so we should not fail due to
:    find_vma()
: 2. we pass MPOL_MF_DISCONTIG_OK, so the discontig checks do not apply
:    and so can not fail
: 3. we pass MPOL_MF_MOVE | MPOL_MF_MOVE_ALL, the page table loops will
:    continue until addr == end, so we never fail with -EIO

And I added a new VM_BUG_ON for checking migrate_to_node's future usecase
which might pass to MPOL_MF_STRICT.

Suggested-by: Johannes Weiner <>
Signed-off-by: Minchan Kim <>
Acked-by: KOSAKI Motohiro <>
Cc: Mel Gorman <>
Cc: Christoph Lameter <>
Cc: David Rientjes <>
Cc: Vasiliy Kulikov <>
Acked-by: Johannes Weiner <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agohugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry
Naoya Horiguchi [Mon, 23 Jun 2014 20:22:03 +0000 (13:22 -0700)]
hugetlb: fix copy_hugetlb_page_range() to handle migration/hwpoisoned entry

commit 4a705fef986231a3e7a6b1a6d3c37025f021f49f upstream.

There's a race between fork() and hugepage migration, as a result we try
to "dereference" a swap entry as a normal pte, causing kernel panic.
The cause of the problem is that copy_hugetlb_page_range() can't handle
"swap entry" family (migration entry and hwpoisoned entry) so let's fix

[ coding-style fixes]
Signed-off-by: Naoya Horiguchi <>
Acked-by: Hugh Dickins <>
Cc: Christoph Lameter <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agox86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)
Andy Lutomirski [Mon, 23 Jun 2014 21:22:15 +0000 (14:22 -0700)]
x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508)

commit 554086d85e71f30abe46fc014fea31929a7c6a8a upstream.

The bad syscall nr paths are their own incomprehensible route
through the entry control flow.  Rearrange them to work just like
syscalls that return -ENOSYS.

This fixes an OOPS in the audit code when fast-path auditing is
enabled and sysenter gets a bad syscall nr (CVE-2014-4508).

This has probably been broken since Linux 2.6.27:
af0575bba0 i386 syscall audit fast-path

Cc: Roland McGrath <>
Reported-by: Toralf Förster <>
Signed-off-by: Andy Lutomirski <>
Signed-off-by: H. Peter Anvin <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agolzo: properly check for overruns
Greg Kroah-Hartman [Sat, 21 Jun 2014 05:00:53 +0000 (22:00 -0700)]
lzo: properly check for overruns

commit 206a81c18401c0cde6e579164f752c4b147324ce upstream.

The lzo decompressor can, if given some really crazy data, possibly
overrun some variable types.  Modify the checking logic to properly
detect overruns before they happen.

Reported-by: "Don A. Bailey" <>
Tested-by: "Don A. Bailey" <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agolib/lzo: Update LZO compression to current upstream version
Markus F.X.J. Oberhumer [Mon, 13 Aug 2012 15:25:44 +0000 (17:25 +0200)]
lib/lzo: Update LZO compression to current upstream version

commit 8b975bd3f9089f8ee5d7bbfd798537b992bbc7e7 upstream.

This commit updates the kernel LZO code to the current upsteam version
which features a significant speed improvement - benchmarking the Calgary
and Silesia test corpora typically shows a doubled performance in
both compression and decompression on modern i386/x86_64/powerpc machines.

Signed-off-by: Markus F.X.J. Oberhumer <>
Signed-off-by: Ben Hutchings <>
7 years agolib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c
Markus F.X.J. Oberhumer [Mon, 13 Aug 2012 15:24:24 +0000 (17:24 +0200)]
lib/lzo: Rename lzo1x_decompress.c to lzo1x_decompress_safe.c

commit b6bec26cea948148a9420e7a0ac337f925de49e7 upstream.

Rename the source file to match the function name and thereby
also make room for a possible future even slightly faster
"non-safe" decompressor version.

Signed-off-by: Markus F.X.J. Oberhumer <>
Signed-off-by: Ben Hutchings <>
7 years agotracing: Fix syscall_*regfunc() vs copy_process() race
Oleg Nesterov [Sun, 13 Apr 2014 18:58:54 +0000 (20:58 +0200)]
tracing: Fix syscall_*regfunc() vs copy_process() race

commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.

syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.

Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.

Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker <>
Acked-by: Paul E. McKenney <>
Signed-off-by: Oleg Nesterov <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
7 years agob43: fix frequency reported on G-PHY with /new/ firmware
Rafał Miłecki [Thu, 12 Jun 2014 20:28:22 +0000 (22:28 +0200)]
b43: fix frequency reported on G-PHY with /new/ firmware

commit 2fc68eb122c7ea6cd5be1fe7d6650c0beb2f4f40 upstream.

Support for firmware rev 508+ was added years ago, but we never noticed
it reports channel in a different way for G-PHY devices. Instead of
offset from 2400 MHz it simply passes channel id (AKA hw_value).

So far it was (most probably) affecting monitor mode users only, but
the following recent commit made it noticeable for quite everybody:

commit 3afc2167f60a327a2c1e1e2600ef209a3c2b75b7
Author: Emmanuel Grumbach <>
Date:   Tue Mar 4 16:50:13 2014 +0200

    cfg80211/mac80211: ignore signal if the frame was heard on wrong channel

Reported-by: Aaro Koskinen <>
Signed-off-by: Rafał Miłecki <>
Tested-by: Aaro Koskinen <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
7 years agort2x00: disable TKIP on USB
Stanislaw Gruszka [Tue, 10 Jun 2014 10:51:06 +0000 (12:51 +0200)]
rt2x00: disable TKIP on USB

commit 8edcb0ba0d56f5914eef11eda6db8bfe74eb9ca8 upstream.

On USB we can not get atomically TKIP key. We have to disable support
for TKIP acceleration on USB hardware to avoid bug as showed bellow.

[  860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002
[  860.827280] Call Trace:
[  860.827282]  [<ffffffff81682ea6>] dump_stack+0x4d/0x66
[  860.827284]  [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55
[  860.827285]  [<ffffffff81685bb3>] __schedule+0x733/0x7b0
[  860.827287]  [<ffffffff81685c59>] schedule+0x29/0x70
[  860.827289]  [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0
[  860.827291]  [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0
[  860.827294]  [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70
[  860.827296]  [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140
[  860.827298]  [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20
[  860.827301]  [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150
[  860.827303]  [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110
[  860.827305]  [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160  [rt2x00usb]
[  860.827307]  [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb]
[  860.827309]  [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb]
[  860.827311]  [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb]
[  860.827314]  [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50  [rt2800lib]
[  860.827321]  [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0  [mac80211]
[  860.827322]  [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80
[  860.827329]  [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211]

Reported-and-tested-by: Peter Wu <>
Reported-and-tested-by: Pontus Fuchs <>
Signed-off-by: Stanislaw Gruszka <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: Fix SSP acceptor just-works confirmation without MITM
Johan Hedberg [Mon, 9 Jun 2014 10:58:14 +0000 (13:58 +0300)]
Bluetooth: Fix SSP acceptor just-works confirmation without MITM

commit ba15a58b179ed76a7e887177f2b06de12c58ec8f upstream.

From the Bluetooth Core Specification 4.1 page 1958:

"if both devices have set the Authentication_Requirements parameter to
one of the MITM Protection Not Required options, authentication stage 1
shall function as if both devices set their IO capabilities to
DisplayOnly (e.g., Numeric comparison with automatic confirmation on
both devices)"

So far our implementation has done user confirmation for all just-works
cases regardless of the MITM requirements, however following the
specification to the word means that we should not be doing confirmation
when neither side has the MITM flag set.

Signed-off-by: Johan Hedberg <>
Tested-by: Szymon Janc <>
Signed-off-by: Marcel Holtmann <>
[bwh: Backported to 3.2: s/conn->flags/conn->pend/]
Signed-off-by: Ben Hutchings <>
7 years agoBluetooth: Fix check for connection encryption
Johan Hedberg [Tue, 10 Jun 2014 06:54:24 +0000 (09:54 +0300)]
Bluetooth: Fix check for connection encryption

commit e694788d73efe139b24f78b036deb97fe57fa8cb upstream.

The conn->link_key variable tracks the type of link key in use. It is
set whenever we respond to a link key request as well as when we get a
link key notification event.

These two events do not however always guarantee that encryption is
enabled: getting a link key request and responding to it may only mean
that the remote side has requested authentication but not encryption. On
the other hand, the encrypt change event is a certain guarantee that
encryption is enabled. The real encryption state is already tracked in
the conn->link_mode variable through the HCI_LM_ENCRYPT bit.

This patch fixes a check for encryption in the hci_conn_auth function to
use the proper conn->link_mode value and thereby eliminates the chance
of a false positive result.

Signed-off-by: Johan Hedberg <>
Signed-off-by: Marcel Holtmann <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoALSA: control: Make sure that id->index does not overflow
Lars-Peter Clausen [Wed, 18 Jun 2014 11:32:35 +0000 (13:32 +0200)]
ALSA: control: Make sure that id->index does not overflow

commit 883a1d49f0d77d30012f114b2e19fc141beb3e8e upstream.

The ALSA control code expects that the range of assigned indices to a control is
continuous and does not overflow. Currently there are no checks to enforce this.
If a control with a overflowing index range is created that control becomes
effectively inaccessible and unremovable since snd_ctl_find_id() will not be
able to find it. This patch adds a check that makes sure that controls with a
overflowing index range can not be created.

Signed-off-by: Lars-Peter Clausen <>
Acked-by: Jaroslav Kysela <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: control: Handle numid overflow
Lars-Peter Clausen [Wed, 18 Jun 2014 11:32:34 +0000 (13:32 +0200)]
ALSA: control: Handle numid overflow

commit ac902c112d90a89e59916f751c2745f4dbdbb4bd upstream.

Each control gets automatically assigned its numids when the control is created.
The allocation is done by incrementing the numid by the amount of allocated
numids per allocation. This means that excessive creation and destruction of
controls (e.g. via SNDRV_CTL_IOCTL_ELEM_ADD/REMOVE) can cause the id to
eventually overflow. Currently when this happens for the control that caused the
overflow kctl->id.numid + kctl->count will also over flow causing it to be
smaller than kctl->id.numid. Most of the code assumes that this is something
that can not happen, so we need to make sure that it won't happen

Signed-off-by: Lars-Peter Clausen <>
Acked-by: Jaroslav Kysela <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: control: Don't access controls outside of protected regions
Lars-Peter Clausen [Wed, 18 Jun 2014 11:32:33 +0000 (13:32 +0200)]
ALSA: control: Don't access controls outside of protected regions

commit fd9f26e4eca5d08a27d12c0933fceef76ed9663d upstream.

A control that is visible on the card->controls list can be freed at any time.
This means we must not access any of its memory while not holding the
controls_rw_lock. Otherwise we risk a use after free access.

Signed-off-by: Lars-Peter Clausen <>
Acked-by: Jaroslav Kysela <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: control: Fix replacing user controls
Lars-Peter Clausen [Wed, 18 Jun 2014 11:32:32 +0000 (13:32 +0200)]
ALSA: control: Fix replacing user controls

commit 82262a46627bebb0febcc26664746c25cef08563 upstream.

There are two issues with the current implementation for replacing user
controls. The first is that the code does not check if the control is actually a
user control and neither does it check if the control is owned by the process
that tries to remove it. That allows userspace applications to remove arbitrary
controls, which can cause a user after free if a for example a driver does not
expect a control to be removed from under its feed.

The second issue is that on one hand when a control is replaced the
user_ctl_count limit is not checked and on the other hand the user_ctl_count is
increased (even though the number of user controls does not change). This allows
userspace, once the user_ctl_count limit as been reached, to repeatedly replace
a control until user_ctl_count overflows. Once that happens new controls can be
added effectively bypassing the user_ctl_count limit.

Both issues can be fixed by instead of open-coding the removal of the control
that is to be replaced to use snd_ctl_remove_user_ctl(). This function does
proper permission checks as well as decrements user_ctl_count after the control
has been removed.

Note that by using snd_ctl_remove_user_ctl() the check which returns -EBUSY at
beginning of the function if the control already exists is removed. This is not
a problem though since the check is quite useless, because the lock that is
protecting the control list is released between the check and before adding the
new control to the list, which means that it is possible that a different
control with the same settings is added to the list after the check. Luckily
there is another check that is done while holding the lock in snd_ctl_add(), so
we'll rely on that to make sure that the same control is not added twice.

Signed-off-by: Lars-Peter Clausen <>
Acked-by: Jaroslav Kysela <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: control: Protect user controls against concurrent access
Lars-Peter Clausen [Wed, 18 Jun 2014 11:32:31 +0000 (13:32 +0200)]
ALSA: control: Protect user controls against concurrent access

commit 07f4d9d74a04aa7c72c5dae0ef97565f28f17b92 upstream.

The user-control put and get handlers as well as the tlv do not protect against
concurrent access from multiple threads. Since the state of the control is not
updated atomically it is possible that either two write operations or a write
and a read operation race against each other. Both can lead to arbitrary memory
disclosure. This patch introduces a new lock that protects user-controls from
concurrent access. Since applications typically access controls sequentially
than in parallel a single lock per card should be fine.

Signed-off-by: Lars-Peter Clausen <>
Acked-by: Jaroslav Kysela <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
7 years agoUSB: EHCI: avoid BIOS handover on the HASEE E200
Alan Stern [Tue, 3 Jun 2014 15:00:27 +0000 (11:00 -0400)]
USB: EHCI: avoid BIOS handover on the HASEE E200

commit b0a50e92bda3c4aeb8017d4e6c6e92146ebd5c9b upstream.

Leandro Liptak reports that his HASEE E200 computer hangs when we ask
the BIOS to hand over control of the EHCI host controller.  This
definitely sounds like a bug in the BIOS, but at the moment there is
no way to fix it.

This patch works around the problem by avoiding the handoff whenever
the motherboard and BIOS version match those of Leandro's computer.

Signed-off-by: Alan Stern <>
Reported-by: Leandro Liptak <>
Tested-by: Leandro Liptak <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
7 years agortmutex: Plug slow unlock race
Thomas Gleixner [Wed, 11 Jun 2014 18:44:04 +0000 (18:44 +0000)]
rtmutex: Plug slow unlock race

commit 27e35715df54cbc4f2d044f681802ae30479e7fb upstream.

When the rtmutex fast path is enabled the slow unlock function can
create the following situation:

foo->m->owner = NULL;
     rt_mutex_lock(foo->m); <-- fast path
free = atomic_dec_and_test(foo->refcnt);
rt_mutex_unlock(foo->m); <-- fast path
if (free)

spin_unlock(foo->m->wait_lock); <--- Use after free.

Plug the race by changing the slow unlock to the following scheme:

     while (!rt_mutex_has_waiters(m)) {
          /* Clear the waiters bit in m->owner */
           owner = rt_mutex_owner(m);
           if (cmpxchg(m->owner, owner, 0) == owner)

So in case of a new waiter incoming while the owner tries the slow
path unlock we have two situations:

 cmpxchg(p, owner, 0) == owner


 cmpxchg(p, owner, 0) != owner
 wakeup_next waiter();

If the fast path is disabled, then the simple

   m->owner = NULL;

is sufficient as all access to m->owner is serialized via

Also document and clarify the wakeup_next_waiter function as suggested
by Oleg Nesterov.

Reported-by: Steven Rostedt <>
Signed-off-by: Thomas Gleixner <>
Reviewed-by: Steven Rostedt <>
Cc: Peter Zijlstra <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
7 years agortmutex: Detect changes in the pi lock chain
Thomas Gleixner [Thu, 5 Jun 2014 09:16:12 +0000 (11:16 +0200)]
rtmutex: Detect changes in the pi lock chain

commit 82084984383babe728e6e3c9a8e5c46278091315 upstream.

When we walk the lock chain, we drop all locks after each step. So the
lock chain can change under us before we reacquire the locks. That's
harmless in principle as we just follow the wrong lock path. But it
can lead to a false positive in the dead lock detection logic:

T0 holds L0
T0 blocks on L1 held by T1
T1 blocks on L2 held by T2
T2 blocks on L3 held by T3
T4 blocks on L4 held by T4

Now we walk the chain

lock T1 -> lock L2 -> adjust L2 -> unlock T1 ->
     lock T2 ->  adjust T2 ->  drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 -> lock L0 -> deadlock detected, but it's not a deadlock at all.

Brad tried to work around that in the deadlock detection logic itself,
but the more I looked at it the less I liked it, because it's crystal
ball magic after the fact.

We actually can detect a chain change very simple:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T2 times out and blocks on L0

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)

So if we detect that T2 is now blocked on a different lock we stop the
chain walk. That's also correct in the following scenario:

lock T1 -> lock L2 -> adjust L2 -> unlock T1 -> lock T2 -> adjust T2 ->

     next_lock = T2->pi_blocked_on->lock;

drop locks

T3 times out and drops L3
T2 acquires L3 and blocks on L4 now

Now we continue:

lock T2 ->

     if (next_lock != T2->pi_blocked_on->lock)

We don't have to follow up the chain at that point, because T2
propagated our priority up to T4 already.

[ Folded a cleanup patch from peterz ]

Signed-off-by: Thomas Gleixner <>
Reported-by: Brad Mouring <>
Cc: Steven Rostedt <>
Cc: Peter Zijlstra <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
7 years agortmutex: Handle deadlock detection smarter
Thomas Gleixner [Thu, 5 Jun 2014 10:34:23 +0000 (12:34 +0200)]
rtmutex: Handle deadlock detection smarter

commit 3d5c9340d1949733eb37616abd15db36aef9a57c upstream.

Even in the case when deadlock detection is not requested by the
caller, we can detect deadlocks. Right now the code stops the lock
chain walk and keeps the waiter enqueued, even on itself. Silly not to
yell when such a scenario is detected and to keep the waiter enqueued.

Return -EDEADLK unconditionally and handle it at the call sites.

The futex calls return -EDEADLK. The non futex ones dequeue the
waiter, throw a warning and put the task into a schedule loop.

Tagged for stable as it makes the code more robust.

Signed-off-by: Thomas Gleixner <>
Cc: Steven Rostedt <>
Cc: Peter Zijlstra <>
Cc: Brad Mouring <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust filenames]
Signed-off-by: Ben Hutchings <>
7 years agomm: rmap: fix use-after-free in __put_anon_vma
Andrey Ryabinin [Fri, 6 Jun 2014 15:09:30 +0000 (19:09 +0400)]
mm: rmap: fix use-after-free in __put_anon_vma

commit 624483f3ea82598ab0f62f1bdb9177f531ab1892 upstream.

While working address sanitizer for kernel I've discovered
use-after-free bug in __put_anon_vma.

For the last anon_vma, anon_vma->root freed before child anon_vma.
Later in anon_vma_free(anon_vma) we are referencing to already freed
anon_vma->root to check rwsem.

This fixes it by freeing the child anon_vma before freeing

Signed-off-by: Andrey Ryabinin <>
Acked-by: Peter Zijlstra <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
7 years agoALSA: hda - Add quirk for external mic on Lifebook U904
David Henningsson [Fri, 13 Jun 2014 09:15:44 +0000 (11:15 +0200)]
ALSA: hda - Add quirk for external mic on Lifebook U904

commit 2041d56464a067461d7cc21734a0f024587ed2ff upstream.

According to the bug reporter (Данило Шеган), the external mic
starts to work and has proper jack detection if only pin 0x19
is marked properly as an external headset mic.

AlsaInfo at

Signed-off-by: David Henningsson <>
Signed-off-by: Takashi Iwai <>
[bwh: Backported to 3.2:
 - s/struct hda_pintbl/struct alc_pincfg/
Signed-off-by: Ben Hutchings <>
7 years agoevm: prohibit userspace writing 'security.evm' HMAC value
Mimi Zohar [Sun, 11 May 2014 04:05:23 +0000 (00:05 -0400)]
evm: prohibit userspace writing 'security.evm' HMAC value

commit 2fb1c9a4f2dbc2f0bd2431c7fa64d0b5483864e4 upstream.

Calculating the 'security.evm' HMAC value requires access to the
EVM encrypted key.  Only the kernel should have access to it.  This
patch prevents userspace tools(eg. setfattr, cp --preserve=xattr)
from setting/modifying the 'security.evm' HMAC value directly.

Signed-off-by: Mimi Zohar <>
Signed-off-by: Ben Hutchings <>
7 years agopowerpc: Don't setup CPUs with bad status
Michael Neuling [Fri, 6 Jun 2014 04:28:51 +0000 (14:28 +1000)]
powerpc: Don't setup CPUs with bad status

commit 59a53afe70fd530040bdc69581f03d880157f15a upstream.

OPAL will mark a CPU that is guarded as "bad" in the status property of the CPU

Unfortunatley Linux doesn't check this property and will put the bad CPU in the
present map.  This has caused hangs on booting when we try to unsplit the core.

This patch checks the CPU is avaliable via this status property before putting
it in the present map.

Signed-off-by: Michael Neuling <>
Tested-by: Anton Blanchard <>
Signed-off-by: Benjamin Herrenschmidt <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agowatchdog: ath79_wdt: avoid spurious restarts on AR934x
Gabor Juhos [Wed, 16 Apr 2014 09:34:41 +0000 (11:34 +0200)]
watchdog: ath79_wdt: avoid spurious restarts on AR934x

commit 23afeb613ec0e10aecfae7838a14d485db62ac52 upstream.

On some AR934x based systems, where the frequency of
the AHB bus is relatively high, the built-in watchdog
causes a spurious restart when it gets enabled.

The possible cause of these restarts is that the timeout
value written into the TIMER register does not reaches
the hardware in time.

Add an explicit delay into the ath79_wdt_enable function
to avoid the spurious restarts.

Signed-off-by: Gabor Juhos <>
Reviewed-by: Guenter Roeck <>
Signed-off-by: Wim Van Sebroeck <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
7 years agoauditsc: audit_krule mask accesses need bounds checking
Andy Lutomirski [Thu, 29 May 2014 03:09:58 +0000 (23:09 -0400)]
auditsc: audit_krule mask accesses need bounds checking

commit a3c54931199565930d6d84f4c3456f6440aefd41 upstream.

Fixes an easy DoS and possible information disclosure.

This does nothing about the broken state of x32 auditing.

eparis: If the admin has enabled auditd and has specifically loaded
audit rules.  This bug has been around since before git.  Wow...

Signed-off-by: Andy Lutomirski <>
Signed-off-by: Eric Paris <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: audit_filter_inode_name() is not a separate
 function but part of audit_filter_inodes()]
Signed-off-by: Ben Hutchings <>
7 years agodrm/radeon: stop poisoning the GART TLB
Christian König [Wed, 4 Jun 2014 13:29:56 +0000 (15:29 +0200)]
drm/radeon: stop poisoning the GART TLB

commit 0986c1a55ca64b44ee126a2f719a6e9f28cbe0ed upstream.

When we set the valid bit on invalid GART entries they are
loaded into the TLB when an adjacent entry is loaded. This
poisons the TLB with invalid entries which are sometimes
not correctly removed on TLB flush.

For stable inclusion the patch probably needs to be modified a bit.

Signed-off-by: Christian König <>
Signed-off-by: Alex Deucher <>
[bwh: Backported to 3.2: R600_PTE_GART is not defined and we list all the
 flags indvidually]
Signed-off-by: Ben Hutchings <>
7 years agoBtrfs: fix double free in find_lock_delalloc_range
Chris Mason [Wed, 21 May 2014 12:49:54 +0000 (05:49 -0700)]
Btrfs: fix double free in find_lock_delalloc_range

commit 7d78874273463a784759916fc3e0b4e2eb141c70 upstream.

We need to NULL the cached_state after freeing it, otherwise
we might free it again if find_delalloc_range doesn't find anything.

Signed-off-by: Chris Mason <>
Signed-off-by: Ben Hutchings <>
7 years agonfsd4: fix FREE_STATEID lockowner leak
J. Bruce Fields [Tue, 27 May 2014 15:14:26 +0000 (11:14 -0400)]
nfsd4: fix FREE_STATEID lockowner leak

commit 48385408b45523d9a432c66292d47ef43efcbb94 upstream.

27b11428b7de ("nfsd4: remove lockowner when removing lock stateid")
introduced a memory leak.

Reported-by: Jeff Layton <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
7 years agoInput: synaptics - fix resolution for manually provided min/max
Benjamin Tissoires [Sun, 8 Jun 2014 05:37:47 +0000 (22:37 -0700)]
Input: synaptics - fix resolution for manually provided min/max

commit d49cb7aeebb974713f9f7ab2991352d3050b095b upstream.

commit 421e08c41fda fixed the reported min/max for the X and Y axis,
but unfortunately, it broke the resolution of those same axis.

On the t540p, the resolution is the same regarding X and Y. It is not
a problem for xf86-input-synaptics because this driver is only interested
in the ratio between X and Y.
Unfortunately, xf86-input-cmt uses directly the resolution, and having a
null resolution leads to some divide by 0 errors, which are translated by
-infinity in the resulting coordinates.

Reported-by: Peter Hutterer <>
Signed-off-by: Benjamin Tissoires <>
Signed-off-by: Dmitry Torokhov <>
[bwh: Backported to 3.2: I didn't apply the PNP ID changes, so the
 code being moved looks different]
Signed-off-by: Ben Hutchings <>