6 years agoALSA: usb-audio: Fix races at disconnection in mixer_quirks.c
Takashi Iwai [Wed, 7 Nov 2012 11:42:46 +0000]
ALSA: usb-audio: Fix races at disconnection in mixer_quirks.c

commit 888ea7d5ac6815ba16b3b3a20f665a92c7af6724 upstream.

Similar like the previous commit, cover with chip->shutdown_rwsem
and chip->shutdown checks.

Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoALSA: usb-audio: Use rwsem for disconnect protection
Takashi Iwai [Wed, 7 Nov 2012 11:42:45 +0000]
ALSA: usb-audio: Use rwsem for disconnect protection

commit 34f3c89fda4fba9fe689db22253ca8db2f5e6386 upstream.

Replace mutex with rwsem for codec->shutdown protection so that
concurrent accesses are allowed.

Also add the protection to snd_usb_autosuspend() and
snd_usb_autoresume(), too.

Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoALSA: usb-audio: Fix races at disconnection
Takashi Iwai [Wed, 7 Nov 2012 11:42:44 +0000]
ALSA: usb-audio: Fix races at disconnection

commit 978520b75f0a1ce82b17e1e8186417250de6d545 upstream.

Close some races at disconnection of a USB audio device by adding the
chip->shutdown_mutex and chip->shutdown check at appropriate places.

The spots to put bandaids are:
- PCM prepare, hw_params and hw_free
- where the usb device is accessed for communication or get speed, in
 mixer.c and others; the device speed is now cached in subs->speed
 instead of accessing to chip->dev

The accesses in PCM open and close don't need the mutex protection
because these are already handled in the core PCM disconnection code.

The autosuspend/autoresume codes are still uncovered by this patch
because of possible mutex deadlocks.  They'll be covered by the
upcoming change to rwsem.

Also the mixer codes are untouched, too.  These will be fixed in
another patch, too.

Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoALSA: PCM: Fix some races at disconnection
Takashi Iwai [Wed, 7 Nov 2012 11:39:51 +0000]
ALSA: PCM: Fix some races at disconnection

commit 9b0573c07f278e9888c352aa9724035c75784ea0 upstream.

Fix races at PCM disconnection:
- while a PCM device is being opened or closed
- while the PCM state is being changed without lock in prepare,
  hw_params, hw_free ops

Reported-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agohwmon: (w83627ehf) Force initial bank selection
Jean Delvare [Mon, 5 Nov 2012 20:54:39 +0000]
hwmon: (w83627ehf) Force initial bank selection

commit 3300fb4f88688029fff8dfb9ec0734f6e4cba3e7 upstream.

Don't assume bank 0 is selected at device probe time. This may not be
the case. Force bank selection at first register access to guarantee
that we read the right registers upon driver loading.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrm: restore open_count if drm_setup fails
Ilija Hadzic [Mon, 29 Oct 2012 17:35:00 +0000]
drm: restore open_count if drm_setup fails

commit 0f1cb1bd94a9c967cd4ad3de51cfdabe61eb5dcc upstream.

If drm_setup (called at first open) fails, the whole
open call has failed, so we should not keep the
open_count incremented.

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoNFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate
Trond Myklebust [Wed, 22 Aug 2012 20:08:17 +0000]
NFS: Fix Oopses in nfs_lookup_revalidate and nfs4_lookup_revalidate

[Fixed upstream as part of 0b728e1911c, but that's a much larger patch,
this is only the nfs portion backported as needed.]

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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoNFS: fix bug in legacy DNS resolver.
NeilBrown [Wed, 31 Oct 2012 01:16:01 +0000]
NFS: fix bug in legacy DNS resolver.

commit 8d96b10639fb402357b75b055b1e82a65ff95050 upstream.

The DNS resolver's use of the sunrpc cache involves a 'ttl' number
(relative) rather that a timeout (absolute).  This confused me when
I wrote
  commit c5b29f885afe890f953f7f23424045cdad31d3e4
     "sunrpc: use seconds since boot in expiry cache"

and I managed to break it.  The effect is that any TTL is interpreted
as 0, and nothing useful gets into the cache.

This patch removes the use of get_expiry() - which really expects an
expiry time - and uses get_uint() instead, treating the int correctly
as a ttl.

This fixes a regression that has been present since 2.6.37, causing
certain NFS accesses in certain environments to incorrectly fail.

Reported-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agonfsd: add get_uint for u32's
J. Bruce Fields [Tue, 12 Jun 2012 20:54:16 +0000]
nfsd: add get_uint for u32's

commit a007c4c3e943ecc054a806c259d95420a188754b upstream.

I don't think there's a practical difference for the range of values
these interfaces should see, but it would be safer to be unambiguous.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoNFSv4.1: We must release the sequence id when we fail to get a session slot
Trond Myklebust [Mon, 29 Oct 2012 22:37:40 +0000]
NFSv4.1: We must release the sequence id when we fail to get a session slot

commit 2240a9e2d013d8269ea425b73e1d7a54c7bc141f upstream.

If we do not release the sequence id in cases where we fail to get a
session slot, then we can deadlock if we hit a recovery scenario.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoNFSv4: nfs4_locku_done must release the sequence id
Trond Myklebust [Mon, 29 Oct 2012 22:53:23 +0000]
NFSv4: nfs4_locku_done must release the sequence id

commit 2b1bc308f492589f7d49012ed24561534ea2be8c upstream.

If the state recovery machinery is triggered by the call to
nfs4_async_handle_error() then we can deadlock.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agonfs: Show original device name verbatim in /proc/*/mount{s,info}
Ben Hutchings [Sun, 21 Oct 2012 18:23:52 +0000]
nfs: Show original device name verbatim in /proc/*/mount{s,info}

commit 97a54868262da1629a3e65121e65b8e8c4419d9f upstream.

