9 years agonet: force a reload of first item in hlist_nulls_for_each_entry_rcu
Eric Dumazet [Wed, 29 May 2013 09:06:27 +0000 (09:06 +0000)]
net: force a reload of first item in  hlist_nulls_for_each_entry_rcu

[ Upstream commit c87a124a5d5e8cf8e21c4363c3372bcaf53ea190 ]

Roman Gushchin discovered that udp4_lib_lookup2() was not reloading
first item in the rcu protected list, in case the loop was restarted.

This produced soft lockups as in

rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is
ptr->field :

In some cases, gcc caches the value or ptr->field in a register.

Use a barrier() to disallow such caching, as documented in
Documentation/atomic_ops.txt line 114

Thanks a lot to Roman for providing analysis and numerous patches.

Diagnosed-by: Roman Gushchin <>
Signed-off-by: Eric Dumazet <>
Reported-by: Boris Zhmurov <>
Signed-off-by: Roman Gushchin <>
Acked-by: Paul E. McKenney <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
Andy Lutomirski [Wed, 22 May 2013 21:07:44 +0000 (14:07 -0700)]
net: Block MSG_CMSG_COMPAT in send(m)msg and  recv(m)msg

[ Upstream commits 1be374a0518a288147c6a7398792583200a67261 and
  a7526eb5d06b0084ef12d7b168d008fcf516caab ]

MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
it's a hack that steals a bit to indicate to other networking code
that a compat entry was used.  So don't allow it from a non-compat

This prevents an oops when running this code:

int main()
int s;
struct sockaddr_in addr;
struct msghdr *hdr;

char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
                      PROT_READ | PROT_WRITE,
                      MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
if (highpage == MAP_FAILED)
err(1, "mmap");

if (s == -1)
err(1, "socket");

        addr.sin_family = AF_INET;
        addr.sin_port = htons(1);
        addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
if (connect(s, (struct sockaddr*)&addr, sizeof(addr)) != 0)
err(1, "connect");

void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
printf("Evil address is %p\n", evil);

if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0)
err(1, "sendmmsg");

return 0;

Cc: David S. Miller <>
Signed-off-by: Andy Lutomirski <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoip_tunnel: fix kernel panic with icmp_dest_unreach
Eric Dumazet [Fri, 24 May 2013 05:49:58 +0000 (05:49 +0000)]
ip_tunnel: fix kernel panic with icmp_dest_unreach

[ Upstream commit a622260254ee481747cceaaa8609985b29a31565 ]

Daniel Petre reported crashes in icmp_dst_unreach() with following call

Daniel found a similar problem mentioned in

And indeed this is the root cause : skb->cb[] contains data fooling IP

We must clear IPCB in ip_tunnel_xmit() sooner in case dst_link_failure()
is called. Or else skb->cb[] might contain garbage from GSO segmentation

A similar fix was tested on linux-3.9, but gre code was refactored in
linux-3.10. I'll send patches for stable kernels as well.

Many thanks to Daniel for providing reports, patches and testing !

Reported-by: Daniel Petre <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agotcp: xps: fix reordering issues
Eric Dumazet [Thu, 23 May 2013 07:44:20 +0000 (07:44 +0000)]
tcp: xps: fix reordering issues

[ Upstream commit 547669d483e5783d722772af1483fa474da7caf9 ]

commit 3853b5841c01a ("xps: Improvements in TX queue selection")
introduced ooo_okay flag, but the condition to set it is slightly wrong.

In our traces, we have seen ACK packets being received out of order,
and RST packets sent in response.

We should test if we have any packets still in host queue.

Signed-off-by: Eric Dumazet <>
Cc: Tom Herbert <>
Cc: Yuchung Cheng <>
Cc: Neal Cardwell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agor8169: fix 8168evl frame padding.
Stefan Bader [Fri, 26 Apr 2013 13:49:32 +0000 (13:49 +0000)]
r8169: fix 8168evl frame padding.

[ Upstream commits e5195c1f31f399289347e043d6abf3ffa80f0005 and
  b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 ]

Signed-off-by: Stefan Bader <>
Acked-by: Francois Romieu <>
Cc: hayeswang <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonetlabel: improve domain mapping validation
Paul Moore [Fri, 17 May 2013 09:08:50 +0000 (09:08 +0000)]
netlabel: improve domain mapping validation

[ Upstream commit 6b21e1b77d1a3d58ebfd513264c885695e8a0ba5 ]

The net/netlabel/netlabel_domainhash.c:netlbl_domhsh_add() function
does not properly validate new domain hash entries resulting in
potential problems when an administrator attempts to add an invalid
entry.  One such problem, as reported by Vlad Halilov, is a kernel
BUG (found in netlabel_domainhash.c:netlbl_domhsh_audit_add()) when
adding an IPv6 outbound mapping with a CIPSO configuration.

This patch corrects this problem by adding the necessary validation
code to netlbl_domhsh_add() via the newly created
netlbl_domhsh_validate() function.

Ideally this patch should also be pushed to the currently active
-stable trees.

Reported-by: Vlad Halilov <>
Signed-off-by: Paul Moore <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipv6: fix possible crashes in ip6_cork_release()
Eric Dumazet [Fri, 17 May 2013 04:53:13 +0000 (04:53 +0000)]
ipv6: fix possible crashes in ip6_cork_release()

[ Upstream commit 284041ef21fdf2e0d216ab6b787bc9072b4eb58a ]

commit 0178b695fd6b4 ("ipv6: Copy cork options in ip6_append_data")
added some code duplication and bad error recovery, leading to potential
crash in ip6_cork_release() as kfree() could be called with garbage.

use kzalloc() to make sure this wont happen.

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Cc: Herbert Xu <>
Cc: Hideaki YOSHIFUJI <>
Cc: Neal Cardwell <>
Signed-off-by: Ben Hutchings <>
9 years agogianfar: add missing iounmap() on error in gianfar_ptp_probe()
Wei Yongjun [Thu, 16 May 2013 22:25:34 +0000 (22:25 +0000)]
gianfar: add missing iounmap() on error in  gianfar_ptp_probe()

[ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ]

Add the missing iounmap() before return from gianfar_ptp_probe()
in the error handling case.

Signed-off-by: Wei Yongjun <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agotcp: fix tcp_md5_hash_skb_data()
Eric Dumazet [Mon, 13 May 2013 21:25:52 +0000 (21:25 +0000)]
tcp: fix tcp_md5_hash_skb_data()

[ Upstream commit 54d27fcb338bd9c42d1dfc5a39e18f6f9d373c2e ]

TCP md5 communications fail [1] for some devices, because sg/crypto code
assume page offsets are below PAGE_SIZE.

This was discovered using mlx4 driver [2], but I suspect loopback
might trigger the same bug now we use order-3 pages in tcp_sendmsg()

[1] Failure is giving following messages.

huh, entered softirq 3 NET_RX ffffffff806ad230 preempt_count 00000100,
exited with 00000101?

[2] mlx4 driver uses order-2 pages to allocate RX frags

Reported-by: Matt Schnall <>
Signed-off-by: Eric Dumazet <>
Cc: Bernhard Beck <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agovirtio-blk: Call revalidate_disk() upon online disk resize
Vivek Goyal [Thu, 29 Mar 2012 08:09:44 +0000 (10:09 +0200)]
virtio-blk: Call revalidate_disk() upon online disk resize

commit e9986f303dc0f285401de28cf96f42f4dd23a4a1 upstream.

If a virtio disk is open in guest and a disk resize operation is done,
(virsh blockresize), new size is not visible to tools like "fdisk -l".
This seems to be happening as we update only part->nr_sects and not
bdev->bd_inode size.

Call revalidate_disk() which should take care of it. I tested growing disk
size of already open disk and it works for me.

Signed-off-by: Vivek Goyal <>
Signed-off-by: Jens Axboe <>
Signed-off-by: Ben Hutchings <>
9 years agoRevert "drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits"
Ben Hutchings [Tue, 25 Jun 2013 03:15:27 +0000 (04:15 +0100)]
Revert "drm/i915: GFX_MODE Flush TLB Invalidate Mode must be  '1' for scanline waits"

This reverts commit 393143615d9f2f581d87387268dc11b95adc339c, which
was commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream.

This has been found to cause GPU hangs when backported to 3.2, though
not in mainline.

