8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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

8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 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 <>
8 years agoInput: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set
Hans de Goede [Sun, 8 Jun 2014 06:07:13 +0000 (23:07 -0700)]
Input: elantech - don't set bit 1 of reg_10 when the no_hw_res quirk is set

commit fb4f8f568a9def02240ef9bf7aabd246dc63a081 upstream.

The touchpad on the GIGABYTE U2442 not only stops communicating when we try
to set bit 3 (enable real hardware resolution) of reg_10, but on some BIOS
versions also when we set bit 1 (enable two finger mode auto correct).

I've asked the original reporter of:

To check that not setting bit 1 does not lead to any adverse effects on his
model / BIOS revision, and it does not, so this commit fixes the touchpad
not working on these versions by simply never setting bit 1 for laptop
models with the no_hw_res quirk.

Reported-and-tested-by: James Lademann <>
Tested-by: Philipp Wolfer <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
8 years agoInput: elantech - deal with clickpads reporting right button events
Hans de Goede [Sun, 8 Jun 2014 05:35:07 +0000 (22:35 -0700)]
Input: elantech - deal with clickpads reporting right button events

commit cd9e83e2754465856097f31c7ab933ce74c473f8 upstream.

At least the Dell Vostro 5470 elantech *clickpad* reports right button
clicks when clicked in the right bottom area:

This is different from how (elantech) clickpads normally operate, normally
no matter where the user clicks on the pad the pad always reports a left
button event, since there is only 1 hardware button beneath the path.

It looks like Dell has put 2 buttons under the pad, one under each bottom
corner, causing this.

Since this however still clearly is a real clickpad hardware-wise, we still
want to report it as such to userspace, so that things like finger movement
in the bottom area can be properly ignored as it should be on clickpads.

So deal with this weirdness by simply mapping a right click to a left click
on elantech clickpads. As an added advantage this is something which we can
simply do on all elantech clickpads, so no need to add special quirks for
this weird model.

Reported-and-tested-by: Elder Marco <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
8 years agoidr: fix overflow bug during maximum ID calculation at maximum height
Lai Jiangshan [Fri, 6 Jun 2014 21:37:10 +0000 (14:37 -0700)]
idr: fix overflow bug during maximum ID calculation at maximum height

commit 3afb69cb5572b3c8c898c00880803cf1a49852c4 upstream.

idr_replace() open-codes the logic to calculate the maximum valid ID
given the height of the idr tree; unfortunately, the open-coded logic
doesn't account for the fact that the top layer may have unused slots
and over-shifts the limit to zero when the tree is at its maximum

The following test code shows it fails to replace the value for

  static void test5(void)
        int id;
  #define TEST5_START ((1<<27)+42) /* use the highest layer */

        printk(KERN_INFO "Start test5\n");
        id = idr_alloc(&test_idr, (void *)1, TEST5_START, 0, GFP_KERNEL);
        BUG_ON(id != TEST5_START);
        TEST_BUG_ON(idr_replace(&test_idr, (void *)2, TEST5_START) != (void *)1);
        printk(KERN_INFO "End of test5\n");

Fix the bug by using idr_max() which correctly takes into account the
maximum allowed shift.

sub_alloc() shares the same problem and may incorrectly fail with
-EAGAIN; however, this bug doesn't affect correct operation because
idr_get_empty_slot(), which already uses idr_max(), retries with the
increased @id in such cases.

[ Updated patch description.]
Signed-off-by: Lai Jiangshan <>
Acked-by: Tejun Heo <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agoptrace: fix fork event messages across pid namespaces
Matthew Dempsky [Fri, 6 Jun 2014 21:36:42 +0000 (14:36 -0700)]
ptrace: fix fork event messages across pid namespaces

commit 4e52365f279564cef0ddd41db5237f0471381093 upstream.

When tracing a process in another pid namespace, it's important for fork
event messages to contain the child's pid as seen from the tracer's pid
namespace, not the parent's.  Otherwise, the tracer won't be able to
correlate the fork event with later SIGTRAP signals it receives from the

We still risk a race condition if a ptracer from a different pid
namespace attaches after we compute the pid_t value.  However, sending a
bogus fork event message in this unlikely scenario is still a vast
improvement over the status quo where we always send bogus fork event
messages to debuggers in a different pid namespace than the forking

Signed-off-by: Matthew Dempsky <>
Acked-by: Oleg Nesterov <>
Cc: Kees Cook <>
Cc: Julien Tinnes <>
Cc: Roland McGrath <>
Cc: Jan Kratochvil <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agortc: rtc-at91rm9200: fix infinite wait for ACKUPD irq
Boris BREZILLON [Fri, 6 Jun 2014 21:36:09 +0000 (14:36 -0700)]
rtc: rtc-at91rm9200: fix infinite wait for ACKUPD irq