Since commit c7f404b ('vfs: new superblock methods to override
/proc/*/mount{s,info}'), nfs_path() is used to generate the mounted
device name reported back to userland.

nfs_path() always generates a trailing slash when the given dentry is
the root of an NFS mount, but userland may expect the original device
name to be returned verbatim (as it used to be).  Make this
canonicalisation optional and change the callers accordingly.

[jrnieder@gmail.com: use flag instead of bool argument]
Reported-and-tested-by: Chris Hiestand <chiestand@salk.edu>
Reference: http://bugs.debian.org/669314
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agonfsv3: Make v3 mounts fail with ETIMEDOUTs instead EIO on mountd timeouts
Scott Mayhew [Tue, 16 Oct 2012 17:22:19 +0000]
nfsv3: Make v3 mounts fail with ETIMEDOUTs instead EIO on mountd timeouts

commit acce94e68a0f346115fd41cdc298197d2d5a59ad upstream.

In very busy v3 environment, rpc.mountd can respond to the NULL
procedure but not the MNT procedure in a timely manner causing
the MNT procedure to time out. The problem is the mount system
call returns EIO which causes the mount to fail, instead of
ETIMEDOUT, which would cause the mount to be retried.

This patch sets the RPC_TASK_SOFT|RPC_TASK_TIMEOUT flags to
the rpc_call_sync() call in nfs_mount() which causes
ETIMEDOUT to be returned on timed out connections.

Signed-off-by: Steve Dickson <steved@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: fix SSID copy on IBSS JOIN
Antonio Quartulli [Fri, 26 Oct 2012 16:54:25 +0000]
mac80211: fix SSID copy on IBSS JOIN

commit badecb001a310408d3473b1fc2ed5aefd0bc92a9 upstream.

The 'ssid' field of the cfg80211_ibss_params is a u8 pointer and
its length is likely to be less than IEEE80211_MAX_SSID_LEN most
of the time.

This patch fixes the ssid copy in ieee80211_ibss_join() by using
the SSID length to prevent it from reading beyond the string.

Signed-off-by: Antonio Quartulli <ordex@autistici.org>
[rewrapped commit message, small rewording]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: make sure data is accessible in EAPOL check
Johannes Berg [Thu, 25 Oct 2012 22:41:23 +0000]
mac80211: make sure data is accessible in EAPOL check

commit 6dbda2d00d466225f9db1dc695ff852443f28832 upstream.

The code to allow EAPOL frames even when the station
isn't yet marked associated needs to check that the
incoming frame is long enough and due to paged RX it
also can't assume skb->data contains the right data,
it must use skb_copy_bits(). Fix this to avoid using
data that doesn't really exist.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: verify that skb data is present
Johannes Berg [Thu, 25 Oct 2012 22:36:40 +0000]
mac80211: verify that skb data is present

commit 9b395bc3be1cebf0144a127c7e67d56dbdac0930 upstream.

A number of places in the mesh code don't check that
the frame data is present and in the skb header when
trying to access. Add those checks and the necessary
pskb_may_pull() calls. This prevents accessing data
that doesn't actually exist.

To do this, export ieee80211_get_mesh_hdrlen() to be
able to use it in mac80211.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: check management frame header length
Johannes Berg [Thu, 25 Oct 2012 22:33:36 +0000]
mac80211: check management frame header length

commit 4a4f1a5808c8bb0b72a4f6e5904c53fb8c9cd966 upstream.

Due to pskb_may_pull() checking the skb length, all
non-management frames are checked on input whether
their 802.11 header is fully present. Also add that
check for management frames and remove a check that
is now duplicate. This prevents accessing skb data
beyond the frame end.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrm/udl: fix stride issues scanning out stride != width*bpp
Dave Airlie [Thu, 1 Nov 2012 03:47:09 +0000]
drm/udl: fix stride issues scanning out stride != width*bpp

commit 3916e1d71b62b120888aa50bcc8d9a6200fc19a7 upstream.

When buffer sharing with the i915 and using a 1680x1050 monitor,
the i915 gives is a 6912 buffer for the 6720 width, the code doesn't
render this properly as it uses one value to set the base address for
reading from the vmap and for where to start on the device.

This fixes it by calculating the values correctly for the device and
for the pixmap. No idea how I haven't seen this before now.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoDRM/Radeon: Fix Load Detection on legacy primary DAC.
Egbert Eich [Wed, 24 Oct 2012 16:29:49 +0000]
DRM/Radeon: Fix Load Detection on legacy primary DAC.

commit 83325d072185899b706de2956170b246585aaec9 upstream.

An uninitialized variable led to broken load detection.

Signed-off-by: Egbert Eich <eich@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: don't inspect Sequence Control field on control frames
Javier Cardona [Thu, 25 Oct 2012 18:10:18 +0000]
mac80211: don't inspect Sequence Control field on control frames

commit f7fbf70ee9db6da6033ae50d100e017ac1f26555 upstream.

Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is
not present in control frames.  We noticed this problem when processing
Block Ack Requests.

Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Javier Lopez <jlopex@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: Only process mesh config header on frames that RA_MATCH
Javier Cardona [Wed, 24 Oct 2012 19:43:30 +0000]
mac80211: Only process mesh config header on frames that RA_MATCH

commit 555cb715be8ef98b8ec362b23dfc254d432a35b1 upstream.

Doing otherwise is wrong, and may wreak havoc on the mpp tables,
specially if the frame is encrypted.

Reported-by: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: use blacklist for duplicate IE check
Johannes Berg [Wed, 24 Oct 2012 12:19:53 +0000]
mac80211: use blacklist for duplicate IE check

commit 9690fb169b433a66485c808e4fc352b8a0f8d866 upstream.

Instead of the current whitelist which accepts duplicates
only for the quiet and vendor IEs, use a blacklist of all
IEs (that we currently parse) that can't be duplicated.

This avoids detecting a beacon as corrupt in the future
when new IEs are added that can be duplicated.

Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agowireless: drop invalid mesh address extension frames
Johannes Berg [Thu, 25 Oct 2012 19:51:59 +0000]
wireless: drop invalid mesh address extension frames

commit 7dd111e8ee10cc6816669eabcad3334447673236 upstream.

The mesh header can have address extension by a 4th
or a 5th and 6th address, but never both. Drop such
frames in 802.11 -> 802.3 conversion along with any
frames that have the wrong extension.

Reviewed-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agocfg80211: fix antenna gain handling
Felix Fietkau [Wed, 17 Oct 2012 11:56:19 +0000]
cfg80211: fix antenna gain handling

commit c4a9fafc77a5318f5ed26c509bbcddf03e18c201 upstream.

No driver initializes chan->max_antenna_gain to something sensible, and
the only place where it is being used right now is inside ath9k. This
leads to ath9k potentially using less tx power than it can use, which can
decrease performance/range in some rare cases.

Rather than going through every single driver, this patch initializes
chan->orig_mag in wiphy_register(), ignoring whatever value the driver
left in there. If a driver for some reason wishes to limit it independent
from regulatory rulesets, it can do so internally.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agotarget: Fix incorrect usage of nested IRQ spinlocks in ABORT_TASK path
Steve Hodgson [Wed, 31 Oct 2012 17:24:02 +0000]
target: Fix incorrect usage of nested IRQ spinlocks in ABORT_TASK path

commit ab74b3d62f05192bf8fb8f169e7999d1183b2e08 upstream.

This patch changes core_tmr_abort_task() to use spin_lock -> spin_unlock
around se_cmd->t_state_lock while spin_lock_irqsave is held via
se_sess->sess_cmd_lock.

Signed-off-by: Steve Hodgson <steve@purestorage.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoiscsi-target: Fix missed wakeup race in TX thread
Roland Dreier [Wed, 31 Oct 2012 16:16:46 +0000]
iscsi-target: Fix missed wakeup race in TX thread

commit d5627acba9ae584cf4928af19f7ddf5f6837de32 upstream.

The sleeping code in iscsi_target_tx_thread() is susceptible to the classic
missed wakeup race:

 - TX thread finishes handle_immediate_queue() and handle_response_queue(),
   thinks both queues are empty.
 - Another thread adds a queue entry and does wake_up_process(), which does
   nothing because the TX thread is still awake.
 - TX thread does schedule_timeout() and sleeps forever.

In practice this can kill an iSCSI connection if for example an initiator
does single-threaded writes and the target misses the wakeup window when
queueing an R2T; in this case the connection will be stuck until the
initiator loses patience and does some task management operation (or kills
the connection entirely).

Fix this by converting to wait_event_interruptible(), which does not
suffer from this sort of race.

Signed-off-by: Roland Dreier <roland@purestorage.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agotarget: Avoid integer overflow in se_dev_align_max_sectors()
Roland Dreier [Wed, 31 Oct 2012 16:16:45 +0000]
target: Avoid integer overflow in se_dev_align_max_sectors()

commit 3e03989b5868acf69a391a424dc71fcd6cc48167 upstream.

The expression (max_sectors * block_size) might overflow a u32
(indeed, since iblock sets max_hw_sectors to UINT_MAX, it is
guaranteed to overflow and end up with a much-too-small result in many
common cases).  Fix this by doing an equivalent calculation that
doesn't require multiplication.

While we're touching this code, avoid splitting a printk format across
two lines and use pr_info(...) instead of printk(KERN_INFO ...).

Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agotarget: Don't return success from module_init() if setup fails
Roland Dreier [Wed, 31 Oct 2012 16:16:44 +0000]
target: Don't return success from module_init() if setup fails

commit 0d0f9dfb31e0a6c92063e235417b42df185b3275 upstream.

If the call to core_dev_release_virtual_lun0() fails, then nothing
sets ret to anything other than 0, so even though everything is
torn down and freed, target_core_init_configfs() will seem to succeed
and the module will be loaded.  Fix this by passing the return value
on up the chain.

Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agort2800: validate step value for temperature compensation
Stanislaw Gruszka [Thu, 25 Oct 2012 07:51:39 +0000]
rt2800: validate step value for temperature compensation

commit bf7e1abe434ba9e22e8dc04a4cba4ab504b788b8 upstream.

Some hardware has correct (!= 0xff) value of tssi_bounds[4] in the
EEPROM, but step is equal to 0xff. This results on ridiculous delta
calculations and completely broke TX power settings.

Reported-and-tested-by: Pavel Lucik <pavel.lucik@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoath9k: Test for TID only in BlockAcks while checking tx status
Sven Eckelmann [Mon, 29 Oct 2012 12:25:20 +0000]
ath9k: Test for TID only in BlockAcks while checking tx status

commit 6fe7cc71bbf3a0bc28c9cec3c00bc11e81344412 upstream.

The ath9k xmit functions for AMPDUs can send frames as non-aggregate in case
only one frame is currently available. The client will then answer using a
normal Ack instead of a BlockAck. This acknowledgement has no TID stored and
therefore the hardware is not able to provide us the corresponding TID.

The TID set by the hardware in the tx status descriptor has to be seen as
undefined and not as a valid TID value for normal acknowledgements. Doing
otherwise results in a massive amount of retransmissions and stalls of
connections.

Users may experience low bandwidth and complete connection stalls in
environments with transfers using multiple TIDs.

This regression was introduced in b11b160defc48e4daa283f785192ea3a23a51f8e
("ath9k: validate the TID in the tx status information").

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoath9k: fix stale pointers potentially causing access to free'd skbs
Felix Fietkau [Thu, 25 Oct 2012 22:31:11 +0000]
ath9k: fix stale pointers potentially causing access to free'd skbs

commit 8c6e30936a7893a85f6222084f0f26aceb81137a upstream.

bf->bf_next is only while buffers are chained as part of an A-MPDU
in the tx queue. When a tid queue is flushed (e.g. on tearing down
an aggregation session), frames can be enqueued again as normal
transmission, without bf_next being cleared. This can lead to the
old pointer being dereferenced again later.

This patch might fix crashes and "Failed to stop TX DMA!" messages.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoInput: tsc40 - remove wrong announcement of pressure support
Rolf Eike Beer [Wed, 31 Oct 2012 06:39:10 +0000]
Input: tsc40 - remove wrong announcement of pressure support

commit 32ed1911fc79908d704023317d4ddeb3883fd07e upstream.

The tsc40 driver announces it supports the pressure event, but will never
send one. The announcement will cause tslib to wait for such events and
sending all touch events with a pressure of 0. Removing the announcement
will make tslib fall back to emulating the pressure on touch events so
everything works as expected.

Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoxen/mmu: Use Xen specific TLB flush instead of the generic one.
Konrad Rzeszutek Wilk [Wed, 31 Oct 2012 16:38:31 +0000]
xen/mmu: Use Xen specific TLB flush instead of the generic one.

commit 95a7d76897c1e7243d4137037c66d15cbf2cce76 upstream.

As Mukesh explained it, the MMUEXT_TLB_FLUSH_ALL allows the
hypervisor to do a TLB flush on all active vCPUs. If instead
we were using the generic one (which ends up being xen_flush_tlb)
we end up making the MMUEXT_TLB_FLUSH_LOCAL hypercall. But
before we make that hypercall the kernel will IPI all of the
vCPUs (even those that were asleep from the hypervisor
perspective). The end result is that we needlessly wake them
up and do a TLB flush when we can just let the hypervisor
do it correctly.

This patch gives around 50% speed improvement when migrating
idle guest's from one host to another.

Oracle-bug: 14630170

Tested-by:  Jingjie Jiang <jingjie.jiang@oracle.com>
Suggested-by:  Mukesh Rathor <mukesh.rathor@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoxen/gntdev: don't leak memory from IOCTL_GNTDEV_MAP_GRANT_REF
David Vrabel [Wed, 24 Oct 2012 11:39:02 +0000]
xen/gntdev: don't leak memory from IOCTL_GNTDEV_MAP_GRANT_REF

commit a67baeb77375199bbd842fa308cb565164dd1f19 upstream.

map->kmap_ops allocated in gntdev_alloc_map() wasn't freed by
gntdev_put_map().

Add a gntdev_free_map() helper function to free everything allocated
by gntdev_alloc_map().

Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoLinux 3.4.18
Greg Kroah-Hartman [Mon, 5 Nov 2012 08:50:52 +0000]
Linux 3.4.18

6 years agoRevert: ARM: SAMSUNG: Add naming of s3c64xx-spi devices
Greg Kroah-Hartman [Wed, 17 Oct 2012 07:47:11 +0000]
Revert: ARM: SAMSUNG: Add naming of s3c64xx-spi devices

This reverts commit baa526f45d3f096a1cd9f14b668203a03bbab6f9, which is
commit 308b3afb97dc342e9c4f958d8b4c459ae0e22bd7 upstream.

To quote Colin Cross:
This patch breaks Exynos5 spi on 3.4.17.  The patch with the bug
that this patch was supposed to address went in to 3.6 and not
3.4, so this patch causes a driver name mismatch when applied to
3.4.

Cc: Colin Cross <ccross@google.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrm/nouveau: headless mode by default if pci class != vga display
Ben Skeggs [Thu, 1 Nov 2012 06:16:32 +0000]
drm/nouveau: headless mode by default if pci class != vga display

This is to prevent nouveau from taking over the console on headless boards
such as Tesla.

Backport of upstream commit: e412e95a268fa8544858ebfe066826b290430d51

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrm/nouveau: fix suspend/resume when in headless mode
Ben Skeggs [Thu, 1 Nov 2012 06:16:31 +0000]
drm/nouveau: fix suspend/resume when in headless mode

Backport of fixes from upstream commit:
9430738d80223a1cd791a2baa74fa170d3df1262

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrm/nouveau: silence modesetting spam on pre-gf8 chipsets
Ben Skeggs [Sun, 28 Oct 2012 23:03:07 +0000]
drm/nouveau: silence modesetting spam on pre-gf8 chipsets

commit cee59f15a60cc6269a25e3f6fbf1a577d6ab8115 upstream.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoHID: microsoft: fix invalid rdesc for 3k kbd
Jiri Slaby [Fri, 19 Oct 2012 11:28:46 +0000]
HID: microsoft: fix invalid rdesc for 3k kbd

commit 3ccc60f9d8c39180c205dba1a020735bda1b2491 upstream.

Microsoft Digital Media Keyboard 3000 has two interfaces, and the
second one has a report descriptor with a bug. The second collection
says:
05 01 -- global; usage page -- 01 -- Generic Desktop Controls
09 80 -- local; usage -- 80 -- System Control
a1 01 -- main; collection -- 01 -- application

85 03 -- global; report ID -- 03
19 00 -- local; Usage Minimum -- 00
29 ff -- local; Usage Maximum -- ff
15 00 -- global; Logical Minimum -- 0
26 ff 00 -- global; Logical Maximum -- ff
81 00 -- main; input

c0 -- main; End Collection

I.e. it makes us think that there are all kinds of usages of system
control. That the keyboard is a not only a keyboard, but also a
joystick, mouse, gamepad, keypad, etc. The same as for the Wireless
Desktop Receiver, this should be Physical Min/Max. So fix that
appropriately.

References: https://bugzilla.novell.com/show_bug.cgi?id=776834
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agotarget: Fix double-free of se_cmd in target_complete_tmr_failure
Nicholas Bellinger [Fri, 26 Oct 2012 22:35:45 +0000]
target: Fix double-free of se_cmd in target_complete_tmr_failure

commit e13d5fef88c40b87c8430f8274c3a9ca32ef90bc upstream.

Fabric drivers currently expect to internally release se_cmd in the event
of a TMR failure during target_submit_tmr(), which means the immediate call
to transport_generic_free_cmd() after TFO->queue_tm_rsp() from within
target_complete_tmr_failure() workqueue context is wrong.

This is done as some fabrics expect TMR operations to be acknowledged
before releasing the descriptor, so the assumption that core is releasing
se_cmd associated TMR memory is incorrect.  This fixes a OOPs where
transport_generic_free_cmd() was being called more than once.

This bug was originally observed with tcm_qla2xxx fabric ports.

Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Roland Dreier <roland@purestorage.com>
Cc: Andy Grover <agrover@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agob43: Fix oops on unload when firmware not found
Larry Finger [Wed, 24 Oct 2012 13:57:16 +0000]
b43: Fix oops on unload when firmware not found

commit f89ff6441df06abc2d95f3ef67525923032d6283 upstream.

When b43 fails to find firmware when loaded, a subsequent unload will
oops due to calling ieee80211_unregister_hw() when the corresponding
register call was never made.

Commit 2d838bb608e2d1f6cb4280e76748cb812dc822e7 fixed the same problem
for b43legacy.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Markus Kanet <dvmailing@gmx.eu>
Cc: Markus Kanet <dvmailing@gmx.eu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agofloppy: do put_disk on current dr if blk_init_queue fails
Herton Ronaldo Krzesinski [Mon, 27 Aug 2012 23:56:52 +0000]
floppy: do put_disk on current dr if blk_init_queue fails

commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.

If blk_init_queue fails, we do not call put_disk on the current dr
(dr is decremented first in the error handling loop).

Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomd/raid1: Fix assembling of arrays containing Replacements.
NeilBrown [Wed, 31 Oct 2012 00:42:03 +0000]
md/raid1: Fix assembling of arrays containing Replacements.

commit 02b898f2f04e418094f0093a3ad0b415bcdbe8eb upstream.

setup_conf in raid1.c uses conf->raid_disks before assigning
a value.  It is used when including 'Replacement' devices.

The consequence is that assembling an array which contains a
replacement will misbehave and either not include the replacement, or
not include the device being replaced.

Though this doesn't lead directly to data corruption, it could lead to
reduced data safety.

So use mddev->raid_disks, which is initialised, instead.

Bug was introduced by commit c19d57980b38a5bb613a898937a1cf85f422fb9b
      md/raid1: recognise replacements when assembling arrays.

in 3.3, so fix is suitable for 3.3.y thru 3.6.y.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agogpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios
Mathias Nyman [Thu, 25 Oct 2012 11:03:03 +0000]
gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios

commit ad2fab36d7922401c4576fb7ea9b21a47a29a17f upstream.

gpios requested with invalid numbers, or gpios requested from userspace via sysfs
should not try to be deferred on failure.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agogpio-timberdale: fix a potential wrapping issue
Dan Carpenter [Thu, 11 Oct 2012 06:56:35 +0000]
gpio-timberdale: fix a potential wrapping issue

commit d79550a7bc35c16476ebdc27c78378d8093390ec upstream.

->last_ier is an unsigned long but the high bits can't be used int the
original code because the shift wraps.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoext4: fix unjournaled inode bitmap modification
Eric Sandeen [Mon, 29 Oct 2012 02:24:57 +0000]
ext4: fix unjournaled inode bitmap modification

commit ffb5387e85d528fb6d0d924abfa3fbf0fc484071 upstream.

commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 changed
ext4_new_inode() such that the inode bitmap was being modified
outside a transaction, which could lead to corruption, and was
discovered when journal_checksum found a bad checksum in the
journal during log replay.

Nix ran into this when using the journal_async_commit mount
option, which enables journal checksumming.  The ensuing
journal replay failures due to the bad checksums led to
filesystem corruption reported as the now infamous
"Apparent serious progressive ext4 data corruption bug"

[ Changed by tytso to only call ext4_journal_get_write_access() only
  when we're fairly certain that we're going to allocate the inode. ]

I've tested this by mounting with journal_checksum and
running fsstress then dropping power; I've also tested by
hacking DM to create snapshots w/o first quiescing, which
allows me to test journal replay repeatedly w/o actually
power-cycling the box.  Without the patch I hit a journal
checksum error every time.  With this fix it survives
many iterations.

Reported-by: Nix <nix@esperi.org.uk>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoLinux 3.4.17
Greg Kroah-Hartman [Wed, 31 Oct 2012 17:05:17 +0000]
Linux 3.4.17

6 years agodrm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13
Sjoerd Simons [Fri, 22 Jun 2012 07:43:07 +0000]
drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13

commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364 upstream.

This box claims to have an LVDS interface but doesn't
actually have one.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agox86, mm: Use memblock memory loop instead of e820_RAM
Yinghai Lu [Mon, 22 Oct 2012 23:35:18 +0000]
x86, mm: Use memblock memory loop instead of e820_RAM

commit 1f2ff682ac951ed82cc043cf140d2851084512df upstream.

We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin <jacob.shin@amd.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agostaging: comedi: amplc_pc236: fix invalid register access during detach
Ian Abbott [Wed, 3 Oct 2012 15:25:17 +0000]
staging: comedi: amplc_pc236: fix invalid register access during detach

commit aaeb61a97b7159ebe30b18a422d04eeabfa8790b upstream.

`pc236_detach()` is called by the comedi core if it attempted to attach
a device and failed.  `pc236_detach()` calls `pc236_intr_disable()` if
the comedi device private data pointer (`devpriv`) is non-null.  This
test is insufficient as `pc236_intr_disable()` accesses hardware
registers and the attach routine may have failed before it has saved
their I/O base addresses.

Fix it by checking `dev->iobase` is non-zero before calling
`pc236_intr_disable()` as that means the I/O base addresses have been
saved and the hardware registers can be accessed.  It also implies the
comedi device private data pointer is valid, so there is no need to
check it.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agox86: efi: Turn off efi_enabled after setup on mixed fw/kernel
Olof Johansson [Wed, 24 Oct 2012 17:00:44 +0000]
x86: efi: Turn off efi_enabled after setup on mixed fw/kernel

commit 5189c2a7c7769ee9d037d76c1a7b8550ccf3481c upstream.

When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

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

Reported-by: Marko Kohtala <marko.kohtala@gmail.com>
Reported-by: Maxim Kammerer <mk@dee.su>
Signed-off-by: Olof Johansson <olof@lixom.net>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoefi: Defer freeing boot services memory until after ACPI init
Josh Triplett [Sat, 29 Sep 2012 00:55:44 +0000]
efi: Defer freeing boot services memory until after ACPI init

commit 785107923a83d8456bbd8564e288a24d84109a46 upstream.

Some new ACPI 5.0 tables reference resources stored in boot services
memory, so keep that memory around until we have ACPI and can extract
data from it.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Link: http://lkml.kernel.org/r/baaa6d44bdc4eb0c58e5d1b4ccd2c729f854ac55.1348876882.git.josh@joshtriplett.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agox86, mm: Undo incorrect revert in arch/x86/mm/init.c
Yinghai Lu [Thu, 25 Oct 2012 22:45:26 +0000]
x86, mm: Undo incorrect revert in arch/x86/mm/init.c

commit f82f64dd9f485e13f29f369772d4a0e868e5633a upstream.

Commit

    844ab6f9 x86, mm: Find_early_table_space based on ranges that are actually being mapped

added back some lines back wrongly that has been removed in commit

    7b16bbf97 Revert "x86/mm: Fix the size calculation of mapping tables"

remove them again.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/CAE9FiQW_vuaYQbmagVnxT2DGsYc=9tNeAbdBq53sYkitPOwxSQ@mail.gmail.com
Acked-by: Jacob Shin <jacob.shin@amd.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agox86, mm: Find_early_table_space based on ranges that are actually being mapped
Jacob Shin [Wed, 24 Oct 2012 19:24:44 +0000]
x86, mm: Find_early_table_space based on ranges that are actually being mapped

commit 844ab6f993b1d32eb40512503d35ff6ad0c57030 upstream.

Current logic finds enough space for direct mapping page tables from 0
to end. Instead, we only need to find enough space to cover mr[0].start
to mr[nr_range].end -- the range that is actually being mapped by
init_memory_mapping()

This is needed after 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a, to address
the panic reported here:

  https://lkml.org/lkml/2012/10/20/160
  https://lkml.org/lkml/2012/10/21/157

Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Link: http://lkml.kernel.org/r/20121024195311.GB11779@jshin-Toonie
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoRevert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"
Felix Fietkau [Wed, 17 Oct 2012 11:50:43 +0000]
Revert "ath9k_hw: Updated AR9003 tx gain table for 5GHz"

commit 73b26df5fa1a6245d6fc982362518b620bc7c2fe upstream.

This reverts commit a240dc7b3c7463bd60cf0a9b2a90f52f78aae0fd.

This commit is reducing tx power by at least 10 db on some devices,
e.g. the Buffalo WZR-HP-G450H.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: rmanohar@qca.qualcomm.com
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agocpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code
Andreas Herrmann [Mon, 22 Oct 2012 22:55:10 +0000]
cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code

commit e4df1cbcc1f329e53a1fff7450b2229e0addff20 upstream.

Commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9
(cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU)
causes powernow-k8 to trigger a preempt warning, e.g.:

  BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776
  caller is powernowk8_target+0x20/0x49
  Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9
  Call Trace:
   [<ffffffff8125b447>] debug_smp_processor_id+0xc7/0xe0
   [<ffffffff814877e7>] powernowk8_target+0x20/0x49
   [<ffffffff81482b02>] __cpufreq_driver_target+0x82/0x8a
   [<ffffffff81484fc6>] cpufreq_governor_performance+0x4e/0x54
   [<ffffffff81482c50>] __cpufreq_governor+0x8c/0xc9
   [<ffffffff81482e6f>] __cpufreq_set_policy+0x1a9/0x21e
   [<ffffffff814839af>] store_scaling_governor+0x16f/0x19b
   [<ffffffff81484f16>] ? cpufreq_update_policy+0x124/0x124
   [<ffffffff8162b4a5>] ? _raw_spin_unlock_irqrestore+0x2c/0x49
   [<ffffffff81483640>] store+0x60/0x88
   [<ffffffff811708c0>] sysfs_write_file+0xf4/0x130
   [<ffffffff8111243b>] vfs_write+0xb5/0x151
   [<ffffffff811126e0>] sys_write+0x4a/0x71
   [<ffffffff816319a9>] system_call_fastpath+0x16/0x1b

Fix this by by always using work_on_cpu().

Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agobcma: fix unregistration of cores
Piotr Haber [Thu, 11 Oct 2012 12:05:15 +0000]
bcma: fix unregistration of cores

commit 1fffa905adffbf0d3767fc978ef09afb830275eb upstream.

When cores are unregistered, entries
need to be removed from cores list in a safe manner.

Reported-by: Stanislaw Gruszka <sgruszka@redhat.com>
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Signed-off-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc()
Wei Yongjun [Sun, 21 Oct 2012 11:58:30 +0000]
dmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc()

commit 720dfd250e48a8c7fd1b2b8645955413989c4ee0 upstream.

Add the missing unlock on the error handling path in function
imxdma_xfer_desc().

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodmaengine: sirf: fix a typo in moving running dma_desc to active queue
Barry Song [Thu, 27 Sep 2012 08:36:10 +0000]
dmaengine: sirf: fix a typo in moving running dma_desc to active queue

commit 26fd12209c08fe947be1828896ef4ffc5bd0e6df upstream.

list_move_tail(&schan->queued, &schan->active) makes the list_empty(schan->queued)
undefined, we either should change it to:
list_move_tail(schan->queued.next, &schan->active)
or
list_move_tail(&sdesc->node, &schan->active)

Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodmaengine: sirf: fix a typo in dma_prep_interleaved
Barry Song [Thu, 27 Sep 2012 08:35:38 +0000]
dmaengine: sirf: fix a typo in dma_prep_interleaved

commit 5997e089e4c3a7f0958a8fb0a54ec2b5a6f06168 upstream.

either DEV_TO_MEM or MEM_TO_DEV is supported, so change
OR to AND.

Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agofreezer: exec should clear PF_NOFREEZE along with PF_KTHREAD
Oleg Nesterov [Thu, 25 Oct 2012 20:28:12 +0000]
freezer: exec should clear PF_NOFREEZE along with PF_KTHREAD

commit b40a79591ca918e7b91b0d9b6abd5d00f2e88c19 upstream.

flush_old_exec() clears PF_KTHREAD but forgets about PF_NOFREEZE.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoBluetooth: SMP: Fix setting unknown auth_req bits
Johan Hedberg [Thu, 11 Oct 2012 14:26:06 +0000]
Bluetooth: SMP: Fix setting unknown auth_req bits

commit 065a13e2cc665f6547dc7e8a9d6b6565badf940a upstream.

When sending a pairing request or response we should not just blindly
copy the value that the remote device sent. Instead we should at least
make sure to mask out any unknown bits. This is particularly critical
from the upcoming LE Secure Connections feature perspective as
incorrectly indicating support for it (by copying the remote value)
would cause a failure to pair with devices that support it.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomac80211: check if key has TKIP type before updating IV
Stanislaw Gruszka [Tue, 2 Oct 2012 19:34:23 +0000]
mac80211: check if key has TKIP type before updating IV

commit 4045f72bcf3c293c7c5932ef001742d8bb5ded76 upstream.

This patch fix corruption which can manifest itself by following crash
when switching on rfkill switch with rt2x00 driver:
https://bugzilla.redhat.com/attachment.cgi?id=615362

Pointer key->u.ccmp.tfm of group key get corrupted in:

ieee80211_rx_h_michael_mic_verify():

        /* update IV in key information to be able to detect replays */
        rx->key->u.tkip.rx[rx->security_idx].iv32 = rx->tkip_iv32;
        rx->key->u.tkip.rx[rx->security_idx].iv16 = rx->tkip_iv16;

because rt2x00 always set RX_FLAG_MMIC_STRIPPED, even if key is not TKIP.

We already check type of the key in different path in
ieee80211_rx_h_michael_mic_verify() function, so adding additional
check here is reasonable.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoARM: at91: at91sam9g10: fix SOC type detection
Ivan Shugov [Wed, 24 Oct 2012 09:02:44 +0000]
ARM: at91: at91sam9g10: fix SOC type detection

commit 3d9a0183dd3423353e9e363bcc261c1220d05f9f upstream.

Newer at91sam9g10 SoC revision can't be detected, so the kernel can't boot with
this kind of kernel panic:
"AT91: Impossible to detect the SOC type"

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Atmel AT91SAM9G10-EK
Ignoring tag cmdline (using the default kernel command line)
bootconsole [earlycon0] enabled
Memory policy: ECC disabled, Data cache writeback
Kernel panic - not syncing: AT91: Impossible to detect the SOC type
[<c00133d4>] (unwind_backtrace+0x0/0xe0) from [<c02366dc>] (panic+0x78/0x1cc)
[<c02366dc>] (panic+0x78/0x1cc) from [<c02fa35c>] (at91_map_io+0x90/0xc8)
[<c02fa35c>] (at91_map_io+0x90/0xc8) from [<c02f9860>] (paging_init+0x564/0x6d0)
[<c02f9860>] (paging_init+0x564/0x6d0) from [<c02f7914>] (setup_arch+0x464/0x704)
[<c02f7914>] (setup_arch+0x464/0x704) from [<c02f44f8>] (start_kernel+0x6c/0x2d4)
[<c02f44f8>] (start_kernel+0x6c/0x2d4) from [<20008040>] (0x20008040)

The reason for this is that the Debug Unit Chip ID Register has changed between
Engineering Sample and definitive revision of the SoC. Changing the check of
cidr to socid will address the problem. We do not integrate this check to the
list just above because we also have to make sure that the extended id is
disregarded.

Signed-off-by: Ivan Shugov <ivan.shugov@gmail.com>
[nicolas.ferre@atmel.com: change commit message]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoARM: at91/i2c: change id to let i2c-gpio work
Bo Shen [Mon, 15 Oct 2012 09:30:27 +0000]
ARM: at91/i2c: change id to let i2c-gpio work

commit 7840487cd6298f9f931103b558290d8d98d41c49 upstream.

The i2c core driver will turn the platform device ID to busnum
When using platfrom device ID as -1, it means dynamically assigned
the busnum. When writing code, we need to make sure the busnum,
and call i2c_register_board_info(int busnum, ...) to register device
if using -1, we do not know the value of busnum

In order to solve this issue, set the platform device ID as a fix number
Here using 0 to match the busnum used in i2c_regsiter_board_info()

Signed-off-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoARM: at91/tc: fix typo in the DT document
Josh Wu [Fri, 14 Sep 2012 09:01:29 +0000]
ARM: at91/tc: fix typo in the DT document

commit 11930c530f3edf81160e4962e363d579f5cdce7e upstream.

Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoARM: SAMSUNG: Add naming of s3c64xx-spi devices
Heiko Stuebner [Wed, 17 Oct 2012 07:47:11 +0000]
ARM: SAMSUNG: Add naming of s3c64xx-spi devices

commit 308b3afb97dc342e9c4f958d8b4c459ae0e22bd7 upstream.

Commit a5238e360b71 (spi: s3c64xx: move controller information into driver
data) introduced separate device names for the different subtypes of the
spi controller but forgot to set these in the relevant machines.

To fix this introduce a s3c64xx_spi_setname function and populate all
Samsung arches with the correct names. The function resides in a new
header, as the s3c64xx-spi.h contains driver platform data and should
therefore at some later point move out of the Samsung include dir.

Tested on a s3c2416-based machine.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[s.nawrocki@samsung.com: tested on mach-exynos]
Tested-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agovhost: fix mergeable bufs on BE hosts
Michael S. Tsirkin [Wed, 24 Oct 2012 18:37:51 +0000]
vhost: fix mergeable bufs on BE hosts

commit 910a578f7e9400a78a3b13aba0b4d2df16a2cb05 upstream.

We copy head count to a 16 bit field, this works by chance on LE but on
BE guest gets 0. Fix it up.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Alexander Graf <agraf@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: mos7840: remove invalid disconnect handling
Johan Hovold [Thu, 25 Oct 2012 16:56:33 +0000]
USB: mos7840: remove invalid disconnect handling

commit e681b66f2e19fadbe8a7e2a17900978cb6bc921f upstream.

Remove private zombie flag used to signal disconnect and to prevent
control urb from being submitted from interrupt urb completion handler.

The control urb will not be re-submitted as both the control urb and the
interrupt urb is killed on disconnect.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: mos7840: remove NULL-urb submission
Johan Hovold [Thu, 25 Oct 2012 16:56:32 +0000]
USB: mos7840: remove NULL-urb submission

commit 28c3ae9a8cf45f439c9a0779ebd0256e2ae72813 upstream.

The private int_urb is never allocated so the submission from the
control completion handler will always fail. Remove this odd piece of
broken code.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: mos7840: fix port-device leak in error path
Johan Hovold [Thu, 25 Oct 2012 11:35:10 +0000]
USB: mos7840: fix port-device leak in error path

commit 3eb55cc4ed88eee3b5230f66abcdbd2a91639eda upstream.

The driver set the usb-serial port pointers to NULL on errors in attach,
effectively preventing usb-serial core from decrementing the port ref
counters and releasing the port devices and associated data.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: mos7840: fix urb leak at release
Johan Hovold [Thu, 25 Oct 2012 11:35:09 +0000]
USB: mos7840: fix urb leak at release

commit 65a4cdbb170e4ec1a7fa0e94936d47e24a17b0e8 upstream.

Make sure control urb is freed at release.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: sierra: fix memory leak in probe error path
Johan Hovold [Thu, 25 Oct 2012 08:29:18 +0000]
USB: sierra: fix memory leak in probe error path

commit 084817d79399ab5ccab2f90a148b0369912a8369 upstream.

Move interface data allocation to attach so that it is deallocated on
errors in usb-serial probe.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: sierra: fix memory leak in attach error path
Johan Hovold [Thu, 25 Oct 2012 08:29:17 +0000]
USB: sierra: fix memory leak in attach error path

commit 7e41f9bcdd2e813ea2a3c40db291d87ea06b559f upstream.

Make sure port private data is deallocated on errors in attach.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: serial: Fix memory leak in sierra_release()
Lennart Sorensen [Wed, 24 Oct 2012 14:23:09 +0000]
USB: serial: Fix memory leak in sierra_release()

commit f7bc5051667b74c3861f79eed98c60d5c3b883f7 upstream.

I found a memory leak in sierra_release() (well sierra_probe() I guess)
that looses 8 bytes each time the driver releases a device.

Signed-off-by: Len Sorensen <lsorense@csclub.uwaterloo.ca>
Acked-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: opticon: fix memory leak in error path
Johan Hovold [Thu, 25 Oct 2012 08:29:12 +0000]
USB: opticon: fix memory leak in error path

commit acbf0e5263de563e25f7c104868e4490b9e72b13 upstream.

Fix memory leak in write error path.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: opticon: fix DMA from stack
Johan Hovold [Thu, 25 Oct 2012 08:29:11 +0000]
USB: opticon: fix DMA from stack

commit ea0dbebffe118724cd4df7d9b071ea8ee48d48f0 upstream.

Make sure to allocate the control-message buffer dynamically as some
platforms cannot do DMA from stack.

Note that only the first byte of the old buffer was used.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoUSB: whiteheat: fix memory leak in error path
Johan Hovold [Thu, 25 Oct 2012 08:29:01 +0000]
USB: whiteheat: fix memory leak in error path

commit c129197c99550d356cf5f69b046994dd53cd1b9d upstream.

Make sure command buffer is deallocated in case of errors during attach.

Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: <support@connecttech.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agousb hub: send clear_tt_buffer_complete events when canceling TT clear work
Octavian Purdila [Mon, 1 Oct 2012 19:21:12 +0000]
usb hub: send clear_tt_buffer_complete events when canceling TT clear work

commit 3b6054da68f9b0d5ed6a7ed0f42a79e61904352c upstream.

There is a race condition in the USB hub code with regard to handling
TT clear requests that can get the HCD driver in a deadlock. Usually
when an TT clear request is scheduled it will be executed immediately:

<7>[    6.077583] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us]
<3>[    6.078041] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[    6.078299] hub_tt_work:731
<7>[    9.309089] usb 2-1.5: link qh1-0e01/f4d506c0 start 0 [1/2 us]
<7>[    9.324526] ehci_hcd 0000:00:1d.0: reused qh f4d4db00 schedule
<7>[    9.324539] usb 2-1.3: link qh1-0e01/f4d4db00 start 0 [1/2 us]
<7>[    9.341530] usb 1-1.1: link qh4-0e01/f397aec0 start 2 [1/2 us]
<7>[   10.116159] usb 2-1.3: unlink qh1-0e01/f4d4db00 start 0 [1/2 us]
<3>[   10.116459] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d82
<7>[   10.116537] hub_tt_work:731

