pandora-kernel.git
9 years agoLinux 3.2.29 v3.2.29
Ben Hutchings [Wed, 12 Sep 2012 02:37:38 +0000 (03:37 +0100)]
Linux 3.2.29

9 years agomm: avoid swapping out with swappiness==0
Satoru Moriya [Tue, 29 May 2012 22:06:47 +0000 (15:06 -0700)]
mm: avoid swapping out with swappiness==0

commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd upstream.

Sometimes we'd like to avoid swapping out anonymous memory.  In
particular, avoid swapping out pages of important process or process
groups while there is a reasonable amount of pagecache on RAM so that we
can satisfy our customers' requirements.

OTOH, we can control how aggressive the kernel will swap memory pages with
/proc/sys/vm/swappiness for global and
/sys/fs/cgroup/memory/memory.swappiness for each memcg.

But with current reclaim implementation, the kernel may swap out even if
we set swappiness=0 and there is pagecache in RAM.

This patch changes the behavior with swappiness==0.  If we set
swappiness==0, the kernel does not swap out completely (for global reclaim
until the amount of free pages and filebacked pages in a zone has been
reduced to something very very small (nr_free + nr_filebacked < high
watermark)).

Signed-off-by: Satoru Moriya <satoru.moriya@hds.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[bwh: Backported to 3.2:
 - Adjust context
 - vmscan_swappiness() does not have a zone parameter]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoSquashfs: fix mount time sanity check for corrupted superblock
Phillip Lougher [Mon, 2 Jan 2012 17:47:14 +0000 (17:47 +0000)]
Squashfs: fix mount time sanity check for corrupted superblock

commit cc37f75a9ffbbfcb1c3297534f293c8284e3c5a6 upstream.

A Squashfs filesystem containing nothing but an empty directory,
although unusual and ultimately pointless, is still valid.

The directory_table >= next_table sanity check rejects these
filesystems as invalid because the directory_table is empty and
equal to next_table.

Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoasus-nb-wmi: add some video toggle keys
AceLan Kao [Wed, 4 Jul 2012 07:20:14 +0000 (15:20 +0800)]
asus-nb-wmi: add some video toggle keys

commit 3766054fff4af1b58a1440a284907887f4d2e8be upstream.

There are some new video switch keys that used by newer machines.
0xA0 - SDSP HDMI only
0xA1 - SDSP LCD + HDMI
0xA2 - SDSP CRT + HDMI
0xA3 - SDSP TV + HDMI
But in Linux, there is no suitable userspace application to handle this,
so, mapping them all to KEY_SWITCHVIDEOMODE.

Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate
Trond Myklebust [Wed, 22 Aug 2012 20:08:17 +0000 (16:08 -0400)]
NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate

Fix the following Oops in 3.5.1:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
 IP: [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
 PGD 337c63067 PUD 0
 Oops: 0000 [#1] SMP
 CPU 5
 Modules linked in: nfs fscache nfsd lockd nfs_acl auth_rpcgss sunrpc af_packet binfmt_misc cpufreq_conservative cpufreq_userspace cpufreq_powersave dm_mod acpi_cpufreq mperf coretemp gpio_ich kvm_intel joydev kvm ioatdma hid_generic igb lpc_ich i7core_edac edac_core ptp serio_raw dca pcspkr i2c_i801 mfd_core sg pps_core usbhid crc32c_intel microcode button autofs4 uhci_hcd ttm drm_kms_helper drm i2c_algo_bit sysimgblt sysfillrect syscopyarea ehci_hcd usbcore usb_common scsi_dh_rdac scsi_dh_emc scsi_dh_hp_sw scsi_dh_alua scsi_dh edd fan ata_piix thermal processor thermal_sys

 Pid: 30431, comm: java Not tainted 3.5.1-2-default #1 Supermicro X8DTT/X8DTT
 RIP: 0010:[<ffffffffa03789cd>]  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
 RSP: 0018:ffff8801b418bd38  EFLAGS: 00010292
 RAX: 00000000fffffff6 RBX: ffff88032016d800 RCX: 0000000000000020
 RDX: ffffffff00000000 RSI: 0000000000000000 RDI: ffff8801824a7b00
 RBP: ffff8801b418bdf8 R08: 7fffff0034323030 R09: fffffffff04c03ed
 R10: ffff8801824a7b00 R11: 0000000000000002 R12: ffff8801824a7b00
 R13: ffff8801824a7b00 R14: 0000000000000000 R15: ffff8803201725d0
 FS:  00002b53a46cb700(0000) GS:ffff88033fc20000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000038 CR3: 000000020a426000 CR4: 00000000000007e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process java (pid: 30431, threadinfo ffff8801b418a000, task ffff8801b5d20600)
 Stack:
  ffff8801b418be44 ffff88032016d800 ffff8801b418bdf8 0000000000000000
  ffff8801824a7b00 ffff8801b418bdd7 ffff8803201725d0 ffffffff8116a9c0
  ffff8801b5c38dc0 0000000000000007 ffff88032016d800 0000000000000000
 Call Trace:
  [<ffffffff8116a9c0>] lookup_dcache+0x80/0xe0
  [<ffffffff8116aa43>] __lookup_hash+0x23/0x90
  [<ffffffff8116b4a5>] lookup_one_len+0xc5/0x100
  [<ffffffffa03869a3>] nfs_sillyrename+0xe3/0x210 [nfs]
  [<ffffffff8116cadf>] vfs_unlink.part.25+0x7f/0xe0
  [<ffffffff8116f22c>] do_unlinkat+0x1ac/0x1d0
  [<ffffffff815717b9>] system_call_fastpath+0x16/0x1b
  [<00002b5348b5f527>] 0x2b5348b5f526
 Code: ec 38 b8 f6 ff ff ff 4c 89 64 24 18 4c 89 74 24 28 49 89 fc 48 89 5c 24 08 48 89 6c 24 10 49 89 f6 4c 89 6c 24 20 4c 89 7c 24 30 <f6> 46 38 40 0f 85 d1 00 00 00 e8 c4 c4 df e0 48 8b 58 30 49 89
 RIP  [<ffffffffa03789cd>] nfs_lookup_revalidate+0x2d/0x480 [nfs]
  RSP <ffff8801b418bd38>
 CR2: 0000000000000038
 ---[ end trace 845113ed191985dd ]---

This Oops affects 3.5 kernels and older, and is due to lookup_one_len()
calling down to the dentry revalidation code with a NULL pointer
to struct nameidata.

It is fixed upstream by commit 0b728e1911c (stop passing nameidata *
to ->d_revalidate())

Reported-by: Richard Ems <richard.ems@cape-horn-eng.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoStaging: speakup: fix an improperly-declared variable.
Christopher Brannon [Sat, 16 Jun 2012 21:55:20 +0000 (16:55 -0500)]
Staging: speakup: fix an improperly-declared variable.

commit 4ea418b8b2fa8a70d0fcc8231b65e67b3a72984b upstream.

A local static variable was declared as a pointer to a string
constant.  We're assigning to the underlying memory, so it
needs to be an array instead.

Signed-off-by: Christopher Brannon <chris@the-brannons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopmac_zilog,kdb: Fix console poll hook to return instead of loop
Jason Wessel [Sun, 12 Aug 2012 12:16:43 +0000 (07:16 -0500)]
pmac_zilog,kdb: Fix console poll hook to return instead of loop

commit 38f8eefccf3a23c4058a570fa2938a4f553cf8e0 upstream.

kdb <-> kgdb transitioning does not work properly with this UART
driver because the get character routine loops indefinitely as opposed
to returning NO_POLL_CHAR per the expectation of the KDB I/O driver
API.

The symptom is a kernel hang when trying to switch debug modes.

Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoHID: add support for Cypress barcode scanner 04B4:ED81
Lionel Vaux [Sun, 22 Jul 2012 09:32:20 +0000 (11:32 +0200)]
HID: add support for Cypress barcode scanner 04B4:ED81

commit 76c9d8fe2c7fc34ffc387d8022c5828d6ff9df48 upstream.

Add yet another device to the list of Cypress barcode scanners
needing the CP_RDESC_SWAPPED_MIN_MAX quirk.

Signed-off-by: Lionel Vaux (iouri) <lionel.vaux@free.fr>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovirtio-blk: Reset device after blk_cleanup_queue()
Asias He [Fri, 25 May 2012 02:34:48 +0000 (10:34 +0800)]
virtio-blk: Reset device after blk_cleanup_queue()

commit 483001c765af6892b3fc3726576cb42f17d1d6b5 upstream.

blk_cleanup_queue() will call blk_drian_queue() to drain all the
requests before queue DEAD marking. If we reset the device before
blk_cleanup_queue() the drain would fail.

1) if the queue is stopped in do_virtblk_request() because device is
full, the q->request_fn() will not be called.

blk_drain_queue() {
   while(true) {
      ...
      if (!list_empty(&q->queue_head))
        __blk_run_queue(q) {
    if (queue is not stoped)
q->request_fn()
}
      ...
   }
}

Do no reset the device before blk_cleanup_queue() gives the chance to
start the queue in interrupt handler blk_done().

2) In commit b79d866c8b7014a51f611a64c40546109beaf24a, We abort requests
dispatched to driver before blk_cleanup_queue(). There is a race if
requests are dispatched to driver after the abort and before the queue
DEAD mark. To fix this, instead of aborting the requests explicitly, we
can just reset the device after after blk_cleanup_queue so that the
device can complete all the requests before queue DEAD marking in the
drain process.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Signed-off-by: Asias He <asias@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovirtio-blk: Call del_gendisk() before disable guest kick
Asias He [Fri, 25 May 2012 02:34:47 +0000 (10:34 +0800)]
virtio-blk: Call del_gendisk() before disable guest kick

commit 02e2b124943648fba0a2ccee5c3656a5653e0151 upstream.

del_gendisk() might not return due to failing to remove the
/sys/block/vda/serial sysfs entry when another thread (udev) is
trying to read it.

virtblk_remove()
  vdev->config->reset() : guest will not kick us through interrupt
    del_gendisk()
      device_del()
        kobject_del(): got stuck, sysfs entry ref count non zero

sysfs_open_file(): user space process read /sys/block/vda/serial
   sysfs_get_active() : got sysfs entry ref count
      dev_attr_show()
        virtblk_serial_show()
           blk_execute_rq() : got stuck, interrupt is disabled
                              request cannot be finished

This patch fixes it by calling del_gendisk() before we disable guest's
interrupt so that the request sent in virtblk_serial_show() will be
finished and del_gendisk() will success.

This fixes another race in hot-unplug process.