commit 2fe121e1f5aa3bf31b418a9790db6c400e922291 upstream.

The rtc user must wait at least 1 sec between each time/calandar update
(see atmel's datasheet chapter "Updating Time/Calendar").

Use the 1Hz interrupt to update the at91_rtc_upd_rdy flag and wait for
the at91_rtc_wait_upd_rdy event if the rtc is not ready.

This patch fixes a deadlock in an uninterruptible wait when the RTC is
updated more than once every second.  AFAICT the bug is here from the
beginning, but I think we should at least backport this fix to 3.10 and
the following longterm and stable releases.

Signed-off-by: Boris BREZILLON <>
Reported-by: Bryan Evenson <>
Tested-by: Bryan Evenson <>
Cc: Andrew Victor <>
Cc: Nicolas Ferre <>
Cc: Jean-Christophe Plagniol-Villard <>
Cc: Alessandro Zummo <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2:
 - Adjust context
 - at91_rtc_write() is called at91_sys_write()
 - Use at91_sys_write() directly instead of the missing
   at91_rtc_write_ier() and at91_rtc_write_idr()]
Signed-off-by: Ben Hutchings <>
8 years agomm: vmscan: clear kswapd's special reclaim powers before exiting
Johannes Weiner [Fri, 6 Jun 2014 21:35:35 +0000 (14:35 -0700)]
mm: vmscan: clear kswapd's special reclaim powers before exiting

commit 71abdc15adf8c702a1dd535f8e30df50758848d2 upstream.

When kswapd exits, it can end up taking locks that were previously held
by allocating tasks while they waited for reclaim.  Lockdep currently
warns about this:

On Wed, May 28, 2014 at 06:06:34PM +0800, Gu Zheng wrote:
>  inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-R} usage.
>  kswapd2/1151 [HC0[0]:SC0[0]:HE1:SE1] takes:
>   (&sig->group_rwsem){+++++?}, at: exit_signals+0x24/0x130
>  {RECLAIM_FS-ON-W} state was registered at:
>     mark_held_locks+0xb9/0x140
>     lockdep_trace_alloc+0x7a/0xe0
>     kmem_cache_alloc_trace+0x37/0x240
>     flex_array_alloc+0x99/0x1a0
>     cgroup_attach_task+0x63/0x430
>     attach_task_by_pid+0x210/0x280
>     cgroup_procs_write+0x16/0x20
>     cgroup_file_write+0x120/0x2c0
>     vfs_write+0xc0/0x1f0
>     SyS_write+0x4c/0xa0
>     tracesys+0xdd/0xe2
>  irq event stamp: 49
>  hardirqs last  enabled at (49):  _raw_spin_unlock_irqrestore+0x36/0x70
>  hardirqs last disabled at (48):  _raw_spin_lock_irqsave+0x2b/0xa0
>  softirqs last  enabled at (0):  copy_process.part.24+0x627/0x15f0
>  softirqs last disabled at (0):            (null)
>  other info that might help us debug this:
>   Possible unsafe locking scenario:
>         CPU0
>         ----
>    lock(&sig->group_rwsem);
>    <Interrupt>
>      lock(&sig->group_rwsem);
>   *** DEADLOCK ***
>  no locks held by kswapd2/1151.
>  stack backtrace:
>  CPU: 30 PID: 1151 Comm: kswapd2 Not tainted 3.10.39+ #4
>  Call Trace:
>    dump_stack+0x19/0x1b
>    print_usage_bug+0x1f7/0x208
>    mark_lock+0x21d/0x2a0
>    __lock_acquire+0x52a/0xb60
>    lock_acquire+0xa2/0x140
>    down_read+0x51/0xa0
>    exit_signals+0x24/0x130
>    do_exit+0xb5/0xa50
>    kthread+0xdb/0x100
>    ret_from_fork+0x7c/0xb0

This is because the kswapd thread is still marked as a reclaimer at the
time of exit.  But because it is exiting, nobody is actually waiting on
it to make reclaim progress anymore, and it's nothing but a regular
thread at this point.  Be tidy and strip it of all its powers
(PF_MEMALLOC, PF_SWAPWRITE, PF_KSWAPD, and the lockdep reclaim state)
before returning from the thread function.

Signed-off-by: Johannes Weiner <>
Reported-by: Gu Zheng <>
Cc: Yasuaki Ishimatsu <>
Cc: Tang Chen <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
8 years agoiscsi-target: Reject mutual authentication with reflected CHAP_C
Nicholas Bellinger [Fri, 6 Jun 2014 01:08:57 +0000 (18:08 -0700)]
iscsi-target: Reject mutual authentication with reflected CHAP_C