However, if a suspend operation is triggered before hub_tt_work is
scheduled, hub_quiesce will cancel the work without notifying the HCD
driver:

<3>[   35.033941] usb 2-1: clear tt buffer port 3, a3 ep2 t04048d80
<5>[   35.034022] sd 0:0:0:0: [sda] Stopping disk
<7>[   35.034039] hub 2-1:1.0: hub_suspend
<7>[   35.034067] usb 2-1: unlink qh256-0001/f3b1ab00 start 1 [1/0 us]
<7>[   35.035085] hub 1-0:1.0: hub_suspend
<7>[   35.035102] usb usb1: bus suspend, wakeup 0
<7>[   35.035106] ehci_hcd 0000:00:1a.0: suspend root hub
<7>[   35.035298] hub 2-0:1.0: hub_suspend
<7>[   35.035313] usb usb2: bus suspend, wakeup 0
<7>[   35.035315] ehci_hcd 0000:00:1d.0: suspend root hub
<6>[   35.250017] PM: suspend of devices complete after 216.979 msecs
<6>[   35.250822] PM: late suspend of devices complete after 0.799 msecs
<7>[   35.252343] ehci_hcd 0000:00:1d.0: wakeup: 1
<7>[   35.262923] ehci_hcd 0000:00:1d.0: --> PCI D3hot
<7>[   35.263302] ehci_hcd 0000:00:1a.0: wakeup: 1
<7>[   35.273912] ehci_hcd 0000:00:1a.0: --> PCI D3hot
<6>[   35.274254] PM: noirq suspend of devices complete after 23.442 msecs
<6>[   35.274975] ACPI: Preparing to enter system sleep state S3
<6>[   35.292666] PM: Saving platform NVS memory
<7>[   35.295030] Disabling non-boot CPUs ...
<6>[   35.297351] CPU 1 is now offline
<6>[   35.300345] CPU 2 is now offline
<6>[   35.303929] CPU 3 is now offline
<7>[   35.303931] lockdep: fixing up alternatives.
<6>[   35.304825] Extended CMOS year: 2000