It is save to call del_gendisk(vblk->disk) before
flush_work(&vblk->config_work) which might access vblk->disk, because
vblk->disk is not freed until put_disk(vblk->disk).

Cc: virtualization@lists.linux-foundation.org
Cc: kvm@vger.kernel.org
Signed-off-by: Asias He <asias@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovirtio-blk: Fix hot-unplug race in remove method
Asias He [Fri, 4 May 2012 12:22:04 +0000 (20:22 +0800)]
virtio-blk: Fix hot-unplug race in remove method

commit b79d866c8b7014a51f611a64c40546109beaf24a upstream.

If we reset the virtio-blk device before the requests already dispatched
to the virtio-blk driver from the block layer are finised, we will stuck
in blk_cleanup_queue() and the remove will fail.

blk_cleanup_queue() calls blk_drain_queue() to drain all requests queued
before DEAD marking. However it will never success if the device is
already stopped. We'll have q->in_flight[] > 0, so the drain will not
finish.

How to reproduce the race:
1. hot-plug a virtio-blk device
2. keep reading/writing the device in guest
3. hot-unplug while the device is busy serving I/O

Test:
~1000 rounds of hot-plug/hot-unplug test passed with this patch.

Changes in v3:
- Drop blk_abort_queue and blk_abort_request
- Use __blk_end_request_all to complete request dispatched to driver

Changes in v2:
- Drop req_in_flight
- Use virtqueue_detach_unused_buf to get request dispatched to driver

Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovirtio_blk: Drop unused request tracking list
Asias He [Fri, 30 Mar 2012 03:24:10 +0000 (11:24 +0800)]
virtio_blk: Drop unused request tracking list

commit f65ca1dc6a8c81c6bd72297d4399ec5f4c1f3a01 upstream.

Benchmark shows small performance improvement on fusion io device.

Before:
  seq-read : io=1,024MB, bw=19,982KB/s, iops=39,964, runt= 52475msec
  seq-write: io=1,024MB, bw=20,321KB/s, iops=40,641, runt= 51601msec
  rnd-read : io=1,024MB, bw=15,404KB/s, iops=30,808, runt= 68070msec
  rnd-write: io=1,024MB, bw=14,776KB/s, iops=29,552, runt= 70963msec

After:
  seq-read : io=1,024MB, bw=20,343KB/s, iops=40,685, runt= 51546msec
  seq-write: io=1,024MB, bw=20,803KB/s, iops=41,606, runt= 50404msec
  rnd-read : io=1,024MB, bw=16,221KB/s, iops=32,442, runt= 64642msec
  rnd-write: io=1,024MB, bw=15,199KB/s, iops=30,397, runt= 68991msec

Signed-off-by: Asias He <asias@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovirtio_blk: fix config handler race
Michael S. Tsirkin [Thu, 12 Jan 2012 05:14:44 +0000 (15:44 +1030)]
virtio_blk: fix config handler race

commit 4678d6f970c2f7c0cbfefc0cc666432d153b321b upstream.

Fix a theoretical race related to config work
handler: a config interrupt might happen
after we flush config work but before we
reset the device. It will then cause the
config work to run during or after reset.

Two problems with this:
- if this runs after device is gone we will get use after free
- access of config while reset is in progress is racy
(as layout is changing).

As a solution
1. flush after reset when we know there will be no more interrupts
2. add a flag to disable config access before reset

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodmi: Feed DMI table to /dev/random driver
Tony Luck [Fri, 20 Jul 2012 20:15:20 +0000 (13:15 -0700)]
dmi: Feed DMI table to /dev/random driver

commit d114a33387472555188f142ed8e98acdb8181c6d upstream.

Send the entire DMI (SMBIOS) table to the /dev/random driver to
help seed its pools.

Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agorandom: Add comment to random_initialize()
Tony Luck [Mon, 23 Jul 2012 16:47:57 +0000 (09:47 -0700)]
random: Add comment to random_initialize()

commit cbc96b7594b5691d61eba2db8b2ea723645be9ca upstream.

Many platforms have per-machine instance data (serial numbers,
asset tags, etc.) squirreled away in areas that are accessed
during early system bringup. Mixing this data into the random
pools has a very high value in providing better random data,
so we should allow (and even encourage) architecture code to
call add_device_randomness() from the setup_arch() paths.

However, this limits our options for internal structure of
the random driver since random_initialize() is not called
until long after setup_arch().

Add a big fat comment to rand_initialize() spelling out
this requirement.

Suggested-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoMAINTAINERS: Theodore Ts'o is taking over the random driver
Theodore Ts'o [Wed, 4 Jul 2012 15:32:48 +0000 (11:32 -0400)]
MAINTAINERS: Theodore Ts'o is taking over the random driver

commit 330e0a01d54c2b8606c56816f99af6ebc58ec92c upstream.

Matt Mackall stepped down as the /dev/random driver maintainer last
year, so Theodore Ts'o is taking back the /dev/random driver.

Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrivers/char/random.c: fix boot id uniqueness race
Mathieu Desnoyers [Thu, 12 Apr 2012 19:49:12 +0000 (12:49 -0700)]
drivers/char/random.c: fix boot id uniqueness race

commit 44e4360fa3384850d65dd36fb4e6e5f2f112709b upstream.

/proc/sys/kernel/random/boot_id can be read concurrently by userspace
processes.  If two (or more) user-space processes concurrently read
boot_id when sysctl_bootid is not yet assigned, a race can occur making
boot_id differ between the reads.  Because the whole point of the boot id
is to be unique across a kernel execution, fix this by protecting this
operation with a spinlock.

Given that this operation is not frequently used, hitting the spinlock
on each call should not be an issue.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Greg Kroah-Hartman <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: Fix using uninitialized option in RFCMode
Szymon Janc [Fri, 8 Jun 2012 09:33:33 +0000 (11:33 +0200)]
Bluetooth: Fix using uninitialized option in RFCMode

commit 8f321f853ea33330c7141977cd34804476e2e07e upstream.

If remote device sends bogus RFC option with invalid length,
undefined options values are used. Fix this by using defaults when
remote misbehaves.

This also fixes the following warning reported by gcc 4.7.0:

net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp':
net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here
net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here
net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here
net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here

Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoblock: replace __getblk_slow misfix by grow_dev_page fix
Hugh Dickins [Thu, 23 Aug 2012 10:17:36 +0000 (12:17 +0200)]
block: replace __getblk_slow misfix by grow_dev_page fix

commit 676ce6d5ca3098339c028d44fe0427d1566a4d2d upstream.

Commit 91f68c89d8f3 ("block: fix infinite loop in __getblk_slow")
is not good: a successful call to grow_buffers() cannot guarantee
that the page won't be reclaimed before the immediate next call to
__find_get_block(), which is why there was always a loop there.

Yesterday I got "EXT4-fs error (device loop0): __ext4_get_inode_loc:3595:
inode #19278: block 664: comm cc1: unable to read itable block" on console,
which pointed to this commit.