commit 1d2b60a5545942b1376cb48c1d55843d71e3a08f upstream.

This patch adds an explicit check in chap_server_compute_md5() to ensure
the CHAP_C value received from the initiator during mutual authentication
does not match the original CHAP_C provided by the target.

This is in line with RFC-3720, section 8.2.1:

   Originators MUST NOT reuse the CHAP challenge sent by the Responder
   for the other direction of a bidirectional authentication.
   Responders MUST check for this condition and close the iSCSI TCP
   connection if it occurs.

Reported-by: Tejas Vaykole <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
8 years agoALSA: hda/realtek - Add support of ALC891 codec
Kailang Yang [Thu, 5 Jun 2014 03:13:44 +0000 (11:13 +0800)]
ALSA: hda/realtek - Add support of ALC891 codec

commit b6c5fbad16aa5026f508093a8d651c25e1cb6179 upstream.

New codec support for ALC891.

Signed-off-by: Kailang Yang <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
8 years agopowerpc/serial: Use saner flags when creating legacy ports
Benjamin Herrenschmidt [Tue, 3 Jun 2014 07:33:41 +0000 (17:33 +1000)]
powerpc/serial: Use saner flags when creating legacy ports

commit c4cad90f9e9dcb85afc5e75a02ae3522ed077296 upstream.

We had a mix & match of flags used when creating legacy ports
depending on where we found them in the device-tree. Among others
we were missing UPF_SKIP_TEST for some kind of ISA ports which is
a problem as quite a few UARTs out there don't support the loopback
test (such as a lot of BMCs).

Let's pick the set of flags used by the SoC code and generalize it
which means autoconf, no loopback test, irq maybe shared and fixed

Sending to stable as the lack of UPF_SKIP_TEST is breaking
serial on some machines so I want this back into distros

Signed-off-by: Benjamin Herrenschmidt <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agomm: fix sleeping function warning from __put_anon_vma
Hugh Dickins [Wed, 4 Jun 2014 23:05:33 +0000 (16:05 -0700)]
mm: fix sleeping function warning from __put_anon_vma

commit 7f39dda9d86fb4f4f17af0de170decf125726f8c upstream.

Trinity reports BUG:

  sleeping function called from invalid context at kernel/locking/rwsem.c:47
  in_atomic(): 0, irqs_disabled(): 0, pid: 5787, name: trinity-c27

__might_sleep < down_write < __put_anon_vma < page_get_anon_vma <
migrate_pages < compact_zone < compact_zone_order < try_to_compact_pages ..

Right, since conversion to mutex then rwsem, we should not put_anon_vma()
from inside an rcu_read_lock()ed section: fix the two places that did so.
And add might_sleep() to anon_vma_free(), as suggested by Peter Zijlstra.

Fixes: 88c22088bf23 ("mm: optimize page_lock_anon_vma() fast-path")
Reported-by: Dave Jones <>
Signed-off-by: Hugh Dickins <>
Cc: Peter Zijlstra <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agonfsd4: use recall_lock for delegation hashing
Benny Halevy [Fri, 30 May 2014 13:09:27 +0000 (09:09 -0400)]
nfsd4: use recall_lock for delegation hashing

commit 931ee56c67573eb4e51c8a4e78598d965b8b059e upstream.

This fixes a bug in the handling of the fi_delegations list.

nfs4_setlease does not hold the recall_lock when adding to it. The
client_mutex is held, which prevents against concurrent list changes,
but nfsd_break_deleg_cb does not hold while walking it. New delegations
could theoretically creep onto the list while we're walking it there.

