4 years agoath9k: Disable PowerSave by default
Sujith Manoharan [Sat, 1 Jun 2013 01:38:09 +0000 (07:08 +0530)]
ath9k: Disable PowerSave by default

commit 531671cb17af07281e6f28c1425f754346e65c41 upstream.

Almost all the DMA issues which have plagued ath9k (in station mode)
for years are related to PS. Disabling PS usually "fixes" the user's
connection stablility. Reports of DMA problems are still trickling in
and are sitting in the kernel bugzilla. Until the PS code in ath9k is
given a thorough review, disbale it by default. The slight increase
in chip power consumption is a small price to pay for improved link

Signed-off-by: Sujith Manoharan <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoBluetooth: Fix mgmt handling of power on failures
Johan Hedberg [Wed, 29 May 2013 06:51:29 +0000 (09:51 +0300)]
Bluetooth: Fix mgmt handling of power on failures

commit 96570ffcca0b872dc8626e97569d2697f374d868 upstream.

If hci_dev_open fails we need to ensure that the corresponding
mgmt_set_powered command gets an appropriate response. This patch fixes
the missing response by adding a new mgmt_set_powered_failed function
that's used to indicate a power on failure to mgmt. Since a situation
with the device being rfkilled may require special handling in user
space the patch uses a new dedicated mgmt status code for this.

Signed-off-by: Johan Hedberg <>
Acked-by: Marcel Holtmann <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/gma500/cdv: Unpin framebuffer on crtc disable
Patrik Jakobsson [Sat, 8 Jun 2013 18:23:08 +0000 (20:23 +0200)]
drm/gma500/cdv: Unpin framebuffer on crtc disable

commit 22e7c385a80d771aaf3a15ae7ccea3b0686bbe10 upstream.

The framebuffer needs to be unpinned in the crtc->disable callback
because of previous pinning in psb_intel_pipe_set_base(). This will fix
a memory leak where the framebuffer was released but not unpinned
properly. This patch only affects Cedarview.

Reviewed-by: Daniel Vetter <>
Signed-off-by: Patrik Jakobsson <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/gma500/psb: Unpin framebuffer on crtc disable
Patrik Jakobsson [Wed, 5 Jun 2013 12:24:01 +0000 (14:24 +0200)]
drm/gma500/psb: Unpin framebuffer on crtc disable

commit 820de86a90089ee607d7864538c98a23b503c846 upstream.

The framebuffer needs to be unpinned in the crtc->disable callback
because of previous pinning in psb_intel_pipe_set_base(). This will fix
a memory leak where the framebuffer was released but not unpinned
properly. This patch only affects Poulsbo.

Reviewed-by: Daniel Vetter <>
Signed-off-by: Patrik Jakobsson <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrivers/rtc/rtc-twl.c: fix missing device_init_wakeup() when booted with device tree
Tony Lindgren [Wed, 12 Jun 2013 21:04:48 +0000 (14:04 -0700)]
drivers/rtc/rtc-twl.c: fix missing device_init_wakeup() when booted with device tree

commit 24b8256a1fb28d357bc6fa09184ba29b4255ba5c upstream.

When booted in legacy mode device_init_wakeup() gets called by
drivers/mfd/twl-core.c when the children are initialized.  However, when
booted using device tree, the children are created with
of_platform_populate() instead add_children().

This means that the RTC driver will not have device_init_wakeup() set,
and we need to call it from the driver probe like RTC drivers typically

Without this we cannot test PM wake-up events on omaps for cases where
there may not be any physical wake-up event.

Signed-off-by: Tony Lindgren <>
Reported-by: Kevin Hilman <>
Cc: Alessandro Zummo <>
Cc: Jingoo Han <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoceph: ceph_pagelist_append might sleep while atomic
Jim Schutt [Wed, 15 May 2013 18:03:35 +0000 (13:03 -0500)]
ceph: ceph_pagelist_append might sleep while atomic

commit 39be95e9c8c0b5668c9f8806ffe29bf9f4bc0f40 upstream.

Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc()
while holding a lock, but it's spoiled because ceph_pagelist_addpage()
always calls kmap(), which might sleep.  Here's the result:

[13439.295457] ceph: mds0 reconnect start
[13439.300572] BUG: sleeping function called from invalid context at include/linux/highmem.h:58
[13439.309243] in_atomic(): 1, irqs_disabled(): 0, pid: 12059, name: kworker/1:1
    . . .
[13439.376225] Call Trace:
[13439.378757]  [<ffffffff81076f4c>] __might_sleep+0xfc/0x110
[13439.384353]  [<ffffffffa03f4ce0>] ceph_pagelist_append+0x120/0x1b0 [libceph]
[13439.391491]  [<ffffffffa0448fe9>] ceph_encode_locks+0x89/0x190 [ceph]
[13439.398035]  [<ffffffff814ee849>] ? _raw_spin_lock+0x49/0x50
[13439.403775]  [<ffffffff811cadf5>] ? lock_flocks+0x15/0x20
[13439.409277]  [<ffffffffa045e2af>] encode_caps_cb+0x41f/0x4a0 [ceph]
[13439.415622]  [<ffffffff81196748>] ? igrab+0x28/0x70
[13439.420610]  [<ffffffffa045e9f8>] ? iterate_session_caps+0xe8/0x250 [ceph]
[13439.427584]  [<ffffffffa045ea25>] iterate_session_caps+0x115/0x250 [ceph]
[13439.434499]  [<ffffffffa045de90>] ? set_request_path_attr+0x2d0/0x2d0 [ceph]
[13439.441646]  [<ffffffffa0462888>] send_mds_reconnect+0x238/0x450 [ceph]
[13439.448363]  [<ffffffffa0464542>] ? ceph_mdsmap_decode+0x5e2/0x770 [ceph]
[13439.455250]  [<ffffffffa0462e42>] check_new_map+0x352/0x500 [ceph]
[13439.461534]  [<ffffffffa04631ad>] ceph_mdsc_handle_map+0x1bd/0x260 [ceph]
[13439.468432]  [<ffffffff814ebc7e>] ? mutex_unlock+0xe/0x10
[13439.473934]  [<ffffffffa043c612>] extra_mon_dispatch+0x22/0x30 [ceph]
[13439.480464]  [<ffffffffa03f6c2c>] dispatch+0xbc/0x110 [libceph]
[13439.486492]  [<ffffffffa03eec3d>] process_message+0x1ad/0x1d0 [libceph]
[13439.493190]  [<ffffffffa03f1498>] ? read_partial_message+0x3e8/0x520 [libceph]
    . . .
[13439.587132] ceph: mds0 reconnect success
[13490.720032] ceph: mds0 caps stale
[13501.235257] ceph: mds0 recovery completed
[13501.300419] ceph: mds0 caps renewed

Fix it up by encoding locks into a buffer first, and when the number
of encoded locks is stable, copy that into a ceph_pagelist.

[ abbreviated the stack info a bit.]

Signed-off-by: Jim Schutt <>
Reviewed-by: Alex Elder <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoceph: add cpu_to_le32() calls when encoding a reconnect capability
Jim Schutt [Wed, 15 May 2013 18:03:35 +0000 (13:03 -0500)]
ceph: add cpu_to_le32() calls when encoding a reconnect capability

commit c420276a532a10ef59849adc2681f45306166b89 upstream.