When the device will resume the EHCI driver will get stuck in
ehci_endpoint_disable waiting for the tt_clearing flag to reset:

<0>[   47.610967] usb 2-1.3: **** DPM device timeout ****
<7>[   47.610972]  f2f11c60 00000092 f2f11c0c c10624a5 00000003 f4c6e880 c1c8a4c0 c1c8a4c0
<7>[   47.610983]  15c55698 0000000b f56b34c0 f2a45b70 f4c6e880 00000082 f2a4602c f2f11c30
<7>[   47.610993]  c10787f8 f4cac000 f2a45b70 00000000 f4cac010 f2f11c58 00000046 00000001
<7>[   47.611004] Call Trace:
<7>[   47.611006]  [<c10624a5>] ? sched_clock_cpu+0xf5/0x160
<7>[   47.611019]  [<c10787f8>] ? lock_release_holdtime.part.22+0x88/0xf0
<7>[   47.611026]  [<c103ed46>] ? lock_timer_base.isra.35+0x26/0x50
<7>[   47.611034]  [<c17592d3>] ? schedule_timeout+0x133/0x290
<7>[   47.611044]  [<c175b43e>] schedule+0x1e/0x50
<7>[   47.611051]  [<c17592d8>] schedule_timeout+0x138/0x290
<7>[   47.611057]  [<c10624a5>] ? sched_clock_cpu+0xf5/0x160
<7>[   47.611063]  [<c103e560>] ? usleep_range+0x40/0x40
<7>[   47.611070]  [<c1759445>] schedule_timeout_uninterruptible+0x15/0x20
<7>[   47.611077]  [<c14935f4>] ehci_endpoint_disable+0x64/0x160
<7>[   47.611084]  [<c147d1ee>] ? usb_hcd_flush_endpoint+0x10e/0x1d0
<7>[   47.611092]  [<c1165663>] ? sysfs_add_file+0x13/0x20
<7>[   47.611100]  [<c147d5a9>] usb_hcd_disable_endpoint+0x29/0x40
<7>[   47.611107]  [<c147fafc>] usb_disable_endpoint+0x5c/0x80
<7>[   47.611111]  [<c147fb57>] usb_disable_interface+0x37/0x50
<7>[   47.611116]  [<c1477650>] usb_reset_and_verify_device+0x4b0/0x640
<7>[   47.611122]  [<c1474665>] ? hub_port_status+0xb5/0x100
<7>[   47.611129]  [<c147a975>] usb_port_resume+0xd5/0x220
<7>[   47.611136]  [<c148877f>] generic_resume+0xf/0x30
<7>[   47.611142]  [<c14821a3>] usb_resume+0x133/0x180
<7>[   47.611147]  [<c1473b10>] ? usb_dev_thaw+0x10/0x10
<7>[   47.611152]  [<c1473b1d>] usb_dev_resume+0xd/0x10
<7>[   47.611157]  [<c13baa60>] dpm_run_callback+0x40/0xb0
<7>[   47.611164]  [<c13bdb03>] ? pm_runtime_enable+0x43/0x70
<7>[   47.611171]  [<c13bafc6>] device_resume+0x1a6/0x2c0
<7>[   47.611177]  [<c13ba940>] ? dpm_show_time+0xe0/0xe0
<7>[   47.611183]  [<c13bb0f9>] async_resume+0x19/0x40
<7>[   47.611189]  [<c10580c4>] async_run_entry_fn+0x64/0x160
<7>[   47.611196]  [<c104a244>] ? process_one_work+0x104/0x480
<7>[   47.611203]  [<c104a24c>] ? process_one_work+0x10c/0x480
<7>[   47.611209]  [<c104a2c0>] process_one_work+0x180/0x480
<7>[   47.611215]  [<c104a244>] ? process_one_work+0x104/0x480
<7>[   47.611220]  [<c1058060>] ? async_schedule+0x10/0x10
<7>[   47.611226]  [<c104c15c>] worker_thread+0x11c/0x2f0
<7>[   47.611233]  [<c104c040>] ? manage_workers.isra.27+0x1f0/0x1f0
<7>[   47.611239]  [<c10507f8>] kthread+0x78/0x80
<7>[   47.611244]  [<c1750000>] ? timer_cpu_notify+0xd6/0x20d
<7>[   47.611253]  [<c1050780>] ? __init_kthread_worker+0x60/0x60
<7>[   47.611258]  [<c176357e>] kernel_thread_helper+0x6/0xd
<7>[   47.611283] ------------[ cut here ]------------