I've been trying to bisect for weeks, why kbuild-on-ext4-on-loop-on-tmpfs
sometimes fails from a missing header file, under memory pressure on
ppc G5.  I've never seen this on x86, and I've never seen it on 3.5-rc7
itself, despite that commit being in there: bisection pointed to an
irrelevant pinctrl merge, but hard to tell when failure takes between
18 minutes and 38 hours (but so far it's happened quicker on 3.6-rc2).

(I've since found such __ext4_get_inode_loc errors in /var/log/messages
from previous weeks: why the message never appeared on console until
yesterday morning is a mystery for another day.)

Revert 91f68c89d8f3, restoring __getblk_slow() to how it was (plus
a checkpatch nitfix).  Simplify the interface between grow_buffers()
and grow_dev_page(), and avoid the infinite loop beyond end of device
by instead checking init_page_buffers()'s end_block there (I presume
that's more efficient than a repeated call to blkdev_max_block()),
returning -ENXIO to __getblk_slow() in that case.

And remove akpm's ten-year-old "__getblk() cannot fail ... weird"
comment, but that is worrying: are all users of __getblk() really
now prepared for a NULL bh beyond end of device, or will some oops??

Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agofs/buffer.c: remove BUG() in possible but rare condition
Glauber Costa [Wed, 25 Apr 2012 23:01:48 +0000 (16:01 -0700)]
fs/buffer.c: remove BUG() in possible but rare condition

commit 61065a30af8df4b8989c2ac7a1f4b4034e4df2d5 upstream.

While stressing the kernel with with failing allocations today, I hit the
following chain of events:

alloc_page_buffers():

bh = alloc_buffer_head(GFP_NOFS);
if (!bh)
goto no_grow; <= path taken

grow_dev_page():
        bh = alloc_page_buffers(page, size, 0);
        if (!bh)
                goto failed;  <= taken, consequence of the above

and then the failed path BUG()s the kernel.

The failure is inserted a litte bit artificially, but even then, I see no
reason why it should be deemed impossible in a real box.

Even though this is not a condition that we expect to see around every
time, failed allocations are expected to be handled, and BUG() sounds just
too much.  As a matter of fact, grow_dev_page() can return NULL just fine
in other circumstances, so I propose we just remove it, then.

Signed-off-by: Glauber Costa <glommer@parallels.com>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agorapidio/tsi721: fix unused variable compiler warning
Alexandre Bounine [Tue, 21 Aug 2012 23:16:12 +0000 (16:16 -0700)]
rapidio/tsi721: fix unused variable compiler warning

commit 9a9a9a7adafe62a34de8b4fb48936c1c5f9bafa5 upstream.

Fix unused variable compiler warning when built with CONFIG_RAPIDIO_DEBUG
option off.

This patch is applicable to kernel versions starting from v3.2

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agorapidio/tsi721: fix inbound doorbell interrupt handling
Alexandre Bounine [Tue, 21 Aug 2012 23:16:11 +0000 (16:16 -0700)]
rapidio/tsi721: fix inbound doorbell interrupt handling

commit 3670e7e12e582c6d67761275d148171feb7a9004 upstream.

Make sure that there is no doorbell messages left behind due to disabled
interrupts during inbound doorbell processing.

The most common case for this bug is loss of rionet JOIN messages in
systems with three or more rionet participants and MSI or MSI-X enabled.
As result, requests for packet transfers may finish with "destination
unreachable" error message.

This patch is applicable to kernel versions starting from v3.2.

Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrivers/rtc/rtc-rs5c348.c: fix hour decoding in 12-hour mode
Atsushi Nemoto [Tue, 21 Aug 2012 23:16:10 +0000 (16:16 -0700)]
drivers/rtc/rtc-rs5c348.c: fix hour decoding in 12-hour mode

commit 7dbfb315b2aaef0a115765946bf3026d074c33a7 upstream.

Correct the offset by subtracting 20 from tm_hour before taking the
modulo 12.

[ "Why 20?" I hear you ask. Or at least I did.

  Here's the reason why: RS5C348_BIT_PM is 32, and is - stupidly -
  included in the RS5C348_HOURS_MASK define.  So it's really subtracting
  out that bit to get "hour+12".  But then because it does things modulo
  12, it needs to add the 12 in again afterwards anyway.

  This code is confused.  It would be much clearer if RS5C348_HOURS_MASK
  just didn't include the RS5C348_BIT_PM bit at all, then it wouldn't
  need to do the silly subtract either.

  Whatever. It's all just math, the end result is the same.   - Linus ]

Reported-by: James Nute <newten82@gmail.com>
Tested-by: James Nute <newten82@gmail.com>
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrivers/misc/sgi-xp/xpc_uv.c: SGI XPC fails to load when cpu 0 is out of IRQ resources
Robin Holt [Tue, 21 Aug 2012 23:16:02 +0000 (16:16 -0700)]
drivers/misc/sgi-xp/xpc_uv.c: SGI XPC fails to load when cpu 0 is out of IRQ resources

commit 7838f994b4fceff24c343f4e26a6cf4393869579 upstream.

On many of our larger systems, CPU 0 has had all of its IRQ resources
consumed before XPC loads.  Worst cases on machines with multiple 10
GigE cards and multiple IB cards have depleted the entire first socket
of IRQs.

This patch makes selecting the node upon which IRQs are allocated (as
well as all the other GRU Message Queue structures) specifiable as a
module load param and has a default behavior of searching all nodes/cpus
for an available resources.

[akpm@linux-foundation.org: fix build: include cpu.h and module.h]
Signed-off-by: Robin Holt <holt@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agomm: hugetlbfs: correctly populate shared pmd
Michal Hocko [Tue, 21 Aug 2012 23:15:52 +0000 (16:15 -0700)]
mm: hugetlbfs: correctly populate shared pmd

commit eb48c071464757414538c68a6033c8f8c15196f8 upstream.

Each page mapped in a process's address space must be correctly
accounted for in _mapcount.  Normally the rules for this are
straightforward but hugetlbfs page table sharing is different.  The page
table pages at the PMD level are reference counted while the mapcount
remains the same.

If this accounting is wrong, it causes bugs like this one reported by
Larry Woodman:

  kernel BUG at mm/filemap.c:135!
  invalid opcode: 0000 [#1] SMP
  CPU 22
  Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr acpi_pad acpi]
  Pid: 18001, comm: mpitest Tainted: G        W    3.3.0+ #4 Dell Inc. PowerEdge R620/07NDJ2
  RIP: 0010:[<ffffffff8112cfed>]  [<ffffffff8112cfed>] __delete_from_page_cache+0x15d/0x170
  Process mpitest (pid: 18001, threadinfo ffff880428972000, task ffff880428b5cc20)
  Call Trace:
    delete_from_page_cache+0x40/0x80
    truncate_hugepages+0x115/0x1f0
    hugetlbfs_evict_inode+0x18/0x30
    evict+0x9f/0x1b0
    iput_final+0xe3/0x1e0
    iput+0x3e/0x50
    d_kill+0xf8/0x110
    dput+0xe2/0x1b0
    __fput+0x162/0x240

During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc()
shared page tables with the check dst_pte == src_pte.  The logic is if
the PMD page is the same, they must be shared.  This assumes that the
sharing is between the parent and child.  However, if the sharing is
with a different process entirely then this check fails as in this
diagram:

  parent
    |
    ------------>pmd
                 src_pte----------> data page
                                        ^
  other--------->pmd--------------------|
                  ^
  child-----------|
                 dst_pte

For this situation to occur, it must be possible for Parent and Other to
have faulted and failed to share page tables with each other.  This is
possible due to the following style of race.

  PROC A                                          PROC B
  copy_hugetlb_page_range                         copy_hugetlb_page_range
    src_pte == huge_pte_offset                      src_pte == huge_pte_offset
    !src_pte so no sharing                          !src_pte so no sharing

  (time passes)

  hugetlb_fault                                   hugetlb_fault
    huge_pte_alloc                                  huge_pte_alloc
      huge_pmd_share                                 huge_pmd_share
        LOCK(i_mmap_mutex)
        find nothing, no sharing
        UNLOCK(i_mmap_mutex)
                                                      LOCK(i_mmap_mutex)
                                                      find nothing, no sharing
                                                      UNLOCK(i_mmap_mutex)
      pmd_alloc                                       pmd_alloc
      LOCK(instantiation_mutex)
      fault
      UNLOCK(instantiation_mutex)
                                                  LOCK(instantiation_mutex)
                                                  fault
                                                  UNLOCK(instantiation_mutex)

These two processes are not poing to the same data page but are not
sharing page tables because the opportunity was missed.  When either
process later forks, the src_pte == dst pte is potentially insufficient.
As the check falls through, the wrong PTE information is copied in
(harmless but wrong) and the mapcount is bumped for a page mapped by a
shared page table leading to the BUG_ON.

This patch addresses the issue by moving pmd_alloc into huge_pmd_share
which guarantees that the shared pud is populated in the same critical
section as pmd.  This also means that huge_pte_offset test in
huge_pmd_share is serialized correctly now which in turn means that the
success of the sharing will be higher as the racing tasks see the pud
and pmd populated together.

Race identified and changelog written mostly by Mel Gorman.

{akpm@linux-foundation.org: attempt to make the huge_pmd_share() comment comprehensible, clean up coding style]
Reported-by: Larry Woodman <lwoodman@redhat.com>
Tested-by: Larry Woodman <lwoodman@redhat.com>
Reviewed-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Ken Chen <kenchen@google.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agocciss: fix incorrect scsi status reporting
Stephen M. Cameron [Tue, 21 Aug 2012 23:15:49 +0000 (16:15 -0700)]
cciss: fix incorrect scsi status reporting

commit b0cf0b118c90477d1a6811f2cd2307f6a5578362 upstream.

Delete code which sets SCSI status incorrectly as it's already been set
correctly above this incorrect code.  The bug was introduced in 2009 by
commit b0e15f6db111 ("cciss: fix typo that causes scsi status to be
lost.")

Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reported-by: Roel van Meer <roel.vanmeer@bokxing.nl>
Tested-by: Roel van Meer <roel.vanmeer@bokxing.nl>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agofbcon: fix race condition between console lock and cursor timer (v1.1)
Dave Airlie [Tue, 21 Aug 2012 06:29:47 +0000 (16:29 +1000)]
fbcon: fix race condition between console lock and cursor timer (v1.1)

commit d8636a2717bb3da2a7ce2154bf08de90bb8c87b0 upstream.

So we've had a fair few reports of fbcon handover breakage between
efi/vesafb and i915 surface recently, so I dedicated a couple of
days to finding the problem.

Essentially the last thing we saw was the conflicting framebuffer
message and that was all.

So after much tracing with direct netconsole writes (printks
under console_lock not so useful), I think I found the race.

Thread A (driver load)    Thread B (timer thread)
  unbind_con_driver ->              |
  bind_con_driver ->                |
  vc->vc_sw->con_deinit ->          |
  fbcon_deinit ->                   |
  console_lock()                    |
      |                             |
      |                       fbcon_flashcursor timer fires
      |                       console_lock() <- blocked for A
      |
      |
fbcon_del_cursor_timer ->
  del_timer_sync
  (BOOM)

Of course because all of this is under the console lock,
we never see anything, also since we also just unbound the active
console guess what we never see anything.

Hopefully this fixes the problem for anyone seeing vesafb->kms
driver handoff.

v1.1: add comment suggestion from Alan.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoRevert "drm/radeon: fix bo creation retry path"
Alex Deucher [Tue, 21 Aug 2012 13:55:01 +0000 (09:55 -0400)]
Revert "drm/radeon: fix bo creation retry path"

commit 676bc2e1e4f9072f7a640d5b7c99ffdf9709a6e7 upstream.

This reverts commit d1c7871ddb1f588b8eb35affd9ee1a3d5e11cd0c.

ttm_bo_init() destroys the BO on failure. So this patch makes
the retry path work with freed memory.  This ends up causing
kernel panics when this path is hit.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agosvcrpc: fix svc_xprt_enqueue/svc_recv busy-looping
J. Bruce Fields [Fri, 17 Aug 2012 21:31:53 +0000 (17:31 -0400)]
svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping

commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream.

The rpc server tries to ensure that there will be room to send a reply
before it receives a request.

It does this by tracking, in xpt_reserved, an upper bound on the total
size of the replies that is has already committed to for the socket.

Currently it is adding in the estimate for a new reply *before* it
checks whether there is space available.  If it finds that there is not
space, it then subtracts the estimate back out.

This may lead the subsequent svc_xprt_enqueue to decide that there is
space after all.

The results is a svc_recv() that will repeatedly return -EAGAIN, causing
server threads to loop without doing any actual work.

Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agosvcrpc: sends on closed socket should stop immediately
J. Bruce Fields [Mon, 20 Aug 2012 20:04:40 +0000 (16:04 -0400)]
svcrpc: sends on closed socket should stop immediately

commit f06f00a24d76e168ecb38d352126fd203937b601 upstream.

svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply.
However, the XPT_CLOSE won't be acted on immediately.  Meanwhile other
threads could send further replies before the socket is really shut
down.  This can manifest as data corruption: for example, if a truncated
read reply is followed by another rpc reply, that second reply will look
to the client like further read data.

Symptoms were data corruption preceded by svc_tcp_sendto logging
something like

kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket

Reported-by: Malahal Naineni <malahal@us.ibm.com>
Tested-by: Malahal Naineni <malahal@us.ibm.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agosvcrpc: fix BUG() in svc_tcp_clear_pages
J. Bruce Fields [Thu, 9 Aug 2012 22:12:28 +0000 (18:12 -0400)]
svcrpc: fix BUG() in svc_tcp_clear_pages

commit be1e44441a560c43c136a562d49a1c9623c91197 upstream.

Examination of svc_tcp_clear_pages shows that it assumes sk_tcplen is
consistent with sk_pages[] (in particular, sk_pages[n] can't be NULL if
sk_tcplen would lead us to expect n pages of data).

svc_tcp_restore_pages zeroes out sk_pages[] while leaving sk_tcplen.
This is OK, since both functions are serialized by XPT_BUSY.  However,
that means the inconsistency must be repaired before dropping XPT_BUSY.

Therefore we should be ensuring that svc_tcp_save_pages repairs the
problem before exiting svc_tcp_recv_record on error.

Symptoms were a BUG() in svc_tcp_clear_pages.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovfs: missed source of ->f_pos races
Al Viro [Mon, 20 Aug 2012 14:28:00 +0000 (15:28 +0100)]
vfs: missed source of ->f_pos races

commit 0e665d5d1125f9f4ccff56a75e814f10f88861a2 upstream.

compat_sys_{read,write}v() need the same "pass a copy of file->f_pos" thing
as sys_{read,write}{,v}().

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFSv3: Ensure that do_proc_get_root() reports errors correctly
Trond Myklebust [Mon, 20 Aug 2012 16:42:15 +0000 (12:42 -0400)]
NFSv3: Ensure that do_proc_get_root() reports errors correctly

commit 086600430493e04b802bee6e5b3ce0458e4eb77f upstream.

If the rpc call to NFS3PROC_FSINFO fails, then we need to report that
error so that the mount fails. Otherwise we can end up with a
superblock with completely unusable values for block sizes, maxfilesize,
etc.

Reported-by: Yuanming Chen <hikvision_linux@163.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: split ATRM support out from the ATPX handler (v3)
Alex Deucher [Thu, 16 Aug 2012 19:39:09 +0000 (15:39 -0400)]
drm/radeon: split ATRM support out from the ATPX handler (v3)

commit c61e2775873f603148e8e998a938721b7d222d24 upstream.

There are systems that use ATRM, but not ATPX.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41265

V2: fix #ifdefs as per Greg's comments
V3: fix it harder

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: fix use after free in ATRM bios reading code.
Dave Airlie [Thu, 2 Feb 2012 15:25:16 +0000 (15:25 +0000)]
drm/radeon: fix use after free in ATRM bios reading code.

commit de47a9cd62771e3e78954d855d2304fbad4c5a44 upstream.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=45503

Reported-and-Debugged-by: mlambda@gmail.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: finish getting bios earlier
Igor Murzov [Sun, 22 Jan 2012 14:47:28 +0000 (18:47 +0400)]
drm/radeon: finish getting bios earlier

commit 211fa4fc4e13492151e698d92b0dff56b29928ec upstream.

Return a number of bytes read in radeon_atrm_get_bios_chunk() and
properly check this value in radeon_atrm_get_bios().
If radeon_atrm_get_bios_chunk() read less bytes then were requested,
it means that it finished reading bios data.

Prior to this patch, condition in radeon_atrm_get_bios() was always
equivalent to "if (ATRM_BIOS_PAGE <= 0)", so it was always false,
thus radeon_atrm_get_bios() was trying to read past the bios data
wasting boot time.

On my lenovo ideapad u455 laptop this patch drops bios reading time
from ~5.5s to ~1.5s.

Signed-off-by: Igor Murzov <e-mail@date.by>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: fix invalid memory access in radeon_atrm_get_bios()
Igor Murzov [Sun, 22 Jan 2012 14:43:25 +0000 (18:43 +0400)]
drm/radeon: fix invalid memory access in radeon_atrm_get_bios()

commit a3f83ab1a717c0e6c2f59a4cfdaa10707cc35c55 upstream.

At a boot time I observed following bug:

 BUG: unable to handle kernel paging request at ffff8800a4244000
 IP: [<ffffffff81275b5b>] memcpy+0xb/0x120
 PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 80000000a4244160
 Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
 CPU 0
 Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 radeon(+)
  mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core
  sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys snd_hda_codec_hdmi
  joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec
  snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon
  i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw snd_page_alloc
  loop btrfs

 Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046                           /AMD CRB
 RIP: 0010:[<ffffffff81275b5b>]  [<ffffffff81275b5b>] memcpy+0xb/0x120
 RSP: 0018:ffff8800aa72db00  EFLAGS: 00010246
 RAX: ffff8800a4150000 RBX: 0000000000001000 RCX: 0000000000000087
 RDX: 0000000000000000 RSI: ffff8800a4244000 RDI: ffff8800a4150bc8
 RBP: ffff8800aa72db78 R08: 0000000000000010 R09: ffffffff8174bbec
 R10: ffffffff812ee010 R11: 0000000000000001 R12: 0000000000001000
 R13: 0000000000010000 R14: ffff8800a4140000 R15: ffff8800aaba1800
 FS:  00007ff9a3bd4720(0000) GS:ffff8800afa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: ffff8800a4244000 CR3: 00000000a9c18000 CR4: 00000000000006f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process modprobe (pid: 1008, threadinfo ffff8800aa72c000, task ffff8800aa0e4000)
 Stack:
  ffffffffa04e7c7b 0000000000000001 0000000000010000 ffff8800aa72db28
  ffffffff00000001 0000000000001000 ffffffff8113cbef 0000000000000020
  ffff8800a4243420 ffff880000000002 ffff8800aa72db08 ffff8800a9d42000
 Call Trace:
  [<ffffffffa04e7c7b>] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon]
  [<ffffffff8113cbef>] ? kmalloc_order_trace+0x3f/0xb0
  [<ffffffffa04a9298>] radeon_get_bios+0x68/0x2f0 [radeon]
  [<ffffffffa04c7a30>] rv770_init+0x40/0x280 [radeon]
  [<ffffffffa047d740>] radeon_device_init+0x560/0x600 [radeon]
  [<ffffffffa047ef4f>] radeon_driver_load_kms+0xaf/0x170 [radeon]
  [<ffffffffa043cdde>] drm_get_pci_dev+0x18e/0x2c0 [drm]
  [<ffffffffa04e7e95>] radeon_pci_probe+0xad/0xb5 [radeon]
  [<ffffffff81296c5f>] local_pci_probe+0x5f/0xd0
  [<ffffffff81297418>] pci_device_probe+0x88/0xb0
  [<ffffffff813417aa>] ? driver_sysfs_add+0x7a/0xb0
  [<ffffffff813418d8>] really_probe+0x68/0x180
  [<ffffffff81341be5>] driver_probe_device+0x45/0x70
  [<ffffffff81341cb3>] __driver_attach+0xa3/0xb0
  [<ffffffff81341c10>] ? driver_probe_device+0x70/0x70
  [<ffffffff813400ce>] bus_for_each_dev+0x5e/0x90
  [<ffffffff8134172e>] driver_attach+0x1e/0x20
  [<ffffffff81341298>] bus_add_driver+0xc8/0x280
  [<ffffffff813422c6>] driver_register+0x76/0x140
  [<ffffffff812976d6>] __pci_register_driver+0x66/0xe0
  [<ffffffffa043d021>] drm_pci_init+0x111/0x120 [drm]
  [<ffffffff8133c67a>] ? vga_switcheroo_register_handler+0x3a/0x60
  [<ffffffffa0229000>] ? 0xffffffffa0228fff
  [<ffffffffa02290ec>] radeon_init+0xec/0xee [radeon]
  [<ffffffff810002f2>] do_one_initcall+0x42/0x180
  [<ffffffff8109d8d2>] sys_init_module+0x92/0x1e0
  [<ffffffff815407a9>] system_call_fastpath+0x16/0x1b
 Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb
  e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 <f3> 48
  a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c
 RIP  [<ffffffff81275b5b>] memcpy+0xb/0x120
  RSP <ffff8800aa72db00>
 CR2: ffff8800a4244000
 ---[ end trace fcffa1599cf56382 ]---

Call to acpi_evaluate_object() not always returns 4096 bytes chunks,
on my system it can return 2048 bytes chunk, so pass the length of
retrieved chunk to memcpy(), not the length of the recieving buffer.

Signed-off-by: Igor Murzov <e-mail@date.by>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: convert radeon vfct code to use acpi_get_table_with_size
Alex Deucher [Mon, 20 Aug 2012 15:06:21 +0000 (11:06 -0400)]
drm/radeon: convert radeon vfct code to use acpi_get_table_with_size

commit 7c3906d04a4587dceaa78cc1ae6b14e6454ee02a upstream.

Allows us to verify the table size.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoACPI: export symbol acpi_get_table_with_size
Alex Deucher [Mon, 20 Aug 2012 14:57:22 +0000 (10:57 -0400)]
ACPI: export symbol acpi_get_table_with_size

commit 4f81f986761a7663db7d24d24cd6ae68008f1fc2 upstream.

We need it in the radeon drm module to fetch
and verify the vbios image on UEFI systems.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: implement ACPI VFCT vbios fetch (v3)
David Lamparter [Thu, 16 Aug 2012 19:45:20 +0000 (15:45 -0400)]
drm/radeon: implement ACPI VFCT vbios fetch (v3)

commit 268ba0a99f89a84dc5eb312470896113d0709c74 upstream.

This is required for pure UEFI systems.  The vbios is stored
in ACPI rather than at the legacy vga location.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=26891

V2: fix #ifdefs as per Greg's comments
V3: fix it harder

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later...
Tvrtko Ursulin [Mon, 20 Aug 2012 14:16:04 +0000 (15:16 +0100)]
drm/radeon/kms: extend the Fujitsu D3003-S2 board connector quirk to cover later silicon stepping

commit 52e9b39d9a89ae33662596bd30e62dd56bddbe73 upstream.

There is a more recent APU stepping with a new PCI ID
shipping in the same board by Fujitsu which needs the
same quirk to correctly mark the back plane connectors.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon/kms: upstream atombios.h updates
Alex Deucher [Tue, 20 Mar 2012 21:17:57 +0000 (17:17 -0400)]
drm/radeon/kms: upstream atombios.h updates

commit bf68adb4df2ac27a8f1b24894c007c9ef1c4195a upstream.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonetconsole: remove a redundant netconsole_target_put()
Amerigo Wang [Sat, 18 Aug 2012 07:02:20 +0000 (07:02 +0000)]
netconsole: remove a redundant netconsole_target_put()

commit 72d3eb13b5c0abe7d63efac41f39c5b644c7bbaa upstream.

This netconsole_target_put() is obviously redundant, and it
causes a kernel segfault when removing a bridge device which has
netconsole running on it.

This is caused by:

commit 8d8fc29d02a33e4bd5f4fa47823c1fd386346093
Author: Amerigo Wang <amwang@redhat.com>
Date:   Thu May 19 21:39:10 2011 +0000

    netpoll: disable netpoll when enslave a device

Cc: David Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoALSA: hda - don't create dysfunctional mixer controls for ca0132
David Henningsson [Mon, 20 Aug 2012 09:17:00 +0000 (11:17 +0200)]
ALSA: hda - don't create dysfunctional mixer controls for ca0132

commit c41999a23929f30808bae6009d8065052d4d73fd upstream.

It's possible that these amps are settable somehow, e g through
secret codec verbs, but for now, don't create the controls (as
they won't be working anyway, and cause errors in amixer).

BugLink: https://bugs.launchpad.net/bugs/1038651
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoRedefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
Mel Gorman [Sun, 19 Aug 2012 02:41:03 +0000 (14:41 +1200)]
Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts

commit 67a806d9499353fabd5b5ff07337f3aa88a1c3ba upstream.

The following build error occurred during an alpha build:

  net/core/sock.c:274:36: error: initializer element is not constant

Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });

The above line contains two compound literals.  It also uses a designated
initializer to initialize the field enabled.  A compound literal is not a
constant expression.

The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.

Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Acked-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoalpha: Don't export SOCK_NONBLOCK to user space.
Michael Cree [Sun, 19 Aug 2012 02:40:56 +0000 (14:40 +1200)]
alpha: Don't export SOCK_NONBLOCK to user space.

commit a2fa3ccd7b43665fe14cb562761a6c3d26a1d13f upstream.

Currently we export SOCK_NONBLOCK to user space but that conflicts with
the definition from glibc leading to compilation errors in user programs
(e.g.  see Debian bug #658460).

The generic socket.h restricts the definition of SOCK_NONBLOCK to the
kernel, as does the MIPS specific socket.h, so let's do the same on
Alpha.

Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Acked-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: CDC ACM: Fix NULL pointer dereference
Sven Schnelle [Fri, 17 Aug 2012 19:43:43 +0000 (21:43 +0200)]
USB: CDC ACM: Fix NULL pointer dereference

commit 99f347caa4568cb803862730b3b1f1942639523f upstream.

If a device specifies zero endpoints in its interface descriptor,
the kernel oopses in acm_probe(). Even though that's clearly an
invalid descriptor, we should test wether we have all endpoints.
This is especially bad as this oops can be triggered by just
plugging a USB device in.

Signed-off-by: Sven Schnelle <svens@stackframe.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: emi62: remove __devinit* from the struct usb_device_id table
Greg Kroah-Hartman [Sat, 18 Aug 2012 00:48:41 +0000 (17:48 -0700)]
USB: emi62: remove __devinit* from the struct usb_device_id table

commit 83957df21dd94655d2b026e0944a69ff37b83988 upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: winbond: remove __devinit* from the struct usb_device_id table
Greg Kroah-Hartman [Sat, 18 Aug 2012 00:48:37 +0000 (17:48 -0700)]
USB: winbond: remove __devinit* from the struct usb_device_id table

commit 43a34695d9cd79c6659f09da6d3b0624f3dd169f upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
CC: Pavel Machek <pavel@ucw.cz>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: "John W. Linville" <linville@tuxdriver.com>
CC: Eliad Peller <eliad@wizery.com>
CC: Devendra Naga <devendra.aaru@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: vt6656: remove __devinit* from the struct usb_device_id table
Greg Kroah-Hartman [Sat, 18 Aug 2012 00:48:33 +0000 (17:48 -0700)]
USB: vt6656: remove __devinit* from the struct usb_device_id table

commit 4d088876f24887cd15a29db923f5f37db6a99f21 upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
CC: Forest Bond <forest@alittletooquiet.net>
CC: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
CC: Jesper Juhl <jj@chaosbits.net>
CC: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: rtl8187: remove __devinit* from the struct usb_device_id table
Greg Kroah-Hartman [Sat, 18 Aug 2012 00:48:29 +0000 (17:48 -0700)]
USB: rtl8187: remove __devinit* from the struct usb_device_id table

commit a3433179d0822ccfa8e80aa4d1d52843bd2dcc63 upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
CC: Herton Ronaldo Krzesinski <herton@canonical.com>
CC: Hin-Tak Leung <htl10@users.sourceforge.net>
CC: Larry Finger <Larry.Finger@lwfinger.net>
CC: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: p54usb: remove __devinit* from the struct usb_device_id table
Greg Kroah-Hartman [Sat, 18 Aug 2012 00:48:28 +0000 (17:48 -0700)]
USB: p54usb: remove __devinit* from the struct usb_device_id table

commit b9c4167cbbafddac3462134013bc15e63e4c53ef upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
CC: Christian Lamparter <chunkeey@googlemail.com>
CC: "John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: spca506: remove __devinit* from the struct usb_device_id table
Greg Kroah-Hartman [Sat, 18 Aug 2012 00:48:27 +0000 (17:48 -0700)]
USB: spca506: remove __devinit* from the struct usb_device_id table

commit e694d518886c7afedcdd1732477832b2e32744e4 upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
CC: Hans de Goede <hdegoede@redhat.com>
CC: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: smsusb: remove __devinit* from the struct usb_device_id table
Greg Kroah-Hartman [Sat, 18 Aug 2012 00:48:26 +0000 (17:48 -0700)]
USB: smsusb: remove __devinit* from the struct usb_device_id table

commit d04dbd1c0ec17a13326c8f2279399c225836a79f upstream.

This structure needs to always stick around, even if CONFIG_HOTPLUG
is disabled, otherwise we can oops when trying to probe a device that
was added after the structure is thrown away.

Thanks to Fengguang Wu and Bjørn Mork for tracking this issue down.

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Bjørn Mork <bjorn@mork.no>
CC: Mauro Carvalho Chehab <mchehab@infradead.org>
CC: Michael Krufky <mkrufky@linuxtv.org>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Doron Cohen <doronc@siano-ms.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoASoC: wm9712: Fix microphone source selection
Mark Brown [Thu, 16 Aug 2012 21:36:04 +0000 (22:36 +0100)]
ASoC: wm9712: Fix microphone source selection

commit ccf795847a38235ee4a56a24129ce75147d6ba8f upstream.

Currently the microphone input source is not selectable as while there is
a DAPM widget it's not connected to anything so it won't be properly
instantiated. Add something more correct for the input structure to get
things going, even though it's not hooked into the rest of the routing
map and so won't actually achieve anything except allowing the relevant
register bits to be written.

Reported-by: Christop Fritz <chf.fritz@googlemail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoPM / Runtime: Clear power.deferred_resume on success in rpm_suspend()
Rafael J. Wysocki [Wed, 15 Aug 2012 19:31:55 +0000 (21:31 +0200)]
PM / Runtime: Clear power.deferred_resume on success in rpm_suspend()

commit 58a34de7b1a920d287d17d2ca08bc9aaf7e6d35b upstream.

The power.deferred_resume can only be set if the runtime PM status
of device is RPM_SUSPENDING and it should be cleared after its
status has been changed, regardless of whether or not the runtime
suspend has been successful.  However, it only is cleared on
suspend failure, while it may remain set on successful suspend and
is happily leaked to rpm_resume() executed in that case.

That shouldn't happen, so if power.deferred_resume is set in
rpm_suspend() after the status has been changed to RPM_SUSPENDED,
clear it before calling rpm_resume().  Then, it doesn't need to be
cleared before changing the status to RPM_SUSPENDING any more,
because it's always cleared after the status has been changed to
either RPM_SUSPENDED (on success) or RPM_ACTIVE (on failure).

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoPM / Runtime: Fix rpm_resume() return value for power.no_callbacks set
Rafael J. Wysocki [Wed, 15 Aug 2012 19:31:45 +0000 (21:31 +0200)]
PM / Runtime: Fix rpm_resume() return value for power.no_callbacks set

commit 7f321c26c04807834fef4c524d2b21573423fc74 upstream.

For devices whose power.no_callbacks flag is set, rpm_resume()
should return 1 if the device's parent is already active, so that
the callers of pm_runtime_get() don't think that they have to wait
for the device to resume (asynchronously) in that case (the core
won't queue up an asynchronous resume in that case, so there's
nothing to wait for anyway).

Modify the code accordingly (and make sure that an idle notification
will be queued up on success, even if 1 is to be returned).

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoext4: fix long mount times on very big file systems
Theodore Ts'o [Thu, 16 Aug 2012 15:59:04 +0000 (11:59 -0400)]
ext4: fix long mount times on very big file systems

commit 0548bbb85337e532ca2ed697c3e9b227ff2ed4b4 upstream.

Commit 8aeb00ff85a: "ext4: fix overhead calculation used by
ext4_statfs()" introduced a O(n**2) calculation which makes very large
file systems take forever to mount.  Fix this with an optimization for
non-bigalloc file systems.  (For bigalloc file systems the overhead
needs to be set in the the superblock.)

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agotarget: fix NULL pointer dereference bug alloc_page() fails to get memory
Yi Zou [Tue, 14 Aug 2012 23:06:43 +0000 (16:06 -0700)]
target: fix NULL pointer dereference bug alloc_page() fails to get memory

commit d0e27c88d795fb9647153063ec48051fd84e1731 upstream.

I am hitting this bug when the target is low in memory that fails the
alloc_page() for the newly submitted command. This is a sort of off-by-one
bug causing NULL pointer dereference in __free_page() since 'i' here is
really the counter of total pages that have been successfully allocated here.

Signed-off-by: Yi Zou <yi.zou@intel.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Open-FCoE.org <devel@open-fcoe.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFS: Alias the nfs module to nfs4
bjschuma@gmail.com [Wed, 8 Aug 2012 17:57:10 +0000 (13:57 -0400)]
NFS: Alias the nfs module to nfs4

commit 425e776d93a7a5070b77d4f458a5bab0f924652c upstream.

This allows distros to remove the line from their modprobe
configuration.

Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agomd: Don't truncate size at 4TB for RAID0 and Linear
NeilBrown [Thu, 16 Aug 2012 06:46:12 +0000 (16:46 +1000)]
md: Don't truncate size at 4TB for RAID0 and Linear

commit 667a5313ecd7308d79629c0738b0db588b0b0a4e upstream.

commit 27a7b260f71439c40546b43588448faac01adb93
   md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.

changed 0.90 metadata handling to truncated size to 4TB as that is
all that 0.90 can record.
However for RAID0 and Linear, 0.90 doesn't need to record the size, so
this truncation is not needed and causes working arrays to become too small.

So avoid the truncation for RAID0 and Linear

This bug was introduced in 3.1 and is suitable for any stable kernels
from then onwards.
As the offending commit was tagged for 'stable', any stable kernel
that it was applied to should also get this patch.  That includes
at least 2.6.32, 2.6.33 and 3.0. (Thanks to Ben Hutchings for
providing that list).

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodccp: check ccid before dereferencing
Mathias Krause [Wed, 15 Aug 2012 11:31:54 +0000 (11:31 +0000)]
dccp: check ccid before dereferencing

commit 276bdb82dedb290511467a5a4fdbe9f0b52dce6f upstream.

ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
a NULL ccid pointer leading to a NULL pointer dereference. This could
lead to a privilege escalation if the attacker is able to map page 0 and
prepare it with a fake ccid_ops pointer.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoIB/srp: Fix a race condition
Bart Van Assche [Tue, 14 Aug 2012 13:18:53 +0000 (13:18 +0000)]
IB/srp: Fix a race condition

commit 220329916c72ee3d54ae7262b215a050f04a18fc upstream.

Avoid a crash caused by the scmnd->scsi_done(scmnd) call in
srp_process_rsp() being invoked with scsi_done == NULL.  This can
happen if a reply is received during or after a command abort.

Reported-by: Joseph Glanville <joseph.glanville@orionvm.com.au>
Reference: http://marc.info/?l=linux-rdma&m=134314367801595
Acked-by: David Dillow <dillowda@ornl.gov>
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoPCI: EHCI: Fix crash during hibernation on ASUS computers
Rafael J. Wysocki [Sun, 12 Aug 2012 21:26:07 +0000 (23:26 +0200)]
PCI: EHCI: Fix crash during hibernation on ASUS computers

commit 0b68c8e2c3afaf9807eb1ebe0ccfb3b809570aa4 upstream.

Commit dbf0e4c (PCI: EHCI: fix crash during suspend on ASUS
computers) added a workaround for an ASUS suspend issue related to
USB EHCI and a bug in a number of ASUS BIOSes that attempt to shut
down the EHCI controller during system suspend if its PCI command
register doesn't contain 0 at that time.

It turns out that the same workaround is necessary in the analogous
hibernation code path, so add it.

References: https://bugzilla.kernel.org/show_bug.cgi?id=45811
Reported-and-tested-by: Oleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovfs: canonicalize create mode in build_open_flags()
Miklos Szeredi [Wed, 15 Aug 2012 11:01:24 +0000 (13:01 +0200)]
vfs: canonicalize create mode in build_open_flags()

commit e68726ff72cf7ba5e7d789857fcd9a75ca573f03 upstream.

Userspace can pass weird create mode in open(2) that we canonicalize to
"(mode & S_IALLUGO) | S_IFREG" in vfs_create().

The problem is that we use the uncanonicalized mode before calling vfs_create()
with unforseen consequences.

So do the canonicalization early in build_open_flags().

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoaudit: fix refcounting in audit-tree
Miklos Szeredi [Wed, 15 Aug 2012 10:55:22 +0000 (12:55 +0200)]
audit: fix refcounting in audit-tree

commit a2140fc0cb0325bb6384e788edd27b9a568714e2 upstream.

Refcounting of fsnotify_mark in audit tree is broken.  E.g:

                              refcount
create_chunk
  alloc_chunk                 1
  fsnotify_add_mark           2

untag_chunk
  fsnotify_get_mark           3
  fsnotify_destroy_mark
    audit_tree_freeing_mark   2
  fsnotify_put_mark           1
  fsnotify_put_mark           0
  via destroy_list
    fsnotify_mark_destroy    -1

This was reported by various people as triggering Oops when stopping auditd.

We could just remove the put_mark from audit_tree_freeing_mark() but that would
break freeing via inode destruction.  So this patch simply omits a put_mark
after calling destroy_mark or adds a get_mark before.

The additional get_mark is necessary where there's no other put_mark after
fsnotify_destroy_mark() since it assumes that the caller is holding a reference
(or the inode is keeping the mark pinned, not the case here AFAICS).

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reported-by: Valentin Avram <aval13@gmail.com>
Reported-by: Peter Moody <pmoody@google.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoaudit: don't free_chunk() after fsnotify_add_mark()
Miklos Szeredi [Wed, 15 Aug 2012 10:55:22 +0000 (12:55 +0200)]
audit: don't free_chunk() after fsnotify_add_mark()

commit 0fe33aae0e94b4097dd433c9399e16e17d638cd8 upstream.

Don't do free_chunk() after fsnotify_add_mark().  That one does a delayed unref
via the destroy list and this results in use-after-free.

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/i915: reorder edp disabling to fix ivb MacBook Air
Daniel Vetter [Sun, 12 Aug 2012 20:17:14 +0000 (22:17 +0200)]
drm/i915: reorder edp disabling to fix ivb MacBook Air

commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 upstream.

eDP is tons of fun. It turns out that at least the new MacBook Air 5,1
model absolutely doesn't like the new force vdd dance we've introduced
in

commit 6cb49835da0426f69a2931bc2a0a8156344b0e41
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun May 20 17:14:50 2012 +0200

    drm/i915: enable vdd when switching off the eDP panel

But that patch also tried to fix some neat edp sequence issue with the
force_vdd timings. Closer inspection reveals that we've raised
force_vdd only to do the aux channel communication dp_sink_dpms. If we
move the edp_panel_off below that, we don't need any force_vdd for the
disable sequence, which makes the Air happy.

Unfortunately the reporter of the original bug that the above commit
fixed is travelling, so we can't test whether this regresses things.
But my theory is that since we don't check for any power-off ->
force_vdd-on delays in edp_panel_vdd_on, this was the actual
root-cause of this failure. With that force_vdd dance completely
eliminated, I'm hopeful the original bug stays fixed, too.

For reference the old bug, which hopefully doesn't get broken by this:

https://bugzilla.kernel.org/show_bug.cgi?id=43163

In any case, regression fixers win over plain bugfixes, so this needs
to go in asap.

v2: The crucial pieces seems to be to clear the force_vdd flag
uncoditionally, too, in edp_panel_off. Looks like this is left behind
by the firmware somehow.

v3: The Apple firmware seems to switch off the panel on it's own, hence
we still need to keep force_vdd on, but properly clear it when switching
the panel off.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671
Tested-by: Roberto Romer <sildurin@gmail.com>
Tested-by: Daniel Wagner <wagi@monom.org>
Tested-by: Keith Packard <keithp@keithp.com>
Cc: Keith Packard <keithp@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate
Christoph Bumiller [Thu, 26 Jul 2012 18:53:19 +0000 (20:53 +0200)]
drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate

commit af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 upstream.

Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
[bwh: Backported to 3.2: register value is in the local 'data' variable]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoath9k: fix decrypt_error initialization in ath_rx_tasklet()
Lorenzo Bianconi [Fri, 10 Aug 2012 09:00:24 +0000 (11:00 +0200)]
ath9k: fix decrypt_error initialization in ath_rx_tasklet()

commit e1352fde5682ab1bdd2a9e5d75c22d1fe210ef77 upstream.

ath_rx_tasklet() calls ath9k_rx_skb_preprocess() and ath9k_rx_skb_postprocess()
in a loop over the received frames. The decrypt_error flag is
initialized to false
just outside ath_rx_tasklet() loop. ath9k_rx_accept(), called by
ath9k_rx_skb_preprocess(),
only sets decrypt_error to true and never to false.
Then ath_rx_tasklet() calls ath9k_rx_skb_postprocess() and passes
decrypt_error to it.
So, after a decryption error, in ath9k_rx_skb_postprocess(), we can
have a leftover value
from another processed frame. In that case, the frame will not be marked with
RX_FLAG_DECRYPTED even if it is decrypted correctly.
When using CCMP encryption this issue can lead to connection stuck
because of CCMP
PN corruption and a waste of CPU time since mac80211 tries to decrypt an already
deciphered frame with ieee80211_aes_ccm_decrypt.
Fix the issue initializing decrypt_error flag at the begging of the
ath_rx_tasklet() loop.

Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agomutex: Place lock in contended state after fastpath_lock failure
Will Deacon [Fri, 10 Aug 2012 14:22:09 +0000 (15:22 +0100)]
mutex: Place lock in contended state after fastpath_lock failure

commit 0bce9c46bf3b15f485d82d7e81dabed6ebcc24b1 upstream.

ARM recently moved to asm-generic/mutex-xchg.h for its mutex
implementation after the previous implementation was found to be missing
some crucial memory barriers. However, this has revealed some problems
running hackbench on SMP platforms due to the way in which the
MUTEX_SPIN_ON_OWNER code operates.

The symptoms are that a bunch of hackbench tasks are left waiting on an
unlocked mutex and therefore never get woken up to claim it. This boils
down to the following sequence of events:

        Task A        Task B        Task C        Lock value
0                                                     1
1       lock()                                        0
2                     lock()                          0
3                     spin(A)                         0
4       unlock()                                      1
5                                   lock()            0
6                     cmpxchg(1,0)                    0
7                     contended()                    -1
8       lock()                                        0
9       spin(C)                                       0
10                                  unlock()          1
11      cmpxchg(1,0)                                  0
12      unlock()                                      1

At this point, the lock is unlocked, but Task B is in an uninterruptible
sleep with nobody to wake it up.

This patch fixes the problem by ensuring we put the lock into the
contended state if we fail to acquire it on the fastpath, ensuring that
any blocked waiters are woken up when the mutex is released.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Chris Mason <chris.mason@fusionio.com>
Cc: Ingo Molnar <mingo@elte.hu>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-6e9lrw2avczr0617fzl5vqb8@git.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agosched: fix divide by zero at {thread_group,task}_times
Stanislaw Gruszka [Wed, 8 Aug 2012 09:27:15 +0000 (11:27 +0200)]
sched: fix divide by zero at {thread_group,task}_times

commit bea6832cc8c4a0a9a65dd17da6aaa657fe27bc3e upstream.

On architectures where cputime_t is 64 bit type, is possible to trigger
divide by zero on do_div(temp, (__force u32) total) line, if total is a
non zero number but has lower 32 bit's zeroed. Removing casting is not
a good solution since some do_div() implementations do cast to u32
internally.

This problem can be triggered in practice on very long lived processes:

  PID: 2331   TASK: ffff880472814b00  CPU: 2   COMMAND: "oraagent.bin"
   #0 [ffff880472a51b70] machine_kexec at ffffffff8103214b
   #1 [ffff880472a51bd0] crash_kexec at ffffffff810b91c2
   #2 [ffff880472a51ca0] oops_end at ffffffff814f0b00
   #3 [ffff880472a51cd0] die at ffffffff8100f26b
   #4 [ffff880472a51d00] do_trap at ffffffff814f03f4
   #5 [ffff880472a51d60] do_divide_error at ffffffff8100cfff
   #6 [ffff880472a51e00] divide_error at ffffffff8100be7b
      [exception RIP: thread_group_times+0x56]
      RIP: ffffffff81056a16  RSP: ffff880472a51eb8  RFLAGS: 00010046
      RAX: bc3572c9fe12d194  RBX: ffff880874150800  RCX: 0000000110266fad
      RDX: 0000000000000000  RSI: ffff880472a51eb8  RDI: 001038ae7d9633dc
      RBP: ffff880472a51ef8   R8: 00000000b10a3a64   R9: ffff880874150800
      R10: 00007fcba27ab680  R11: 0000000000000202  R12: ffff880472a51f08
      R13: ffff880472a51f10  R14: 0000000000000000  R15: 0000000000000007
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
   #7 [ffff880472a51f00] do_sys_times at ffffffff8108845d
   #8 [ffff880472a51f40] sys_times at ffffffff81088524
   #9 [ffff880472a51f80] system_call_fastpath at ffffffff8100b0f2
      RIP: 0000003808caac3a  RSP: 00007fcba27ab6d8  RFLAGS: 00000202
      RAX: 0000000000000064  RBX: ffffffff8100b0f2  RCX: 0000000000000000
      RDX: 00007fcba27ab6e0  RSI: 000000000076d58e  RDI: 00007fcba27ab6e0
      RBP: 00007fcba27ab700   R8: 0000000000000020   R9: 000000000000091b
      R10: 00007fcba27ab680  R11: 0000000000000202  R12: 00007fff9ca41940
      R13: 0000000000000000  R14: 00007fcba27ac9c0  R15: 00007fff9ca41940
      ORIG_RAX: 0000000000000064  CS: 0033  SS: 002b

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120808092714.GA3580@redhat.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[bwh: Backported to 3.2:
 - Adjust filename
 - Most conversions in the original code are implicit]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoALSA: hda - fix Copyright debug message
Wang Xingchao [Mon, 13 Aug 2012 06:11:10 +0000 (14:11 +0800)]
ALSA: hda - fix Copyright debug message

commit 088c820b732dbfd515fc66d459d5f5777f79b406 upstream.

As spec said, 1 indicates no copyright is asserted.

Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/i915: ignore eDP bpc settings from vbt
Daniel Vetter [Fri, 10 Aug 2012 09:10:20 +0000 (11:10 +0200)]
drm/i915: ignore eDP bpc settings from vbt

commit 4344b813f105a19f793f1fd93ad775b784648b95 upstream.

This has originally been introduced to not oversubscribe the dp links
in

commit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Tue Jan 12 05:38:31 2010 +0800

    drm/i915: fix pixel color depth setting on eDP

Since then we've fixed up the dp link bandwidth calculation code and
should now automatically fall back to 6bpc dithering. So this is
unnecessary.

Furthermore it seems to break the new MacbookPro with retina display,
hence let's just rip this out.

Reported-by: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Benoit Gschwind <gschwind@gnu-log.net>
Cc: Francois Rigaut <frigaut@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Tested-by: Bernhard Froemel <froemel at vmars tuwien.ac.at>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
--

Testing feedback highgly welcome, and thanks for Benoit for finding
out that the bpc computations are busted.
-Daniel
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoARM: 7489/1: errata: fix workaround for erratum #720789 on UP systems
Will Deacon [Fri, 10 Aug 2012 18:13:36 +0000 (19:13 +0100)]
ARM: 7489/1: errata: fix workaround for erratum #720789 on UP systems

commit 730a8128cd8978467eb1cf546b11014acb57d433 upstream.

Commit 5a783cbc4836 ("ARM: 7478/1: errata: extend workaround for erratum
 #720789") added workarounds for erratum #720789 to the range TLB
invalidation functions with the observation that the erratum only
affects SMP platforms. However, when running an SMP_ON_UP kernel on a
uniprocessor platform we must take care to preserve the ASID as the
workaround is not required.

This patch ensures that we don't set the ASID to 0 when flushing the TLB
on such a system, preserving the original behaviour with the workaround
disabled.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoARM: 7488/1: mm: use 5 bits for swapfile type encoding
Will Deacon [Fri, 10 Aug 2012 16:51:19 +0000 (17:51 +0100)]
ARM: 7488/1: mm: use 5 bits for swapfile type encoding

commit f5f2025ef3e2cdb593707cbf87378761f17befbe upstream.

Page migration encodes the pfn in the offset field of a swp_entry_t.
For LPAE, we support physical addresses of up to 36 bits (due to
sparsemem limitations with the size of page flags), requiring 24 bits
to represent a pfn. A further 3 bits are used to encode a swp_entry into
a pte, leaving 5 bits for the type field. Furthermore, the core code
defines MAX_SWAPFILES_SHIFT as 5, so the additional type bit does not
get used.

This patch reduces the width of the type field to 5 bits, allowing us
to create up to 31 swapfiles of 64GB each.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoARM: 7483/1: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled
Will Deacon [Fri, 3 Aug 2012 16:24:14 +0000 (17:24 +0100)]
ARM: 7483/1: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled

commit 3d9fb0038a9b02febb01efc79a4a5d97f1822a90 upstream.

VFPv4 support depends on the VFPv3 context save/restore code, so only
advertise support in the hwcaps if the kernel can actually handle it.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agousb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop
Michael Grzeschik [Wed, 8 Aug 2012 09:48:10 +0000 (11:48 +0200)]
usb: gadget: u_ether: fix kworker 100% CPU issue with still used interfaces in eth_stop

commit b1b552a69b8805e7e338074a9e8b670b4a795218 upstream.

This patch fixes an issue introduced by patch:

    72c973d usb: gadget: add usb_endpoint_descriptor to struct usb_ep

Without this patch we see a kworker taking 100% CPU, after this sequence:

- Connect gadget to a windows host
- load g_ether
- ifconfig up <ip>; ifconfig down; ifconfig up
- ping <windows host>

The "ifconfig down" results in calling eth_stop(), which will call
usb_ep_disable() and, if the carrier is still ok, usb_ep_enable():

         usb_ep_disable(link->in_ep);
         usb_ep_disable(link->out_ep);
         if (netif_carrier_ok(net)) {
                 usb_ep_enable(link->in_ep);
                 usb_ep_enable(link->out_ep);
         }

The ep should stay enabled, but will not, as ep_disable set the desc
pointer to NULL, therefore the subsequent ep_enable will fail. This leads
to permanent rescheduling of the eth_work() worker as usb_ep_queue()
(called by the worker) will fail due to the unconfigured endpoint.

We fix this issue by saving the ep descriptors and re-assign them before
usb_ep_enable().

Cc: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agousb: serial: mos7840: Fixup mos7840_chars_in_buffer()
Mark Ferrell [Tue, 24 Jul 2012 19:15:13 +0000 (14:15 -0500)]
usb: serial: mos7840: Fixup mos7840_chars_in_buffer()

commit 5c263b92f828af6a8cf54041db45ceae5af8f2ab upstream.

 * Use the buffer content length as opposed to the total buffer size.  This can
   be a real problem when using the mos7840 as a usb serial-console as all
   kernel output is truncated during boot.

Signed-off-by: Mark Ferrell <mferrell@uplogix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: support the new interfaces of Huawei Data Card devices in option driver
fangxiaozhi [Wed, 8 Aug 2012 09:24:45 +0000 (09:24 +0000)]
USB: support the new interfaces of Huawei Data Card devices in option driver

commit ee6f827df9107139e8960326e49e1376352ced4d upstream.

In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices. And at the same time, remove the
redundant declarations from option.c.

Signed-off-by: fangxiaozhi <huananhu@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: add USB_VENDOR_AND_INTERFACE_INFO() macro
Gustavo Padovan [Tue, 10 Jul 2012 22:10:06 +0000 (19:10 -0300)]
USB: add USB_VENDOR_AND_INTERFACE_INFO() macro

commit d81a5d1956731c453b85c141458d4ff5d6cc5366 upstream.

A lot of Broadcom Bluetooth devices provides vendor specific interface
class and we are getting flooded by patches adding new device support.
This change will help us enable support for any other Broadcom with vendor
specific device that arrives in the future.

Only the product id changes for those devices, so this macro would be
perfect for us:

{ USB_VENDOR_AND_INTERFACE_INFO(0x0a5c, 0xff, 0x01, 0x01) }

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: Henrik Rydberg <rydberg@bitmath.se>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: option: Add Vodafone/Huawei K5005 support
Bjørn Mork [Sat, 19 May 2012 17:20:50 +0000 (19:20 +0200)]
USB: option: Add Vodafone/Huawei K5005 support

commit 4cbbb039a9719fb3bba73d255c6a95bc6dc6428b upstream.

Tested-by: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: ftdi_sio: Add VID/PID for Kondo Serial USB
Ozan Çağlayan [Fri, 10 Aug 2012 14:25:10 +0000 (17:25 +0300)]
USB: ftdi_sio: Add VID/PID for Kondo Serial USB

commit 7724a1edbe463b06d4e7831a41149ba095b16c53 upstream.

This adds VID/PID for Kondo Kagaku Co. Ltd. Serial USB Adapter
interface:
http://www.kondo-robot.com/EN/wp/?cat=28

Tested by controlling an RCB3 board using libRCB3.

Signed-off-by: Ozan Çağlayan <ozancag@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.
Sarah Sharp [Mon, 2 Jul 2012 20:36:23 +0000 (13:36 -0700)]
xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.

commit 5cb7df2b2d3afee7638b3ef23a5bcb89c6f07bd9 upstream.

Gary reports that with recent kernels, he notices more xHCI driver
warnings:

xhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?

We think his Etron xHCI host controller may have the same buggy behavior
as the Fresco Logic xHCI host.  When a short transfer is received, the
host will mark the transfer as successfully completed when it should be
marking it with a short completion.

Fix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron
host is discovered.  Note that Gary has revision 1, but if Etron fixes
this bug in future revisions, the quirk will have no effect.

This patch should be backported to kernels as old as 2.6.36, that
contain a backported version of commit
1530bbc6272d9da1e39ef8e06190d42c13a02733 "xhci: Add new short TX quirk
for Fresco Logic host."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Gary E. Miller <gem@rellim.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxhci: Increase reset timeout for Renesas 720201 host.
Sarah Sharp [Mon, 23 Jul 2012 23:06:08 +0000 (16:06 -0700)]
xhci: Increase reset timeout for Renesas 720201 host.

commit 22ceac191211cf6688b1bf6ecd93c8b6bf80ed9b upstream.

The NEC/Renesas 720201 xHCI host controller does not complete its reset
within 250 milliseconds.  In fact, it takes about 9 seconds to reset the
host controller, and 1 second for the host to be ready for doorbell
rings.  Extend the reset and CNR polling timeout to 10 seconds each.

This patch should be backported to kernels as old as 2.6.31, that
contain the commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci:
BIOS handoff and HW initialization."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Edwin Klein Mentink <e.kleinmentink@zonnet.nl>
[bwh: Backported to 3.2: result of second handshake call is returned directly]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: Fix legacy pairing with some devices
Szymon Janc [Thu, 19 Jul 2012 12:46:08 +0000 (14:46 +0200)]
Bluetooth: Fix legacy pairing with some devices

commit a9ea3ed9b71cc3271dd59e76f65748adcaa76422 upstream.

Some devices e.g. some Android based phones don't do SDP search before
pairing and cancel legacy pairing when ACL is disconnected.

PIN Code Request event which changes ACL timeout to HCI_PAIRING_TIMEOUT
is only received after remote user entered PIN.

In that case no L2CAP is connected so default HCI_DISCONN_TIMEOUT
(2 seconds) is being used to timeout ACL connection. This results in
problems with legacy pairing as remote user has only few seconds to
enter PIN before ACL is disconnected.

Increase disconnect timeout for incomming connection to
HCI_PAIRING_TIMEOUT if SSP is disabled and no linkey exists.

To avoid keeping ACL alive for too long after SDP search set ACL
timeout back to HCI_DISCONN_TIMEOUT when L2CAP is connected.

2012-07-19 13:24:43.413521 < HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr 00:02:72:D6:6A:3F ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
2012-07-19 13:24:43.425224 > HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
2012-07-19 13:24:43.885222 > HCI Event: Role Change (0x12) plen 8
    status 0x00 bdaddr 00:02:72:D6:6A:3F role 0x01
    Role: Slave
2012-07-19 13:24:44.054221 > HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 42 bdaddr 00:02:72:D6:6A:3F type ACL encrypt 0x00
2012-07-19 13:24:44.054313 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 42
2012-07-19 13:24:44.055176 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
    bdaddr 00:02:72:D6:6A:3F mode 0
2012-07-19 13:24:44.056217 > HCI Event: Max Slots Change (0x1b) plen 3
    handle 42 slots 5
2012-07-19 13:24:44.059218 > HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
2012-07-19 13:24:44.062192 > HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 1
2012-07-19 13:24:44.067219 > HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 42
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
2012-07-19 13:24:44.067248 < HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
    handle 42 page 1
2012-07-19 13:24:44.071217 > HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
2012-07-19 13:24:44.076218 > HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 42 page 1 max 1
    Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
2012-07-19 13:24:44.076249 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 00:02:72:D6:6A:3F mode 2 clkoffset 0x0000
2012-07-19 13:24:44.081218 > HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2012-07-19 13:24:44.105214 > HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:02:72:D6:6A:3F name 'uw000951-0'
2012-07-19 13:24:44.105284 < HCI Command: Authentication Requested (0x01|0x0011) plen 2
    handle 42
2012-07-19 13:24:44.111207 > HCI Event: Command Status (0x0f) plen 4
    Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
2012-07-19 13:24:44.112220 > HCI Event: Link Key Request (0x17) plen 6
    bdaddr 00:02:72:D6:6A:3F
2012-07-19 13:24:44.112249 < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
    bdaddr 00:02:72:D6:6A:3F
2012-07-19 13:24:44.115215 > HCI Event: Command Complete (0x0e) plen 10
    Link Key Request Negative Reply (0x01|0x000c) ncmd 1
    status 0x00 bdaddr 00:02:72:D6:6A:3F
2012-07-19 13:24:44.116215 > HCI Event: PIN Code Request (0x16) plen 6
    bdaddr 00:02:72:D6:6A:3F
2012-07-19 13:24:48.099184 > HCI Event: Auth Complete (0x06) plen 3
    status 0x13 handle 42
    Error: Remote User Terminated Connection
2012-07-19 13:24:48.179182 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 42 reason 0x13
    Reason: Remote User Terminated Connection

Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
[bwh: Backported to 3.2:
 - Adjust context
 - hci_conn_ssp_enabled() is not defined; open-code the condition]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agofuse: verify all ioctl retry iov elements
Zach Brown [Tue, 24 Jul 2012 19:10:11 +0000 (12:10 -0700)]
fuse: verify all ioctl retry iov elements

commit fb6ccff667712c46b4501b920ea73a326e49626a upstream.

Commit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that
the total iovec from the client doesn't overflow iov_length() but it
only checked the first element.  The iovec could still overflow by
starting with a small element.  The obvious fix is to check all the
elements.

The overflow case doesn't look dangerous to the kernel as the copy is
limited by the length after the overflow.  This fix restores the
intention of returning an error instead of successfully copying less
than the iovec represented.

I found this by code inspection.  I built it but don't have a test case.
I'm cc:ing stable because the initial commit did as well.

Signed-off-by: Zach Brown <zab@redhat.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoext4: avoid kmemcheck complaint from reading uninitialized memory
Theodore Ts'o [Mon, 6 Aug 2012 03:28:16 +0000 (23:28 -0400)]
ext4: avoid kmemcheck complaint from reading uninitialized memory

commit 7e731bc9a12339f344cddf82166b82633d99dd86 upstream.

Commit 03179fe923 introduced a kmemcheck complaint in
ext4_da_get_block_prep() because we save and restore
ei->i_da_metadata_calc_last_lblock even though it is left
uninitialized in the case where i_da_metadata_calc_len is zero.

This doesn't hurt anything, but silencing the kmemcheck complaint
makes it easier for people to find real bugs.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45631
(which is marked as a regression).

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopnfs: defer release of pages in layoutget
Idan Kedar [Thu, 2 Aug 2012 08:47:10 +0000 (11:47 +0300)]
pnfs: defer release of pages in layoutget

commit 8554116e17eef055d9dd58a94b3427cb2ad1c317 upstream.

we have encountered a bug whereby reading a lot of files (copying
fedora's /bin) from a pNFS mount and hitting Ctrl+C in the middle caused
a general protection fault in xdr_shrink_bufhead. this function is
called when decoding the response from LAYOUTGET. the decoding is done
by a worker thread, and the caller of LAYOUTGET waits for the worker
thread to complete.

hitting Ctrl+C caused the synchronous wait to end and the next thing the
caller does is to free the pages, so when the worker thread calls
xdr_shrink_bufhead, the pages are gone. therefore, the cleanup of these
pages has been moved to nfs4_layoutget_release.

Signed-off-by: Idan Kedar <idank@tonian.com>
Signed-off-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agofix page number calculation bug for block layout decode buffer
Jim Rees [Tue, 10 Apr 2012 02:33:39 +0000 (22:33 -0400)]
fix page number calculation bug for block layout decode buffer

commit 10bd295a0b6488ebe634b72a11d8986bd3af3819 upstream.

Signed-off-by: Jim Rees <rees@umich.edu>
Suggested-by: Andy Adamson <andros@netapp.com>
Suggested-by: Fred Isaman <iisaman@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFSv4.1 fix page number calculation bug for filelayout decode buffers
Andy Adamson [Sat, 14 Apr 2012 07:56:35 +0000 (03:56 -0400)]
NFSv4.1 fix page number calculation bug for filelayout decode buffers

commit e5265a0c587423bbd21a6b39a572cecff16b9346 upstream.

Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFS: Use kcalloc() when allocating arrays
Trond Myklebust [Fri, 20 Jan 2012 23:57:02 +0000 (18:57 -0500)]
NFS: Use kcalloc() when allocating arrays

commit 7d9dea915fe333357912bce2d624ee848dfbd890 upstream.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonfs: tear down caches in nfs_init_writepagecache when allocation fails
Jeff Layton [Thu, 2 Aug 2012 18:30:56 +0000 (14:30 -0400)]
nfs: tear down caches in nfs_init_writepagecache when allocation fails

commit 3dd4765fce04c0b4af1e0bc4c0b10f906f95fabc upstream.

...and ensure that we tear down the nfs_commit_data cache too when
unloading the module.

Cc: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[bwh: Backported to 3.2: drop the nfs_cdata_cachep cleanup; it doesn't exist]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoHID: add ASUS AIO keyboard model AK1D
Cyrus Lien [Mon, 23 Jul 2012 09:11:51 +0000 (17:11 +0800)]
HID: add ASUS AIO keyboard model AK1D

commit 2d8767bb421574dfcf48e4be0751ce7d8f73d5d7 upstream.

Add Asus All-In-One PC keyboard model AK1D.

BugLink: https://bugs.launchpad.net/bugs/1027789
Signed-off-by: Cyrus Lien <cyrus.lien@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoLinux 3.2.28 v3.2.28
Ben Hutchings [Sun, 19 Aug 2012 17:15:38 +0000 (18:15 +0100)]
Linux 3.2.28

9 years agodrm/radeon: do not reenable crtc after moving vram start address
Jerome Glisse [Fri, 27 Jul 2012 20:32:24 +0000 (16:32 -0400)]
drm/radeon: do not reenable crtc after moving vram start address

commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream.

It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc display request lead to same behavior.

So after changing the vram address if we don't keep crtc disabled
we will have the GPU trying to read some random system memory address
with some iommu this will broke the crtc engine and will lead to
broken display and iommu error message.

So to avoid this, disable crtc. For flicker less boot we will need
to avoid moving the vram start address.

This patch should also fix :

https://bugs.freedesktop.org/show_bug.cgi?id=42373

Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: fix bank tiling parameters on cayman
Alex Deucher [Tue, 31 Jul 2012 15:05:11 +0000 (11:05 -0400)]
drm/radeon: fix bank tiling parameters on cayman

commit 5b23c9045a8b61352986270b2d109edf5085e113 upstream.

Handle the 16 bank case.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: fix bank tiling parameters on evergreen
Alex Deucher [Tue, 31 Jul 2012 15:01:10 +0000 (11:01 -0400)]
drm/radeon: fix bank tiling parameters on evergreen

commit c8d15edc17d836686d1f071e564800e1a2724fa6 upstream.

Handle the 16 bank case.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agos390/compat: fix mmap compat system calls
Heiko Carstens [Wed, 8 Aug 2012 07:32:20 +0000 (09:32 +0200)]
s390/compat: fix mmap compat system calls

commit e85871218513c54f7dfdb6009043cb638f2fecbe upstream.

The native 31 bit and the compat behaviour for the mmap system calls differ:

In native 31 bit mode the passed in address for the mmap system call will be
unmodified passed to sys_mmap_pgoff().
In compat mode however the passed in address will be modified with
compat_ptr() which masks out the most significant bit.

The result is that in native 31 bit mode each mmap request (with MAP_FIXED)
will fail where the most significat bit is set, while in compat mode it
may succeed.

This odd behaviour was introduced with d3815898 "[S390] mmap: add missing
compat_ptr conversion to both mmap compat syscalls".

To restore a consistent behaviour accross native and compat mode this
patch functionally reverts the above mentioned commit.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agos390/compat: fix compat wrappers for process_vm system calls
Heiko Carstens [Tue, 7 Aug 2012 07:48:13 +0000 (09:48 +0200)]
s390/compat: fix compat wrappers for process_vm system calls

commit 82aabdb6f1eb61e0034ec23901480f5dd23db7c4 upstream.

The compat wrappers incorrectly called the non compat versions of
the system process_vm system calls.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>