In his review, Alex Elder mentioned that he hadn't checked that
num_fcntl_locks and num_flock_locks were properly decoded on the
server side, from a le32 over-the-wire type to a cpu type.
I checked, and AFAICS it is done; those interested can consult
in src/mds/ and src/include/encoding.h in the Ceph server
code (git://

I also checked the server side for flock_len decoding, and I believe
that also happens correctly, by virtue of having been declared
__le32 in struct ceph_mds_cap_reconnect, in src/include/ceph_fs.h.

Signed-off-by: Jim Schutt <>
Reviewed-by: Alex Elder <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agolibceph: must hold mutex for reset_changed_osds()
Alex Elder [Wed, 15 May 2013 21:28:33 +0000 (16:28 -0500)]
libceph: must hold mutex for reset_changed_osds()

commit 14d2f38df67fadee34625fcbd282ee22514c4846 upstream.

An osd client has a red-black tree describing its osds, and
occasionally we would get crashes due to one of these trees tree
becoming corrupt somehow.

The problem turned out to be that reset_changed_osds() was being
called without protection of the osd client request mutex.  That
function would call __reset_osd() for any osd that had changed, and
__reset_osd() would call __remove_osd() for any osd with no
outstanding requests, and finally __remove_osd() would remove the
corresponding entry from the red-black tree.  Thus, the tree was
getting modified without having any lock protection, and was
vulnerable to problems due to concurrent updates.

This appears to be the only osd tree updating path that has this
problem.  It can be fairly easily fixed by moving the call up
a few lines, to just before the request mutex gets dropped
in kick_requests().

This resolves:

Signed-off-by: Alex Elder <>
Reviewed-by: Sage Weil <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agob43: stop format string leaking into error msgs
Kees Cook [Fri, 10 May 2013 21:48:21 +0000 (14:48 -0700)]
b43: stop format string leaking into error msgs

commit e0e29b683d6784ef59bbc914eac85a04b650e63c upstream.

The module parameter "fwpostfix" is userspace controllable, unfiltered,
and is used to define the firmware filename. b43_do_request_fw() populates
ctx->errors[] on error, containing the firmware filename. b43err()
parses its arguments as a format string. For systems with b43 hardware,
this could lead to a uid-0 to ring-0 escalation.


Signed-off-by: Kees Cook <>
Signed-off-by: John W. Linville <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoLinux 3.4.49
Greg Kroah-Hartman [Thu, 13 Jun 2013 16:48:06 +0000 (09:48 -0700)]
Linux 3.4.49

4 years agoftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section
Steven Rostedt [Fri, 7 Jun 2013 09:02:08 +0000 (17:02 +0800)]
ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section

commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream.

As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to
be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the
ftrace_pid_fops is defined when DYNAMIC_FTRACE is not.

Signed-off-by: Steven Rostedt <>
Cc: Namhyung Kim <>
[ lizf: adjust context ]
Signed-off-by: Li Zefan <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agotracing: Fix possible NULL pointer dereferences
Namhyung Kim [Fri, 7 Jun 2013 09:01:16 +0000 (17:01 +0800)]
tracing: Fix possible NULL pointer dereferences

commit 6a76f8c0ab19f215af2a3442870eeb5f0e81998d upstream.

Currently set_ftrace_pid and set_graph_function files use seq_lseek
for their fops.  However seq_open() is called only for FMODE_READ in
the fops->open() so that if an user tries to seek one of those file
when she open it for writing, it sees NULL seq_file and then panic.

It can be easily reproduced with following command:

  $ cd /sys/kernel/debug/tracing
  $ echo 1234 | sudo tee -a set_ftrace_pid

In this example, GNU coreutils' tee opens the file with fopen(, "a")
and then the fopen() internally calls lseek().


Signed-off-by: Namhyung Kim <>
Cc: Frederic Weisbecker <>
Cc: Ingo Molnar <>
Cc: Namhyung Kim <>
Signed-off-by: Steven Rostedt <>
[ lizf: adjust context ]
Signed-off-by: Li Zefan <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/gma500: Increase max resolution for mode setting
Patrik Jakobsson [Thu, 25 Apr 2013 20:23:36 +0000 (22:23 +0200)]
drm/gma500: Increase max resolution for mode setting

commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream.

By having a higher max resolution we can now set up a virtual
framebuffer that spans several monitors. 4096 should be ok since we're
gen 3 or higher and should be enough for most dual head setups.

Signed-off-by: Patrik Jakobsson <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer
Ying Xue [Mon, 6 Aug 2012 09:46:37 +0000 (17:46 +0800)]
USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer

commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream.

Pointers should not be compared to plain integers.
Quiets the sparse warning:
warning: Using plain integer as NULL pointer

Signed-off-by: Ying Xue <>
Cc: Lotfi Manseur <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()
Jan Beulich [Wed, 6 Feb 2013 15:30:38 +0000 (10:30 -0500)]
xen-pciback: rate limit error messages from xen_pcibk_enable_msi{,x}()

commit 51ac8893a7a51b196501164e645583bf78138699 upstream.

... as being guest triggerable (e.g. by invoking
XEN_PCI_OP_enable_msi{,x} on a device not being MSI/MSI-X capable).

This is CVE-2013-0231 / XSA-43.

Also make the two messages uniform in both their wording and severity.

Signed-off-by: Jan Beulich <>
Acked-by: Ian Campbell <>
Reviewed-by: Konrad Rzeszutek Wilk <>
[stable tree: Added two extra #include files]
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/i915: no lvds quirk for hp t5740
Ben Mesman [Tue, 16 Apr 2013 18:00:28 +0000 (20:00 +0200)]
drm/i915: no lvds quirk for hp t5740

commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream.

Last year, a patch was made for the "HP t5740e Thin Client" (see
This device reports an lvds panel, but does not really have one.

The predecessor of this device is the "hp t5740", which also does not have
an lvds panel. This patch will add the same quirk for this device.

Signed-off-by: Ben Mesman <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.
Egbert Eich [Tue, 4 Jun 2013 15:13:21 +0000 (17:13 +0200)]
drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC.

commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream.

In intel_sdvo_get_lvds_modes() the wrong i2c adapter record is used
for DDC. Thus the code will always have to rely on a LVDS panel
mode supplied by VBT.
In most cases this succeeds, so this didn't get detected for quite
a while.

This regression seems to have been introduced in

commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson <>
Date:   Tue Jul 20 15:44:45 2010 -0700

    drm/i915: use GMBUS to manage i2c links

Signed-off-by: Egbert Eich <>
Reviewed-by: Chris Wilson <>
[danvet: Add note about which commit likely introduced this issue.]
Signed-off-by: Daniel Vetter <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm: fix a use-after-free when GPU acceleration disabled
Huacai Chen [Tue, 21 May 2013 06:23:43 +0000 (06:23 +0000)]
drm: fix a use-after-free when GPU acceleration disabled

commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream.

When GPU acceleration is disabled, drm_vblank_cleanup() will free the
vblank-related data, such as vblank_refcount, vblank_inmodeset, etc.
But we found that drm_vblank_post_modeset() may be called after the
cleanup, which use vblank_refcount and vblank_inmodeset. And this will
cause a kernel panic.

Fix this by return immediately if dev->num_crtcs is zero. This is the
same thing that drm_vblank_pre_modeset() does.

Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup():
[   62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4
[   62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174
[   62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38
[   62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc
[   62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988
[   62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104
[   62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c
[   62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118
[   62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384
[   62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc
[   62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94
[   62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68
[   62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260
[   62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314
[   62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234
[   62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4
[   62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18
[   62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c
[   62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238
[   62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0
[   62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30
[   62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc
[   62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44
[   62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4
[   62.628906] [<ffffffff802497a8>] kthread+0x88/0x90
[   62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18

Signed-off-by: Huacai Chen <>
Signed-off-by: Binbin Zhou <>
Reviewed-by: Michel Dänzer <>
Acked-by: Paul Menzel <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agohwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617
Guenter Roeck [Wed, 5 Jun 2013 21:09:30 +0000 (14:09 -0700)]
hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617

commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream.

On a system with both MAX1617 and JC42 sensors, JC42 sensors can be misdetected
as LM84. Strengthen detection sufficiently enough to avoid this misdetection.
Also improve detection for ADM1021.

Modeled after chip detection code in sensors-detect command.

Signed-off-by: Guenter Roeck <>
Tested-by: Jean Delvare <>
Acked-by: Jean Delvare <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/radeon: don't allow audio on DCE6
Alex Deucher [Mon, 3 Jun 2013 14:32:40 +0000 (10:32 -0400)]
drm/radeon: don't allow audio on DCE6

commit 1cbcca302a318499f20a512847c5d6a510c08c35 upstream.

It's not supported yet.  Fixes display issues when
users force it on.

Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoradeon: Fix system hang issue when using KMS with older cards
Adis Hamzić [Sun, 2 Jun 2013 14:47:54 +0000 (16:47 +0200)]
radeon: Fix system hang issue when using KMS with older cards

commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream.

The current radeon driver initialization routines, when using KMS, are written
so that the IRQ installation routine is called before initializing the WB buffer
and the CP rings. With some ASICs, though, the IRQ routine tries to access the
GFX_INDEX ring causing a call to RREG32 with the value of -1 in
radeon_fence_read. This, in turn causes the system to completely hang with some
cards, requiring a hard reset.

A call stack that can cause such a hang looks like this (using rv515 ASIC for the
example here):
 * rv515_init (rv515.c)
 * radeon_irq_kms_init (radeon_irq_kms.c)
 * drm_irq_install (drm_irq.c)
 * radeon_driver_irq_preinstall_kms (radeon_irq_kms.c)
 * rs600_irq_process (rs600.c)
 * radeon_fence_process - due to SW interrupt (radeon_fence.c)
 * radeon_fence_read (radeon_fence.c)
 * hang due to RREG32(-1)

The patch moves the IRQ installation to the card startup routine, after the ring
has been initialized, but before the IRQ has been set. This fixes the issue, but
requires a check to see if the IRQ is already installed, as is the case in the
system resume codepath.
I have tested the patch on three machines using the rv515, the rv770 and the
evergreen ASIC. They worked without issues.

This seems to be a known issue and has been reported on several bug tracking
sites by various distributions (see links below). Most of reports recommend
booting the system with KMS disabled and then enabling KMS by reloading the
radeon module. For some reason, this was indeed a usable workaround, however,
UMS is now deprecated and disabled by default.

Bug reports:

Signed-off-by: Adis Hamzić <>
Signed-off-by: Alex Deucher <>
4 years agopowerpc/eeh: Don't check RTAS token to get PE addr
Gavin Shan [Wed, 5 Jun 2013 14:25:50 +0000 (14:25 +0000)]
powerpc/eeh: Don't check RTAS token to get PE addr

commit b8b3de224f194005ad87ede6fd022fcc2bef3b1a upstream.

RTAS token "ibm,get-config-addr-info" or ibm,get-config-addr-info2"
are used to retrieve the PE address according to PCI address, which
made up of domain/bus/slot/function. If we don't have those 2 tokens,
the domain/bus/slot/function would be used as the address for EEH
RTAS operations. Some older f/w might not have those 2 tokens and
that blocks the EEH functionality to be initialized. It was introduced
by commit e2af155c ("powerpc/eeh: pseries platform EEH initialization").

The patch skips the check on those 2 tokens so we can bring up EEH
functionality successfully. And domain/bus/slot/function will be
used as address for EEH RTAS operations.

Reported-by: Robert Knight <>
Signed-off-by: Gavin Shan <>
Tested-by: Robert Knight <>
Signed-off-by: Benjamin Herrenschmidt <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoACPI / video: ignore BIOS initial backlight value for HP Pavilion g6
Ash Willis [Wed, 29 May 2013 01:27:59 +0000 (01:27 +0000)]
ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6

commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream.

This patch addresses kernel bug 56661. BIOS reports an incorrect
backlight value, causing the driver to switch off the backlight
completely during startup. This patch ignores the incorrect value from

Signed-off-by: Ash Willis <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoACPI / video: ignore BIOS initial backlight value for HP m4
Alex Hung [Tue, 28 May 2013 02:05:09 +0000 (02:05 +0000)]
ACPI / video: ignore BIOS initial backlight value for HP m4

commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream.

On HP m4 lapops, BIOS reports minimum backlight on boot and
causes backlight to dim completely. This ignores the initial backlight
values and set to max brightness.

Signed-off-by: Alex Hung <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: mos7720: fix hardware flow control
Johan Hovold [Tue, 4 Jun 2013 16:50:31 +0000 (18:50 +0200)]
USB: mos7720: fix hardware flow control

commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream.

The register access to enable hardware flow control depends on the
device port number and not the port minor number.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: mos7720: fix message timeouts
Johan Hovold [Mon, 27 May 2013 12:44:43 +0000 (14:44 +0200)]
USB: mos7720: fix message timeouts

commit 849513a7809175420d353625b6f651d961e99d49 upstream.

The control and bulk-message timeouts are specified in milliseconds and
should not depend on HZ.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: mos7720: fix DMA to stack
Johan Hovold [Mon, 27 May 2013 12:44:39 +0000 (14:44 +0200)]
USB: mos7720: fix DMA to stack

commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream.

The read_mos_reg function is called with stack-allocated buffers, which
must not be used for control messages.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: revert periodic scheduling bugfix
Alan Stern [Tue, 28 May 2013 18:03:10 +0000 (14:03 -0400)]
USB: revert periodic scheduling bugfix

commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream.

This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d
(USB: EHCI: fix bug in scheduling periodic split transfers).  The
commit was valid -- it fixed a real bug -- but the periodic scheduler
in ehci-hcd is in such bad shape (especially the part that handles
split transactions) that fixing one bug is very likely to cause
another to surface.  That's what happened in this case; the result was
choppy and noisy playback on certain 24-bit audio devices.

The only real fix will be to rewrite this entire section of code.  My
next project...

This fixes

Thanks to Tim Richardson for extra testing and feedback, and to Joseph
Salisbury and Tyson Tan for tracking down the original source of the

Signed-off-by: Alan Stern <>
CC: Joseph Salisbury <>
CC: Tim Richardson <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: serial: fix Treo/Kyocera interrrupt-in urb context
Johan Hovold [Mon, 27 May 2013 12:44:37 +0000 (14:44 +0200)]
USB: serial: fix Treo/Kyocera interrrupt-in urb context

commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream.

The first and second interrupt-in urbs are swapped for some Treo/Kyocera
devices, but the urb context was never updated with the new port.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: whiteheat: fix broken port configuration
Johan Hovold [Thu, 6 Jun 2013 11:32:47 +0000 (13:32 +0200)]
USB: whiteheat: fix broken port configuration

commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream.

When configuring the port (e.g. set_termios) the port minor number
rather than the port number was used in the request (and they only
coincide for minor number 0).

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: Serial: cypress_M8: Enable FRWD Dongle hidcom device
Robert Butora [Fri, 31 May 2013 15:09:51 +0000 (18:09 +0300)]
USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device

commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream.

The patch adds a new HIDCOM device and does not affect other devices
driven by the cypress_M8 module. Changes are:
- add VendorID ProductID to device tables
- skip unstable speed check because FRWD uses 115200bps
- skip reset at probe which is an issue workaround for this
particular device.

Signed-off-by: Robert Butora <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: visor: fix initialisation of Treo/Kyocera devices
Johan Hovold [Mon, 27 May 2013 12:44:38 +0000 (14:44 +0200)]
USB: visor: fix initialisation of Treo/Kyocera devices

commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3 upstream.

Fix regression introduced by commit 214916f2e ("USB: visor: reimplement
using generic framework") which broke initialisation of Treo/Kyocera
devices that re-mapped bulk-in endpoints.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: ark3116: fix control-message timeout
Johan Hovold [Mon, 27 May 2013 12:44:41 +0000 (14:44 +0200)]
USB: ark3116: fix control-message timeout

commit 634371911730a462626071065b64cd6e1fe213e0 upstream.

The control-message timeout is specified in milliseconds and should not
depend on HZ.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: keyspan: fix bogus array index
Johan Hovold [Tue, 4 Jun 2013 16:50:29 +0000 (18:50 +0200)]
USB: keyspan: fix bogus array index

commit a07088098a650267b2eda689538133a324b9523f upstream.

The outcont_endpoints array was indexed using the port minor number
(which can be greater than the array size) rather than the device port

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: iuu_phoenix: fix bulk-message timeout
Johan Hovold [Mon, 27 May 2013 12:44:42 +0000 (14:44 +0200)]
USB: iuu_phoenix: fix bulk-message timeout

commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7 upstream.

The bulk-message timeout is specified in milliseconds and should not
depend on HZ.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270
Takashi Iwai [Wed, 5 Jun 2013 06:35:26 +0000 (08:35 +0200)]
ALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270

commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993 upstream.

USB audio driver spews an error message when probing Logitech HD
webcam c270:
  ALSA mixer.c:1300 usb_audio: Warning! Unlikely big volume range (=6144), cval->res is probably wrong.
  ALSA mixer.c:1304 usb_audio: [5] FU [Mic Capture Volume] ch = 1, val = 1536/7680/1

Obviously the device needs a fixed volume resolution (cval->res = 384)
like other Logitech devices.


Reported-and-tested-by: Cristian Rodríguez <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface
Takashi Iwai [Tue, 4 Jun 2013 14:02:54 +0000 (16:02 +0200)]
ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface

commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89 upstream.

... instead of applying to all interfaces.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoALSA: usb-audio: fix Roland/Cakewalk UM-3G support
Clemens Ladisch [Sun, 2 Jun 2013 17:49:07 +0000 (19:49 +0200)]
ALSA: usb-audio: fix Roland/Cakewalk UM-3G support

commit a0c6d309c6df14655f9962f666d1da96318b0b7c upstream.

Commit 927c9423dd5f2d1c0b93d5e694ab84b4a5559713 (ALSA: usb-audio: add
Edirol UM-3G support) used a wrong quirk type, which would make the
driver refuse to attach with the error message "MIDIStreaming interface
descriptor not found".

Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxhci: fix list access before init
Vladimir Murzin [Tue, 9 Apr 2013 18:33:31 +0000 (22:33 +0400)]
xhci: fix list access before init

commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream.

If for whatever reason we fall into fail path in xhci_mem_init()
before bw table gets initialized we may access the uninitialized lists
in xhci_mem_cleanup().

Check for bw table before traversing lists in cleanup routine.

This patch should be backported to kernels as old as 3.2, that contain
the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store
information about roothubs and TTs."

Reported-by: Sergey Dyasly <>
Tested-by: Sergey Dyasly <>
Signed-off-by: Vladimir Murzin <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxhci-mem: init list heads at the beginning of init
Sergio Aguirre [Thu, 4 Apr 2013 17:32:13 +0000 (10:32 -0700)]
xhci-mem: init list heads at the beginning of init

commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream.

It is possible that we fail on xhci_mem_init, just before doing
the INIT_LIST_HEAD, and calling xhci_mem_cleanup.

Problem is that, the list_for_each_entry_safe macro, assumes
list heads are initialized (not NULL), and dereferences their 'next'
pointer, causing a kernel panic if this is not yet initialized.

Let's protect from that by moving inits to the beginning.

This patch should be backported to kernels as old as 3.2, that
contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test
USB2 software LPM".

Signed-off-by: Sergio Aguirre <>
Acked-by: David Cohen <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxhci - correct comp_mode_recovery_timer on return from hibernate
Tony Camuso [Thu, 21 Feb 2013 21:11:27 +0000 (16:11 -0500)]
xhci - correct comp_mode_recovery_timer on return from hibernate

commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream.

Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.

The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.

Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.

At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.

The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty

This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.

Thanks to Alan Stern for his help with understanding the problem.

[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false.  The original patch would have caused list corruption in this

This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"

Signed-off-by: Tony Camuso <>
Tested-by: Tony Camuso <>
Acked-by: Don Zickus <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: option: blacklist network interface on Huawei E1820
Bjørn Mork [Thu, 6 Jun 2013 10:57:24 +0000 (12:57 +0200)]
USB: option: blacklist network interface on Huawei E1820

commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream.

The mode used by Windows for the Huawei E1820 will use the
same ff/ff/ff class codes for both serial and network

Reported-by: Graham Inggs <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoLinux 3.4.48
Greg Kroah-Hartman [Fri, 7 Jun 2013 19:50:29 +0000 (12:50 -0700)]
Linux 3.4.48

4 years agothinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
Manoj Iyer [Mon, 6 Aug 2012 23:15:37 +0000 (18:15 -0500)]
thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR

commit a4f46bb9fa84642e356898ee44b670989622f8bb upstream.

In the latest V-series bios DMI_PRODUCT_VERSION does not contain
the string Lenovo or Thinkpad, but is set to the model number, this
causes the thinkpad_acpi module to fail to load. Recognize laptop
as Lenovo using DMI_BIOS_VENDOR instead, which is set to Lenovo.

Test on V490u
== After the patch ==

[ 1350.295757] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[ 1350.295760] thinkpad_acpi:
[ 1350.295761] thinkpad_acpi: ThinkPad BIOS H7ET21WW (1.00 ), EC unknown
[ 1350.295763] thinkpad_acpi: Lenovo LENOVO, model LV5DXXX
[ 1350.296086] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[ 1350.296694] thinkpad_acpi: radio switch found; radios are enabled
[ 1350.296703] thinkpad_acpi: possible tablet mode switch found; ThinkPad in laptop mode
[ 1350.306466] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
[ 1350.307082] Registered led device: tpacpi::thinklight
[ 1350.307215] Registered led device: tpacpi::power
[ 1350.307255] Registered led device: tpacpi::standby
[ 1350.307294] Registered led device: tpacpi::thinkvantage
[ 1350.308160] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
[ 1350.308333] thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
[ 1350.312287] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input14

== Before the patch ==
sudo modprobe thinkpad_acpi
FATAL: Error inserting thinkpad_acpi (/lib/modules/3.2.0-27-generic/kernel/drivers/platform/x86/thinkpad_acpi.ko): No such device

Test on B485
This patch was also test in a B485 where the thinkpad_acpi module does not
have any issues loading. But, I tested it to make sure this patch does not
break on already functioning models of Lenovo products.

[13486.746359] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[13486.746364] thinkpad_acpi:
[13486.746368] thinkpad_acpi: ThinkPad BIOS HJET15WW(1.01), EC unknown
[13486.746373] thinkpad_acpi: Lenovo Lenovo LB485, model 814TR01
[13486.747300] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[13486.752435] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is unblocked
[13486.752883] Registered led device: tpacpi::thinklight
[13486.752915] thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
[13486.753216] thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
[13486.757147] input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input15

Signed-off-by: Manoj Iyer <>
Signed-off-by: Matthew Garrett <>
Cc: Shuduo Sang <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomac80211: close AP_VLAN interfaces before unregistering all
Johannes Berg [Thu, 23 May 2013 23:06:09 +0000 (01:06 +0200)]
mac80211: close AP_VLAN interfaces before unregistering all

commit c8aa22db0112f640ac6631347f850879c621840b upstream.

Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.

Signed-off-by: Johannes Berg <>
Cc: Eric Dumazet <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agox86, um: Correct syscall table type attributes breaking gcc 4.8
Martin Pelikan [Sat, 9 Jun 2012 19:22:11 +0000 (21:22 +0200)]
x86, um: Correct syscall table type attributes breaking gcc 4.8

commit 9271b0b4b2044c6db06051fe60bc58cdd4f17c7c upstream.

The latest GCC 4.8 does some more checking on type attributes that
break the build for ARCH=um -> fill them in.  Specifically, the
"asmlinkage" attributes is now tested for consistency.

Signed-off-by: Martin Pelikan <>
Acked-by: Richard Weinberger <>
Signed-off-by: H. Peter Anvin <>
Cc: Bernhard M. Wiedemann <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoiommu/amd: Workaround for ERBT1312
Joerg Roedel [Thu, 18 Apr 2013 15:55:04 +0000 (17:55 +0200)]
iommu/amd: Workaround for ERBT1312

commit d3263bc29706e42f74d8800807c2dedf320d77f1 upstream.

Work around an IOMMU  hardware bug where clearing the
EVT_INT or PPR_INT bit in the status register may race with
the hardware trying to set it again. When not handled the
bit might not be cleared and we lose all future event or ppr

Reported-by: Suravee Suthikulpanit <>
Signed-off-by: Joerg Roedel <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoiommu/amd: Re-enable IOMMU event log interrupt after handling.
Suravee Suthikulpanit [Wed, 27 Mar 2013 23:51:52 +0000 (18:51 -0500)]
iommu/amd: Re-enable IOMMU event log interrupt after handling.

commit 925fe08bce38d1ff052fe2209b9e2b8d5fbb7f98 upstream.

Current driver does not clear the IOMMU event log interrupt bit
in the IOMMU status register after processing an interrupt.
This causes the IOMMU hardware to generate event log interrupt only once.
This has been observed in both IOMMU v1 and V2 hardware.
This patch clears the bit by writing 1 to bit 1 of the IOMMU
status register (MMIO Offset 2020h)

Signed-off-by: Suravee Suthikulpanit <>
Signed-off-by: Joerg Roedel <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxen-netback: remove skb in xen_netbk_alloc_page
Wei Liu [Mon, 25 Mar 2013 01:08:20 +0000 (01:08 +0000)]
xen-netback: remove skb in xen_netbk_alloc_page

commit 27f852282ab9a028f57da96d05c26f38c424a315 upstream.

This variable is never used.

Signed-off-by: Wei Liu <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agojfs: fix a couple races
Dave Kleikamp [Wed, 1 May 2013 16:08:38 +0000 (11:08 -0500)]
jfs: fix a couple races

commit 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271 upstream.

This patch fixes races uncovered by xfstests testcase 068.

One race is the result of jfs_sync() trying to write a sync point to the
journal after it has been frozen (or possibly in the process). Since
freezing sync's the journal, there is no need to write a sync point so
we simply want to return.

The second involves jfs_write_inode() being called on a deleted inode.
It calls jfs_flush_journal which is held up by the jfs_commit thread
doing the final iput on the same deleted inode, which itself is
waiting for the I_SYNC flag to be cleared. jfs_write_inode need not
do anything when i_nlink is zero, which is the easy fix.

Reported-by: Michael L. Semon <>
Signed-off-by: Dave Kleikamp <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxen/events: Handle VIRQ_TIMER before any other hardirq in event loop.
Keir Fraser [Thu, 28 Mar 2013 14:03:36 +0000 (10:03 -0400)]
xen/events: Handle VIRQ_TIMER before any other hardirq in event loop.

commit bee980d9e9642e96351fa3ca9077b853ecf62f57 upstream.

This avoids any other hardirq handler seeing a very stale jiffies
value immediately after wakeup from a long idle period. The one
observable symptom of this was a USB keyboard, with software keyboard
repeat, which would always repeat a key immediately that it was
pressed. This is due to the key press waking the guest, the key
handler immediately runs, sees an old jiffies value, and then that
jiffies value significantly updated, before the key is unpressed.

Reviewed-by: David Vrabel <>
Signed-off-by: Keir Fraser <>
Signed-off-by: Konrad Rzeszutek Wilk <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agom68k/mac: Fix unexpected interrupt with CONFIG_EARLY_PRINTK
Finn Thain [Wed, 29 May 2013 02:37:17 +0000 (12:37 +1000)]
m68k/mac: Fix unexpected interrupt with CONFIG_EARLY_PRINTK

commit df66834a43c461de2565c45d815288ba1c0def37 upstream.

The present code does not wait for the SCC to finish resetting itself
before trying to initialise the device. The result is that the SCC
interrupt sources become enabled (if they weren't already). This leads to
an early boot crash (unexpected interrupt) given CONFIG_EARLY_PRINTK. Fix
this by adding a delay. A successful reset disables the interrupt sources.

Also, after the reset for channel A setup, the SCC then gets a second
reset for channel B setup which leaves channel A uninitialised again. Fix
this by performing the reset only once.

Signed-off-by: Finn Thain <>
Signed-off-by: Geert Uytterhoeven <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agolibata: make ata_exec_internal_sg honor DMADIR
Vincent Pelletier [Sat, 18 May 2013 16:44:04 +0000 (18:44 +0200)]
libata: make ata_exec_internal_sg honor DMADIR

commit e771451c0a831d96a7c14b0ca8a8ec671d98567b upstream.

libata honors DMADIR for regular commands, but not for internal commands
used (among other) during device initialisation.

This makes SATA-host-to-PATA-device bridges based on Silicon Image SiL3611
(such as "Abit Serillel 2") end up disabled when used with an ATAPI device
after a few tries.

Log output of the bridge being hot-plugged with an ATAPI drive:

  [ 9631.212901] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
  [ 9631.212913] ata1: irq_stat 0x00000040, connection status changed
  [ 9631.212923] ata1: SError: { CommWake 10B8B DevExch }
  [ 9631.212939] ata1: hard resetting link
  [ 9632.104962] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  [ 9632.106393] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33
  [ 9632.106407] ata1.00: applying bridge limits
  [ 9632.108151] ata1.00: configured for UDMA/33
  [ 9637.105303] ata1.00: qc timeout (cmd 0xa0)
  [ 9637.105324] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
  [ 9637.105335] ata1: hard resetting link
  [ 9638.044599] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  [ 9638.047878] ata1.00: configured for UDMA/33
  [ 9643.044933] ata1.00: qc timeout (cmd 0xa0)
  [ 9643.044953] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
  [ 9643.044963] ata1: limiting SATA link speed to 1.5 Gbps
  [ 9643.044971] ata1.00: limiting speed to UDMA/33:PIO3
  [ 9643.044979] ata1: hard resetting link
  [ 9643.984225] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
  [ 9643.987471] ata1.00: configured for UDMA/33
  [ 9648.984591] ata1.00: qc timeout (cmd 0xa0)
  [ 9648.984612] ata1.00: failed to clear UNIT ATTENTION (err_mask=0x5)
  [ 9648.984619] ata1.00: disabled
  [ 9649.000593] ata1: hard resetting link
  [ 9649.939902] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
  [ 9649.955864] ata1: EH complete

With this patch, the drive enumerates correctly when libata is loaded with

  [ 9891.810863] ata1: exception Emask 0x10 SAct 0x0 SErr 0x40c0000 action 0xe frozen
  [ 9891.810874] ata1: irq_stat 0x00000040, connection status changed
  [ 9891.810884] ata1: SError: { CommWake 10B8B DevExch }
  [ 9891.810900] ata1: hard resetting link
  [ 9892.762105] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
  [ 9892.763544] ata1.00: ATAPI: PIONEER DVD-RW  DVR-115, 1.06, max UDMA/33, DMADIR
  [ 9892.763558] ata1.00: applying bridge limits
  [ 9892.765393] ata1.00: configured for UDMA/33
  [ 9892.786063] ata1: EH complete
  [ 9892.792062] scsi 0:0:0:0: CD-ROM            PIONEER  DVD-RW  DVR-115  1.06 PQ: 0 ANSI: 5
  [ 9892.798455] sr2: scsi3-mmc drive: 12x/12x writer dvd-ram cd/rw xa/form2 cdda tray
  [ 9892.798837] sr 0:0:0:0: Attached scsi CD-ROM sr2
  [ 9892.799109] sr 0:0:0:0: Attached scsi generic sg6 type 5

Based on a patch by Csaba Halász <> on linux-ide:

tj: minor formatting changes.

Signed-off-by: Vincent Pelletier <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoata_piix: add PCI IDs for Intel BayTail
Chew, Chiau Ee [Thu, 16 May 2013 07:33:29 +0000 (15:33 +0800)]
ata_piix: add PCI IDs for Intel BayTail

commit fca8c90d519dedd4f4b19901d005c243f7f0bf2e upstream.

Adds IDE-mode SATA Device IDs for the Intel BayTrail platform.

Signed-off-by: Chew, Chiau Ee <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: io_ti: Fix NULL dereference in chase_port()
Wolfgang Frisch [Thu, 17 Jan 2013 00:07:02 +0000 (01:07 +0100)]
USB: io_ti: Fix NULL dereference in chase_port()

commit 1ee0a224bc9aad1de496c795f96bc6ba2c394811 upstream.

The tty is NULL when the port is hanging up.
chase_port() needs to check for this.

This patch is intended for stable series.
The behavior was observed and tested in Linux 3.2 and 3.7.1.

Johan Hovold submitted a more elaborate patch for the mainline kernel.

[   56.277883] usb 1-1: edge_bulk_in_callback - nonzero read bulk status received: -84
[   56.278811] usb 1-1: USB disconnect, device number 3
[   56.278856] usb 1-1: edge_bulk_in_callback - stopping read!
[   56.279562] BUG: unable to handle kernel NULL pointer dereference at 00000000000001c8
[   56.280536] IP: [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35
[   56.281212] PGD 1dc1b067 PUD 1e0f7067 PMD 0
[   56.282085] Oops: 0002 [#1] SMP
[   56.282744] Modules linked in:
[   56.283512] CPU 1
[   56.283512] Pid: 25, comm: khubd Not tainted 3.7.1 #1 innotek GmbH VirtualBox/VirtualBox
[   56.283512] RIP: 0010:[<ffffffff8144e62a>]  [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35
[   56.283512] RSP: 0018:ffff88001fa99ab0  EFLAGS: 00010046
[   56.283512] RAX: 0000000000000046 RBX: 00000000000001c8 RCX: 0000000000640064
[   56.283512] RDX: 0000000000010000 RSI: ffff88001fa99b20 RDI: 00000000000001c8
[   56.283512] RBP: ffff88001fa99b20 R08: 0000000000000000 R09: 0000000000000000
[   56.283512] R10: 0000000000000000 R11: ffffffff812fcb4c R12: ffff88001ddf53c0
[   56.283512] R13: 0000000000000000 R14: 00000000000001c8 R15: ffff88001e19b9f4
[   56.283512] FS:  0000000000000000(0000) GS:ffff88001fd00000(0000) knlGS:0000000000000000
[   56.283512] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[   56.283512] CR2: 00000000000001c8 CR3: 000000001dc51000 CR4: 00000000000006e0
[   56.283512] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   56.283512] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[   56.283512] Process khubd (pid: 25, threadinfo ffff88001fa98000, task ffff88001fa94f80)
[   56.283512] Stack:
[   56.283512]  0000000000000046 00000000000001c8 ffffffff810578ec ffffffff812fcb4c
[   56.283512]  ffff88001e19b980 0000000000002710 ffffffff812ffe81 0000000000000001
[   56.283512]  ffff88001fa94f80 0000000000000202 ffffffff00000001 0000000000000296
[   56.283512] Call Trace:
[   56.283512]  [<ffffffff810578ec>] ? add_wait_queue+0x12/0x3c
[   56.283512]  [<ffffffff812fcb4c>] ? usb_serial_port_work+0x28/0x28
[   56.283512]  [<ffffffff812ffe81>] ? chase_port+0x84/0x2d6
[   56.283512]  [<ffffffff81063f27>] ? try_to_wake_up+0x199/0x199
[   56.283512]  [<ffffffff81263a5c>] ? tty_ldisc_hangup+0x222/0x298
[   56.283512]  [<ffffffff81300171>] ? edge_close+0x64/0x129
[   56.283512]  [<ffffffff810612f7>] ? __wake_up+0x35/0x46
[   56.283512]  [<ffffffff8106135b>] ? should_resched+0x5/0x23
[   56.283512]  [<ffffffff81264916>] ? tty_port_shutdown+0x39/0x44
[   56.283512]  [<ffffffff812fcb4c>] ? usb_serial_port_work+0x28/0x28
[   56.283512]  [<ffffffff8125d38c>] ? __tty_hangup+0x307/0x351
[   56.283512]  [<ffffffff812e6ddc>] ? usb_hcd_flush_endpoint+0xde/0xed
[   56.283512]  [<ffffffff8144e625>] ? _raw_spin_lock_irqsave+0x14/0x35
[   56.283512]  [<ffffffff812fd361>] ? usb_serial_disconnect+0x57/0xc2
[   56.283512]  [<ffffffff812ea99b>] ? usb_unbind_interface+0x5c/0x131
[   56.283512]  [<ffffffff8128d738>] ? __device_release_driver+0x7f/0xd5
[   56.283512]  [<ffffffff8128d9cd>] ? device_release_driver+0x1a/0x25
[   56.283512]  [<ffffffff8128d393>] ? bus_remove_device+0xd2/0xe7
[   56.283512]  [<ffffffff8128b7a3>] ? device_del+0x119/0x167
[   56.283512]  [<ffffffff812e8d9d>] ? usb_disable_device+0x6a/0x180
[   56.283512]  [<ffffffff812e2ae0>] ? usb_disconnect+0x81/0xe6
[   56.283512]  [<ffffffff812e4435>] ? hub_thread+0x577/0xe82
[   56.283512]  [<ffffffff8144daa7>] ? __schedule+0x490/0x4be
[   56.283512]  [<ffffffff8105798f>] ? abort_exclusive_wait+0x79/0x79
[   56.283512]  [<ffffffff812e3ebe>] ? usb_remote_wakeup+0x2f/0x2f
[   56.283512]  [<ffffffff812e3ebe>] ? usb_remote_wakeup+0x2f/0x2f
[   56.283512]  [<ffffffff810570b4>] ? kthread+0x81/0x89
[   56.283512]  [<ffffffff81057033>] ? __kthread_parkme+0x5c/0x5c
[   56.283512]  [<ffffffff8145387c>] ? ret_from_fork+0x7c/0xb0
[   56.283512]  [<ffffffff81057033>] ? __kthread_parkme+0x5c/0x5c
[   56.283512] Code: 8b 7c 24 08 e8 17 0b c3 ff 48 8b 04 24 48 83 c4 10 c3 53 48 89 fb 41 50 e8 e0 0a c3 ff 48 89 04 24 e8 e7 0a c3 ff ba 00 00 01 00
<f0> 0f c1 13 48 8b 04 24 89 d1 c1 ea 10 66 39 d1 74 07 f3 90 66
[   56.283512] RIP  [<ffffffff8144e62a>] _raw_spin_lock_irqsave+0x19/0x35
[   56.283512]  RSP <ffff88001fa99ab0>
[   56.283512] CR2: 00000000000001c8
[   56.283512] ---[ end trace 49714df27e1679ce ]---

Signed-off-by: Wolfgang Frisch <>
Cc: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocifs: fix potential buffer overrun when composing a new options string
Jeff Layton [Fri, 24 May 2013 11:40:04 +0000 (07:40 -0400)]
cifs: fix potential buffer overrun when composing a new options string

commit 166faf21bd14bc5c5295a44874bf7f3930c30b20 upstream.

Consider the case where we have a very short ip= string in the original
mount options, and when we chase a referral we end up with a very long
IPv6 address. Be sure to allow for that possibility when estimating the
size of the string to allocate.

Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/radeon: fix card_posted check for newer asics
Alex Deucher [Wed, 22 May 2013 15:22:51 +0000 (11:22 -0400)]
drm/radeon: fix card_posted check for newer asics

commit 09fb8bd1a63b0f9f15e655c4fe8d047e5d2bf67a upstream.

Newer asics have variable numbers of crtcs.  Use that
rather than the asic family to determine which crtcs
to check.  This avoids checking non-existent crtcs or
missing crtcs on certain asics.

Reviewed-by: Michel Dänzer <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoxfs: kill suid/sgid through the truncate path.
Dave Chinner [Mon, 27 May 2013 06:38:25 +0000 (16:38 +1000)]
xfs: kill suid/sgid through the truncate path.

commit 2962f5a5dcc56f69cbf62121a7be67cc15d6940b upstream.

XFS has failed to kill suid/sgid bits correctly when truncating
files of non-zero size since commit c4ed4243 ("xfs: split
xfs_setattr") introduced in the 3.1 kernel. Fix it.

Fix it.

Signed-off-by: Dave Chinner <>
Reviewed-by: Brian Foster <>
Signed-off-by: Ben Myers <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoNFSv4: Fix a thinko in nfs4_try_open_cached
Trond Myklebust [Wed, 29 May 2013 19:36:40 +0000 (15:36 -0400)]
NFSv4: Fix a thinko in nfs4_try_open_cached

commit f448badd34700ae728a32ba024249626d49c10e1 upstream.

We need to pass the full open mode flags to nfs_may_open() when doing
a delegated open.

Signed-off-by: Trond Myklebust <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoiscsi-target: fix heap buffer overflow on error
Kees Cook [Thu, 23 May 2013 17:32:17 +0000 (10:32 -0700)]
iscsi-target: fix heap buffer overflow on error

commit cea4dcfdad926a27a18e188720efe0f2c9403456 upstream.

If a key was larger than 64 bytes, as checked by iscsi_check_key(), the
error response packet, generated by iscsi_add_notunderstood_response(),
would still attempt to copy the entire key into the packet, overflowing
the structure on the heap.

Remote preauthentication kernel memory corruption was possible if a
target was configured and listening on the network.


Signed-off-by: Kees Cook <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomm/THP: use pmd_populate() to update the pmd with pgtable_t pointer
Aneesh Kumar K.V [Fri, 24 May 2013 22:55:21 +0000 (15:55 -0700)]
mm/THP: use pmd_populate() to update the pmd with pgtable_t pointer

commit 7c3425123ddfdc5f48e7913ff59d908789712b18 upstream.

We should not use set_pmd_at to update pmd_t with pgtable_t pointer.
set_pmd_at is used to set pmd with huge pte entries and architectures
like ppc64, clear few flags from the pte when saving a new entry.
Without this change we observe bad pte errors like below on ppc64 with
THP enabled.

  BUG: Bad page map in process ld mm=0xc000001ee39f4780 pte:7fc3f37848000001 pmd:c000001ec0000000

Signed-off-by: Aneesh Kumar K.V <>
Cc: Hugh Dickins <>
Cc: Benjamin Herrenschmidt <>
Reviewed-by: Andrea Arcangeli <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas
Cliff Wickman [Fri, 24 May 2013 22:55:36 +0000 (15:55 -0700)]
mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas

commit a9ff785e4437c83d2179161e012f5bdfbd6381f0 upstream.

A panic can be caused by simply cat'ing /proc/<pid>/smaps while an
application has a VM_PFNMAP range.  It happened in-house when a
benchmarker was trying to decipher the memory layout of his program.

/proc/<pid>/smaps and similar walks through a user page table should not
be looking at VM_PFNMAP areas.

Certain tests in walk_page_range() (specifically split_huge_page_pmd())
assume that all the mapped PFN's are backed with page structures.  And
this is not usually true for VM_PFNMAP areas.  This can result in panics
on kernel page faults when attempting to address those page structures.

There are a half dozen callers of walk_page_range() that walk through a
task's entire page table (as N.  Horiguchi pointed out).  So rather than
change all of them, this patch changes just walk_page_range() to ignore
VM_PFNMAP areas.

The logic of hugetlb_vma() is moved back into walk_page_range(), as we
want to test any vma in the range.

VM_PFNMAP areas are used by:
- graphics memory manager   gpu/drm/drm_gem.c
- global reference unit     sgi-gru/grufile.c
- sgi special memory        char/mspec.c
- and probably several out-of-tree modules

[ remove now-unused hugetlb_vma() stub]
Signed-off-by: Cliff Wickman <>
Reviewed-by: Naoya Horiguchi <>
Cc: Mel Gorman <>
Cc: Andrea Arcangeli <>
Cc: Dave Hansen <>
Cc: David Sterba <>
Cc: Johannes Weiner <>
Cc: KOSAKI Motohiro <>
Cc: "Kirill A. Shutemov" <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrivers/block/brd.c: fix brd_lookup_page() race
Brian Behlendorf [Fri, 24 May 2013 22:55:28 +0000 (15:55 -0700)]
drivers/block/brd.c: fix brd_lookup_page() race

commit dfd20b2b174d3a9b258ea3b7a35ead33576587b1 upstream.

The index on the page must be set before it is inserted in the radix
tree.  Otherwise there is a small race which can occur during lookup
where the page can be found with the incorrect index.  This will trigger
the BUG_ON() in brd_lookup_page().

Signed-off-by: Brian Behlendorf <>
Reported-by: Chris Wedgwood <>
Cc: Jens Axboe <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomm: mmu_notifier: re-fix freed page still mapped in secondary MMU
Xiao Guangrong [Fri, 24 May 2013 22:55:11 +0000 (15:55 -0700)]
mm: mmu_notifier: re-fix freed page still mapped in secondary MMU

commit d34883d4e35c0a994e91dd847a82b4c9e0c31d83 upstream.

Commit 751efd8610d3 ("mmu_notifier_unregister NULL Pointer deref and
multiple ->release()") breaks the fix 3ad3d901bbcf ("mm: mmu_notifier:
fix freed page still mapped in secondary MMU").

Since hlist_for_each_entry_rcu() is changed now, we can not revert that
patch directly, so this patch reverts the commit and simply fix the bug
spotted by that patch

This bug spotted by commit 751efd8610d3 is:

    There is a race condition between mmu_notifier_unregister() and

    Assume two tasks, one calling mmu_notifier_unregister() as a result
    of a filp_close() ->flush() callout (task A), and the other calling
    mmu_notifier_release() from an mmput() (task B).

                        A                               B
    t1                                            srcu_read_lock()
    t2            if (!hlist_unhashed())
    t3                                            srcu_read_unlock()
    t4            srcu_read_lock()
    t5                                            hlist_del_init_rcu()
    t6                                            synchronize_srcu()
    t7            srcu_read_unlock()
    t8            hlist_del_rcu()  <--- NULL pointer deref.

This can be fixed by using hlist_del_init_rcu instead of hlist_del_rcu.

The another issue spotted in the commit is "multiple ->release()
callouts", we needn't care it too much because it is really rare (e.g,
can not happen on kvm since mmu-notify is unregistered after
exit_mmap()) and the later call of multiple ->release should be fast
since all the pages have already been released by the first call.
Anyway, this issue should be fixed in a separate patch.

-stable suggestions: Any version that has commit 751efd8610d3 need to be
backported.  I find the oldest version has this commit is 3.0-stable.

[ tweak comments]
Signed-off-by: Xiao Guangrong <>
Tested-by: Robin Holt <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agonilfs2: fix issue of nilfs_set_page_dirty() for page at EOF boundary
Ryusuke Konishi [Fri, 24 May 2013 22:55:29 +0000 (15:55 -0700)]
nilfs2: fix issue of nilfs_set_page_dirty() for page at EOF boundary

commit 136e8770cd5d1fe38b3c613100dd6dc4db6d4fa6 upstream.

nilfs2: fix issue of nilfs_set_page_dirty for page at EOF boundary

 There are use-cases when NILFS2 file system (formatted with block size
lesser than 4 KB) can be remounted in RO mode because of encountering of
"broken bmap" issue.

The issue was reported by Anthony Doggett <>:
 "The machine I've been trialling nilfs on is running Debian Testing,
  Linux version 3.2.0-4-686-pae ( (gcc
  version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2), but I've
  also reproduced it (identically) with Debian Unstable amd64 and Debian
  Experimental (using the 3.8-trunk kernel).  The problematic partitions
  were formatted with "mkfs.nilfs2 -b 1024 -B 8192"."

(1) System log contains error messages likewise:

    [63102.496756] nilfs_direct_assign: invalid pointer: 0
    [63102.496786] NILFS error (device dm-17): nilfs_bmap_assign: broken bmap (inode number=28)
    [63102.524403] Remounting filesystem read-only

(2) The NILFS2 file system is remounted in RO mode.

(1) Create volume group with name "unencrypted" by means of vgcreate utility.
(2) Run script (prepared by Anthony Doggett <>):

----------------[BEGIN SCRIPT]--------------------

lvcreate --size 2G --name ntest $VG
mkfs.nilfs2 -b 1024 -B 8192 /dev/mapper/$VG-ntest
mkdir /var/tmp/n
mkdir /var/tmp/n/ntest
mount /dev/mapper/$VG-ntest /var/tmp/n/ntest
mkdir /var/tmp/n/ntest/thedir
cd /var/tmp/n/ntest/thedir
sleep 2
darcs init
sleep 2
dmesg|tail -n 5
darcs whatsnew || true
sleep 2
dmesg|tail -n 5
----------------[END SCRIPT]--------------------


As it was discovered, the issue takes place during segment
construction after executing such sequence of user-space operations:

  open("_darcs/index", O_RDWR|O_CREAT|O_NOCTTY, 0666) = 7
  fstat(7, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
  ftruncate(7, 60)

The error message "NILFS error (device dm-17): nilfs_bmap_assign: broken
bmap (inode number=28)" takes place because of trying to get block
number for third block of the file with logical offset #3072 bytes.  As
it is possible to see from above output, the file has 60 bytes of the
whole size.  So, it is enough one block (1 KB in size) allocation for
the whole file.  Trying to operate with several blocks instead of one
takes place because of discovering several dirty buffers for this file
in nilfs_segctor_scan_file() method.

The root cause of this issue is in nilfs_set_page_dirty function which
is called just before writing to an mmapped page.

When nilfs_page_mkwrite function handles a page at EOF boundary, it
fills hole blocks only inside EOF through __block_page_mkwrite().

The __block_page_mkwrite() function calls set_page_dirty() after filling
hole blocks, thus nilfs_set_page_dirty function (=
a_ops->set_page_dirty) is called.  However, the current implementation
of nilfs_set_page_dirty() wrongly marks all buffers dirty even for page
at EOF boundary.

As a result, buffers outside EOF are inconsistently marked dirty and
queued for write even though they are not mapped with nilfs_get_block

This modifies nilfs_set_page_dirty() not to mark hole blocks dirty.

Thanks to Vyacheslav Dubeyko for his effort on analysis and proposals
for this issue.

Signed-off-by: Ryusuke Konishi <>
Reported-by: Anthony Doggett <>
Reported-by: Vyacheslav Dubeyko <>
Cc: Vyacheslav Dubeyko <>
Tested-by: Ryusuke Konishi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agowait: fix false timeouts when using wait_event_timeout()
Imre Deak [Fri, 24 May 2013 22:55:09 +0000 (15:55 -0700)]
wait: fix false timeouts when using wait_event_timeout()

commit 4c663cfc523a88d97a8309b04a089c27dc57fd7e upstream.

Many callers of the wait_event_timeout() and
wait_event_interruptible_timeout() expect that the return value will be
positive if the specified condition becomes true before the timeout
elapses.  However, at the moment this isn't guaranteed.  If the wake-up
handler is delayed enough, the time remaining until timeout will be
calculated as 0 - and passed back as a return value - even if the
condition became true before the timeout has passed.

Fix this by returning at least 1 if the condition becomes true.  This
semantic is in line with what wait_for_condition_timeout() does; see
commit bb10ed09 ("sched: fix wait_for_completion_timeout() spurious
failure under heavy load").

Daniel said "We have 3 instances of this bug in drm/i915.  One case even
where we switch between the interruptible and not interruptible
wait_event_timeout variants, foolishly presuming they have the same
semantics.  I very much like this."

One such bug is reported at

Signed-off-by: Imre Deak <>
Acked-by: Daniel Vetter <>
Acked-by: David Howells <>
Acked-by: Jens Axboe <>
Cc: "Paul E. McKenney" <>
Cc: Dave Jones <>
Cc: Lukas Czerner <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoklist: del waiter from klist_remove_waiters before wakeup waitting process
wang, biao [Thu, 16 May 2013 01:50:13 +0000 (09:50 +0800)]
klist: del waiter from klist_remove_waiters before wakeup waitting process

commit ac5a2962b02f57dea76d314ef2521a2170b28ab6 upstream.

There is a race between klist_remove and klist_release. klist_remove
uses a local var waiter saved on stack. When klist_release calls
wake_up_process(waiter->process) to wake up the waiter, waiter might run
immediately and reuse the stack. Then, klist_release calls
list_del(&waiter->list) to change previous
wait data and cause prior waiter thread corrupt.

The patch fixes it against kernel 3.9.

Signed-off-by: wang, biao <>
Acked-by: Peter Zijlstra <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agomm compaction: fix of improper cache flush in migration code
Leonid Yegoshin [Fri, 24 May 2013 22:55:18 +0000 (15:55 -0700)]
mm compaction: fix of improper cache flush in migration code

commit c2cc499c5bcf9040a738f49e8051b42078205748 upstream.

Page 'new' during MIGRATION can't be flushed with flush_cache_page().
Using flush_cache_page(vma, addr, pfn) is justified only if the page is
already placed in process page table, and that is done right after
flush_cache_page().  But without it the arch function has no knowledge
of process PTE and does nothing.

Besides that, flush_cache_page() flushes an application cache page, but
the kernel has a different page virtual address and dirtied it.

Replace it with flush_dcache_page(new) which is the proper usage.

The old page is flushed in try_to_unmap_one() before migration.

This bug takes place in Sead3 board with M14Kc MIPS CPU without cache
aliasing (but Harvard arch - separate I and D cache) in tight memory
environment (128MB) each 1-3days on SOAK test.  It fails in cc1 during
kernel build (SIGILL, SIGBUS, SIGSEG) if CONFIG_COMPACTION is switched

Signed-off-by: Leonid Yegoshin <>
Cc: Leonid Yegoshin <>
Acked-by: Rik van Riel <>
Cc: Michal Hocko <>
Acked-by: Mel Gorman <>
Cc: Ralf Baechle <>
Cc: Russell King <>
Cc: David Miller <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrivers/leds/leds-ot200.c: fix error caused by shifted mask
Christian Gmeiner [Fri, 24 May 2013 22:55:22 +0000 (15:55 -0700)]
drivers/leds/leds-ot200.c: fix error caused by shifted mask

commit 4b949b8af12e24b8a48fa5bb775a13b558d9f4da upstream.

During the development of this driver an in-house register documentation
was used.  The last week some integration tests were done and this
problem was found.  It turned out that the released register
documentation is wrong.

The fix is very simple: shift all masks by one.

Signed-off-by: Christian Gmeiner <>
Cc: Bryan Wu <>
Cc: Sebastian Andrzej Siewior <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoKirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x
Martin Michlmayr [Sun, 21 Apr 2013 16:14:00 +0000 (17:14 +0100)]
Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x

commit 99e11334dcb846f9b76fb808196c7f47aa83abb3 upstream.

Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
(rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
to Marek Vasut for identifying this issue!

Signed-off-by: Martin Michlmayr <>
Tested-by: Marek Vasut <>
Acked-by: Andrew Lunn <>
Signed-off-by: Jason Cooper <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoocfs2: goto out_unlock if ocfs2_get_clusters_nocache() failed in ocfs2_fiemap()
Joseph Qi [Fri, 24 May 2013 22:55:34 +0000 (15:55 -0700)]
ocfs2: goto out_unlock if ocfs2_get_clusters_nocache() failed in ocfs2_fiemap()

commit b4ca2b4b577c3530e34dcfaafccb2cc680ce95d1 upstream.

Last time we found there is lock/unlock bug in ocfs2_file_aio_write, and
then we did a thorough search for all lock resources in
ocfs2_inode_info, including rw, inode and open lockres and found this
bug.  My kernel version is 3.0.13, and it is also in the lastest version
3.9.  In ocfs2_fiemap, once ocfs2_get_clusters_nocache failed, it should
goto out_unlock instead of out, because we need release buffer head, up
read alloc sem and unlock inode.

Signed-off-by: Joseph Qi <>
Reviewed-by: Jie Liu <>
Cc: Mark Fasheh <>
Cc: Joel Becker <>
Acked-by: Sunil Mushran <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoperf: net_dropmonitor: Fix symbol-relative addresses
Ben Hutchings [Mon, 20 May 2013 14:45:26 +0000 (14:45 +0000)]
perf: net_dropmonitor: Fix symbol-relative addresses

commit 5a1e99dd2028e00998d42029be86835d8ef4a46e upstream.

The comparison between traced and symbol addresses is backwards: if
the traced address doesn't exactly match a symbol (which we don't
expect it to), we'll show the next symbol and the offset to it,
whereas we should show the previous symbol and the offset from it.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoperf: net_dropmonitor: Fix trace parameter order
Ben Hutchings [Mon, 20 May 2013 14:44:43 +0000 (14:44 +0000)]
perf: net_dropmonitor: Fix trace parameter order

commit 140c3c6a2bcd2c31e2f7f5a8d59689724776c8e5 upstream.

This works much better if we don't treat protocol numbers as addresses.

Signed-off-by: Ben Hutchings <>
Signed-off-by: David S. Miller <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agofat: fix possible overflow for fat_clusters
OGAWA Hirofumi [Fri, 24 May 2013 22:55:08 +0000 (15:55 -0700)]
fat: fix possible overflow for fat_clusters

commit 7b92d03c3239f43e5b86c9cc9630f026d36ee995 upstream.

Intermediate value of fat_clusters can be overflowed on 32bits arch.

Reported-by: Krzysztof Strasburger <>
Signed-off-by: OGAWA Hirofumi <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agocifs: only set ops for inodes in I_NEW state
Jeff Layton [Tue, 7 May 2013 15:28:31 +0000 (11:28 -0400)]
cifs: only set ops for inodes in I_NEW state

commit c2b93e0699723700f886ce17bb65ffd771195a6d upstream.

It's generally not safe to reset the inode ops once they've been set. In
the case where the inode was originally thought to be a directory and
then later found to be a DFS referral, this can lead to an oops when we
try to trigger an inode op on it after changing the ops to the blank
referral operations.

Reported-and-Tested-by: Sachin Prabhu <>
Signed-off-by: Jeff Layton <>
Signed-off-by: Steve French <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: UHCI: fix for suspend of virtual HP controller
Alan Stern [Tue, 14 May 2013 17:55:29 +0000 (13:55 -0400)]
USB: UHCI: fix for suspend of virtual HP controller

commit 997ff893603c6455da4c5e26ba1d0f81adfecdfc upstream.

HP's virtual UHCI host controller takes a long time to suspend
(several hundred microseconds), even when no devices are attached.
This provokes a warning message from uhci-hcd in the auto-stop case.

To prevent this from happening, this patch adds a test to avoid
performing an auto-stop when the wait_for_hp quirk flag is set.  The
controller will still suspend through the normal runtime PM mechanism.
And since that pathway includes a 1-ms delay, the slowness of the
virtual hardware won't matter.

Signed-off-by: Alan Stern <>
Reported-and-tested-by: ZhenHua <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: xHCI: override bogus bulk wMaxPacketSize values
Alan Stern [Wed, 8 May 2013 15:18:05 +0000 (11:18 -0400)]
USB: xHCI: override bogus bulk wMaxPacketSize values

commit e4f47e3675e6f1f40906b785b934ce963e9f2eb3 upstream.

This patch shortens the logic in xhci_endpoint_init() by moving common
calculations involving max_packet and max_burst outside the switch
statement, rather than repeating the same code in multiple
case-specific statements.  It also replaces two usages of max_packet
which were clearly intended to be max_burst all along.

More importantly, it compensates for a common bug in high-speed bulk
endpoint descriptors.  In many devices there is a bulk endpoint having
a wMaxPacketSize value smaller than 512, which is forbidden by the USB
spec.  Some xHCI controllers can't handle this and refuse to accept
the endpoint.  This patch changes the max_packet value to 512, which
allows the controller to use the endpoint properly.

In practice the bogus maxpacket size doesn't matter, because none of
the transfers sent via these endpoints are longer than the maxpacket
value anyway.

Signed-off-by: Alan Stern <>
Reported-and-tested-by: "Aurélien Leblond" <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: reset resume quirk needed by a hub
Oliver Neukum [Tue, 30 Apr 2013 08:18:04 +0000 (10:18 +0200)]
USB: reset resume quirk needed by a hub

commit bac6b03275184c912ad0818c9a0a736847804dca upstream.

Werner Fink has reported problems with this hub.

Signed-off-by: Oliver Neukum <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: Blacklisted Cinterion's PLxx WWAN Interface
Schemmel Hans-Christoph [Mon, 6 May 2013 09:05:12 +0000 (11:05 +0200)]
USB: Blacklisted Cinterion's PLxx WWAN Interface

commit 8ff10bdb14a52e3f25d4ce09e0582a8684c1a6db upstream.

/drivers/usb/serial/option.c: Blacklisted Cinterion's PLxx WWAN
Interface (USB Interface 4), because it will be handled by QMI WWAN
driver. Product IDs renamed.

Signed-off-by: Hans-Christoph Schemmel <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoTTY: Fix tty miss restart after we turn off flow-control
Wang YanQing [Thu, 9 May 2013 06:16:47 +0000 (14:16 +0800)]
TTY: Fix tty miss restart after we turn off flow-control

commit dab73b4eb9ef924a2b90dab84e539076d82b256f upstream.

I meet emacs hang in start if I do the operation below:
  1: echo 3 > /proc/sys/vm/drop_caches
  2: emacs BigFile
  3: Press CTRL-S follow 2 immediately

Then emacs hang on, CTRL-Q can't resume, the terminal
hang on, you can do nothing with this terminal except
close it.

The reason is before emacs takeover control the tty,
we use CTRL-S to XOFF it. Then when emacs takeover the
control, it may don't use the flow-control, so emacs hang.
This patch fix it.

This patch will fix a kind of strange tty relation hang problem,
I believe I meet it with vim in ssh, and also see below bug report:

Signed-off-by: Wang YanQing <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: cxacru: potential underflow in cxacru_cm_get_array()
Dan Carpenter [Sun, 19 May 2013 18:52:20 +0000 (21:52 +0300)]
USB: cxacru: potential underflow in cxacru_cm_get_array()

commit 2a0ebf80aa95cc758d4725f74a7016e992606a39 upstream.

The value of "offd" comes off the instance->rcv_buf[] and we used it as
the offset into an array.  The problem is that we check the upper bound
but not for negative values.

Signed-off-by: Dan Carpenter <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: ftdi_sio: Add support for Newport CONEX motor drivers
Gomella, Andrew (NIH/NHLBI) [F] [Fri, 17 May 2013 17:39:46 +0000 (17:39 +0000)]
USB: ftdi_sio: Add support for Newport CONEX motor drivers

commit 7138143972b7c293267c783fc99a194f0ceff7f2 upstream.

Here are two more devices that use FTDI USB-to-serial chips with new product ID's.

The devices are the Newport Conex-AGP and Conex-CC motor controllers.

usb-devices command yields:

P:  Vendor=104d ProdID=3002 Rev=06.00
S:  Manufacturer=Newport
S:  Product=CONEX-CC

as well as

P:  Vendor=104d ProdID=3006 Rev=06.00
S:  Manufacturer=Newport
S:  Product=CONEX-AGP

Signed-off-by: Andrew Gomella <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoUSB: option: add device IDs for Dell 5804 (Novatel E371) WWAN card
Dan Williams [Mon, 6 May 2013 21:16:44 +0000 (16:16 -0500)]
USB: option: add device IDs for Dell 5804 (Novatel E371) WWAN card

commit 49c6e370dd6400b84897c4100095089b5c13a061 upstream.

A rebranded Novatel E371 for AT&T's LTE bands.

Signed-off-by: Dan Williams <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agousb: option: Add Telewell TW-LTE 4G
Teppo Kotilainen [Fri, 3 May 2013 07:28:12 +0000 (10:28 +0300)]
usb: option: Add Telewell TW-LTE 4G

commit 73c042df6e1bc50544842a04b777b36bbe3630e6 upstream.

Information from driver description files:

  diag:  VID_19D2&PID_0412&MI_00
  nmea:  VID_19D2&PID_0412&MI_01
  at:    VID_19D2&PID_0412&MI_02
  modem: VID_19D2&PID_0412&MI_03
  net:   VID_19D2&PID_0412&MI_04

Signed-off-by: Teppo Kotilainen <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agostaging: vt6656: use free_netdev instead of kfree
Hema Prathaban [Sat, 11 May 2013 17:09:47 +0000 (22:39 +0530)]
staging: vt6656: use free_netdev instead of kfree

commit 0a438d5b381e2bdfd5e02d653bf46fcc878356e3 upstream.

use free_netdev() instead of kfree(pDevice->apdev)

Signed-off-by: Hema Prathaban <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoARM: plat-orion: Fix num_resources and id for ge10 and ge11
Gregory CLEMENT [Sun, 19 May 2013 20:12:43 +0000 (22:12 +0200)]
ARM: plat-orion: Fix num_resources and id for ge10 and ge11

commit 2b8b2797142c7951e635c6eec5d1705ee9bc45c5 upstream.

When platform data were moved from arch/arm/mach-mv78xx0/common.c to
arch/arm/plat-orion/common.c with the commit "7e3819d ARM: orion:
Consolidate ethernet platform data", there were few typo made on
gigabit Ethernet interface ge10 and ge11. This commit writes back
their initial value, which allows to use this interfaces again.

Signed-off-by: Gregory CLEMENT <>
Acked-by: Andrew Lunn <>
Signed-off-by: Jason Cooper <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoavr32: fix relocation check for signed 18-bit offset
Hans-Christian Egtvedt [Mon, 13 May 2013 20:22:10 +0000 (22:22 +0200)]
avr32: fix relocation check for signed 18-bit offset

commit e68c636d88db3fda74e664ecb1a213ae0d50a7d8 upstream.

Caught by static code analysis by David.

Reported-by: David Binderman <>
Signed-off-by: Hans-Christian Egtvedt <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoLinux 3.4.47
Greg Kroah-Hartman [Fri, 24 May 2013 18:14:41 +0000 (11:14 -0700)]
Linux 3.4.47

4 years agomedia: mantis: fix silly crash case
Alan Cox [Thu, 9 Aug 2012 15:33:52 +0000 (12:33 -0300)]
media: mantis: fix silly crash case

commit e1d45ae10aea8e8a403e5d96bf5902ee670007ff upstream.

If we set mantis->fe to NULL on an error its not a good idea to then try
passing NULL to the unregister paths and oopsing really.


Signed-off-by: Alan Cox <>
Signed-off-by: Mauro Carvalho Chehab <>
Cc: Bjørn Mork <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/radeon: Fix VRAM size calculation for VRAM >= 4GB
Niels Ole Salscheider [Sat, 18 May 2013 19:19:23 +0000 (21:19 +0200)]
drm/radeon: Fix VRAM size calculation for VRAM >= 4GB

commit fc986034540102cd090237bf3f70262e1ae80d9c upstream.

Add ULL prefix to avoid overflow.

Signed-off-by: Niels Ole Salscheider <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoi2c: designware: always clear interrupts before enabling them
Mika Westerberg [Mon, 13 May 2013 00:54:30 +0000 (00:54 +0000)]
i2c: designware: always clear interrupts before enabling them

commit 2a2d95e9d6d29e726cc294b65391917ed2e32bf4 upstream.

If the I2C bus is put to a low power state by an ACPI method it might pull
the SDA line low (as its power is removed). Once the bus is put to full
power state again, the SDA line is pulled back to high. This transition
looks like a STOP condition from the controller point-of-view which sets
STOP detected bit in its status register causing the driver to fail
subsequent transfers.

Fix this by always clearing all interrupts before we start a transfer.

Signed-off-by: Mika Westerberg <>
Signed-off-by: Wolfram Sang <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agohwmon: fix error return code in abituguru_probe()
Wei Yongjun [Mon, 13 May 2013 06:01:43 +0000 (14:01 +0800)]
hwmon: fix error return code in abituguru_probe()

commit ecacb0b17c08fae89f65468727f0e4b8e91da4e1 upstream.

Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <>
Signed-off-by: Guenter Roeck <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agobtrfs: don't stop searching after encountering the wrong item
Gabriel de Perthuis [Mon, 6 May 2013 17:40:18 +0000 (17:40 +0000)]
btrfs: don't stop searching after encountering the wrong item

commit 03b71c6ca6286625d8f1ed44aabab9b5bf5dac10 upstream.

The search ioctl skips items that are too large for a result buffer, but
inline items of a certain size occuring before any search result is
found would trigger an overflow and stop the search entirely.


Signed-off-by: Gabriel de Perthuis <>
Signed-off-by: Josef Bacik <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoLinux 3.4.46
Greg Kroah-Hartman [Sun, 19 May 2013 17:58:34 +0000 (10:58 -0700)]
Linux 3.4.46

4 years agousermodehelper: check subprocess_info->path != NULL
Oleg Nesterov [Thu, 16 May 2013 15:43:55 +0000 (17:43 +0200)]
usermodehelper: check subprocess_info->path != NULL

commit 264b83c07a84223f0efd0d1db9ccc66d6f88288f upstream.

argv_split(empty_or_all_spaces) happily succeeds, it simply returns
argc == 0 and argv[0] == NULL. Change call_usermodehelper_exec() to
check sub_info->path != NULL to avoid the crash.

This is the minimal fix, todo:

 - perhaps we should change argv_split() to return NULL or change the

 - kill or justify ->path[0] check

 - narrow the scope of helper_lock()

Signed-off-by: Oleg Nesterov <>
Acked-By: Lucas De Marchi <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrm/radeon: check incoming cliprects pointer
Kees Cook [Mon, 13 May 2013 05:00:51 +0000 (22:00 -0700)]
drm/radeon: check incoming cliprects pointer

commit fefaedcfb82d2e57c2320acf60604ab03b750cc0 upstream.

The "boxes" parameter points into userspace memory. It should be verified
like any other operation against user memory.

Signed-off-by: Kees Cook <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex
Benjamin LaHaise [Thu, 16 May 2013 19:04:27 +0000 (14:04 -0500)]
ipmi: ipmi_devintf: compat_ioctl method fails to take ipmi_mutex

commit 6368087e851e697679af059b4247aca33a69cef3 upstream.

When a 32 bit version of ipmitool is used on a 64 bit kernel, the
ipmi_devintf code fails to correctly acquire ipmi_mutex.  This results in
incomplete data being retrieved in some cases, or other possible failures.
Add a wrapper around compat_ipmi_ioctl() to take ipmi_mutex to fix this.

Signed-off-by: Benjamin LaHaise <>
Signed-off-by: Corey Minyard <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agodrivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow
Chen Gang [Thu, 16 May 2013 19:04:25 +0000 (14:04 -0500)]
drivers/char/ipmi: memcpy, need additional 2 bytes to avoid memory overflow

commit a5f2b3d6a738e7d4180012fe7b541172f8c8dcea upstream.

When calling memcpy, read_data and write_data need additional 2 bytes.

    for checking:  "if (size > IPMI_MAX_MSG_LENGTH)"
    for operating: "memcpy(bt->write_data + 3, data + 1, size - 1)"

    for checking:  "if (msg_len < 3 || msg_len > IPMI_MAX_MSG_LENGTH)"
    for operating: "memcpy(data + 2, bt->read_data + 4, msg_len - 2)"

Signed-off-by: Chen Gang <>
Signed-off-by: Corey Minyard <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoACPI / EC: Restart transaction even when the IBF flag set
Lan Tianyu [Mon, 6 May 2013 03:23:40 +0000 (03:23 +0000)]
ACPI / EC: Restart transaction even when the IBF flag set

commit 28fe5c825f8e15744d04c7c1b8df197950923ecd upstream.

The EC driver works abnormally with IBF flag always set.
IBF means "The host has written a byte of data to the command
or data port, but the embedded controller has not yet read it".
If IBF is set in the EC status and not cleared, this will cause
all subsequent EC requests to fail with a timeout error.

Change the EC driver so that it doesn't refuse to restart a
transaction if IBF is set in the status.  Also increase the
number of transaction restarts to 5, as it turns out that 2
is not sufficient in some cases.

This bug happens on several different machines (Asus V1S,
Dell Latitude E6530, Samsung R719, Acer Aspire 5930G,
Sony Vaio SR19VN and others).

[rjw: Changelog]
Signed-off-by: Lan Tianyu <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Greg Kroah-Hartman <>
4 years agoiscsi-target: Fix processing of OOO commands
Shlomo Pongratz [Sun, 5 May 2013 14:36:26 +0000 (17:36 +0300)]
iscsi-target: Fix processing of OOO commands

commit 3eccfdb01da58fbd0f789ae6ca61cee3769e26de upstream.

Fix two issues in OOO commands processing done at iscsit_attach_ooo_cmdsn.

Handle command serial numbers wrap around by using iscsi_sna_lt and not regular comparisson.

The routine iterates until it finds an entry whose serial number is greater than the serial number of
the new one, thus the new entry should be inserted before that entry and not after.

Signed-off-by: Shlomo Pongratz <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Greg Kroah-Hartman <>