This patch changes hub_quiesce behavior to flush the TT clear work
instead of canceling it, to make sure that no TT clear request remains
uncompleted before suspend.

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agousb-storage: add unusual_devs entry for Casio EX-N1 digital camera
Michael Shigorin [Mon, 22 Oct 2012 09:18:56 +0000]
usb-storage: add unusual_devs entry for Casio EX-N1 digital camera

commit d7870af7e2e3a91b462075ec1ca669b482215187 upstream.

This commit sets removable subclass for Casio EX-N1 digital camera.

The patch has been tested within an ALT Linux kernel:
http://git.altlinux.org/people/led/packages/?p=kernel-image-3.0.git;a=commitdiff;h=c0fd891836e89fe0c93a4d536a59216d90e4e3e7

See also https://bugzilla.kernel.org/show_bug.cgi?id=49221

Signed-off-by: Oleksandr Chumachenko <ledest@gmail.com>
Signed-off-by: Michael Shigorin <mike@osdn.org.ua>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoehci: Add yet-another Lucid nohandoff pci quirk
Anisse Astier [Tue, 9 Oct 2012 10:22:37 +0000]
ehci: Add yet-another Lucid nohandoff pci quirk

commit 8daf8b6086f9d575200cd0aa3797e26137255609 upstream.