Cc: Steve Conklin <>
Cc: Stefan Bader <>
Cc: Bradd Figg <>
Cc: Luis Henriques <>
Signed-off-by: Ben Hutchings <>
9 years agox86/efi: Fix dummy variable buffer allocation
Ben Hutchings [Sun, 16 Jun 2013 20:27:12 +0000 (21:27 +0100)]
x86/efi: Fix dummy variable buffer allocation

commit b8cb62f82103083a6e8fa5470bfe634a2c06514d upstream.

1. Check for allocation failure
2. Clear the buffer contents, as they may actually be written to flash
3. Don't leak the buffer

Compile-tested only.

[ Tested successfully on my buggy ASUS machine - Matt ]

Signed-off-by: Ben Hutchings <>
Signed-off-by: Matt Fleming <>
9 years agoModify UEFI anti-bricking code
Matthew Garrett [Sat, 1 Jun 2013 20:06:20 +0000 (16:06 -0400)]
Modify UEFI anti-bricking code

commit f8b8404337de4e2466e2e1139ea68b1f8295974f upstream.

This patch reworks the UEFI anti-bricking code, including an effective
reversion of cc5a080c and 31ff2f20. It turns out that calling
QueryVariableInfo() from boot services results in some firmware
implementations jumping to physical addresses even after entering virtual
mode, so until we have 1:1 mappings for UEFI runtime space this isn't
going to work so well.

Reverting these gets us back to the situation where we'd refuse to create
variables on some systems because they classify deleted variables as "used"
until the firmware triggers a garbage collection run, which they won't do
until they reach a lower threshold. This results in it being impossible to
install a bootloader, which is unhelpful.

Feedback from Samsung indicates that the firmware doesn't need more than
5KB of storage space for its own purposes, so that seems like a reasonable
threshold. However, there's still no guarantee that a platform will attempt
garbage collection merely because it drops below this threshold. It seems
that this is often only triggered if an attempt to write generates a
genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
create a variable larger than the remaining space. This should fail, but if
it somehow succeeds we can then immediately delete it.

I've tested this on the UEFI machines I have available, but I don't have
a Samsung and so can't verify that it avoids the bricking problem.

Signed-off-by: Matthew Garrett <>
Signed-off-by: Lee, Chun-Y <> [ dummy variable cleanup ]
Signed-off-by: Matt Fleming <>
[bwh: Backported to 3.2: the reverted changes were never applied here]
Signed-off-by: Ben Hutchings <>
9 years agoUSB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable
Anders Hammarquist [Tue, 18 Jun 2013 23:45:48 +0000 (01:45 +0200)]
USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable

commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.

Add product id for Abbott strip port cable for Precision meter which
uses the TI 3410 chip.

Signed-off-by: Anders Hammarquist <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agox86: fix build error and kconfig for ia32_emulation and binfmt
Randy Dunlap [Tue, 18 Jun 2013 19:33:40 +0000 (12:33 -0700)]
x86: fix build error and kconfig for ia32_emulation and binfmt

commit d1603990ea626668c78527376d9ec084d634202d upstream.

Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF
when COMPAT_BINFMT_ELF is being selected.

warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)