Signed-off-by: Benny Halevy <>
Signed-off-by: Jeff Layton <>
Signed-off-by: J. Bruce Fields <>
[bwh: Backported to 3.2:
 - Adjust context
 - Also remove a list_del_init() in nfs4_setlease() which would now be
   before the corresponding list_add()
 - Drop change to nfsd_find_all_delegations(), which doesn't exist]
Signed-off-by: Ben Hutchings <>
8 years agoahci: Add Device ID for HighPoint RocketRaid 642L
Jérôme Carretero [Tue, 3 Jun 2014 18:56:25 +0000 (14:56 -0400)]
ahci: Add Device ID for HighPoint RocketRaid 642L

commit d251836508fb26cd1a22b41381739835ee23728d upstream.

This device normally comes with a proprietary driver, using a web GUI
to configure RAID:
But thankfully it also works out of the box with the AHCI driver,
being just a Marvell 88SE9235.

Devices 640L, 644L, 644LS should also be supported but not tested here.

Signed-off-by: Jérôme Carretero <>
Signed-off-by: Tejun Heo <>
Signed-off-by: Ben Hutchings <>
8 years agodrm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi
Alex Deucher [Tue, 22 Apr 2014 01:45:09 +0000 (21:45 -0400)]
drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi

commit 7d5ab3009a8ca777174f6f469277b3922d56fd4b upstream.

May fix display issues with non-HDMI displays.

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
8 years agodrm/radeon/atom: fix dithering on certain panels
Alex Deucher [Tue, 27 May 2014 20:40:51 +0000 (16:40 -0400)]
drm/radeon/atom: fix dithering on certain panels

commit 642528355c694f5ed68f6bff9ff520326a249f99 upstream.

We need to specify the encoder mode as LVDS for eDP
when using the Crtc_Source atom table in order to properly
set up the FMT hardware.


Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
8 years agodrm/radeon: fix typo in radeon_connector_is_dp12_capable()
Alex Deucher [Tue, 27 May 2014 17:11:36 +0000 (13:11 -0400)]
drm/radeon: fix typo in radeon_connector_is_dp12_capable()

commit af5d36539dfe043f1cf0f8b7334d6bb12cd14e75 upstream.

We were checking the ext clock rather than the display clock.

Noticed by ArtForz on IRC.

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
8 years agoUBIFS: Remove incorrect assertion in shrink_tnc()
hujianyang [Sat, 31 May 2014 03:39:32 +0000 (11:39 +0800)]
UBIFS: Remove incorrect assertion in shrink_tnc()

commit 72abc8f4b4e8574318189886de627a2bfe6cd0da upstream.

I hit the same assert failed as Dolev Raviv reported in Kernel v3.10
shows like this:

[ 9641.164028] UBIFS assert failed in shrink_tnc at 131 (pid 13297)
[ 9641.234078] CPU: 1 PID: 13297 Comm: mmap.test Tainted: G           O 3.10.40 #1
[ 9641.234116] [<c0011a6c>] (unwind_backtrace+0x0/0x12c) from [<c000d0b0>] (show_stack+0x20/0x24)
[ 9641.234137] [<c000d0b0>] (show_stack+0x20/0x24) from [<c0311134>] (dump_stack+0x20/0x28)
[ 9641.234188] [<c0311134>] (dump_stack+0x20/0x28) from [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs])
[ 9641.234265] [<bf22425c>] (shrink_tnc_trees+0x25c/0x350 [ubifs]) from [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs])
[ 9641.234307] [<bf2245ac>] (ubifs_shrinker+0x25c/0x310 [ubifs]) from [<c00cdad8>] (shrink_slab+0x1d4/0x2f8)
[ 9641.234327] [<c00cdad8>] (shrink_slab+0x1d4/0x2f8) from [<c00d03d0>] (do_try_to_free_pages+0x300/0x544)
[ 9641.234344] [<c00d03d0>] (do_try_to_free_pages+0x300/0x544) from [<c00d0a44>] (try_to_free_pages+0x2d0/0x398)
[ 9641.234363] [<c00d0a44>] (try_to_free_pages+0x2d0/0x398) from [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8)
[ 9641.234382] [<c00c6a60>] (__alloc_pages_nodemask+0x494/0x7e8) from [<c00f62d8>] (new_slab+0x78/0x238)
[ 9641.234400] [<c00f62d8>] (new_slab+0x78/0x238) from [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c)
[ 9641.234419] [<c031081c>] (__slab_alloc.constprop.42+0x1a4/0x50c) from [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188)
[ 9641.234459] [<c00f80e8>] (kmem_cache_alloc_trace+0x54/0x188) from [<bf227908>] (do_readpage+0x168/0x468 [ubifs])
[ 9641.234553] [<bf227908>] (do_readpage+0x168/0x468 [ubifs]) from [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs])
[ 9641.234606] [<bf2296a0>] (ubifs_readpage+0x424/0x464 [ubifs]) from [<c00c17c0>] (filemap_fault+0x304/0x418)
[ 9641.234638] [<c00c17c0>] (filemap_fault+0x304/0x418) from [<c00de694>] (__do_fault+0xd4/0x530)
[ 9641.234665] [<c00de694>] (__do_fault+0xd4/0x530) from [<c00e10c0>] (handle_pte_fault+0x480/0xf54)
[ 9641.234690] [<c00e10c0>] (handle_pte_fault+0x480/0xf54) from [<c00e2bf8>] (handle_mm_fault+0x140/0x184)
[ 9641.234716] [<c00e2bf8>] (handle_mm_fault+0x140/0x184) from [<c0316688>] (do_page_fault+0x150/0x3ac)
[ 9641.234737] [<c0316688>] (do_page_fault+0x150/0x3ac) from [<c000842c>] (do_DataAbort+0x3c/0xa0)
[ 9641.234759] [<c000842c>] (do_DataAbort+0x3c/0xa0) from [<c0314e38>] (__dabt_usr+0x38/0x40)