Board name changed on another shipping Lucid tablet.

Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoehci: fix Lucid nohandoff pci quirk to be more generic with BIOS versions
Anisse Astier [Tue, 9 Oct 2012 10:22:36 +0000]
ehci: fix Lucid nohandoff pci quirk to be more generic with BIOS versions

commit c323dc023b9501e5d09582ec7efd1d40a9001d99 upstream.

BIOS vendors keep changing the BIOS versions. Only match the beginning
of the string to match all Lucid tablets with board name M11JB.

Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoDrivers: hv: Cleanup error handling in vmbus_open()
K. Y. Srinivasan [Fri, 12 Oct 2012 20:22:42 +0000]
Drivers: hv: Cleanup error handling in vmbus_open()

commit 1392550240aaa72ce3a094a38bd23525cd67ce60 upstream.

Fix a memory leak  in the error handling path in the function vmbus_open().

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Reported-by: Jason Wang <jasowang@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoStaging: android: binder: Allow using highmem for binder buffers
Arve Hjønnevåg [Tue, 16 Oct 2012 22:29:55 +0000]
Staging: android: binder: Allow using highmem for binder buffers

commit 585650dcec88e704a19bb226a34b6a7166111623 upstream.

The default kernel mapping for the pages allocated for the binder
buffers is never used. Set the __GFP_HIGHMEM flag when allocating
these pages so we don't needlessly use low memory pages that may
be required elsewhere.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoStaging: android: binder: Fix memory leak on thread/process exit
Arve Hjønnevåg [Tue, 16 Oct 2012 22:29:54 +0000]
Staging: android: binder: Fix memory leak on thread/process exit