fs/built-in.o: In function `elf_core_dump':
compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs'
compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size'
compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs'
compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data'

[ hpa: This was sent to me for -next but it is a low risk build fix ]

Signed-off-by: Randy Dunlap <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
9 years agoKVM: x86: remove vcpu's CPL check in host-invoked XCR set
Zhanghaoyu (A) [Fri, 14 Jun 2013 07:36:13 +0000 (07:36 +0000)]
KVM: x86: remove vcpu's CPL check in host-invoked XCR set

commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.

__kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
called in two flows, one is invoked by guest, call stack shown as below,

  handle_xsetbv(or xsetbv_interception)

the other one is invoked by host, for example during system reset:


The former does need the CPL check, but the latter does not.

Signed-off-by: Zhang Haoyu <>
[Tweaks to commit message. - Paolo]
Signed-off-by: Paolo Bonzini <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: 7772/1: Fix missing flush_kernel_dcache_page() for noMMU
Simon Baatz [Sat, 22 Jun 2013 21:01:25 +0000 (22:01 +0100)]
ARM: 7772/1: Fix missing flush_kernel_dcache_page() for noMMU

commit 63384fd0b1509acf522a8a8fcede09087eedb7df upstream.

Commit 1bc3974 (ARM: 7755/1: handle user space mapped pages in
flush_kernel_dcache_page) moved the implementation of
flush_kernel_dcache_page() into mm/flush.c but did not implement it
on noMMU ARM.

Signed-off-by: Simon Baatz <>
Acked-by: Kevin Hilman <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page
Simon Baatz [Mon, 10 Jun 2013 20:10:12 +0000 (21:10 +0100)]
ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page

commit 1bc39742aab09248169ef9d3727c9def3528b3f3 upstream.

Commit f8b63c1 made flush_kernel_dcache_page a no-op assuming that
the pages it needs to handle are kernel mapped only.  However, for
example when doing direct I/O, pages with user space mappings may

Thus, continue to do lazy flushing if there are no user space
mappings.  Otherwise, flush the kernel cache lines directly.

Signed-off-by: Simon Baatz <>
Reviewed-by: Catalin Marinas <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310
Takashi Iwai [Mon, 17 Jun 2013 08:25:02 +0000 (10:25 +0200)]
ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310

commit 36691e1be6ec551eef4a5225f126a281f8c051c2 upstream.

Just like the previous fix for LogitechHD Webcam c270 in commit
11e7064f35bb87da8f427d1aa4bbd8b7473a3993, c310 model also requires the
same workaround for avoiding the kernel warning.

Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: usb-audio: work around Android accessory firmware bug
Clemens Ladisch [Sat, 15 Jun 2013 09:21:09 +0000 (11:21 +0200)]
ALSA: usb-audio: work around Android accessory firmware bug

commit 342cda29343a6272c630f94ed56810a76740251b upstream.

When the Android firmware enables the audio interfaces in accessory
mode, it always declares in the control interface's baInterfaceNr array
that interfaces 0 and 1 belong to the audio function.  However, the
accessory interface itself, if also enabled, already is at index 0 and
shifts the actual audio interface numbers to 1 and 2, which prevents the
PCM streaming interface from being seen by the host driver.

To get the PCM interface interface to work, detect when the descriptors
point to the (for this driver useless) accessory interface, and redirect
to the correct one.

Reported-by: Jeremy Rosen <>
Tested-by: Jeremy Rosen <>
Signed-off-by: Clemens Ladisch <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agotilepro: work around module link error with gcc 4.7
Chris Metcalf [Sat, 15 Jun 2013 20:47:47 +0000 (16:47 -0400)]
tilepro: work around module link error with gcc 4.7

commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555 upstream.

gcc 4.7.x is emitting calls to __ffsdi2 where previously
it used to inline the appropriate ctz instructions.
While this needs to be fixed in gcc, it's also easy to avoid
having it cause build failures when building with those
compilers by exporting __ffsdi2 to modules.

Signed-off-by: Chris Metcalf <>
Signed-off-by: Ben Hutchings <>
9 years agoLinux 3.2.47 v3.2.47
Ben Hutchings [Wed, 19 Jun 2013 01:17:03 +0000 (02:17 +0100)]
Linux 3.2.47

9 years agopowerpc: Fix emulation of illegal instructions on PowerNV platform
Paul Mackerras [Fri, 14 Jun 2013 10:07:41 +0000 (20:07 +1000)]
powerpc: Fix emulation of illegal instructions on PowerNV platform

commit bf593907f7236e95698a76b7c7a2bbf8b1165327 upstream.

Normally, the kernel emulates a few instructions that are unimplemented
on some processors (e.g. the old dcba instruction), or privileged (e.g.
mfpvr).  The emulation of unimplemented instructions is currently not
working on the PowerNV platform.  The reason is that on these machines,
unimplemented and illegal instructions cause a hypervisor emulation
assist interrupt, rather than a program interrupt as on older CPUs.
Our vector for the emulation assist interrupt just calls
program_check_exception() directly, without setting the bit in SRR1
that indicates an illegal instruction interrupt.  This fixes it by
making the emulation assist interrupt set that bit before calling
program_check_interrupt().  With this, old programs that use no-longer
implemented instructions such as dcba now work again.

Signed-off-by: Paul Mackerras <>
Signed-off-by: Benjamin Herrenschmidt <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agotg3: Wait for boot code to finish after power on
Nithin Sujir [Wed, 12 Jun 2013 18:08:59 +0000 (11:08 -0700)]
tg3: Wait for boot code to finish after power on

commit df465abfe06f7dc4f33f4a96d17f096e9e8ac917 upstream.

Some systems that don't need wake-on-lan may choose to power down the
chip on system standby. Upon resume, the power on causes the boot code
to startup and initialize the hardware. On one new platform, this is
causing the device to go into a bad state due to a race between the
driver and boot code, once every several hundred resumes. The same race
exists on open since we come up from a power on.

This patch adds a wait for boot code signature at the beginning of
tg3_init_hw() which is common to both cases. If there has not been a
power-off or the boot code has already completed, the signature will be
present and poll_fw() returns immediately. Also return immediately if
the device does not have firmware.

Signed-off-by: Nithin Nayak Sujir <>
Signed-off-by: Michael Chan <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agomd/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuil...
Alex Lyakas [Tue, 4 Jun 2013 17:42:21 +0000 (20:42 +0300)]
md/raid1: consider WRITE as successful only if at least one non-Faulty and non-rebuilding drive completed it.

commit 3056e3aec8d8ba61a0710fb78b2d562600aa2ea7 upstream.

Without that fix, the following scenario could happen:

- RAID1 with drives A and B; drive B was freshly-added and is rebuilding
- Drive A fails
- WRITE request arrives to the array. It is failed by drive A, so
r1_bio is marked as R1BIO_WriteError, but the rebuilding drive B
succeeds in writing it, so the same r1_bio is marked as
- r1_bio arrives to handle_write_finished, badblocks are disabled,
md_error()->error() does nothing because we don't fail the last drive
of raid1
- raid_end_bio_io()  calls call_bio_endio()
- As a result, in call_bio_endio():
        if (!test_bit(R1BIO_Uptodate, &r1_bio->state))
                clear_bit(BIO_UPTODATE, &bio->bi_flags);
this code doesn't clear the BIO_UPTODATE flag, and the whole master
WRITE succeeds, back to the upper layer.

So we returned success to the upper layer, even though we had written
the data onto the rebuilding drive only. But when we want to read the
data back, we would not read from the rebuilding drive, so this data
is lost.

[neilb - applied identical change to raid10 as well]

This bug can result in lost data, so it is suitable for any
-stable kernel.

Signed-off-by: Alex Lyakas <>
Signed-off-by: NeilBrown <>
[bwh: Backported to 3.2: for raid10, s/rdev/conf->mirrors[dev].rdev/]
Signed-off-by: Ben Hutchings <>
9 years agox86: Fix typo in kexec register clearing
Kees Cook [Wed, 5 Jun 2013 18:47:18 +0000 (11:47 -0700)]
x86: Fix typo in kexec register clearing

commit c8a22d19dd238ede87aa0ac4f7dbea8da039b9c1 upstream.

Fixes a typo in register clearing code. Thanks to PaX Team for fixing
this originally, and James Troup for pointing it out.

Signed-off-by: Kees Cook <>
Cc: PaX Team <>
Signed-off-by: H. Peter Anvin <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: pl2303: fix device initialisation at open
Johan Hovold [Mon, 10 Jun 2013 16:29:38 +0000 (18:29 +0200)]
USB: pl2303: fix device initialisation at open

commit 2d8f4447b58bba5f8cb895c07690434c02307eaf upstream.

Do not use uninitialised termios data to determine when to configure the
device at open.

This also prevents stack data from leaking to userspace in the OOM error

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: tty_struct::termios is a pointer, not a struct]
Signed-off-by: Ben Hutchings <>
9 years agoUSB: spcp8x5: fix device initialisation at open
Johan Hovold [Mon, 10 Jun 2013 16:29:39 +0000 (18:29 +0200)]
USB: spcp8x5: fix device initialisation at open

commit 5e4211f1c47560c36a8b3d4544dfd866dcf7ccd0 upstream.

Do not use uninitialised termios data to determine when to configure the
device at open.

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: tty_struct::termios is a pointer, not a struct]
Signed-off-by: Ben Hutchings <>
9 years agomm: migration: add migrate_entry_wait_huge()
Naoya Horiguchi [Wed, 12 Jun 2013 21:05:04 +0000 (14:05 -0700)]
mm: migration: add migrate_entry_wait_huge()

commit 30dad30922ccc733cfdbfe232090cf674dc374dc upstream.

When we have a page fault for the address which is backed by a hugepage
under migration, the kernel can't wait correctly and do busy looping on
hugepage fault until the migration finishes.  As a result, users who try
to kick hugepage migration (via soft offlining, for example) occasionally
experience long delay or soft lockup.

This is because pte_offset_map_lock() can't get a correct migration entry
or a correct page table lock for hugepage.  This patch introduces
migration_entry_wait_huge() to solve this.

Signed-off-by: Naoya Horiguchi <>
Reviewed-by: Rik van Riel <>
Reviewed-by: Wanpeng Li <>
Reviewed-by: Michal Hocko <>
Cc: Mel Gorman <>
Cc: Andi Kleen <>
Cc: KOSAKI Motohiro <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agoswap: avoid read_swap_cache_async() race to deadlock while waiting on discard I/O...
Rafael Aquini [Wed, 12 Jun 2013 21:04:49 +0000 (14:04 -0700)]
swap: avoid read_swap_cache_async() race to deadlock while waiting on discard I/O completion

commit cbab0e4eec299e9059199ebe6daf48730be46d2b upstream.

read_swap_cache_async() can race against get_swap_page(), and stumble
across a SWAP_HAS_CACHE entry in the swap map whose page wasn't brought
into the swapcache yet.

This transient swap_map state is expected to be transitory, but the
actual placement of discard at scan_swap_map() inserts a wait for I/O
completion thus making the thread at read_swap_cache_async() to loop
around its -EEXIST case, while the other end at get_swap_page() is
scheduled away at scan_swap_map().  This can leave the system deadlocked
if the I/O completion happens to be waiting on the CPU waitqueue where
read_swap_cache_async() is busy looping and !CONFIG_PREEMPT.

This patch introduces a cond_resched() call to make the aforementioned
read_swap_cache_async() busy loop condition to bail out when necessary,
thus avoiding the subtle race window.

Signed-off-by: Rafael Aquini <>
Acked-by: Johannes Weiner <>
Acked-by: KOSAKI Motohiro <>
Acked-by: Hugh Dickins <>
Cc: Shaohua Li <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agodrivers/rtc/rtc-twl.c: fix missing device_init_wakeup() when booted with device tree
Tony Lindgren [Wed, 12 Jun 2013 21:04:48 +0000 (14:04 -0700)]
drivers/rtc/rtc-twl.c: fix missing device_init_wakeup() when booted with device tree

commit 24b8256a1fb28d357bc6fa09184ba29b4255ba5c upstream.

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

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

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

Signed-off-by: Tony Lindgren <>
Reported-by: Kevin Hilman <>
Cc: Alessandro Zummo <>
Cc: Jingoo Han <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agocciss: fix broken mutex usage in ioctl
Stephen M. Cameron [Wed, 12 Jun 2013 21:04:47 +0000 (14:04 -0700)]
cciss: fix broken mutex usage in ioctl

commit 03f47e888daf56c8e9046c674719a0bcc644eed5 upstream.

If a new logical drive is added and the CCISS_REGNEWD ioctl is invoked
(as is normal with the Array Configuration Utility) the process will
hang as below.  It attempts to acquire the same mutex twice, once in
do_ioctl() and once in cciss_unlocked_open().  The BKL was recursive,
the mutex isn't.

  Linux version 3.10.0-rc2 (scameron@localhost.localdomain) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Fri May 24 14:32:12 CDT 2013
  acu             D 0000000000000001     0  3246   3191 0x00000080
  Call Trace:
    cciss_unlocked_open+0x2f/0x110 [cciss]
    cciss_add_disk+0x13a/0x170 [cciss]
    cciss_update_drive_info+0x39b/0x480 [cciss]
    rebuild_lun_table+0x258/0x370 [cciss]
    cciss_ioctl+0x34f/0x470 [cciss]
    do_ioctl+0x49/0x70 [cciss]

This mutex usage was added into the ioctl path when the big kernel lock
was removed.  As it turns out, these paths are all thread safe anyway
(or can easily be made so) and we don't want ioctl() to be single
threaded in any case.

Signed-off-by: Stephen M. Cameron <>
Cc: Jens Axboe <>
Cc: Mike Miller <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoaudit: wait_for_auditd() should use TASK_UNINTERRUPTIBLE
Oleg Nesterov [Wed, 12 Jun 2013 21:04:46 +0000 (14:04 -0700)]
audit: wait_for_auditd() should use TASK_UNINTERRUPTIBLE

commit f000cfdde5de4fc15dead5ccf524359c07eadf2b upstream.

audit_log_start() does wait_for_auditd() in a loop until
audit_backlog_wait_time passes or audit_skb_queue has a room.

If signal_pending() is true this becomes a busy-wait loop, schedule() in

Thanks to Guy for fully investigating and explaining the problem.

(akpm: that'll cause the system to lock up on a non-preemptible
uniprocessor kernel)

(Guy: "Our customer was in fact running a uniprocessor machine, and they
reported a system hang.")

Signed-off-by: Oleg Nesterov <>
Reported-by: Guy Streeter <>
Cc: Eric Paris <>
Cc: Al Viro <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <>
9 years agoreboot: rigrate shutdown/reboot to boot cpu
Robin Holt [Wed, 12 Jun 2013 21:04:37 +0000 (14:04 -0700)]
reboot: rigrate shutdown/reboot to boot cpu

commit cf7df378aa4ff7da3a44769b7ff6e9eef1a9f3db upstream.

We recently noticed that reboot of a 1024 cpu machine takes approx 16
minutes of just stopping the cpus.  The slowdown was tracked to commit
f96972f2dc63 ("kernel/sys.c: call disable_nonboot_cpus() in

The current implementation does all the work of hot removing the cpus
before halting the system.  We are switching to just migrating to the
boot cpu and then continuing with shutdown/reboot.

This also has the effect of not breaking x86's command line parameter
for specifying the reboot cpu.  Note, this code was shamelessly copied
from arch/x86/kernel/reboot.c with bits removed pertaining to the
reboot_cpu command line parameter.

Signed-off-by: Robin Holt <>
Tested-by: Shawn Guo <>
Cc: "Srivatsa S. Bhat" <>
Cc: H. Peter Anvin <>
Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Russ Anderson <>
Cc: Robin Holt <>
Cc: Russell King <>
Cc: Guan Xuetao <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agoCPU hotplug: provide a generic helper to disable/enable CPU hotplug
Srivatsa S. Bhat [Wed, 12 Jun 2013 21:04:36 +0000 (14:04 -0700)]
CPU hotplug: provide a generic helper to disable/enable CPU hotplug

commit 16e53dbf10a2d7e228709a7286310e629ede5e45 upstream.

There are instances in the kernel where we would like to disable CPU
hotplug (from sysfs) during some important operation.  Today the freezer
code depends on this and the code to do it was kinda tailor-made for

Restructure the code and make it generic enough to be useful for other
usecases too.

Signed-off-by: Srivatsa S. Bhat <>
Signed-off-by: Robin Holt <>
Cc: H. Peter Anvin <>
Cc: Thomas Gleixner <>
Cc: Ingo Molnar <>
Cc: Russ Anderson <>
Cc: Robin Holt <>
Cc: Russell King <>
Cc: Guan Xuetao <>
Cc: Shawn Guo <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Linus Torvalds <>
Signed-off-by: Ben Hutchings <>
9 years agob43: stop format string leaking into error msgs
Kees Cook [Fri, 10 May 2013 21:48:21 +0000 (14:48 -0700)]
b43: stop format string leaking into error msgs

commit e0e29b683d6784ef59bbc914eac85a04b650e63c upstream.

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


Signed-off-by: Kees Cook <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agoath9k: Use minstrel rate control by default
Sujith Manoharan [Thu, 6 Jun 2013 04:36:29 +0000 (10:06 +0530)]
ath9k: Use minstrel rate control by default

commit 5efac94999ff218e0101f67a059e44abb4b0b523 upstream.

The ath9k rate control algorithm has various architectural
issues that make it a poor fit in scenarios like congested
environments etc.

An example:

Change the default to minstrel which is more robust in such cases.
The ath9k RC code is left in the driver for now, maybe it can
be removed altogether later on.

Cc: Jouni Malinen <>
Cc: Linus Torvalds <>
Signed-off-by: Sujith Manoharan <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoath9k: Disable PowerSave by default
Sujith Manoharan [Sat, 1 Jun 2013 01:38:09 +0000 (07:08 +0530)]
ath9k: Disable PowerSave by default

commit 531671cb17af07281e6f28c1425f754346e65c41 upstream.

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

Signed-off-by: Sujith Manoharan <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: Fix missing length checks for L2CAP signalling PDUs
Johan Hedberg [Tue, 28 May 2013 10:46:30 +0000 (13:46 +0300)]
Bluetooth: Fix missing length checks for L2CAP signalling PDUs

commit cb3b3152b2f5939d67005cff841a1ca748b19888 upstream.

There has been code in place to check that the L2CAP length header
matches the amount of data received, but many PDU handlers have not been
checking that the data received actually matches that expected by the
specific PDU. This patch adds passing the length header to the specific
handler functions and ensures that those functions fail cleanly in the
case of an incorrect amount of data.

Signed-off-by: Johan Hedberg <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2:
 - Adjust context
 - Move uses of *req below the new check in l2cap_connect_req]
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: prefer VBT modes for SVDO-LVDS over EDID
Daniel Vetter [Mon, 10 Jun 2013 07:47:58 +0000 (09:47 +0200)]
drm/i915: prefer VBT modes for SVDO-LVDS over EDID

commit c3456fb3e4712d0448592af3c5d644c9472cd3c1 upstream.


commit 53d3b4d7778daf15900867336c85d3f8dd70600c
Author: Egbert Eich <>
Date:   Tue Jun 4 17:13:21 2013 +0200

    drm/i915/sdvo: Use &intel_sdvo->ddc instead of intel_sdvo->i2c for DDC

Egbert Eich fixed a long-standing bug where we simply used a
non-working i2c controller to read the EDID for SDVO-LVDS panels.
Unfortunately some machines seem to not be able to cope with the mode
provided in the EDID. Specifically they seem to not be able to cope
with a 4x pixel mutliplier instead of a 2x one, which seems to have
been worked around by slightly changing the panels native mode in the
VBT so that the dotclock is just barely above 50MHz.

Since it took forever to notice the breakage it's fairly safe to
assume that at least for SDVO-LVDS panels the VBT contains fairly sane
data. So just switch around the order and use VBT modes first.

v2: Also add EDID modes just in case, and spell Egbert correctly.

v3: Elaborate a bit more about what's going on on Chris' machine.

Cc: Egbert Eich <>
Cc: Chris Wilson <>
Reported-and-tested-by: Chris Wilson <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/gma500/cdv: Unpin framebuffer on crtc disable
Patrik Jakobsson [Sat, 8 Jun 2013 18:23:08 +0000 (20:23 +0200)]
drm/gma500/cdv: Unpin framebuffer on crtc disable

commit 22e7c385a80d771aaf3a15ae7ccea3b0686bbe10 upstream.

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

Reviewed-by: Daniel Vetter <>
Signed-off-by: Patrik Jakobsson <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agodrm/gma500/psb: Unpin framebuffer on crtc disable
Patrik Jakobsson [Wed, 5 Jun 2013 12:24:01 +0000 (14:24 +0200)]
drm/gma500/psb: Unpin framebuffer on crtc disable

commit 820de86a90089ee607d7864538c98a23b503c846 upstream.

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

Reviewed-by: Daniel Vetter <>
Signed-off-by: Patrik Jakobsson <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agohwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617
Guenter Roeck [Wed, 5 Jun 2013 21:09:30 +0000 (14:09 -0700)]
hwmon: (adm1021) Strengthen chip detection for ADM1021, LM84 and MAX1617

commit 591bfcfc334a003ba31c0deff03b22e73349939b upstream.

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

Modeled after chip detection code in sensors-detect command.

Signed-off-by: Guenter Roeck <>
Tested-by: Jean Delvare <>
Acked-by: Jean Delvare <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: option: blacklist network interface on Huawei E1820
Bjørn Mork [Thu, 6 Jun 2013 10:57:24 +0000 (12:57 +0200)]
USB: option: blacklist network interface on Huawei E1820

commit b8a24e6281d37243c06b9497dcbfaa98c1e2ad35 upstream.

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

Reported-by: Graham Inggs <>
Signed-off-by: Bjørn Mork <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: whiteheat: fix broken port configuration
Johan Hovold [Thu, 6 Jun 2013 11:32:47 +0000 (13:32 +0200)]
USB: whiteheat: fix broken port configuration

commit 9eecf22d2b375b9064a20421c6c307b760b03d46 upstream.

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

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoARM: 7743/1: compressed/head.S: work around new binutils warning
Arnd Bergmann [Fri, 31 May 2013 21:50:47 +0000 (22:50 +0100)]
ARM: 7743/1: compressed/head.S: work around new binutils warning

commit da94a829305f1c217cfdf6771cb1faca0917e3b9 upstream.

In August 2012, Matthew Gretton-Dann checked a change into binutils
labelled "Error on obsolete & warn on deprecated registers", apparently as
part of ARMv8 support. Apparently, this was supposed to emit the message
"Warning: This coprocessor register access is deprecated in ARMv8" when
using certain mcr/mrc instructions and building for ARMv8. Unfortunately,
the message that is actually emitted appears to be '(null)', which is
less helpful in comparison.

Even more unfortunately, this is biting us on every single kernel
build with a new gas, because arch/arm/boot/compressed/head.S and some
other files in that directory are built with -march=all since kernel
commit 80cec14a8 "[ARM] Add -march=all to assembly file build in
arch/arm/boot/compressed" back in v2.6.28.

This patch reverts Russell's nice solution and instead marks the head.S
file to be built for armv7-a, which fortunately lets us build all
instructions in that file without warnings even on the broken binutils.

Without this patch, building anything results in:

arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:565: Warning: (null)
arch/arm/boot/compressed/head.S:676: Warning: (null)
arch/arm/boot/compressed/head.S:698: Warning: (null)
arch/arm/boot/compressed/head.S:722: Warning: (null)
arch/arm/boot/compressed/head.S:726: Warning: (null)
arch/arm/boot/compressed/head.S:957: Warning: (null)
arch/arm/boot/compressed/head.S:996: Warning: (null)
arch/arm/boot/compressed/head.S:997: Warning: (null)
arch/arm/boot/compressed/head.S:1027: Warning: (null)
arch/arm/boot/compressed/head.S:1035: Warning: (null)
arch/arm/boot/compressed/head.S:1046: Warning: (null)
arch/arm/boot/compressed/head.S:1060: Warning: (null)
arch/arm/boot/compressed/head.S:1092: Warning: (null)
arch/arm/boot/compressed/head.S:1094: Warning: (null)
arch/arm/boot/compressed/head.S:1095: Warning: (null)
arch/arm/boot/compressed/head.S:1102: Warning: (null)
arch/arm/boot/compressed/head.S:1134: Warning: (null)

Signed-off-by: Arnd Bergmann <>
Cc: Matthew Gretton-Dann <>
Signed-off-by: Russell King <>
[bwh: Backported to 3.2:
 - Adjust context
 - Remove definition of asflags-y as it is now empty]
Signed-off-by: Ben Hutchings <>
9 years agoARM: 7742/1: topology: export cpu_topology
Arnd Bergmann [Fri, 31 May 2013 21:49:22 +0000 (22:49 +0100)]
ARM: 7742/1: topology: export cpu_topology

commit 92bdd3f5eba299b33c2f4407977d6fa2e2a6a0da upstream.

The cpu_topology symbol is required by any driver using the topology
interfaces, which leads to a couple of build errors:

ERROR: "cpu_topology" [drivers/net/ethernet/sfc/sfc.ko] undefined!
ERROR: "cpu_topology" [drivers/cpufreq/arm_big_little.ko] undefined!
ERROR: "cpu_topology" [drivers/block/mtip32xx/mtip32xx.ko] undefined!

The obvious solution is to export this symbol.

Signed-off-by: Arnd Bergmann <>
Acked-by: Will Deacon <>
Cc: Nicolas Pitre <>
Cc: Vincent Guittot <>
Signed-off-by: Russell King <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270
Takashi Iwai [Wed, 5 Jun 2013 06:35:26 +0000 (08:35 +0200)]
ALSA: usb-audio - Fix invalid volume resolution on Logitech HD webcam c270

commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993 upstream.

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

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


Reported-and-tested-by: Cristian Rodríguez <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: mos7720: fix hardware flow control
Johan Hovold [Tue, 4 Jun 2013 16:50:31 +0000 (18:50 +0200)]
USB: mos7720: fix hardware flow control

commit a26f009a070e840fadacb91013b2391ba7ab6cc2 upstream.

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

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

commit a07088098a650267b2eda689538133a324b9523f upstream.

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

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

commit 53d3b4d7778daf15900867336c85d3f8dd70600c upstream.

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

This regression seems to have been introduced in

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

    drm/i915: use GMBUS to manage i2c links

Signed-off-by: Egbert Eich <>
Reviewed-by: Chris Wilson <>
[danvet: Add note about which commit likely introduced this issue.]
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface
Takashi Iwai [Tue, 4 Jun 2013 14:02:54 +0000 (16:02 +0200)]
ALSA: usb-audio - Apply Logitech QuickCam Pro 9000 quirk only to audio iface

commit 8eafc0a161123d90617c9ca2eddfe87b382b1b89 upstream.

... instead of applying to all interfaces.


Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: serial: Add Option GTM681W to qcserial device table.
Richard Weinberger [Fri, 24 May 2013 10:01:51 +0000 (12:01 +0200)]
USB: serial: Add Option GTM681W to qcserial device table.

commit 8a2f132a01c2dd4c3905fa560f92019761ed72b1 upstream.

The Option GTM681W uses a qualcomm chip and can be
served by the qcserial device driver.

Signed-off-by: Richard Weinberger <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoUSB: Serial: cypress_M8: Enable FRWD Dongle hidcom device
Robert Butora [Fri, 31 May 2013 15:09:51 +0000 (18:09 +0300)]
USB: Serial: cypress_M8: Enable FRWD Dongle hidcom device

commit 6529591e3eef65f0f528a81ac169f6e294b947a7 upstream.

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

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

commit e49f3959a96dc279860af7e86e6dbcfda50580a5 upstream.

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

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

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

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

Bug reports:

Signed-off-by: Adis Hamzić <>
Signed-off-by: Alex Deucher <>
[bwh: Backported to 3.2:
 - Adjust context
 - Drop changes for Southern Islands]
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: no lvds quirk for hp t5740
Ben Mesman [Tue, 16 Apr 2013 18:00:28 +0000 (20:00 +0200)]
drm/i915: no lvds quirk for hp t5740

commit 45a211d75137b1ac869a8a758a6667f15827a115 upstream.

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

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

Signed-off-by: Ben Mesman <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
9 years agodrm: fix a use-after-free when GPU acceleration disabled
Huacai Chen [Tue, 21 May 2013 06:23:43 +0000 (06:23 +0000)]
drm: fix a use-after-free when GPU acceleration disabled

commit b7ea85a4fed37835eec78a7be3039c8dc22b8178 upstream.

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

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

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

Signed-off-by: Huacai Chen <>
Signed-off-by: Binbin Zhou <>
Reviewed-by: Michel Dänzer <>
Acked-by: Paul Menzel <>
Signed-off-by: Dave Airlie <>
Signed-off-by: Ben Hutchings <>
9 years agoACPI / video: ignore BIOS initial backlight value for HP Pavilion g6
Ash Willis [Wed, 29 May 2013 01:27:59 +0000 (01:27 +0000)]
ACPI / video: ignore BIOS initial backlight value for HP Pavilion g6

commit 780a6ec640a3fed671fc2c40e4dd30c03eca3ac3 upstream.

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

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

commit fedbe9bc6fd3e14b1ffbb3dac407777ac4a3650c upstream.

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

Signed-off-by: Alex Hung <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
9 years agoACPI video: ignore BIOS initial backlight value for HP 1000
Alex Hung [Mon, 6 May 2013 08:23:43 +0000 (08:23 +0000)]
ACPI video: ignore BIOS initial backlight value for HP 1000

commit 4ef366c583d6180b1c951147869ee5a3038834f2 upstream.

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

Signed-off-by: Alex Hung <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
9 years agoACPI video: ignore BIOS backlight value for HP dm4
Gustavo Maciel Dias Vieira [Mon, 4 Mar 2013 15:23:37 +0000 (15:23 +0000)]
ACPI video: ignore BIOS backlight value for HP dm4

commit 771d09b3c4c45d4d534a83a68e6331b97fd82e15 upstream.

On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot,
completely dimming the screen. Ignore this initial value for this

Signed-off-by: Gustavo Maciel Dias Vieira <>
Signed-off-by: Rafael J. Wysocki <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: mos7720: fix message timeouts
Johan Hovold [Mon, 27 May 2013 12:44:43 +0000 (14:44 +0200)]
USB: mos7720: fix message timeouts

commit 849513a7809175420d353625b6f651d961e99d49 upstream.

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

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

commit 6c13ff68a7ce01da7a51b44241a7aad8eaaedde7 upstream.

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

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

commit 634371911730a462626071065b64cd6e1fe213e0 upstream.

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

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

commit 72ea18a558ed7a63a50bb121ba60d73b5b38ae30 upstream.

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

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

commit 420021a395ce38b7ab2cceb52dee4038be7d8fa3 upstream.

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

Signed-off-by: Johan Hovold <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: only copy bulk_in_size as the other new fields
 don't exist here]
Signed-off-by: Ben Hutchings <>
9 years agoUSB: serial: fix Treo/Kyocera interrrupt-in urb context
Johan Hovold [Mon, 27 May 2013 12:44:37 +0000 (14:44 +0200)]
USB: serial: fix Treo/Kyocera interrrupt-in urb context

commit 5f8e2c07d75967ee49a5da1d21ddf5f50d48cda0 upstream.

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

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

commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream.

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

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

This fixes

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

Signed-off-by: Alan Stern <>
CC: Joseph Salisbury <>
CC: Tim Richardson <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agousb: dwc3: gadget: free trb pool only from epnum 2
George Cherian [Mon, 27 May 2013 09:05:49 +0000 (14:35 +0530)]
usb: dwc3: gadget: free trb pool only from epnum 2

commit 5bf8fae33d14cc5c3c53a926f9079f92c8b082b0 upstream.

we never allocate a TRB pool for physical endpoints
0 and 1 so trying to free it (a invalid TRB pool pointer)
will lead us in a warning while removing dwc3.ko module.

In order to fix the situation, all we have to do is skip
dwc3_free_trb_pool() for physical endpoints 0 and 1 just
as we while deleting endpoints from the endpoints list.

Signed-off-by: George Cherian <>
Signed-off-by: Felipe Balbi <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoxhci - correct comp_mode_recovery_timer on return from hibernate
Tony Camuso [Thu, 21 Feb 2013 21:11:27 +0000 (16:11 -0500)]
xhci - correct comp_mode_recovery_timer on return from hibernate

commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream.

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

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

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

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

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

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

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

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

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

Signed-off-by: Tony Camuso <>
Tested-by: Tony Camuso <>
Acked-by: Don Zickus <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Ben Hutchings <>
9 years agoxhci: fix list access before init
Vladimir Murzin [Tue, 9 Apr 2013 18:33:31 +0000 (22:33 +0400)]
xhci: fix list access before init

commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream.

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

Check for bw table before traversing lists in cleanup routine.

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

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

commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream.

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

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

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

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

Signed-off-by: Sergio Aguirre <>
Acked-by: David Cohen <>
Signed-off-by: Sarah Sharp <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agodrm/gma500: Increase max resolution for mode setting
Patrik Jakobsson [Thu, 25 Apr 2013 20:23:36 +0000 (22:23 +0200)]
drm/gma500: Increase max resolution for mode setting

commit cbbd379aa43890f36da934f5af619d2fb8ec3d87 upstream.

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

Signed-off-by: Patrik Jakobsson <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agoUSB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer
Ying Xue [Mon, 6 Aug 2012 09:46:37 +0000 (17:46 +0800)]
USB: ftdi_sio: Quiet sparse noise about using plain integer was NULL pointer

commit a816e3113b63753c330ca4751ea1d208e93e3015 upstream.

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

Signed-off-by: Ying Xue <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: serial: ftdi_sio: Handle the old_termios == 0 case e.g. uart_resume_port()
Andrew Worsley [Tue, 22 Nov 2011 09:00:19 +0000 (20:00 +1100)]
USB: serial: ftdi_sio: Handle the old_termios == 0 case e.g. uart_resume_port()

commit c515598e0f5769916c31c00392cc2bfe6af74e55 upstream.

  Handle null old_termios in ftdi_set_termios() calls from uart_resume_port().

Signed-off-by: Andrew Worsley <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section
Steven Rostedt (Red Hat) [Fri, 12 Apr 2013 20:40:13 +0000 (16:40 -0400)]
ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section

commit 7f49ef69db6bbf756c0abca7e9b65b32e999eec8 upstream.

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

Cc: Namhyung Kim <>
Signed-off-by: Steven Rostedt <>
[bwh: Backported to 3.2:
 - ftrace_filter_lseek() is static and not declared in ftrace.h
 - 'whence' parameter was called 'origin']
Signed-off-by: Ben Hutchings <>
9 years agothinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR
Manoj Iyer [Mon, 6 Aug 2012 23:15:37 +0000 (18:15 -0500)]
thinkpad-acpi: recognize latest V-Series using DMI_BIOS_VENDOR

commit a4f46bb9fa84642e356898ee44b670989622f8bb upstream.

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

Test on V490u
== After the patch ==

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

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

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

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

Signed-off-by: Manoj Iyer <>
Signed-off-by: Matthew Garrett <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: lock i_mutex when truncating orphan inodes
Theodore Ts'o [Thu, 27 Dec 2012 06:42:48 +0000 (01:42 -0500)]
ext4: lock i_mutex when truncating orphan inodes

commit 721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream.

Commit c278531d39 added a warning when ext4_flush_unwritten_io() is
called without i_mutex being taken.  It had previously not been taken
during orphan cleanup since races weren't possible at that point in
the mount process, but as a result of this c278531d39, we will now see
a kernel WARN_ON in this case.  Take the i_mutex in
ext4_orphan_cleanup() to suppress this warning.

Reported-by: Alexander Beregalov <>
Signed-off-by: "Theodore Ts'o" <>
Reviewed-by: Zheng Liu <>
Signed-off-by: Ben Hutchings <>
9 years agob43legacy: Fix crash on unload when firmware not available
Larry Finger [Wed, 26 Sep 2012 17:32:02 +0000 (12:32 -0500)]
b43legacy: Fix crash on unload when firmware not available

commit 2d838bb608e2d1f6cb4280e76748cb812dc822e7 upstream.

When b43legacy is loaded without the firmware being available, a following
unload generates a kernel NULL pointer dereference BUG as follows:

[  214.330789] BUG: unable to handle kernel NULL pointer dereference at 0000004c
[  214.330997] IP: [<c104c395>] drain_workqueue+0x15/0x170
[  214.331179] *pde = 00000000
[  214.331311] Oops: 0000 [#1] SMP
[  214.331471] Modules linked in: b43legacy(-) ssb pcmcia mac80211 cfg80211 af_packet mperf arc4 ppdev sr_mod cdrom sg shpchp yenta_socket pcmcia_rsrc pci_hotplug pcmcia_core battery parport_pc parport floppy container ac button edd autofs4 ohci_hcd ehci_hcd usbcore usb_common thermal processor scsi_dh_rdac scsi_dh_hp_sw scsi_dh_emc scsi_dh_alua scsi_dh fan thermal_sys hwmon ata_generic pata_ali libata [last unloaded: cfg80211]
[  214.333421] Pid: 3639, comm: modprobe Not tainted 3.6.0-rc6-wl+ #163 Source Technology VIC 9921/ALI Based Notebook
[  214.333580] EIP: 0060:[<c104c395>] EFLAGS: 00010246 CPU: 0
[  214.333687] EIP is at drain_workqueue+0x15/0x170
[  214.333788] EAX: c162ac40 EBX: cdfb8360 ECX: 0000002a EDX: 00002a2a
[  214.333890] ESI: 00000000 EDI: 00000000 EBP: cd767e7c ESP: cd767e5c
[  214.333957]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[  214.333957] CR0: 8005003b CR2: 0000004c CR3: 0c96a000 CR4: 00000090
[  214.333957] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[  214.333957] DR6: ffff0ff0 DR7: 00000400
[  214.333957] Process modprobe (pid: 3639, ti=cd766000 task=cf802e90 task.ti=cd766000)
[  214.333957] Stack:
[  214.333957]  00000292 cd767e74 c12c5e09 00000296 00000296 cdfb8360 cdfb9220 00000000
[  214.333957]  cd767e90 c104c4fd cdfb8360 cdfb9220 cd682800 cd767ea4 d0c10184 cd682800
[  214.333957]  cd767ea4 cba31064 cd767eb8 d0867908 cba31064 d087e09c cd96f034 cd767ec4
[  214.333957] Call Trace:
[  214.333957]  [<c12c5e09>] ? skb_dequeue+0x49/0x60
[  214.333957]  [<c104c4fd>] destroy_workqueue+0xd/0x150
[  214.333957]  [<d0c10184>] ieee80211_unregister_hw+0xc4/0x100 [mac80211]
[  214.333957]  [<d0867908>] b43legacy_remove+0x78/0x80 [b43legacy]
[  214.333957]  [<d083654d>] ssb_device_remove+0x1d/0x30 [ssb]
[  214.333957]  [<c126f15a>] __device_release_driver+0x5a/0xb0
[  214.333957]  [<c126fb07>] driver_detach+0x87/0x90
[  214.333957]  [<c126ef4c>] bus_remove_driver+0x6c/0xe0
[  214.333957]  [<c1270120>] driver_unregister+0x40/0x70
[  214.333957]  [<d083686b>] ssb_driver_unregister+0xb/0x10 [ssb]
[  214.333957]  [<d087c488>] b43legacy_exit+0xd/0xf [b43legacy]
[  214.333957]  [<c1089dde>] sys_delete_module+0x14e/0x2b0
[  214.333957]  [<c110a4a7>] ? vfs_write+0xf7/0x150
[  214.333957]  [<c1240050>] ? tty_write_lock+0x50/0x50
[  214.333957]  [<c110a6f8>] ? sys_write+0x38/0x70
[  214.333957]  [<c1397c55>] syscall_call+0x7/0xb
[  214.333957] Code: bc 27 00 00 00 00 a1 74 61 56 c1 55 89 e5 e8 a3 fc ff ff 5d c3 90 55 89 e5 57 56 89 c6 53 b8 40 ac 62 c1 83 ec 14 e8 bb b7 34 00 <8b> 46 4c 8d 50 01 85 c0 89 56 4c 75 03 83 0e 40 80 05 40 ac 62
[  214.333957] EIP: [<c104c395>] drain_workqueue+0x15/0x170 SS:ESP 0068:cd767e5c
[  214.333957] CR2: 000000000000004c
[  214.341110] ---[ end trace c7e90ec026d875a6 ]---Index: wireless-testing/drivers/net/wireless/b43legacy/main.c

The problem is fixed by making certain that the ucode pointer is not NULL
before deregistering the driver in mac80211.

Signed-off-by: Larry Finger <>
Signed-off-by: John W. Linville <>
Signed-off-by: Ben Hutchings <>
9 years agoxen/events: Handle VIRQ_TIMER before any other hardirq in event loop.
Keir Fraser [Thu, 28 Mar 2013 14:03:36 +0000 (10:03 -0400)]
xen/events: Handle VIRQ_TIMER before any other hardirq in event loop.

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

Reviewed-by: David Vrabel <>
Signed-off-by: Keir Fraser <>
Signed-off-by: Konrad Rzeszutek Wilk <>
(cherry picked from commit bee980d9e9642e96351fa3ca9077b853ecf62f57)
Signed-off-by: Ben Hutchings <>
9 years agojfs: fix a couple races
Dave Kleikamp [Wed, 1 May 2013 16:08:38 +0000 (11:08 -0500)]
jfs: fix a couple races

commit 73aaa22d5ffb2630456bac2f9a4ed9b81d0d7271 upstream.

This patch fixes races uncovered by xfstests testcase 068.

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

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

Reported-by: Michael L. Semon <>
Signed-off-by: Dave Kleikamp <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netfront: reduce gso_max_size to account for max TCP header
Wei Liu [Mon, 22 Apr 2013 02:20:41 +0000 (02:20 +0000)]
xen-netfront: reduce gso_max_size to account for max TCP header

commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 upstream.

The maximum packet including header that can be handled by netfront / netback
wire format is 65535. Reduce gso_max_size accordingly.

Drop skb and print warning when skb->len > 65535. This can 1) save the effort
to send malformed packet to netback, 2) help spotting misconfiguration of
netfront in the future.

Signed-off-by: Wei Liu <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agonet: Add net_ratelimited_function and net_<level>_ratelimited macros
Joe Perches [Sun, 13 May 2012 21:56:25 +0000 (21:56 +0000)]
net: Add net_ratelimited_function and net_<level>_ratelimited macros

commit 3a3bfb61e64476ff1e4ac3122cb6dec9c79b795c upstream.

__ratelimit() can be considered an inverted bool test because
it returns true when not ratelimited.  Several tests in the
kernel tree use this __ratelimit() function incorrectly.

No net_ratelimit uses are incorrect currently though.

Most uses of net_ratelimit are to log something via printk or

In order to minimize the uses of net_ratelimit, and to start
standardizing the code style used for __ratelimit() and net_ratelimit(),
add a net_ratelimited_function() macro and net_<level>_ratelimited()
logging macros similar to pr_<level>_ratelimited that use the global
net_ratelimit instead of a static per call site "struct ratelimit_state".

Signed-off-by: Joe Perches <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: better names for thresholds
Wei Liu [Thu, 2 May 2013 00:43:59 +0000 (00:43 +0000)]
xen-netback: better names for thresholds

commit 376414945d15aa636e65f7e773c1e398b7a21cb9 upstream.

This patch only changes some names to avoid confusion.

In this patch we have:

  max_skb_slots -> fatal_skb_slots

The fatal_skb_slots is the threshold to determine whether a packet is

XEN_NETBK_LEGACY_SLOTS_MAX is the maximum slots a valid packet can have at
this point. It is defined to be XEN_NETIF_NR_SLOTS_MIN because that's
guaranteed to be supported by all backends.

Suggested-by: Ian Campbell <>
Signed-off-by: Wei Liu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: avoid allocating variable size array on stack
Wei Liu [Thu, 2 May 2013 00:43:58 +0000 (00:43 +0000)]
xen-netback: avoid allocating variable size array on stack

commit 59ccb4ebbc35e36a3c143f2d1355deb75c2e628f upstream.

Tune xen_netbk_count_requests to not touch working array beyond limit, so that
we can make working array size constant.

Suggested-by: Jan Beulich <>
Signed-off-by: Wei Liu <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: remove redundent parameter in netbk_count_requests
Wei Liu [Thu, 2 May 2013 00:43:57 +0000 (00:43 +0000)]
xen-netback: remove redundent parameter in netbk_count_requests

commit ac69c26e7accb04ae2cb9ab0872068983a42b3c8 upstream.

Tracking down from the caller, first_idx is always equal to vif->tx.req_cons.
Remove it to avoid confusion.

Suggested-by: Jan Beulich <>
Signed-off-by: Wei Liu <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: don't disconnect frontend when seeing oversize packet
Wei Liu [Mon, 22 Apr 2013 02:20:43 +0000 (02:20 +0000)]
xen-netback: don't disconnect frontend when seeing oversize packet

commit 03393fd5cc2b6cdeec32b704ecba64dbb0feae3c upstream.

Some frontend drivers are sending packets > 64 KiB in length. This length
overflows the length field in the first slot making the following slots have
an invalid length.

Turn this error back into a non-fatal error by dropping the packet. To avoid
having the following slots having fatal errors, consume all slots in the

This does not reopen the security hole in XSA-39 as if the packet as an
invalid number of slots it will still hit fatal error case.

Signed-off-by: David Vrabel <>
Signed-off-by: Wei Liu <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: coalesce slots in TX path and fix regressions
Wei Liu [Mon, 22 Apr 2013 02:20:42 +0000 (02:20 +0000)]
xen-netback: coalesce slots in TX path and fix regressions

commit 2810e5b9a7731ca5fce22bfbe12c96e16ac44b6f upstream.

This patch tries to coalesce tx requests when constructing grant copy
structures. It enables netback to deal with situation when frontend's
MAX_SKB_FRAGS is larger than backend's MAX_SKB_FRAGS.

With the help of coalescing, this patch tries to address two regressions
avoid reopening the security hole in XSA-39.

Regression 1. The reduction of the number of supported ring entries (slots)
per packet (from 18 to 17). This regression has been around for some time but
remains unnoticed until XSA-39 security fix. This is fixed by coalescing

Regression 2. The XSA-39 security fix turning "too many frags" errors from
just dropping the packet to a fatal error and disabling the VIF. This is fixed
by coalescing slots (handling 18 slots when backend's MAX_SKB_FRAGS is 17)
which rules out false positive (using 18 slots is legit) and dropping packets
using 19 to `max_skb_slots` slots.

To avoid reopening security hole in XSA-39, frontend sending packet using more
than max_skb_slots is considered malicious.

The behavior of netback for packet is thus:

    1-18            slots: valid
   19-max_skb_slots slots: drop and respond with an error
   max_skb_slots+   slots: fatal error

max_skb_slots is configurable by admin, default value is 20.

Also change variable name from "frags" to "slots" in netbk_count_requests.

Please note that RX path still has dependency on MAX_SKB_FRAGS. This will be
fixed with separate patch.

Signed-off-by: Wei Liu <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: fix sparse warning
stephen hemminger [Wed, 10 Apr 2013 10:54:46 +0000 (10:54 +0000)]
xen-netback: fix sparse warning

commit 9eaee8beeeb3bca0d9b14324fd9d467d48db784c upstream.

Fix warning about 0 used as NULL.

Signed-off-by: Stephen Hemminger <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonetback: remove redundant assignment
Wei Liu [Tue, 6 Dec 2011 00:08:20 +0000 (00:08 +0000)]
netback: remove redundant assignment

commit 16ecba2605a3bbd374cd993e532264e2d8de49e5 upstream.

New value for netbk->mmap_pages[pending_idx] is assigned in
xen_netbk_alloc_page(), no need for a second assignment which
exposes internal to the outside world.

Signed-off-by: Wei Liu <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoxen-netback: remove skb in xen_netbk_alloc_page
Wei Liu [Mon, 25 Mar 2013 01:08:20 +0000 (01:08 +0000)]
xen-netback: remove skb in xen_netbk_alloc_page

commit 27f852282ab9a028f57da96d05c26f38c424a315 upstream.

This variable is never used.

Signed-off-by: Wei Liu <>
Acked-by: Ian Campbell <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: usb-audio: avoid integer overflow in create_fixed_stream_quirk()
Xi Wang [Tue, 14 Feb 2012 10:18:48 +0000 (05:18 -0500)]
ALSA: usb-audio: avoid integer overflow in create_fixed_stream_quirk()

commit 8866f405efd4171f9d9c91901d2dd02f01bacb60 upstream.

A malicious USB device could feed in a large nr_rates value.  This would
cause the subsequent call to kmemdup() to allocate a smaller buffer than
expected, leading to out-of-bounds access.

This patch validates the nr_rates value and reuses the limit introduced
in commit 4fa0e81b ("ALSA: usb-audio: fix possible hang and overflow
in parse_uac2_sample_rate_range()").

Signed-off-by: Xi Wang <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agoALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()
Xi Wang [Sun, 8 Jan 2012 14:02:52 +0000 (09:02 -0500)]
ALSA: usb-audio: fix possible hang and overflow in parse_uac2_sample_rate_range()

commit 4fa0e81b83503900be277e6273a79651b375e288 upstream.

A malicious USB device may feed in carefully crafted min/max/res values,
so that the inner loop in parse_uac2_sample_rate_range() could run for
a long time or even never terminate, e.g., given max = INT_MAX.

Also nr_rates could be a large integer, which causes an integer overflow
in the subsequent call to kmalloc() in parse_audio_format_rates_v2().
Thus, kmalloc() would allocate a smaller buffer than expected, leading
to a memory corruption.

To exploit the two vulnerabilities, an attacker needs physical access
to the machine to plug in a malicious USB device.

This patch makes two changes.

1) The type of "rate" is changed to unsigned int, so that the loop could
   stop once "rate" is larger than INT_MAX.

2) Limit nr_rates to 1024.

Suggested-by: Takashi Iwai <>
Signed-off-by: Xi Wang <>
Signed-off-by: Takashi Iwai <>
Signed-off-by: Ben Hutchings <>
9 years agotg3: Add read dma workaround for 5720
Nithin Sujir [Mon, 3 Jun 2013 09:19:34 +0000 (09:19 +0000)]
tg3: Add read dma workaround for 5720

commit 9bc297ea0622bb2a6b3abfa2fa84f0a3b86ef8c8 upstream.

Commit 091f0ea30074bc43f9250961b3247af713024bc6 "tg3: Add New 5719 Read
DMA workaround" added a workaround for TX DMA stall on the 5719. This
workaround needs to be applied to the 5720 as well.

Reported-by: Roland Dreier <>
Tested-by: Roland Dreier <>
Signed-off-by: Nithin Nayak Sujir <>
Signed-off-by: Michael Chan <>
Signed-off-by: David S. Miller <>
[bwh: Backported to 3.2: use GET_ASIC_REV() instead of tg3_asic_rev()]
Signed-off-by: Ben Hutchings <>
9 years agotg3: Add New 5719 Read DMA workaround
Michael Chan [Sun, 29 Jul 2012 19:15:43 +0000 (19:15 +0000)]
tg3: Add New 5719 Read DMA workaround

commit 091f0ea30074bc43f9250961b3247af713024bc6 upstream.

After Power-on-reset, the 5719's TX DMA length registers may contain
uninitialized values and cause TX DMA to stall.  Check for invalid
values and set a register bit to flush the TX channels.  The bit
needs to be turned off after the DMA channels have been flushed.

Signed-off-by: Michael Chan <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoiscsi-target: fix heap buffer overflow on error
Kees Cook [Thu, 23 May 2013 17:32:17 +0000 (10:32 -0700)]
iscsi-target: fix heap buffer overflow on error

commit cea4dcfdad926a27a18e188720efe0f2c9403456 upstream.

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

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


Signed-off-by: Kees Cook <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
9 years agoxfs: kill suid/sgid through the truncate path.
Dave Chinner [Mon, 27 May 2013 06:38:25 +0000 (16:38 +1000)]
xfs: kill suid/sgid through the truncate path.

commit 2962f5a5dcc56f69cbf62121a7be67cc15d6940b upstream.

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

Fix it.

Signed-off-by: Dave Chinner <>
Reviewed-by: Brian Foster <>
Signed-off-by: Ben Myers <>
(cherry picked from commit 56c19e89b38618390addfc743d822f99519055c6)
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: fix card_posted check for newer asics
Alex Deucher [Wed, 22 May 2013 15:22:51 +0000 (11:22 -0400)]
drm/radeon: fix card_posted check for newer asics

commit 09fb8bd1a63b0f9f15e655c4fe8d047e5d2bf67a upstream.

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

Reviewed-by: Michel Dänzer <>
Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
9 years agoiwlwifi: dvm: fix zero LQ CMD sending avoidance
Emmanuel Grumbach [Wed, 22 May 2013 07:48:10 +0000 (10:48 +0300)]
iwlwifi: dvm: fix zero LQ CMD sending avoidance

commit a87783699b23395c46bbeeb5d28f6db24897bf26 upstream.

In 63b77bf489881747c5118476918cc8c29378ee63

iwlwifi: dvm: don't send zeroed LQ cmd

I tried to avoid to send zeroed LQ cmd, but I made a (very)
stupid mistake in the memcmp.
Since this patch has been ported to stable, the fix should
go to stable too.

This fixes

Reported-by: Hinnerk van Bruinehsen <>
Signed-off-by: Emmanuel Grumbach <>
Signed-off-by: Johannes Berg <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agomac80211: close AP_VLAN interfaces before unregistering all
Johannes Berg [Thu, 23 May 2013 23:06:09 +0000 (01:06 +0200)]
mac80211: close AP_VLAN interfaces before unregistering all

commit c8aa22db0112f640ac6631347f850879c621840b upstream.

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

Cc: Eric Dumazet <>
Signed-off-by: Johannes Berg <>
Signed-off-by: Ben Hutchings <>