After analyzing the code, I found a condition that may cause this failed
in correct operations. Thus, I think this assertion is wrong and should be

Suppose there are two clean znodes and one dirty znode in TNC. So the
per-filesystem atomic_t @clean_zn_cnt is (2). If commit start, dirty_znode
is set to COW_ZNODE in get_znodes_to_commit() in case of potentially ops
on this znode. We clear COW bit and DIRTY bit in write_index() without
@tnc_mutex locked. We don't increase @clean_zn_cnt in this place. As the
comments in write_index() shows, if another process hold @tnc_mutex and
dirty this znode after we clean it, @clean_zn_cnt would be decreased to (1).
We will increase @clean_zn_cnt to (2) with @tnc_mutex locked in
free_obsolete_znodes() to keep it right.

If shrink_tnc() performs between decrease and increase, it will release
other 2 clean znodes it holds and found @clean_zn_cnt is less than zero
(1 - 2 = -1), then hit the assertion. Because free_obsolete_znodes() will
soon correct @clean_zn_cnt and no harm to fs in this case, I think this
assertion could be removed.

2 clean zondes and 1 dirty znode, @clean_zn_cnt == 2

Thread A (commit)         Thread B (write or others)       Thread C (shrinker)

            @clean_zn_cnt == 2

            @clean_zn_cnt == 1
                                                             ->atomic_sub(&clean_zn_cnt, 2)
                                                             ->ubifs_assert  <- hit

            @clean_zn_cnt == -1

            @clean_zn_cnt == 0 (correct after shrink)

Signed-off-by: hujianyang <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Ben Hutchings <>
8 years agonfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer
Christoph Hellwig [Wed, 28 May 2014 08:46:13 +0000 (10:46 +0200)]
nfsd: getattr for FATTR4_WORD0_FILES_AVAIL needs the statfs buffer

commit 12337901d654415d9f764b5f5ba50052e9700f37 upstream.

Note nobody's ever noticed because the typical client probably never
requests FILES_AVAIL without also requesting something else on the list.

Signed-off-by: Christoph Hellwig <>
Signed-off-by: J. Bruce Fields <>
Signed-off-by: Ben Hutchings <>
8 years agoRDMA/cxgb4: Add missing padding at end of struct c4iw_create_cq_resp
Yann Droneaud [Mon, 5 May 2014 17:33:23 +0000 (19:33 +0200)]
RDMA/cxgb4: Add missing padding at end of struct c4iw_create_cq_resp

commit b6f04d3d21458818073a2f5af5339f958864bf71 upstream.

The i386 ABI disagrees with most other ABIs regarding alignment of
data types larger than 4 bytes: on most ABIs a padding must be added
at end of the structures, while it is not required on i386.

So for most ABI struct c4iw_create_cq_resp gets implicitly padded
to be aligned on a 8 bytes multiple, while for i386, such padding
is not added.

The tool pahole can be used to find such implicit padding:

  $ pahole --anon_include \
           --nested_anon_include \
           --recursive \
           --class_name c4iw_create_cq_resp \

Then, structure layout can be compared between i386 and x86_64:

# +++ obj-i386/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt   2014-03-28 11:43:05.547432195 +0100
# --- obj-x86_64/drivers/infiniband/hw/cxgb4/iw_cxgb4.o.pahole.txt 2014-03-28 10:55:10.990133017 +0100
  @@ -14,9 +13,8 @@ struct c4iw_create_cq_resp {
          __u32                      size;                 /*    28     4 */
          __u32                      qid_mask;             /*    32     4 */

  -       /* size: 36, cachelines: 1, members: 6 */
  -       /* last cacheline: 36 bytes */
  +       /* size: 40, cachelines: 1, members: 6 */
  +       /* padding: 4 */
  +       /* last cacheline: 40 bytes */

This ABI disagreement will make an x86_64 kernel try to write past the
buffer provided by an i386 binary.

When boundary check will be implemented, the x86_64 kernel will refuse
to write past the i386 userspace provided buffer and the uverbs will

If the structure is on a page boundary and the next page is not
mapped, ib_copy_to_udata() will fail and the uverb will fail.

This patch adds an explicit padding at end of structure
c4iw_create_cq_resp, and, like 92b0ca7cb149 ("IB/mlx5: Fix stack info
leak in mlx5_ib_alloc_ucontext()"), makes function c4iw_create_cq()
not writting this padding field to userspace. This way, x86_64 kernel
will be able to write struct c4iw_create_cq_resp as expected by
unpatched and patched i386 libcxgb4.

Fixes: cfdda9d764362 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC")
Fixes: e24a72a3302a6 ("RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()")
Cc: Dan Carpenter <>
Signed-off-by: Yann Droneaud <>
Acked-by: Steve Wise <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
8 years agoRDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()
Dan Carpenter [Sat, 19 Oct 2013 09:14:35 +0000 (12:14 +0300)]
RDMA/cxgb4: Fix four byte info leak in c4iw_create_cq()

commit e24a72a3302a638d4c6e77f0b40c45cc61c3f089 upstream.

There is a four byte hole at the end of the "uresp" struct after the
->qid_mask member.

Signed-off-by: Dan Carpenter <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
8 years agoIB/umad: Fix error handling
Bart Van Assche [Tue, 20 May 2014 08:33:41 +0000 (10:33 +0200)]
IB/umad: Fix error handling

commit 8ec0a0e6b58218bdc1db91dd70ebfcd6ad8dd6cd upstream.

Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL
or if nonseekable_open() fails.

Avoid leaking a kref count, that sm_sem is kept down and also that the
IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if
nonseekable_open() fails.

Since container_of() never returns NULL, remove the code that tests
whether container_of() returns NULL.

Moving the kref_get() call from the start of ib_umad_*open() to the
end is safe since it is the responsibility of the caller of these
functions to ensure that the cdev pointer remains valid until at least
when these functions return.

Signed-off-by: Bart Van Assche <>
[ rework a bit to reduce the amount of code changed]

Signed-off-by: Yann Droneaud <>
[ nonseekable_open() can't actually fail, but....  - Roland ]

Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
8 years agoxhci: delete endpoints from bandwidth list before freeing whole device
Mathias Nyman [Wed, 28 May 2014 20:51:13 +0000 (23:51 +0300)]
xhci: delete endpoints from bandwidth list before freeing whole device

commit 5dc2808c4729bf080487e61b80ee04e0fdb12a37 upstream.

Lists of endpoints are stored for bandwidth calculation for roothub ports.
Make sure we remove all endpoints from the list before the whole device,
containing its endpoints list_head stuctures, is freed.

This used to be done in the wrong order in xhci_mem_cleanup(),
and triggered an oops in resume from S4 (hibernate).

Tested-by: Ville Syrjälä <>
Signed-off-by: Mathias Nyman <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agortmutex: Fix deadlock detector for real
Thomas Gleixner [Thu, 22 May 2014 03:25:39 +0000 (03:25 +0000)]
rtmutex: Fix deadlock detector for real

commit 397335f004f41e5fcf7a795e94eb3ab83411a17c upstream.

The current deadlock detection logic does not work reliably due to the
following early exit path:

 * Drop out, when the task has no waiters. Note,
 * top_waiter can be NULL, when we are in the deboosting
 * mode!
if (top_waiter && (!task_has_pi_waiters(task) ||
   top_waiter != task_top_pi_waiter(task)))
goto out_unlock_pi;

So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.

So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.

Simple fix: Continue the chain walk, when deadlock detection is

We also avoid the whole enqueue, if we detect the deadlock right away
(A-A). It's an optimization, but also prevents that another waiter who
comes in after the detection and before the task has undone the damage
observes the situation and detects the deadlock and returns
-EDEADLOCK, which is wrong as the other task is not in a deadlock

Signed-off-by: Thomas Gleixner <>
Cc: Peter Zijlstra <>
Reviewed-by: Steven Rostedt <>
Cc: Lai Jiangshan <>
Signed-off-by: Thomas Gleixner <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
8 years agomac80211: don't check netdev state for debugfs read/write
Arik Nemtsov [Mon, 26 May 2014 11:40:51 +0000 (14:40 +0300)]
mac80211: don't check netdev state for debugfs read/write

commit 923eaf367206e01f22c97aee22300e332d071916 upstream.

Doing so will lead to an oops for a p2p-dev interface, since it has
no netdev.

Signed-off-by: Arik Nemtsov <>
Signed-off-by: Emmanuel Grumbach <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>
8 years agos390/lowcore: reserve 96 bytes for IRB in lowcore
Christian Borntraeger [Mon, 26 May 2014 19:55:08 +0000 (21:55 +0200)]
s390/lowcore: reserve 96 bytes for IRB in lowcore

commit 993072ee67aa179c48c85eb19869804e68887d86 upstream.

The IRB might be 96 bytes if the extended-I/O-measurement facility is
used. This feature is currently not used by Linux, but struct irb
already has the emw defined. So let's make the irb in lowcore match the
size of the internal data structure to be future proof.
We also have to add a pad, to correctly align the paste.

The bigger irb field also circumvents a bug in some QEMU versions that
always write the emw field on test subchannel and therefore destroy the
paste definitions of this CPU. Running under these QEMU version broke
some timing functions in the VDSO and all users of these functions,
e.g. some JREs.

Signed-off-by: Christian Borntraeger <>
Signed-off-by: Martin Schwidefsky <>
Cc: Heiko Carstens <>
Cc: Sebastian Ott <>
Cc: Cornelia Huck <>
[bwh: Backported to 3.2: offsets of the affected fields in the 64-bit version
 of struct _lowcore are 128 bytes smaller]
Signed-off-by: Ben Hutchings <>
8 years agomd: always set MD_RECOVERY_INTR when aborting a reshape or other "resync".
NeilBrown [Wed, 28 May 2014 03:39:23 +0000 (13:39 +1000)]
md: always set MD_RECOVERY_INTR when aborting a reshape or other "resync".

commit 3991b31ea072b070081ca3bfa860a077eda67de5 upstream.

If mddev->ro is set, md_to_sync will (correctly) abort.
However in that case MD_RECOVERY_INTR isn't set.

If a RESHAPE had been requested, then ->finish_reshape() will be
called and it will think the reshape was successful even though
nothing happened.

Normally a resync will not be requested if ->ro is set, but if an
array is stopped while a reshape is on-going, then when the array is
started, the reshape will be restarted.  If the array is also set
read-only at this point, the reshape will instantly appear to success,
resulting in data corruption.

Consequently, this patch is suitable for any -stable kernel.

Signed-off-by: NeilBrown <>
Signed-off-by: Ben Hutchings <>
8 years agopowerpc: Fix 64 bit builds with binutils 2.24
Guenter Roeck [Thu, 15 May 2014 16:33:42 +0000 (09:33 -0700)]
powerpc: Fix 64 bit builds with binutils 2.24

commit 7998eb3dc700aaf499f93f50b3d77da834ef9e1d upstream.

With binutils 2.24, various 64 bit builds fail with relocation errors
such as

arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_base_book3e' defined in .text section
in arch/powerpc/kernel/built-in.o
arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e':
(.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI
against symbol `interrupt_end_book3e' defined in .text section
in arch/powerpc/kernel/built-in.o

The assembler maintainer says:

 I changed the ABI, something that had to be done but unfortunately
 happens to break the booke kernel code.  When building up a 64-bit
 value with lis, ori, shl, oris, ori or similar sequences, you now
 should use @high and @higha in place of @h and @ha.  @h and @ha
 (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA)
 now report overflow if the value is out of 32-bit signed range.
 ie. @h and @ha assume you're building a 32-bit value. This is needed
 to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h
 and @toc@ha expressions, and for consistency I did the same for all
 other @h and @ha relocs.

Replacing @h with @high in one strategic location fixes the relocation
errors. This has to be done conditionally since the assembler either
supports @h or @high but not both.

Signed-off-by: Guenter Roeck <>
Signed-off-by: Benjamin Herrenschmidt <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
8 years agousb: usbtest: fix unlink write error with pattern 1
Huang Rui [Mon, 26 May 2014 02:55:36 +0000 (10:55 +0800)]
usb: usbtest: fix unlink write error with pattern 1

commit e4d58f5dcb7d7be45df8def31881ebfae99c75da upstream.

TEST 12 and TEST 24 unlinks the URB write request for N times. When
host and gadget both initialize pattern 1 (mod 63) data series to
transfer, the gadget side will complain the wrong data which is not
expected.  Because in host side, usbtest doesn't fill the data buffer
as mod 63 and this patch fixed it.

[20285.488974] dwc3 ep1out-bulk: Transfer Not Ready
[20285.489181] dwc3 ep1out-bulk: reason Transfer Not Active
[20285.489423] dwc3 ep1out-bulk: req ffff8800aa6cb480 dma aeb50800 length 512 last
[20285.489727] dwc3 ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000
[20285.490055] dwc3 Command Complete --> 0
[20285.490281] dwc3 ep1out-bulk: Transfer Not Ready
[20285.490492] dwc3 ep1out-bulk: reason Transfer Active
[20285.490713] dwc3 ep1out-bulk: endpoint busy
[20285.490909] dwc3 ep1out-bulk: Transfer Complete
[20285.491117] dwc3 request ffff8800aa6cb480 from ep1out-bulk completed 512/512 ===> 0
[20285.491431] zero gadget: bad OUT byte, buf[1] = 0
[20285.491605] dwc3 ep1out-bulk: cmd 'Set Stall' params 00000000 00000000 00000000
[20285.491915] dwc3 Command Complete --> 0
[20285.492099] dwc3 queing request ffff8800aa6cb480 to ep1out-bulk length 512
[20285.492387] dwc3 ep1out-bulk: Transfer Not Ready
[20285.492595] dwc3 ep1out-bulk: reason Transfer Not Active
[20285.492830] dwc3 ep1out-bulk: req ffff8800aa6cb480 dma aeb51000 length 512 last
[20285.493135] dwc3 ep1out-bulk: cmd 'Start Transfer' params 00000000 a9eaf000 00000000
[20285.493465] dwc3 Command Complete --> 0

Signed-off-by: Huang Rui <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: serial: option: add support for Novatel E371 PCIe card
Alexej Starschenko [Wed, 7 May 2014 08:43:29 +0000 (10:43 +0200)]
USB: serial: option: add support for Novatel E371 PCIe card

commit 8a61ba3a47ac39f660702aa66a172185dd605a86 upstream.

Adds product ID for the Novatel E371 PCI Express Mini Card.

$ lsusb
Bus 001 Device 024: ID 1410:9011 Novatel Wireless

$ usb-devices
T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 24 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=1410 ProdID=9011 Rev=00.03
S:  Manufacturer=Novatel Wireless, Inc.
S:  Product=Novatel Wireless HSPA
S:  SerialNumber=012773002115811
C:  #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 6 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I:  If#= 7 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether

Tested with kernel 3.2.0.

Signed-off-by: Alexej Starschenko <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: ftdi_sio: add NovaTech OrionLXm product ID
George McCollister [Sat, 26 Apr 2014 10:04:47 +0000 (12:04 +0200)]
USB: ftdi_sio: add NovaTech OrionLXm product ID

commit d0839d757e6294921c31b1c4ca4f1dcc5df63bcd upstream.

The NovaTech OrionLXm uses an onboard FTDI serial converter for JTAG and
console access.

Here is the lsusb output:
Bus 004 Device 123: ID 0403:7c90 Future Technology Devices
International, Ltd

Signed-off-by: George McCollister <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: io_ti: fix firmware download on big-endian machines (part 2)
Johan Hovold [Sat, 26 Apr 2014 09:53:44 +0000 (11:53 +0200)]
USB: io_ti: fix firmware download on big-endian machines (part 2)

commit c03890ff5e24a4bf59059f2d179f427559b7330a upstream.

A recent patch that purported to fix firmware download on big-endian
machines failed to add the corresponding sparse annotation to the
i2c-header. This was reported by the kbuild test robot.

Adding the appropriate annotation revealed another endianess bug related
to the i2c-header Size-field in a code path that is exercised when the
firmware is actually being downloaded (and not just verified and left
untouched unless older than the firmware at hand).

This patch adds the required sparse annotation to the i2c-header and
makes sure that the Size-field is sent in little-endian byte order
during firmware download also on big-endian machines.

Note that this patch is only compile-tested, but that there is no
functional change for little-endian systems.

Reported-by: kbuild test robot <>
Cc: Ludovic Drolez <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: cdc-acm: fix potential urb leak and PM imbalance in write
Johan Hovold [Mon, 26 May 2014 17:23:41 +0000 (19:23 +0200)]
USB: cdc-acm: fix potential urb leak and PM imbalance in write

commit 183a45087d126d126e8dd1d9b2602fc129dff9ad upstream.

Make sure to check return value of autopm get in write() in order to
avoid urb leak and PM counter imbalance on errors.

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

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2:
 - Adjust context
 - Error/status variable is called rc, not stat]
Signed-off-by: Ben Hutchings <>
8 years agoUSB: cdc-acm: fix runtime PM for control messages
Johan Hovold [Mon, 26 May 2014 17:23:39 +0000 (19:23 +0200)]
USB: cdc-acm: fix runtime PM for control messages

commit bae3f4c53585e9a170da9436e0f06919874bda9a upstream.

Fix runtime PM handling of control messages by adding the required PM
counter operations.

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

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
8 years agoUSB: cdc-acm: fix broken runtime suspend
Johan Hovold [Mon, 26 May 2014 17:23:38 +0000 (19:23 +0200)]
USB: cdc-acm: fix broken runtime suspend

commit 140cb81ac8c625942a1d695875932c615767a526 upstream.

The current ACM runtime-suspend implementation is broken in several

Firstly, it buffers only the first write request being made while
suspended -- any further writes are silently dropped.

Secondly, writes being dropped also leak write urbs, which are never
reclaimed (until the device is unbound).

Thirdly, even the single buffered write is not cleared at shutdown
(which may happen before the device is resumed), something which can
lead to another urb leak as well as a PM usage-counter leak.

Fix this by implementing a delayed-write queue using urb anchors and
making sure to discard the queue properly at shutdown.

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

Reported-by: Xiao Jin <>
Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>