commit 675d66b0ed5fd170d6a44cf8dbb3fa56a5347bdb upstream.

If a thread or process exited while a reply, one-way transaction or
death notification was pending, the struct holding the pending work
was leaked.

Signed-off-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agosysfs: sysfs_pathname/sysfs_add_one: Use strlcat() instead of strcat()
Geert Uytterhoeven [Sat, 29 Sep 2012 20:23:19 +0000]
sysfs: sysfs_pathname/sysfs_add_one: Use strlcat() instead of strcat()

commit 66081a72517a131430dcf986775f3268aafcb546 upstream.

The warning check for duplicate sysfs entries can cause a buffer overflow
when printing the warning, as strcat() doesn't check buffer sizes.
Use strlcat() instead.

Since strlcat() doesn't return a pointer to the passed buffer, unlike
strcat(), I had to convert the nested concatenation in sysfs_add_one() to
an admittedly more obscure comma operator construct, to avoid emitting code
for the concatenation if CONFIG_BUG is disabled.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoxhci: Fix potential NULL ptr deref in command cancellation.
Sarah Sharp [Tue, 16 Oct 2012 20:17:43 +0000]
xhci: Fix potential NULL ptr deref in command cancellation.

commit 43a09f7fb01fa1e091416a2aa49b6c666458c1ee upstream.

The command cancellation code doesn't check whether find_trb_seg()
couldn't find the segment that contains the TRB to be canceled.  This
could cause a NULL pointer deference later in the function when next_trb
is called.  It's unlikely to happen unless something is wrong with the
command ring pointers, so add some debugging in case it happens.

This patch should be backported to stable kernels as old as 3.0, that
contain the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI:
handle command after aborting the command ring".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoSUNRPC: Prevent races in xs_abort_connection()
Trond Myklebust [Tue, 23 Oct 2012 21:50:07 +0000]
SUNRPC: Prevent races in xs_abort_connection()

commit 4bc1e68ed6a8b59be8a79eb719be515a55c7bc68 upstream.

The call to xprt_disconnect_done() that is triggered by a successful
connection reset will trigger another automatic wakeup of all tasks
on the xprt->pending rpc_wait_queue. In particular it will cause an
early wake up of the task that called xprt_connect().

All we really want to do here is clear all the socket-specific state
flags, so we split that functionality out of xs_sock_mark_closed()
into a helper that can be called by xs_abort_connection()

Reported-by: Chris Perl <chris.perl@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Chris Perl <chris.perl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoRevert "SUNRPC: Ensure we close the socket on EPIPE errors too..."
Trond Myklebust [Tue, 23 Oct 2012 15:40:02 +0000]
Revert "SUNRPC: Ensure we close the socket on EPIPE errors too..."

commit b9d2bb2ee537424a7f855e1f93eed44eb9ee0854 upstream.

This reverts commit 55420c24a0d4d1fce70ca713f84aa00b6b74a70e.
Now that we clear the connected flag when entering TCP_CLOSE_WAIT,
the deadlock described in this commit is no longer possible.
Instead, the resulting call to xs_tcp_shutdown() can interfere
with pending reconnection attempts.

Reported-by: Chris Perl <chris.perl@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Chris Perl <chris.perl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoSUNRPC: Clear the connect flag when socket state is TCP_CLOSE_WAIT
Trond Myklebust [Tue, 23 Oct 2012 15:35:47 +0000]
SUNRPC: Clear the connect flag when socket state is TCP_CLOSE_WAIT

commit d0bea455dd48da1ecbd04fedf00eb89437455fdc upstream.

This is needed to ensure that we call xprt_connect() upon the next
call to call_connect().

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Chris Perl <chris.perl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoSUNRPC: Get rid of the xs_error_report socket callback
Trond Myklebust [Mon, 22 Oct 2012 21:14:36 +0000]
SUNRPC: Get rid of the xs_error_report socket callback

commit f878b657ce8e7d3673afe48110ec208a29e38c4a upstream.

Chris Perl reports that we're seeing races between the wakeup call in
xs_error_report and the connect attempts. Basically, Chris has shown
that in certain circumstances, the call to xs_error_report causes the
rpc_task that is responsible for reconnecting to wake up early, thus
triggering a disconnect and retry.

Since the sk->sk_error_report() calls in the socket layer are always
followed by a tcp_done() in the cases where we care about waking up
the rpc_tasks, just let the state_change callbacks take responsibility
for those wake ups.

Reported-by: Chris Perl <chris.perl@gmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Chris Perl <chris.perl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agomm: fix XFS oops due to dirty pages without buffers on s390
Jan Kara [Thu, 25 Oct 2012 20:37:31 +0000]
mm: fix XFS oops due to dirty pages without buffers on s390

commit ef5d437f71afdf4afdbab99213add99f4b1318fd upstream.

On s390 any write to a page (even from kernel itself) sets architecture
specific page dirty bit.  Thus when a page is written to via buffered
write, HW dirty bit gets set and when we later map and unmap the page,
page_remove_rmap() finds the dirty bit and calls set_page_dirty().

Dirtying of a page which shouldn't be dirty can cause all sorts of
problems to filesystems.  The bug we observed in practice is that
buffers from the page get freed, so when the page gets later marked as
dirty and writeback writes it, XFS crashes due to an assertion
BUG_ON(!PagePrivate(page)) in page_buffers() called from
xfs_count_page_state().

Similar problem can also happen when zero_user_segment() call from
xfs_vm_writepage() (or block_write_full_page() for that matter) set the
hardware dirty bit during writeback, later buffers get freed, and then
page unmapped.

Fix the issue by ignoring s390 HW dirty bit for page cache pages of
mappings with mapping_cap_account_dirty().  This is safe because for
such mappings when a page gets marked as writeable in PTE it is also
marked dirty in do_wp_page() or do_page_fault().  When the dirty bit is
cleared by clear_page_dirty_for_io(), the page gets writeprotected in
page_mkclean().  So pagecache page is writeable if and only if it is
dirty.

Thanks to Hugh Dickins for pointing out mapping has to have
mapping_cap_account_dirty() for things to work and proposing a cleaned
up variant of the patch.

The patch has survived about two hours of running fsx-linux on tmpfs
while heavily swapping and several days of running on out build machines
where the original problem was triggered.

Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agox86, mm: Trim memory in memblock to be page aligned
Yinghai Lu [Mon, 22 Oct 2012 23:35:18 +0000]
x86, mm: Trim memory in memblock to be page aligned

commit 6ede1fd3cb404c0016de6ac529df46d561bd558b upstream.

We will not map partial pages, so need to make sure memblock
allocation will not allocate those bytes out.

Also we will use for_each_mem_pfn_range() to loop to map memory
range to keep them consistent.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin <jacob.shin@amd.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoARM: 7559/1: smp: switch away from the idmap before updating init_mm.mm_count
Will Deacon [Fri, 19 Oct 2012 16:53:01 +0000]
ARM: 7559/1: smp: switch away from the idmap before updating init_mm.mm_count

commit 5f40b909728ad784eb43aa309d3c4e9bdf050781 upstream.

When booting a secondary CPU, the primary CPU hands two sets of page
tables via the secondary_data struct:

(1) swapper_pg_dir: a normal, cacheable, shared (if SMP) mapping
    of the kernel image (i.e. the tables used by init_mm).

(2) idmap_pgd: an uncached mapping of the .idmap.text ELF
    section.

The idmap is generally used when enabling and disabling the MMU, which
includes early CPU boot. In this case, the secondary CPU switches to
swapper as soon as it enters C code:

struct mm_struct *mm = &init_mm;
unsigned int cpu = smp_processor_id();

/*
 * All kernel threads share the same mm context; grab a
 * reference and switch to it.
 */
atomic_inc(&mm->mm_count);
current->active_mm = mm;
cpumask_set_cpu(cpu, mm_cpumask(mm));
cpu_switch_mm(mm->pgd, mm);

This causes a problem on ARMv7, where the identity mapping is treated as
strongly-ordered leading to architecturally UNPREDICTABLE behaviour of
exclusive accesses, such as those used by atomic_inc.

This patch re-orders the secondary_start_kernel function so that we
switch to swapper before performing any exclusive accesses.

Reported-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: David McKay <david.mckay@st.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agogenalloc: stop crashing the system when destroying a pool
Thadeu Lima de Souza Cascardo [Thu, 25 Oct 2012 20:37:51 +0000]
genalloc: stop crashing the system when destroying a pool

commit eedce141cd2dad8d0cefc5468ef41898949a7031 upstream.

The genalloc code uses the bitmap API from include/linux/bitmap.h and
lib/bitmap.c, which is based on long values.  Both bitmap_set from
lib/bitmap.c and bitmap_set_ll, which is the lockless version from
genalloc.c, use BITMAP_LAST_WORD_MASK to set the first bits in a long in
the bitmap.

That one uses (1 << bits) - 1, 0b111, if you are setting the first three
bits.  This means that the API counts from the least significant bits
(LSB from now on) to the MSB.  The LSB in the first long is bit 0, then.
The same works for the lookup functions.

The genalloc code uses longs for the bitmap, as it should.  In
include/linux/genalloc.h, struct gen_pool_chunk has unsigned long
bits[0] as its last member.  When allocating the struct, genalloc should
reserve enough space for the bitmap.  This should be a proper number of
longs that can fit the amount of bits in the bitmap.

However, genalloc allocates an integer number of bytes that fit the
amount of bits, but may not be an integer amount of longs.  9 bytes, for
example, could be allocated for 70 bits.

This is a problem in itself if the Least Significat Bit in a long is in
the byte with the largest address, which happens in Big Endian machines.
This means genalloc is not allocating the byte in which it will try to
set or check for a bit.

This may end up in memory corruption, where genalloc will try to set the
bits it has not allocated.  In fact, genalloc may not set these bits
because it may find them already set, because they were not zeroed since
they were not allocated.  And that's what causes a BUG when
gen_pool_destroy is called and check for any set bits.

What really happens is that genalloc uses kmalloc_node with __GFP_ZERO
on gen_pool_add_virt.  With SLAB and SLUB, this means the whole slab
will be cleared, not only the requested bytes.  Since struct
gen_pool_chunk has a size that is a multiple of 8, and slab sizes are
multiples of 8, we get lucky and allocate and clear the right amount of
bytes.

Hower, this is not the case with SLOB or with older code that did memset
after allocating instead of using __GFP_ZERO.

So, a simple module as this (running 3.6.0), will cause a crash when
rmmod'ed.

  [root@phantom-lp2 foo]# cat foo.c
  #include <linux/kernel.h>
  #include <linux/module.h>
  #include <linux/init.h>
  #include <linux/genalloc.h>

  MODULE_LICENSE("GPL");
  MODULE_VERSION("0.1");

  static struct gen_pool *foo_pool;

  static __init int foo_init(void)
  {
          int ret;
          foo_pool = gen_pool_create(10, -1);
          if (!foo_pool)
                  return -ENOMEM;
          ret = gen_pool_add(foo_pool, 0xa0000000, 32 << 10, -1);
          if (ret) {
                  gen_pool_destroy(foo_pool);
                  return ret;
          }
          return 0;
  }

  static __exit void foo_exit(void)
  {
          gen_pool_destroy(foo_pool);
  }

  module_init(foo_init);
  module_exit(foo_exit);
  [root@phantom-lp2 foo]# zcat /proc/config.gz | grep SLOB
  CONFIG_SLOB=y
  [root@phantom-lp2 foo]# insmod ./foo.ko
  [root@phantom-lp2 foo]# rmmod foo
  ------------[ cut here ]------------
  kernel BUG at lib/genalloc.c:243!
  cpu 0x4: Vector: 700 (Program Check) at [c0000000bb0e7960]
      pc: c0000000003cb50c: .gen_pool_destroy+0xac/0x110
      lr: c0000000003cb4fc: .gen_pool_destroy+0x9c/0x110
      sp: c0000000bb0e7be0
     msr: 8000000000029032
    current = 0xc0000000bb0e0000
    paca    = 0xc000000006d30e00   softe: 0        irq_happened: 0x01
      pid   = 13044, comm = rmmod
  kernel BUG at lib/genalloc.c:243!
  [c0000000bb0e7ca0] d000000004b00020 .foo_exit+0x20/0x38 [foo]
  [c0000000bb0e7d20] c0000000000dff98 .SyS_delete_module+0x1a8/0x290
  [c0000000bb0e7e30] c0000000000097d4 syscall_exit+0x0/0x94
  --- Exception: c00 (System Call) at 000000800753d1a0
  SP (fffd0b0e640) is in userspace

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Benjamin Gaignard <benjamin.gaignard@stericsson.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agodrivers/rtc/rtc-imxdi.c: add missing spin lock initialization
Jan Luebbe [Thu, 25 Oct 2012 20:38:11 +0000]
drivers/rtc/rtc-imxdi.c: add missing spin lock initialization

commit fee0de7791f967c2c5f0d43eb7b7261761b45e64 upstream.

Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Roland Stigge <stigge@antcom.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Roland Stigge <stigge@antcom.de>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agofs/compat_ioctl.c: VIDEO_SET_SPU_PALETTE missing error check
Kees Cook [Thu, 25 Oct 2012 20:38:16 +0000]
fs/compat_ioctl.c: VIDEO_SET_SPU_PALETTE missing error check

commit 12176503366885edd542389eed3aaf94be163fdb upstream.

The compat ioctl for VIDEO_SET_SPU_PALETTE was missing an error check
while converting ioctl arguments.  This could lead to leaking kernel
stack contents into userspace.

Patch extracted from existing fix in grsecurity.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: David Miller <davem@davemloft.net>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: PaX Team <pageexec@freemail.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agogen_init_cpio: avoid stack overflow when expanding
Kees Cook [Thu, 25 Oct 2012 20:38:14 +0000]
gen_init_cpio: avoid stack overflow when expanding

commit 20f1de659b77364d55d4e7fad2ef657e7730323f upstream.

Fix possible overflow of the buffer used for expanding environment
variables when building file list.

In the extremely unlikely case of an attacker having control over the
environment variables visible to gen_init_cpio, control over the
contents of the file gen_init_cpio parses, and gen_init_cpio was built
without compiler hardening, the attacker can gain arbitrary execution
control via a stack buffer overflow.

  $ cat usr/crash.list
  file foo ${BIG}${BIG}${BIG}${BIG}${BIG}${BIG} 0755 0 0
  $ BIG=$(perl -e 'print "A" x 4096;') ./usr/gen_init_cpio usr/crash.list
  *** buffer overflow detected ***: ./usr/gen_init_cpio terminated

This also replaces the space-indenting with tabs.

Patch based on existing fix extracted from grsecurity.

Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: PaX Team <pageexec@freemail.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

6 years agoALSA: hda - add dock support for Thinkpad T430
Stefán Freyr [Fri, 19 Oct 2012 20:46:00 +0000]
ALSA: hda - add dock support for Thinkpad T430

commit 84f98fdf7865fbd35b312eb39ea91e5618c514c7 upstream.

I have a Lenovo ThinkPad T430 and an UltraBase Series 3 docking
station.

Without this patch, if I plug my headphones into the jack on the
computer, everything works fine. The computer speakers mute and the
audio is played in the headphones. However, if I plug into the docking
station headphone jack the computer speakers are muted but there is no
audio in the headphones.

Addresses https://bugs.launchpad.net/bugs/1060372

Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>