Trond Myklebust [Mon, 19 Mar 2012 17:39:35 +0000 (13:39 -0400)]
SUNRPC: We must not use list_for_each_entry_safe() in rpc_wake_up()
commit
540a0f7584169651f485e8ab67461fcb06934e38 upstream.
The problem is that for the case of priority queues, we
have to assume that __rpc_remove_wait_queue_priority will move new
elements from the tk_wait.links lists into the queue->tasks[] list.
We therefore cannot use list_for_each_entry_safe() on queue->tasks[],
since that will skip these new tasks that __rpc_remove_wait_queue_priority
is adding.
Without this fix, rpc_wake_up and rpc_wake_up_status will both fail
to wake up all functions on priority wait queues, which can result
in some nasty hangs.
Reported-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Artem Bityutskiy [Wed, 7 Mar 2012 17:08:36 +0000 (19:08 +0200)]
UBI: fix eraseblock picking criteria
commit
7eb3aa65853e1b223bfc786b023b702018cb76c0 upstream.
The 'find_wl_entry()' function expects the maximum difference as the second
argument, not the maximum absolute value. So the "unknown" eraseblock picking
was incorrect, as Shmulik Ladkani spotted. This patch fixes the issue.
Reported-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Reviewed-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Weinberger [Mon, 30 Jan 2012 17:20:13 +0000 (18:20 +0100)]
UBI: fix error handling in ubi_scan()
commit
a29852be492d61001d86c6ebf5fff9b93d7b4be9 upstream.
Two bad things can happen in ubi_scan():
1. If kmem_cache_create() fails we jump to out_si and call
ubi_scan_destroy_si() which calls kmem_cache_destroy().
But si->scan_leb_slab is NULL.
2. If process_eb() fails we jump to out_vidh, call
kmem_cache_destroy() and ubi_scan_destroy_si() which calls
again kmem_cache_destroy().
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeff Layton [Wed, 21 Mar 2012 10:30:40 +0000 (06:30 -0400)]
cifs: fix issue mounting of DFS ROOT when redirecting from one domain controller to the next
commit
1daaae8fa4afe3df78ca34e724ed7e8187e4eb32 upstream.
This patch fixes an issue when cifs_mount receives a
STATUS_BAD_NETWORK_NAME error during cifs_get_tcon but is able to
continue after an DFS ROOT referral. In this case, the return code
variable is not reset prior to trying to mount from the system referred
to. Thus, is_path_accessible is not executed and the final DFS referral
is not performed causing a mount error.
Use case: In DNS, example.com resolves to the secondary AD server
ad2.example.com Our primary domain controller is ad1.example.com and has
a DFS redirection set up from \\ad1\share\Users to \\files\share\Users.
Mounting \\example.com\share\Users fails.
Regression introduced by commit 724d9f1.
Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru
Signed-off-by: Thomas Hadig <thomas@intapp.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Wed, 7 Mar 2012 04:50:25 +0000 (04:50 +0000)]
xfs: fix inode lookup race
commit
f30d500f809eca67a21704347ab14bb35877b5ee upstream.
When we get concurrent lookups of the same inode that is not in the
per-AG inode cache, there is a race condition that triggers warnings
in unlock_new_inode() indicating that we are initialising an inode
that isn't in a the correct state for a new inode.
When we do an inode lookup via a file handle or a bulkstat, we don't
serialise lookups at a higher level through the dentry cache (i.e.
pathless lookup), and so we can get concurrent lookups of the same
inode.
The race condition is between the insertion of the inode into the
cache in the case of a cache miss and a concurrently lookup:
Thread 1 Thread 2
xfs_iget()
xfs_iget_cache_miss()
xfs_iread()
lock radix tree
radix_tree_insert()
rcu_read_lock
radix_tree_lookup
lock inode flags
XFS_INEW not set
igrab()
unlock inode flags
rcu_read_unlock
use uninitialised inode
.....
lock inode flags
set XFS_INEW
unlock inode flags
unlock radix tree
xfs_setup_inode()
inode flags = I_NEW
unlock_new_inode()
WARNING as inode flags != I_NEW
This can lead to inode corruption, inode list corruption, etc, and
is generally a bad thing to occur.
Fix this by setting XFS_INEW before inserting the inode into the
radix tree. This will ensure any concurrent lookup will find the new
inode with XFS_INEW set and that forces the lookup to wait until the
XFS_INEW flag is removed before allowing the lookup to succeed.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Wed, 7 Mar 2012 21:39:06 +0000 (16:39 -0500)]
NFSv4: Return the delegation if the server returns NFS4ERR_OPENMODE
commit
3114ea7a24d3264c090556a2444fc6d2c06176d4 upstream.
If a setattr() fails because of an NFS4ERR_OPENMODE error, it is
probably due to us holding a read delegation. Ensure that the
recovery routines return that delegation in this case.
Reported-by: Miklos Szeredi <miklos@szeredi.hu>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 6 Mar 2012 00:56:44 +0000 (19:56 -0500)]
NFS: Properly handle the case where the delegation is revoked
commit
a1d0b5eebc4fd6e0edb02688b35f17f67f42aea5 upstream.
If we know that the delegation stateid is bad or revoked, we need to
remove that delegation as soon as possible, and then mark all the
stateids that relied on that delegation for recovery. We cannot use
the delegation as part of the recovery process.
Also note that NFSv4.1 uses a different error code (NFS4ERR_DELEG_REVOKED)
to indicate that the delegation was revoked.
Finally, ensure that setlk() and setattr() can both recover safely from
a revoked delegation.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephan Bärwolf [Thu, 12 Jan 2012 15:43:04 +0000 (16:43 +0100)]
KVM: x86: fix missing checks in syscall emulation
commit
c2226fc9e87ba3da060e47333657cd6616652b84 upstream.
On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following
nasm-demo-application:
[bits 32]
global _start
SECTION .text
_start: syscall
(I tested it with winxp and linux - both always crashed)
Disassembly of section .text:
00000000 <_start>:
0: 0f 05 syscall
The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)
Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.
Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.
[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephan Bärwolf [Thu, 12 Jan 2012 15:43:03 +0000 (16:43 +0100)]
KVM: x86: extend "struct x86_emulate_ops" with "get_cpuid"
commit
bdb42f5afebe208eae90406959383856ae2caf2b upstream.
In order to be able to proceed checks on CPU-specific properties
within the emulator, function "get_cpuid" is introduced.
With "get_cpuid" it is possible to virtually call the guests
"cpuid"-opcode without changing the VM's context.
[mtosatti: cleanup/beautify code]
Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clemens Ladisch [Mon, 12 Mar 2012 20:45:47 +0000 (21:45 +0100)]
firewire: ohci: fix too-early completion of IR multichannel buffers
commit
0c0efbacab8d70700d13301e0ae7975783c0cb0a upstream.
handle_ir_buffer_fill() assumed that a completed descriptor would be
indicated by a non-zero transfer_status (as in most other descriptors).
However, this field is written by the controller as soon as (the end of)
the first packet has been written into the buffer. As a consequence, if
we happen to run into such a descriptor when the interrupt handler is
executed after such a packet has completed, the descriptor would be
taken out of the list of active descriptors as soon as the buffer had
been partially filled, so the event for the buffer being completely
filled would never be sent.
To fix this, handle descriptors only when they have been completely
filled, i.e., when res_count == 0. (This also matches the condition
that is reported by the controller with an interrupt.)
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Shtylyov [Thu, 19 Jan 2012 16:09:56 +0000 (19:09 +0300)]
pata_legacy: correctly mask recovery field for HT6560B
commit
9716387311c790de381214c03e7f1b72b91a8189 upstream.
According to the HT6560H datasheet, the recovery timing field is 4-bit wide,
with a value of 0 meaning 16 cycles. Correct obvious thinko in the recovery
field mask.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keng-Yu Lin [Mon, 30 Jan 2012 06:25:45 +0000 (14:25 +0800)]
HID: add more hotkeys in Asus AIO keyboards
commit
6c30d5a53229aad22bb675e0bd6eb518ecaa4316 upstream.
Add support for the camera key. The hotkey for
Asus S.H.E(Super Hybrid Engine) mode is mapped to KEY_KEY_PROG1
just for notifying the userspace.
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keng-Yu Lin [Thu, 2 Feb 2012 09:31:26 +0000 (10:31 +0100)]
HID: add extra hotkeys in Asus AIO keyboards
commit
3596bb929f2abd3433c2eaa5755fad48ac207af1 upstream.
The Asus All-In-One PC has a wireless keyboard with wifi toggle,
brightness up, brightness down and display off hotkeys.
This patch adds suppoort for these hotkeys.
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keng-Yu Lin [Wed, 30 Nov 2011 10:32:37 +0000 (18:32 +0800)]
Bluetooth: Add AR30XX device ID on Asus laptops
commit
6b6ba88b5bb8779156b21bb957520a448c3642e2 upstream.
The ID is found on Asus K54HR and K53U.
Blacklist the AR3011-based device ID [0489:e03d]
and add to ath3k.c for firmware loading.
Below is the output of usb-devices script:
Before the fiwmware loading:
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e03d Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
After the fiwmware loading:
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0cf3 ProdID=3005 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roland Dreier [Fri, 24 Feb 2012 01:22:12 +0000 (17:22 -0800)]
target: Fix 16-bit target ports for SET TARGET PORT GROUPS emulation
commit
33395fb8a13731c7ef7b175dbf5a4d8a6738fe6c upstream.
The old code did (MSB << 8) & 0xff, which always evaluates to 0. Just use
get_unaligned_be16() so we don't have to worry about whether our open-coded
version is correct or not.
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>
Roland Dreier [Tue, 14 Feb 2012 00:18:16 +0000 (16:18 -0800)]
target: Don't set WBUS16 or SYNC bits in INQUIRY response
commit
effc6cc8828257c32c37635e737f14fd6e19ecd7 upstream.
SPC-4 says about the WBUS16 and SYNC bits:
The meanings of these fields are specific to SPI-5 (see 6.4.3).
For SCSI transport protocols other than the SCSI Parallel
Interface, these fields are reserved.
We don't have a SPI fabric module, so we should never set these bits.
(The comment was misleading, since it only mentioned Sync but the
actual code set WBUS16 too).
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>
Alex Deucher [Fri, 16 Mar 2012 16:22:10 +0000 (12:22 -0400)]
drm/radeon/kms: add connector quirk for Fujitsu D3003-S2 board
commit
4c1b2d2da3451f5c8dd59bd7e05bd9729d2aee05 upstream.
vbios lists DVI-I port as VGA and DVI-D.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=47007
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Fri, 16 Mar 2012 16:22:09 +0000 (12:22 -0400)]
drm/radeon/kms: fix analog load detection on DVI-I connectors
commit
e00e8b5e760cbbe9067daeae5454d67c44c8d035 upstream.
We digital encoders have a detect function as well (for
DP to VGA bridges), so we make sure we choose the analog
one here.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=47007
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michel Dänzer [Wed, 14 Mar 2012 16:12:41 +0000 (17:12 +0100)]
drm/radeon: Restrict offset for legacy hardware cursor.
commit
c4353016dac10133fa5d8535af83f0c4845a2915 upstream.
The hardware only takes 27 bits for the offset, so larger offsets are
truncated, and the hardware cursor shows random bits other than the intended
ones.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46796
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
NeilBrown [Mon, 19 Mar 2012 01:46:38 +0000 (12:46 +1100)]
md/raid1,raid10: avoid deadlock during resync/recovery.
commit
d6b42dcb995e6acd7cc276774e751ffc9f0ef4bf upstream.
If RAID1 or RAID10 is used under LVM or some other stacking
block device, it is possible to enter a deadlock during
resync or recovery.
This can happen if the upper level block device creates
two requests to the RAID1 or RAID10. The first request gets
processed, blocks recovery and queue requests for underlying
requests in current->bio_list. A resync request then starts
which will wait for those requests and block new IO.
But then the second request to the RAID1/10 will be attempted
and it cannot progress until the resync request completes,
which cannot progress until the underlying device requests complete,
which are on a queue behind that second request.
So allow that second request to proceed even though there is
a resync request about to start.
This is suitable for any -stable kernel.
Reported-by: Ray Morris <support@bettercgi.com>
Tested-by: Ray Morris <support@bettercgi.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Mon, 19 Mar 2012 01:46:37 +0000 (12:46 +1100)]
md/bitmap: ensure to load bitmap when creating via sysfs.
commit
4474ca42e2577563a919fd3ed782e2ec55bf11a2 upstream.
When commit
69e51b449d383e (md/bitmap: separate out loading a bitmap...)
created bitmap_load, it missed calling it after bitmap_create when a
bitmap is created through the sysfs interface.
So if a bitmap is added this way, we don't allocate memory properly
and can crash.
This is suitable for any -stable release since 2.6.35.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Sat, 10 Mar 2012 07:45:38 +0000 (23:45 -0800)]
tcm_fc: Fix fc_exch memory leak in ft_send_resp_status
commit
031ed4d565b31880a4136bb7366bc89f5b1dba7d upstream.
This patch fixes a bug in tcm_fc where fc_exch memory from fc_exch_mgr->ep_pool
is currently being leaked by ft_send_resp_status() usage. Following current
code in ft_queue_status() response path, using lport->tt.seq_send() needs to be
followed by a lport->tt.exch_done() in order to release fc_exch memory back into
libfc_em kmem_cache.
ft_send_resp_status() code is currently used in pre submit se_cmd ft_send_work()
error exceptions, TM request setup exceptions, and main TM response callback
path in ft_queue_tm_resp(). This bugfix addresses the leak in these cases.
Cc: Mark D Rustad <mark.d.rustad@intel.com>
Cc: Kiran Patil <kiran.patil@intel.com>
Cc: Robert Love <robert.w.love@intel.com>
Cc: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kay Sievers [Sat, 28 Jan 2012 19:57:46 +0000 (19:57 +0000)]
udlfb: remove sysfs framebuffer device with USB .disconnect()
commit
ce880cb860f36694d2cdebfac9e6ae18176fe4c4 upstream.
The USB graphics card driver delays the unregistering of the framebuffer
device to a workqueue, which breaks the userspace visible remove uevent
sequence. Recent userspace tools started to support USB graphics card
hotplug out-of-the-box and rely on proper events sent by the kernel.
The framebuffer device is a direct child of the USB interface which is
removed immediately after the USB .disconnect() callback. But the fb device
in /sys stays around until its final cleanup, at a time where all the parent
devices have been removed already.
To work around that, we remove the sysfs fb device directly in the USB
.disconnect() callback and leave only the cleanup of the internal fb
data to the delayed work.
Before:
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
remove /2-1.2:1.0/graphics/fb0 (graphics)
After:
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
Tested-by: Bernie Thompson <bernie@plugable.com>
Acked-by: Bernie Thompson <bernie@plugable.com>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roland Dreier [Tue, 14 Feb 2012 23:30:31 +0000 (15:30 -0800)]
tcm_loop: Set residual field for SCSI commands
commit
6cf3fa6918baab0c447f1206f1cef9166ad04864 upstream.
If the target core signals an over- or under-run, tcm_loop should call
scsi_set_resid() to tell the SCSI midlayer about the residual data length.
The difference can be seen by doing something like
strace -eioctl sg_raw -r 1024 /dev/sda 8 0 0 0 1 0 > /dev/null
and looking at the "resid=" part of the SG_IO ioctl -- after this patch,
the field is correctly reported as 512.
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>
Daniel Mack [Mon, 19 Mar 2012 08:12:53 +0000 (09:12 +0100)]
ASoC: pxa-ssp: atomically set stream active masks
commit
273b72c8ce6b28df6b49423d775c3e59072c73c5 upstream.
PXA's SSP engine fails to take its current channel phase into account
when enabling a stream while the engine is already running. This
results in randomly swapped left/right channels on either the record
or the playback side, depending on which one was enabled first.
The following patch fixes this by factoring out the bit field
modifications in question to a separate function that pauses the
engine temporarily, modifies the bits and kicks it off again
afterwards. Appearantly, a transition of SSCR0_SSE syncs both
directions properly.
The patch has been rolled out to quite a number of devices over the
last weeks and seems to fix the issue reliably.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Reported-and-tested-by: Sven Neumann <s.neumann@raumfeld.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Aneesh Kumar K.V [Wed, 21 Mar 2012 23:34:08 +0000 (16:34 -0700)]
hugetlbfs: avoid taking i_mutex from hugetlbfs_read()
commit
a05b0855fd15504972dba2358e5faa172a1e50ba upstream.
Taking i_mutex in hugetlbfs_read() can result in deadlock with mmap as
explained below
Thread A:
read() on hugetlbfs
hugetlbfs_read() called
i_mutex grabbed
hugetlbfs_read_actor() called
__copy_to_user() called
page fault is triggered
Thread B, sharing address space with A:
mmap() the same file
->mmap_sem is grabbed on task_B->mm->mmap_sem
hugetlbfs_file_mmap() is called
attempt to grab ->i_mutex and block waiting for A to give it up
Thread A:
pagefault handled blocked on attempt to grab task_A->mm->mmap_sem,
which happens to be the same thing as task_B->mm->mmap_sem. Block waiting
for B to give it up.
AFAIU the i_mutex locking was added to hugetlbfs_read() as per
http://lkml.indiana.edu/hypermail/linux/kernel/0707.2/3066.html to take
care of the race between truncate and read. This patch fixes this by
looking at page->mapping under lock_page() (find_lock_page()) to ensure
that the inode didn't get truncated in the range during a parallel read.
Ideally we can extend the patch to make sure we don't increase i_size in
mmap. But that will break userspace, because applications will now have
to use truncate(2) to increase i_size in hugetlbfs.
Based on the original patch from Hillf Danton.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Hugh Dickins <hughd@google.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>
Nishanth Aravamudan [Wed, 21 Mar 2012 23:34:07 +0000 (16:34 -0700)]
bootmem/sparsemem: remove limit constraint in alloc_bootmem_section
commit
f5bf18fa22f8c41a13eb8762c7373eb3a93a7333 upstream.
While testing AMS (Active Memory Sharing) / CMO (Cooperative Memory
Overcommit) on powerpc, we tripped the following:
kernel BUG at mm/bootmem.c:483!
cpu 0x0: Vector: 700 (Program Check) at [
c000000000c03940]
pc:
c000000000a62bd8: .alloc_bootmem_core+0x90/0x39c
lr:
c000000000a64bcc: .sparse_early_usemaps_alloc_node+0x84/0x29c
sp:
c000000000c03bc0
msr:
8000000000021032
current = 0xc000000000b0cce0
paca = 0xc000000001d80000
pid = 0, comm = swapper
kernel BUG at mm/bootmem.c:483!
enter ? for help
[
c000000000c03c80]
c000000000a64bcc
.sparse_early_usemaps_alloc_node+0x84/0x29c
[
c000000000c03d50]
c000000000a64f10 .sparse_init+0x12c/0x28c
[
c000000000c03e20]
c000000000a474f4 .setup_arch+0x20c/0x294
[
c000000000c03ee0]
c000000000a4079c .start_kernel+0xb4/0x460
[
c000000000c03f90]
c000000000009670 .start_here_common+0x1c/0x2c
This is
BUG_ON(limit && goal + size > limit);
and after some debugging, it seems that
goal = 0x7ffff000000
limit = 0x80000000000
and sparse_early_usemaps_alloc_node ->
sparse_early_usemaps_alloc_pgdat_section calls
return alloc_bootmem_section(usemap_size() * count, section_nr);
This is on a system with 8TB available via the AMS pool, and as a quirk
of AMS in firmware, all of that memory shows up in node 0. So, we end
up with an allocation that will fail the goal/limit constraints.
In theory, we could "fall-back" to alloc_bootmem_node() in
sparse_early_usemaps_alloc_node(), but since we actually have HOTREMOVE
defined, we'll BUG_ON() instead. A simple solution appears to be to
unconditionally remove the limit condition in alloc_bootmem_section,
meaning allocations are allowed to cross section boundaries (necessary
for systems of this size).
Johannes Weiner pointed out that if alloc_bootmem_section() no longer
guarantees section-locality, we need check_usemap_section_nr() to print
possible cross-dependencies between node descriptors and the usemaps
allocated through it. That makes the two loops in
sparse_early_usemaps_alloc_node() identical, so re-factor the code a
bit.
[akpm@linux-foundation.org: code simplification]
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: Anton Blanchard <anton@au1.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Robert Jennings <rcj@linux.vnet.ibm.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Mel Gorman <mgorman@suse.de>
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>
Andrea Arcangeli [Wed, 21 Mar 2012 23:33:42 +0000 (16:33 -0700)]
mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read mode
commit
1a5a9906d4e8d1976b701f889d8f35d54b928f25 upstream.
In some cases it may happen that pmd_none_or_clear_bad() is called with
the mmap_sem hold in read mode. In those cases the huge page faults can
allocate hugepmds under pmd_none_or_clear_bad() and that can trigger a
false positive from pmd_bad() that will not like to see a pmd
materializing as trans huge.
It's not khugepaged causing the problem, khugepaged holds the mmap_sem
in write mode (and all those sites must hold the mmap_sem in read mode
to prevent pagetables to go away from under them, during code review it
seems vm86 mode on 32bit kernels requires that too unless it's
restricted to 1 thread per process or UP builds). The race is only with
the huge pagefaults that can convert a pmd_none() into a
pmd_trans_huge().
Effectively all these pmd_none_or_clear_bad() sites running with
mmap_sem in read mode are somewhat speculative with the page faults, and
the result is always undefined when they run simultaneously. This is
probably why it wasn't common to run into this. For example if the
madvise(MADV_DONTNEED) runs zap_page_range() shortly before the page
fault, the hugepage will not be zapped, if the page fault runs first it
will be zapped.
Altering pmd_bad() not to error out if it finds hugepmds won't be enough
to fix this, because zap_pmd_range would then proceed to call
zap_pte_range (which would be incorrect if the pmd become a
pmd_trans_huge()).
The simplest way to fix this is to read the pmd in the local stack
(regardless of what we read, no need of actual CPU barriers, only
compiler barrier needed), and be sure it is not changing under the code
that computes its value. Even if the real pmd is changing under the
value we hold on the stack, we don't care. If we actually end up in
zap_pte_range it means the pmd was not none already and it was not huge,
and it can't become huge from under us (khugepaged locking explained
above).
All we need is to enforce that there is no way anymore that in a code
path like below, pmd_trans_huge can be false, but pmd_none_or_clear_bad
can run into a hugepmd. The overhead of a barrier() is just a compiler
tweak and should not be measurable (I only added it for THP builds). I
don't exclude different compiler versions may have prevented the race
too by caching the value of *pmd on the stack (that hasn't been
verified, but it wouldn't be impossible considering
pmd_none_or_clear_bad, pmd_bad, pmd_trans_huge, pmd_none are all inlines
and there's no external function called in between pmd_trans_huge and
pmd_none_or_clear_bad).
if (pmd_trans_huge(*pmd)) {
if (next-addr != HPAGE_PMD_SIZE) {
VM_BUG_ON(!rwsem_is_locked(&tlb->mm->mmap_sem));
split_huge_page_pmd(vma->vm_mm, pmd);
} else if (zap_huge_pmd(tlb, vma, pmd, addr))
continue;
/* fall through */
}
if (pmd_none_or_clear_bad(pmd))
Because this race condition could be exercised without special
privileges this was reported in CVE-2012-1179.
The race was identified and fully explained by Ulrich who debugged it.
I'm quoting his accurate explanation below, for reference.
====== start quote =======
mapcount 0 page_mapcount 1
kernel BUG at mm/huge_memory.c:1384!
At some point prior to the panic, a "bad pmd ..." message similar to the
following is logged on the console:
mm/memory.c:145: bad pmd
ffff8800376e1f98(
80000000314000e7).
The "bad pmd ..." message is logged by pmd_clear_bad() before it clears
the page's PMD table entry.
143 void pmd_clear_bad(pmd_t *pmd)
144 {
-> 145 pmd_ERROR(*pmd);
146 pmd_clear(pmd);
147 }
After the PMD table entry has been cleared, there is an inconsistency
between the actual number of PMD table entries that are mapping the page
and the page's map count (_mapcount field in struct page). When the page
is subsequently reclaimed, __split_huge_page() detects this inconsistency.
1381 if (mapcount != page_mapcount(page))
1382 printk(KERN_ERR "mapcount %d page_mapcount %d\n",
1383 mapcount, page_mapcount(page));
-> 1384 BUG_ON(mapcount != page_mapcount(page));
The root cause of the problem is a race of two threads in a multithreaded
process. Thread B incurs a page fault on a virtual address that has never
been accessed (PMD entry is zero) while Thread A is executing an madvise()
system call on a virtual address within the same 2 MB (huge page) range.
virtual address space
.---------------------.
| |
| |
.-|---------------------|
| | |
| | |<-- B(fault)
| | |
2 MB | |/////////////////////|-.
huge < |/////////////////////| > A(range)
page | |/////////////////////|-'
| | |
| | |
'-|---------------------|
| |
| |
'---------------------'
- Thread A is executing an madvise(..., MADV_DONTNEED) system call
on the virtual address range "A(range)" shown in the picture.
sys_madvise
// Acquire the semaphore in shared mode.
down_read(¤t->mm->mmap_sem)
...
madvise_vma
switch (behavior)
case MADV_DONTNEED:
madvise_dontneed
zap_page_range
unmap_vmas
unmap_page_range
zap_pud_range
zap_pmd_range
//
// Assume that this huge page has never been accessed.
// I.e. content of the PMD entry is zero (not mapped).
//
if (pmd_trans_huge(*pmd)) {
// We don't get here due to the above assumption.
}
//
// Assume that Thread B incurred a page fault and
.---------> // sneaks in here as shown below.
| //
| if (pmd_none_or_clear_bad(pmd))
| {
| if (unlikely(pmd_bad(*pmd)))
| pmd_clear_bad
| {
| pmd_ERROR
| // Log "bad pmd ..." message here.
| pmd_clear
| // Clear the page's PMD entry.
| // Thread B incremented the map count
| // in page_add_new_anon_rmap(), but
| // now the page is no longer mapped
| // by a PMD entry (-> inconsistency).
| }
| }
|
v
- Thread B is handling a page fault on virtual address "B(fault)" shown
in the picture.
...
do_page_fault
__do_page_fault
// Acquire the semaphore in shared mode.
down_read_trylock(&mm->mmap_sem)
...
handle_mm_fault
if (pmd_none(*pmd) && transparent_hugepage_enabled(vma))
// We get here due to the above assumption (PMD entry is zero).
do_huge_pmd_anonymous_page
alloc_hugepage_vma
// Allocate a new transparent huge page here.
...
__do_huge_pmd_anonymous_page
...
spin_lock(&mm->page_table_lock)
...
page_add_new_anon_rmap
// Here we increment the page's map count (starts at -1).
atomic_set(&page->_mapcount, 0)
set_pmd_at
// Here we set the page's PMD entry which will be cleared
// when Thread A calls pmd_clear_bad().
...
spin_unlock(&mm->page_table_lock)
The mmap_sem does not prevent the race because both threads are acquiring
it in shared mode (down_read). Thread B holds the page_table_lock while
the page's map count and PMD table entry are updated. However, Thread A
does not synchronize on that lock.
====== end quote =======
[akpm@linux-foundation.org: checkpatch fixes]
Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Dave Jones <davej@redhat.com>
Acked-by: Larry Woodman <lwoodman@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Mark Salter <msalter@redhat.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>
Suresh Siddha [Mon, 12 Mar 2012 18:36:33 +0000 (11:36 -0700)]
x86/ioapic: Add register level checks to detect bogus io-apic entries
commit
73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream.
With the recent changes to clear_IO_APIC_pin() which tries to
clear remoteIRR bit explicitly, some of the users started to see
"Unable to reset IRR for apic .." messages.
Close look shows that these are related to bogus IO-APIC entries
which return's all 1's for their io-apic registers. And the
above mentioned error messages are benign. But kernel should
have ignored such io-apic's in the first place.
Check if register 0, 1, 2 of the listed io-apic are all 1's and
ignore such io-apic.
Reported-by: Álvaro Castillo <midgoon@gmail.com>
Tested-by: Jon Dufresne <jon@jondufresne.org>
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: yinghai@kernel.org
Cc: kernel-team@fedoraproject.org
Cc: Josh Boyer <jwboyer@redhat.com>
Link: http://lkml.kernel.org/r/1331577393.31585.94.camel@sbsiddha-desk.sc.intel.com
[ Performed minor cleanup of affected code. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Or Gerlitz [Mon, 5 Mar 2012 16:21:44 +0000 (18:21 +0200)]
IB/iser: Post initial receive buffers before sending the final login request
commit
89e984e2c2cd14f77ccb26c47726ac7f13b70ae8 upstream.
An iser target may send iscsi NO-OP PDUs as soon as it marks the iSER
iSCSI session as fully operative. This means that there is window
where there are no posted receive buffers on the initiator side, so
it's possible for the iSER RC connection to break because of RNR NAK /
retry errors. To fix this, rely on the flags bits in the login
request to have FFP (0x3) in the lower nibble as a marker for the
final login request, and post an initial chunk of receive buffers
before sending that login request instead of after getting the login
response.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Max Filippov [Wed, 29 Feb 2012 20:40:08 +0000 (00:40 +0400)]
p54spi: Release GPIO lines and IRQ on error in p54spi_probe
commit
62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream.
This makes it possible to reload driver if insmod has failed due to
missing firmware.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rabin Vincent [Tue, 22 Nov 2011 10:03:14 +0000 (11:03 +0100)]
rtc: Disable the alarm in the hardware (v2)
commit
41c7f7424259ff11009449f87c95656f69f9b186 upstream.
Currently, the RTC code does not disable the alarm in the hardware.
This means that after a sequence such as the one below (the files are in the
RTC sysfs), the box will boot up after 2 minutes even though we've
asked for the alarm to be turned off.
# echo $((`cat since_epoch`)+120) > wakealarm
# echo 0 > wakealarm
# poweroff
Fix this by disabling the alarm when there are no timers to run.
The original version of this patch was reverted. This version
disables the irq directly instead of setting a disabled timer
in the future.
Cc: John Stultz <john.stultz@linaro.org>
Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com>
[Merged in the second revision from Rabin]
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Gordeev [Fri, 9 Mar 2012 13:59:13 +0000 (14:59 +0100)]
genirq: Fix incorrect check for forced IRQ thread handler
commit
540b60e24f3f4781d80e47122f0c4486a03375b8 upstream.
We do not want a bitwise AND between boolean operands
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20120309135912.GA2114@dhcp-26-207.brq.redhat.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Mon, 5 Mar 2012 23:07:25 +0000 (15:07 -0800)]
genirq: Fix long-term regression in genirq irq_set_irq_type() handling
commit
a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 upstream.
In 2008, commit
0c5d1eb77a8be ("genirq: record trigger type") modified the
way set_irq_type() handles the 'no trigger' condition. However, this has
an adverse effect on PCMCIA support on Intel StrongARM and probably PXA
platforms.
PCMCIA has several status signals on the socket which can trigger
interrupts; some of these status signals depend on the card's mode
(whether it is configured in memory or IO mode). For example, cards have
a 'Ready/IRQ' signal: in memory mode, this provides an indication to
PCMCIA that the card has finished its power up initialization. In IO
mode, it provides the device interrupt signal. Other status signals
switch between on-board battery status and loud speaker output.
In classical PCMCIA implementations, where you have a specific socket
controller, the controller provides a method to mask interrupts from the
socket, and importantly ignore any state transitions on the pins which
correspond with interrupts once masked. This masking prevents unwanted
events caused by the removal and application of socket power being
forwarded.
However, on platforms where there is no socket controller, the PCMCIA
status and interrupt signals are routed to standard edge-triggered GPIOs.
These GPIOs can be configured to interrupt on rising edge, falling edge,
or never. This is where the problems start.
Edge triggered interrupts are required to record events while disabled via
the usual methods of {free,request,disable,enable}_irq() to prevent
problems with dropped interrupts (eg, the 8390 driver uses disable_irq()
to defer the delivery of interrupts). As a result, these interfaces can
not be used to implement the desired behaviour.
The side effect of this is that if the 'Ready/IRQ' GPIO is disabled via
disable_irq() on suspend, and enabled via enable_irq() after resume, we
will record the state transitions caused by powering events as valid
interrupts, and foward them to the card driver, which may attempt to
access a card which is not powered up.
This leads delays resume while drivers spin in their interrupt handlers,
and complaints from drivers before they realize what's happened.
Moreover, in the case of the 'Ready/IRQ' signal, this is requested and
freed by the card driver itself; the PCMCIA core has no idea whether the
interrupt is requested, and, therefore, whether a call to disable_irq()
would be valid. (We tried this around 2.4.17 / 2.5.1 kernel era, and
ended up throwing it out because of this problem.)
Therefore, it was decided back in around 2002 to disable the edge
triggering instead, resulting in all state transitions on the GPIO being
ignored. That's what we actually need the hardware to do.
The commit above changes this behaviour; it explicitly prevents the 'no
trigger' state being selected.
The reason that request_irq() does not accept the 'no trigger' state is
for compatibility with existing drivers which do not provide their desired
triggering configuration. The set_irq_type() function is 'new' and not
used by non-trigger aware drivers.
Therefore, revert this change, and restore previously working platforms
back to their former state.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: linux@arm.linux.org.uk
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Vagin [Wed, 7 Mar 2012 10:49:56 +0000 (14:49 +0400)]
uevent: send events in correct order according to seqnum (v3)
commit
7b60a18da393ed70db043a777fd9e6d5363077c4 upstream.
The queue handling in the udev daemon assumes that the events are
ordered.
Before this patch uevent_seqnum is incremented under sequence_lock,
than an event is send uner uevent_sock_mutex. I want to say that code
contained a window between incrementing seqnum and sending an event.
This patch locks uevent_sock_mutex before incrementing uevent_seqnum.
v2: delete sequence_lock, uevent_seqnum is protected by uevent_sock_mutex
v3: unlock the mutex before the goto exit
Thanks for Kay for the comments.
Signed-off-by: Andrew Vagin <avagin@openvz.org>
Tested-By: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Levin [Thu, 15 Mar 2012 16:36:14 +0000 (12:36 -0400)]
ntp: Fix integer overflow when setting time
commit
a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33 upstream.
'long secs' is passed as divisor to div_s64, which accepts a 32bit
divisor. On 64bit machines that value is trimmed back from 8 bytes
back to 4, causing a divide by zero when the number is bigger than
(1 << 32) - 1 and all 32 lower bits are 0.
Use div64_long() instead.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-2-git-send-email-levinsasha928@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Levin [Thu, 15 Mar 2012 16:36:13 +0000 (12:36 -0400)]
math: Introduce div64_long
commit
f910381a55cdaa097030291f272f6e6e4380c39a upstream.
Add a div64_long macro which is used to devide a 64bit number by a long (which
can be 4 bytes on 32bit systems and 8 bytes on 64bit systems).
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Cc: johnstul@us.ibm.com
Link: http://lkml.kernel.org/r/1331829374-31543-1-git-send-email-levinsasha928@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jingjun Wu [Sat, 3 Mar 2012 02:52:14 +0000 (20:52 -0600)]
rtlwifi: rtl8192ce: Fix loss of receive performance
commit
a9b89e2567c743483e6354f64d7a7e3a8c101e9e upstream.
Driver rtl8192ce when used with the RTL8188CE device would start at about
20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the
symptoms is that the AP would need to retransmit each packet 4 of 5 times
before the driver would acknowledge it. Recovery is possible only by
unloading and reloading the driver. This problem was reported at
https://bugzilla.redhat.com/show_bug.cgi?id=770207.
The problem is due to a missing update of the gain setting.
Signed-off-by: Jingjun Wu <jingjun_wu@realsil.com.cn>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Fri, 2 Mar 2012 21:23:36 +0000 (15:23 -0600)]
rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu
commit
ebecdcc12fed5d3c81853dea61a0a78a5aefab52 upstream.
When driver rtl8192cu is used with the debug level set to 3 or greater,
the result is "sleeping function called from invalid context" due to
an rcu_read_lock() call in the DM refresh routine in driver rtl8192c.
This lock is not necessary as the USB driver does not use the struct
being protected, thus the lock is set only when a PCI interface is
active.
This bug is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42775.
Reported-by: Ronald Wahl <ronald.wahl@raritan.com>
Tested-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Graham [Wed, 8 Feb 2012 00:07:38 +0000 (18:07 -0600)]
rtlwifi: Handle previous allocation failures when freeing device memory
commit
7f66c2f93e5779625c10d262c84537427a2673ca upstream.
Handle previous allocation failures when freeing device memory
Signed-off-by: Simon Graham <simon.graham@virtualcomputer.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gertjan van Wingerde [Sat, 11 Feb 2012 20:58:09 +0000 (21:58 +0100)]
rt2x00: Add support for D-Link DWA-127 to rt2800usb.
commit
d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream.
This is an RT3070 based device.
Reported-by: Mikhail Kryshen <mikhail@kryshen.net>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.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>
Donald Lee [Wed, 14 Mar 2012 07:26:33 +0000 (15:26 +0800)]
USB: serial: mos7840: Fixed MCS7820 device attach problem
commit
093ea2d3a766cb8a4c4de57efec6c0a127a58792 upstream.
A MCS7820 device supports two serial ports and a MCS7840 device supports
four serial ports. Both devices use the same driver, but the attach function
in driver was unable to correctly handle the port numbers for MCS7820
device. This problem has been fixed in this patch and this fix has been
verified on x86 Linux kernel 3.2.9 with both MCS7820 and MCS7840 devices.
Signed-off-by: Donald Lee <donald@asix.com.tw>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Preston Fick [Fri, 24 Feb 2012 19:42:39 +0000 (13:42 -0600)]
usb: cp210x: Update to support CP2105 and multiple interface devices
commit
a5360a53a7ccad5ed9ccef210b94fef13c6e5529 upstream.
This patch updates the cp210x driver to support CP210x multiple
interface devices devices from Silicon Labs. The existing driver
always sends control requests to interface 0, which is hardcoded in
the usb_control_msg function calls. This only allows for single
interface devices to be used, and causes a bug when using ports on an
interface other than 0 in the multiple interface devices.
Here are the changes included in this patch:
- Updated the device list to contain the Silicon Labs factory default
VID/PID for multiple interface CP210x devices
- Created a cp210x_port_private struct created for each port on
startup, this struct holds the interface number
- Added a cp210x_release function to clean up the cp210x_port_private
memory created on startup
- Modified usb_get_config and usb_set_config to get a pointer to the
cp210x_port_private struct, and use the interface number there in the
usb_control_message wIndex param
Signed-off-by: Preston Fick <preston.fick@silabs.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Scott Dial [Sat, 25 Feb 2012 00:04:09 +0000 (19:04 -0500)]
usb-serial: Add support for the Sealevel SeaLINK+8 2038-ROHS device
commit
6d161b99f875269ad4ffa44375e1e54bca6fd02e upstream.
This patch adds new device IDs to the ftdi_sio module to support
the new Sealevel SeaLINK+8 2038-ROHS device.
Signed-off-by: Scott Dial <scott.dial@scientiallc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Fri, 24 Feb 2012 19:08:43 +0000 (13:08 -0600)]
USB: qcserial: don't grab QMI port on Gobi 1000 devices
commit
c192c8e71a2ded01170c1a992cd21aaedc822756 upstream.
Gobi 1000 devices have a different port layout, which wasn't respected
by the current driver, and thus it grabbed the QMI/net port. In the
near future we'll be attaching another driver to the QMI/net port for
these devices (cdc-wdm and qmi_wwan) so make sure the qcserial driver
doesn't claim them. This patch also prevents qcserial from binding to
interfaces 0 and 1 on 1K devices because those interfaces do not
respond.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Tuttle [Wed, 1 Feb 2012 21:07:17 +0000 (16:07 -0500)]
USB: qcserial: add several new serial devices
commit
2db4d87070e87d198ab630e66a898b45eff316d9 upstream.
Signed-off-by: Thomas Tuttle <ttuttle@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Peter Chen [Thu, 16 Feb 2012 01:41:52 +0000 (09:41 +0800)]
usb: Fix build error due to dma_mask is not at pdev_archdata at ARM
commit
e90fc3cb087ce5c5f81e814358222cd6d197b5db upstream.
When build i.mx platform with imx_v6_v7_defconfig, and after adding
USB Gadget support, it has below build error:
CC drivers/usb/host/fsl-mph-dr-of.o
drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl_usb2_device_register':
drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev_archdata'
has no member named 'dma_mask'
It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html
For PowerPC, there is dma_mask at struct pdev_archdata, but there is
no dma_mask at struct pdev_archdata for ARM. The pdev_archdata is
related to specific platform, it should NOT be accessed by
cross platform drivers, like USB.
The code for pdev_archdata should be useless, as for PowerPC,
it has already gotten the value for pdev->dev.dma_mask at function
arch_setup_pdev_archdata of arch/powerpc/kernel/setup-common.c.
Tested-by: Ramneek Mehresh <ramneek.mehresh@freescale.com>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Chen [Thu, 16 Feb 2012 01:36:25 +0000 (09:36 +0800)]
usb: fsl_udc_core: Fix scheduling while atomic dump message
commit
c5cc5ed86667d4ae74fe40ee4ed893f4b46aba05 upstream.
When loading g_ether gadget, there is below message:
Backtrace:
[<
80012248>] (dump_backtrace+0x0/0x10c) from [<
803cb42c>] (dump_stack+0x18/0x1c)
r7:
00000000 r6:
80512000 r5:
8052bef8 r4:
80513f30
[<
803cb414>] (dump_stack+0x0/0x1c) from [<
8000feb4>] (show_regs+0x44/0x50)
[<
8000fe70>] (show_regs+0x0/0x50) from [<
8004c840>] (__schedule_bug+0x68/0x84)
r5:
8052bef8 r4:
80513f30
[<
8004c7d8>] (__schedule_bug+0x0/0x84) from [<
803cd0e4>] (__schedule+0x4b0/0x528)
r5:
8052bef8 r4:
809aad00
[<
803ccc34>] (__schedule+0x0/0x528) from [<
803cd214>] (_cond_resched+0x44/0x58)
[<
803cd1d0>] (_cond_resched+0x0/0x58) from [<
800a9488>] (dma_pool_alloc+0x184/0x250)
r5:
9f9b4000 r4:
9fb4fb80
[<
800a9304>] (dma_pool_alloc+0x0/0x250) from [<
802a8ad8>] (fsl_req_to_dtd+0xac/0x180)
[<
802a8a2c>] (fsl_req_to_dtd+0x0/0x180) from [<
802a8ce4>] (fsl_ep_queue+0x138/0x274)
[<
802a8bac>] (fsl_ep_queue+0x0/0x274) from [<
7f004328>] (composite_setup+0x2d4/0xfac [g_ether])
[<
7f004054>] (composite_setup+0x0/0xfac [g_ether]) from [<
802a9bb4>] (fsl_udc_irq+0x8dc/0xd38)
[<
802a92d8>] (fsl_udc_irq+0x0/0xd38) from [<
800704f8>] (handle_irq_event_percpu+0x54/0x188)
[<
800704a4>] (handle_irq_event_percpu+0x0/0x188) from [<
80070674>] (handle_irq_event+0x48/0x68)
[<
8007062c>] (handle_irq_event+0x0/0x68) from [<
800738ec>] (handle_level_irq+0xb4/0x138)
r5:
80514f94 r4:
80514f40
[<
80073838>] (handle_level_irq+0x0/0x138) from [<
8006ffa4>] (generic_handle_irq+0x38/0x44)
r7:
00000012 r6:
80510b1c r5:
80529860 r4:
80512000
[<
8006ff6c>] (generic_handle_irq+0x0/0x44) from [<
8000f4c4>] (handle_IRQ+0x54/0xb4)
[<
8000f470>] (handle_IRQ+0x0/0xb4) from [<
800085b8>] (tzic_handle_irq+0x64/0x94)
r9:
412fc085 r8:
00000000 r7:
80513f30 r6:
00000001 r5:
00000000
r4:
00000000
[<
80008554>] (tzic_handle_irq+0x0/0x94) from [<
8000e680>] (__irq_svc+0x40/0x60)
The reason of above dump message is calling dma_poll_alloc with can-schedule
mem_flags at atomic context.
To fix this problem, below changes are made:
- fsl_req_to_dtd doesn't need to be protected by spin_lock_irqsave,
as struct usb_request can be access at process context. Move lock
to beginning of hardware visit (fsl_queue_td).
- Change the memory flag which using to allocate dTD descriptor buffer,
the memory flag can be from gadget layer.
It is tested at i.mx51 bbg board with g_mass_storage, g_ether, g_serial.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Li Yang <leoli@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Sun, 12 Feb 2012 06:02:43 +0000 (06:02 +0000)]
cdc-wdm: Don't clear WDM_READ unless entire read buffer is emptied
commit
b7a205545345578712611106b371538992e142ff upstream.
The WDM_READ flag is cleared later iff desc->length is reduced to 0.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Bjørn Mork <bjorn@mork.no>
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Sun, 12 Feb 2012 06:00:41 +0000 (06:00 +0000)]
cdc-wdm: Fix more races on the read path
commit
711c68b3c0f7a924ffbee4aa962d8f62b85188ff upstream.
We must not allow the input buffer length to change while we're
shuffling the buffer contents. We also mustn't clear the WDM_READ
flag after more data might have arrived. Therefore move both of these
into the spinlocked region at the bottom of wdm_read().
When reading desc->length without holding the iuspin lock, use
ACCESS_ONCE() to ensure the compiler doesn't re-read it with
inconsistent results.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Bjørn Mork <bjorn@mork.no>
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Fri, 10 Feb 2012 12:20:49 +0000 (13:20 +0100)]
USB: serial: fix console error reporting
commit
548dd4b6da8a8e428453d55f7fa7b8a46498d147 upstream.
Do not report errors in write path if port is used as a console as this
may trigger the same error (and error report) resulting in a loop.
Reported-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liz Clark [Thu, 15 Mar 2012 17:33:29 +0000 (10:33 -0700)]
TTY: Wrong unicode value copied in con_set_unimap()
commit
4a4c61b7ce26bfc9d49ea4bd121d52114bad9f99 upstream.
Bugzilla 40012: PIO_UNIMAP bug: error updating Unicode-to-font map
https://bugzilla.kernel.org/show_bug.cgi?id=40012
The unicode font map for the virtual console is a 32x32x64 table which
allocates rows dynamically as entries are added. The unicode value
increases sequentially and should count all entries even in empty
rows. The defect is when copying the unicode font map in con_set_unimap(),
the unicode value is not incremented properly. The wrong unicode value
is entered in the new font map.
Signed-off-by: Liz Clark <liz.clark@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Wed, 7 Mar 2012 10:05:00 +0000 (13:05 +0300)]
tty: moxa: fix bit test in moxa_start()
commit
58112dfbfe02d803566a2c6c8bd97b5fa3c62cdc upstream.
This is supposed to be doing a shift before the comparison instead of
just doing a bitwise AND directly. The current code means the start()
just returns without doing anything.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Ichikawa [Mon, 20 Feb 2012 22:43:50 +0000 (07:43 +0900)]
sysfs: Fix memory leak in sysfs_sd_setsecdata().
commit
93518dd2ebafcc761a8637b2877008cfd748c202 upstream.
This patch fixies follwing two memory leak patterns that reported by kmemleak.
sysfs_sd_setsecdata() is called during sys_lsetxattr() operation.
It checks sd->s_iattr is NULL or not. Then if it is NULL, it calls
sysfs_init_inode_attrs() to allocate memory.
That code is this.
iattrs = sd->s_iattr;
if (!iattrs)
iattrs = sysfs_init_inode_attrs(sd);
The iattrs recieves sysfs_init_inode_attrs()'s result, but sd->s_iattr
doesn't know the address. so it needs to set correct address to
sd->s_iattr to free memory in other function.
unreferenced object 0xffff880250b73e60 (size 32):
comm "systemd", pid 1, jiffies
4294683888 (age 94.553s)
hex dump (first 32 bytes):
73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f system_u:object_
72 3a 73 79 73 66 73 5f 74 3a 73 30 00 00 00 00 r:sysfs_t:s0....
backtrace:
[<
ffffffff814cb1d0>] kmemleak_alloc+0x73/0x98
[<
ffffffff811270ab>] __kmalloc+0x100/0x12c
[<
ffffffff8120775a>] context_struct_to_string+0x106/0x210
[<
ffffffff81207cc1>] security_sid_to_context_core+0x10b/0x129
[<
ffffffff812090ef>] security_sid_to_context+0x10/0x12
[<
ffffffff811fb0da>] selinux_inode_getsecurity+0x7d/0xa8
[<
ffffffff811fb127>] selinux_inode_getsecctx+0x22/0x2e
[<
ffffffff811f4d62>] security_inode_getsecctx+0x16/0x18
[<
ffffffff81191dad>] sysfs_setxattr+0x96/0x117
[<
ffffffff811542f0>] __vfs_setxattr_noperm+0x73/0xd9
[<
ffffffff811543d9>] vfs_setxattr+0x83/0xa1
[<
ffffffff811544c6>] setxattr+0xcf/0x101
[<
ffffffff81154745>] sys_lsetxattr+0x6a/0x8f
[<
ffffffff814efda9>] system_call_fastpath+0x16/0x1b
[<
ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff88024163c5a0 (size 96):
comm "systemd", pid 1, jiffies
4294683888 (age 94.553s)
hex dump (first 32 bytes):
00 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 .....A..........
00 00 00 00 00 00 00 00 0c 64 42 4f 00 00 00 00 .........dBO....
backtrace:
[<
ffffffff814cb1d0>] kmemleak_alloc+0x73/0x98
[<
ffffffff81127402>] kmem_cache_alloc_trace+0xc4/0xee
[<
ffffffff81191cbe>] sysfs_init_inode_attrs+0x2a/0x83
[<
ffffffff81191dd6>] sysfs_setxattr+0xbf/0x117
[<
ffffffff811542f0>] __vfs_setxattr_noperm+0x73/0xd9
[<
ffffffff811543d9>] vfs_setxattr+0x83/0xa1
[<
ffffffff811544c6>] setxattr+0xcf/0x101
[<
ffffffff81154745>] sys_lsetxattr+0x6a/0x8f
[<
ffffffff814efda9>] system_call_fastpath+0x16/0x1b
[<
ffffffffffffffff>] 0xffffffffffffffff
`
Signed-off-by: Masami Ichikawa <masami256@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Wed, 15 Feb 2012 11:08:34 +0000 (12:08 +0100)]
futex: Cover all PI opcodes with cmpxchg enabled check
commit
59263b513c11398cd66a52d4c5b2b118ce1e0359 upstream.
Some of the newer futex PI opcodes do not check the cmpxchg enabled
variable and call unconditionally into the handling functions. Cover
all PI opcodes in a separate check.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Orjan Friberg [Wed, 7 Mar 2012 16:16:14 +0000 (17:16 +0100)]
USB: gadget: Make g_hid device class conform to spec.
commit
33d2832ab0149a26418d360af3c444969a63fb28 upstream.
HID devices should specify this in their interface descriptors, not in the
device descriptor. This fixes a "missing hardware id" bug under Windows 7 with
a VIA VL800 (3.0) controller.
Signed-off-by: Orjan Friberg <of@flatfrog.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Faber [Fri, 2 Mar 2012 08:41:50 +0000 (09:41 +0100)]
usb: gadgetfs: return number of bytes on ep0 read request
commit
85b4b3c8c189e0159101f7628a71411af072ff69 upstream.
A read from GadgetFS endpoint 0 during the data stage of a control
request would always return 0 on success (as returned by
wait_event_interruptible) despite having written data into the user
buffer.
This patch makes it correctly set the return value to the number of
bytes read.
Signed-off-by: Thomas Faber <thfabba@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Supriya Karanth [Fri, 17 Feb 2012 09:24:52 +0000 (14:54 +0530)]
usb: musb: Reselect index reg in interrupt context
commit
39287076e46d2c19aaceaa6f0a44168ae4d257ec upstream.
musb INDEX register is getting modified/corrupted during temporary
un-locking in a SMP system. Set this register with proper value
after re-acquiring the lock
Scenario:
---------
CPU1 is handling a data transfer completion interrupt received for
the CLASS1 EP
CPU2 is handling a CLASS2 thread which is queuing data to musb for
transfer
Below is the error sequence:
CPU1 | CPU2
--------------------------------------------------------------------
Data transfer completion inter- |
rupt recieved. |
|
musb INDEX reg set to CLASS1 EP |
|
musb LOCK is acquired. |
|
| CLASS2 thread queues data.
|
| CLASS2 thread tries to acquire musb
| LOCK but lock is already taken by
| CLASS1, so CLASS2 thread is
| spinning.
|
From Interrupt Context musb |
giveback function is called |
|
The giveback function releases | CLASS2 thread now acquires LOCK
LOCK |
|
ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and
lback is called | sets the MUSB INDEX to Class2 EP number
|
Interrupt handler for CLASS1 EP |
tries to acquire LOCK and is |
spinning |
|
Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and
the MUSB LOCK | releases the musb LOCK
|
Interrupt for Class1 EP schedul-|
es the next data transfer |
but musb INDEX register is still|
set to CLASS2 EP |
Since the MUSB INDEX register is set to a different endpoint, we
read and modify the wrong registers. Hence data transfer will not
happen properly. This results in unpredictable behavior
So, the MUSB INDEX register is set to proper value again when
interrupt re-acquires the lock
Signed-off-by: Supriya Karanth <supriya.karanth@stericsson.com>
Signed-off-by: Praveena Nadahally <praveen.nadahally@stericsson.com>
Reviewed-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Shengzhou Liu [Thu, 16 Feb 2012 10:02:20 +0000 (18:02 +0800)]
powerpc/usb: fix bug of kernel hang when initializing usb
commit
28c56ea1431421dec51b7b229369e991481453df upstream.
If USB UTMI PHY is not enable, writing to portsc register will lead to
kernel hang during boot up.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Wróbel [Thu, 15 Mar 2012 16:24:04 +0000 (17:24 +0100)]
USB: ftdi_sio: new PID: LUMEL PD12
commit
57e596f3af88ef52dea9640ed5e34ecd38893a02 upstream.
Signed-off-by: Michał Wróbel <michal.wrobel@flytronic.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jim Paris [Wed, 14 Mar 2012 21:54:25 +0000 (17:54 -0400)]
USB: ftdi_sio: add support for FT-X series devices
commit
dc0827c128c0ee5a58b822b99d662b59f4b8e970 upstream.
Add PID 0x6015, corresponding to the new series of FT-X chips
(FT220XD, FT201X, FT220X, FT221X, FT230X, FT231X, FT240X). They all
appear as serial devices, and seem indistinguishable except for the
default product string stored in their EEPROM. The baudrate
generation matches FT232RL devices.
Tested with a FT201X and FT230X at various baudrates (100 - 3000000).
Sample dmesg:
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
usb 2-1: new full-speed USB device number 6 using ohci_hcd
usb 2-1: New USB device found, idVendor=0403, idProduct=6015
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 2-1: Product: FT230X USB Half UART
usb 2-1: Manufacturer: FTDI
usb 2-1: SerialNumber: DC001WI6
ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
drivers/usb/serial/ftdi_sio.c: ftdi_sio_port_probe
drivers/usb/serial/ftdi_sio.c: ftdi_determine_type: bcdDevice = 0x1000, bNumInterfaces = 1
usb 2-1: Detected FT-X
usb 2-1: Number of endpoints 2
usb 2-1: Endpoint 1 MaxPacketSize 64
usb 2-1: Endpoint 2 MaxPacketSize 64
usb 2-1: Setting MaxPacketSize 64
drivers/usb/serial/ftdi_sio.c: read_latency_timer
drivers/usb/serial/ftdi_sio.c: write_latency_timer: setting latency timer = 1
drivers/usb/serial/ftdi_sio.c: create_sysfs_attrs
drivers/usb/serial/ftdi_sio.c: sysfs attributes for FT-X
usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0
Signed-off-by: Jim Paris <jim@jtan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michał Wróbel [Fri, 9 Mar 2012 13:40:18 +0000 (14:40 +0100)]
USB: ftdi_sio: new PID: Distortec JTAG-lock-pick
commit
47594d5528f28a4c025c2955c68104c75815637c upstream.
Signed-off-by: Michał Wróbel <michal.wrobel@flytronic.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bruno Thomsen [Sun, 4 Mar 2012 14:19:14 +0000 (15:19 +0100)]
USB: Microchip VID mislabeled as Hornby VID in ftdi_sio.
commit
c1cee1d84001815a1b4321c49b995254c0df3100 upstream.
Microchip VID (0x04d8) was mislabeled as Hornby VID according to USB-IDs.
A Full Speed USB Demo Board PID (0x000a) was mislabeled as
Hornby Elite (an Digital Command Controller Console for model railways).
Most likely the Hornby based their design on
PIC18F87J50 Full Speed USB Demo Board.
Signed-off-by: Bruno Thomsen <bruno.thomsen@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Korsgaard [Wed, 29 Feb 2012 09:05:37 +0000 (10:05 +0100)]
USB: ftdi_sio: add support for BeagleBone rev A5+
commit
444aa7fa9bd752d19ce472d3e02558b987c3cc67 upstream.
BeagleBone changed to the default FTDI 0403:6010 id in rev A5 to make life
easier for Windows users, so we need a similar workaround as the Calao
board to support it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Tue, 28 Feb 2012 17:20:09 +0000 (09:20 -0800)]
USB: ftdi_sio: fix problem when the manufacture is a NULL string
commit
656d2b3964a9d0f9864d472f8dfa2dd7dd42e6c0 upstream.
On some misconfigured ftdi_sio devices, if the manufacturer string is
NULL, the kernel will oops when the device is plugged in. This patch
fixes the problem.
Reported-by: Wojciech M Zabolotny <W.Zabolotny@elka.pw.edu.pl>
Tested-by: Wojciech M Zabolotny <W.Zabolotny@elka.pw.edu.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Fri, 16 Mar 2012 14:41:26 +0000 (15:41 +0100)]
USB: option: add ZTE MF820D
commit
5889d3d4209c1050b4a3c96c41faf6c0976a4acf upstream.
This device presents a total of 5 interfaces with ff/ff/ff
class/subclass/protocol. The last one of these is verified
to be a QMI/wwan combined interface which should be handled
by the qmi_wwan driver, so we blacklist it here.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Fri, 16 Mar 2012 11:56:44 +0000 (12:56 +0100)]
USB: option: make interface blacklist work again
commit
963940cf472d76eca2d36296e461202cc6997352 upstream.
commit 0d905fd "USB: option: convert Huawei K3765, K4505, K4605
reservered interface to blacklist" accidentally ANDed two
blacklist tests by leaving out a return. This was not noticed
because the two consecutive bracketless if statements made it
syntactically correct.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniele Palmas [Wed, 29 Feb 2012 14:32:05 +0000 (15:32 +0100)]
USB: option driver: adding support for Telit CC864-SINGLE, CC864-DUAL and DE910-DUAL modems
commit
7204cf584836c24b4b06e4ad4a8e6bb8ea84908e upstream.
Adding PID for Telit CC864-SINGLE, CC864-DUAL and DE910-DUAL
modems
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Meng Zhang [Mon, 27 Feb 2012 07:24:19 +0000 (08:24 +0100)]
USB: option: Add MediaTek MT6276M modem&app interfaces
commit
0d8520a1d7f43328bc7085d4244d93c595064157 upstream.
Add MEDIATEK products to Option driver
Signed-off-by: Meng Zhang <meng.zhang@mediatek.com>
Signed-off-by: Matthias Urlichs <matthias@urlichs.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 23 Mar 2012 20:55:24 +0000 (13:55 -0700)]
Linux 3.0.26
Benjamin Herrenschmidt [Fri, 9 Dec 2011 04:06:18 +0000 (15:06 +1100)]
powerpc/pmac: Fix SMP kernels on pre-core99 UP machines
commit
78c5c68a4cf4329d17abfa469345ddf323d4fd62 upstream.
The code for "powersurge" SMP would kick in and cause a crash
at boot due to the lack of a NULL test.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
Reported-by: Adam Conrad <adconrad@ubuntu.com>
Tested-by: Adam Conrad <adconrad@ubuntu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Thu, 8 Mar 2012 12:16:01 +0000 (13:16 +0100)]
iwl3945: fix possible il->txq NULL pointer dereference in delayed works
commit
210787e82a0ac1ffb5d7be1c796f0c51050849ad upstream.
On il3945_down procedure we free tx queue data and nullify il->txq
pointer. After that we drop mutex and then cancel delayed works. There
is possibility, that after drooping mutex and before the cancel, some
delayed work will start and crash while trying to send commands to
the device. For example, here is reported crash in
il3945_bg_reg_txpower_periodic():
https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10
Patch fix problem by adding il->txq check on works that send commands,
hence utilize tx queue.
Reported-by: Clemens Eisserer <linuxhippy@gmail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
RongQing.Li [Thu, 15 Mar 2012 22:54:14 +0000 (22:54 +0000)]
ipv6: Don't dev_hold(dev) in ip6_mc_find_dev_rcu.
[ Upstream commit
c577923756b7fe9071f28a76b66b83b306d1d001 ]
ip6_mc_find_dev_rcu() is called with rcu_read_lock(), so don't
need to dev_hold().
With dev_hold(), not corresponding dev_put(), will lead to leak.
[ bug introduced in
96b52e61be1 (ipv6: mcast: RCU conversions) ]
Signed-off-by: RongQing.Li <roy.qing.li@gmail.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Sat, 10 Mar 2012 09:20:21 +0000 (09:20 +0000)]
tcp: fix syncookie regression
[ Upstream commit
dfd25ffffc132c00070eed64200e8950da5d7e9d ]
commit
ea4fc0d619 (ipv4: Don't use rt->rt_{src,dst} in ip_queue_xmit())
added a serious regression on synflood handling.
Simon Kirby discovered a successful connection was delayed by 20 seconds
before being responsive.
In my tests, I discovered that xmit frames were lost, and needed ~4
retransmits and a socket dst rebuild before being really sent.
In case of syncookie initiated connection, we use a different path to
initialize the socket dst, and inet->cork.fl.u.ip4 is left cleared.
As ip_queue_xmit() now depends on inet flow being setup, fix this by
copying the temp flowi4 we use in cookie_v4_check().
Reported-by: Simon Kirby <sim@netnation.com>
Bisected-by: Simon Kirby <sim@netnation.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Wed, 7 Mar 2012 00:42:49 +0000 (11:42 +1100)]
perf tools: Incorrect use of snprintf results in SEGV
commit
b832796caa1fda8516464a003c8c7cc547bc20c2 upstream.
I have a workload where perf top scribbles over the stack and we SEGV.
What makes it interesting is that an snprintf is causing this.
The workload is a c++ gem that has method names over 3000 characters
long, but snprintf is designed to avoid overrunning buffers. So what
went wrong?
The problem is we assume snprintf returns the number of characters
written:
ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level);
...
ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name);
Unfortunately this is not how snprintf works. snprintf returns the
number of characters that would have been written if there was enough
space. In the above case, if the first snprintf returns a value larger
than size, we pass a negative size into the second snprintf and happily
scribble over the stack. If you have 3000 character c++ methods thats a
lot of stack to trample.
This patch fixes repsep_snprintf by clamping the value at size - 1 which
is the maximum snprintf can write before adding the NULL terminator.
I get the sinking feeling that there are a lot of other uses of snprintf
that have this same bug, we should audit them all.
Cc: David Ahern <dsahern@gmail.com>
Cc: Eric B Munson <emunson@mgebm.net>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Link: http://lkml.kernel.org/r/20120307114249.44275ca3@kryten
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Fri, 16 Mar 2012 10:28:19 +0000 (10:28 +0000)]
afs: Remote abort can cause BUG in rxrpc code
commit
c0173863528a8c9212c53e080d63a1aaae5ef4f4 upstream.
When writing files to afs I sometimes hit a BUG:
kernel BUG at fs/afs/rxrpc.c:179!
With a backtrace of:
afs_free_call
afs_make_call
afs_fs_store_data
afs_vnode_store_data
afs_write_back_from_locked_page
afs_writepages_region
afs_writepages
The cause is:
ASSERT(skb_queue_empty(&call->rx_queue));
Looking at a tcpdump of the session the abort happens because we
are exceeding our disk quota:
rx abort fs reply store-data error diskquota exceeded (32)
So the abort error is valid. We hit the BUG because we haven't
freed all the resources for the call.
By freeing any skbs in call->rx_queue before calling afs_free_call
we avoid hitting leaking memory and avoid hitting the BUG.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anton Blanchard [Fri, 16 Mar 2012 10:28:07 +0000 (10:28 +0000)]
afs: Read of file returns EBADMSG
commit
2c724fb92732c0b2a5629eb8af74e82eb62ac947 upstream.
A read of a large file on an afs mount failed:
# cat junk.file > /dev/null
cat: junk.file: Bad message
Looking at the trace, call->offset wrapped since it is only an
unsigned short. In afs_extract_data:
_enter("{%u},{%zu},%d,,%zu", call->offset, len, last, count);
...
if (call->offset < count) {
if (last) {
_leave(" = -EBADMSG [%d < %zu]", call->offset, count);
return -EBADMSG;
}
Which matches the trace:
[cat ] ==> afs_extract_data({65132},{524},1,,65536)
[cat ] <== afs_extract_data() = -EBADMSG [0 < 65536]
call->offset went from 65132 to 0. Fix this by making call->offset an
unsigned int.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ryusuke Konishi [Sat, 17 Mar 2012 00:08:39 +0000 (17:08 -0700)]
nilfs2: fix NULL pointer dereference in nilfs_load_super_block()
commit
d7178c79d9b7c5518f9943188091a75fc6ce0675 upstream.
According to the report from Slicky Devil, nilfs caused kernel oops at
nilfs_load_super_block function during mount after he shrank the
partition without resizing the filesystem:
BUG: unable to handle kernel NULL pointer dereference at
00000048
IP: [<
d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2]
*pde =
00000000
Oops: 0000 [#1] PREEMPT SMP
...
Call Trace:
[<
d0d7a87b>] init_nilfs+0x4b/0x2e0 [nilfs2]
[<
d0d6f707>] nilfs_mount+0x447/0x5b0 [nilfs2]
[<
c0226636>] mount_fs+0x36/0x180
[<
c023d961>] vfs_kern_mount+0x51/0xa0
[<
c023ddae>] do_kern_mount+0x3e/0xe0
[<
c023f189>] do_mount+0x169/0x700
[<
c023fa9b>] sys_mount+0x6b/0xa0
[<
c04abd1f>] sysenter_do_call+0x12/0x28
Code: 53 18 8b 43 20 89 4b 18 8b 4b 24 89 53 1c 89 43 24 89 4b 20 8b 43
20 c7 43 2c 00 00 00 00 23 75 e8 8b 50 68 89 53 28 8b 54 b3 20 <8b> 72
48 8b 7a 4c 8b 55 08 89 b3 84 00 00 00 89 bb 88 00 00 00
EIP: [<
d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2] SS:ESP 0068:
ca9bbdcc
CR2:
0000000000000048
This turned out due to a defect in an error path which runs if the
calculated location of the secondary super block was invalid.
This patch fixes it and eliminates the reported oops.
Reported-by: Slicky Devil <slicky.dvl@gmail.com>
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Tested-by: Slicky Devil <slicky.dvl@gmail.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>
Greg Kroah-Hartman [Mon, 19 Mar 2012 15:58:30 +0000 (08:58 -0700)]
Linux 3.0.25
Ville Syrjala [Thu, 15 Mar 2012 17:11:05 +0000 (18:11 +0100)]
i2c-algo-bit: Fix spurious SCL timeouts under heavy load
commit
8ee161ce5e0cfc689eb677f227a6248191165fac upstream.
When the system is under heavy load, there can be a significant delay
between the getscl() and time_after() calls inside sclhi(). That delay
may cause the time_after() check to trigger after SCL has gone high,
causing sclhi() to return -ETIMEDOUT.
To fix the problem, double check that SCL is still low after the
timeout has been reached, before deciding to return -ETIMEDOUT.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Mon, 12 Mar 2012 15:33:10 +0000 (08:33 -0700)]
hwmon: (w83627ehf) Fix memory leak in probe function
commit
32260d94408c553dca4ce54104edf79941a27536 upstream.
The driver probe function leaked memory if creating the cpu0_vid attribute file
failed. Fix by converting the driver to use devm_kzalloc.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Mon, 12 Mar 2012 15:21:16 +0000 (08:21 -0700)]
hwmon: (w83627ehf) Fix writing into fan_stop_time for NCT6775F/NCT6776F
commit
33fa9b620409edfc71aa6cf01a51f990fbe46ab8 upstream.
NCT6775F and NCT6776F have their own set of registers for FAN_STOP_TIME. The
correct registers were used to read FAN_STOP_TIME, but writes used the wrong
registers. Fix it.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Mon, 5 Mar 2012 13:06:38 +0000 (14:06 +0100)]
compat: Re-add missing asm/compat.h include to fix compile breakage on s390
For 3.0 stable kernel the backport of
048cd4e51d24ebf7f3552226d03c769d6ad91658
"compat: fix compile breakage on s390" breaks compilation...
Re-add a single #include <asm/compat.h> in order to fix this.
This patch is _not_ necessary for upstream, only for stable kernels
which include the "build fix" mentioned above.
One fix for arch/s390/kernel/setup.c was already sent and applied. But
we need a similar patch for drivers/s390/char/fs3270.c.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David S. Miller [Wed, 14 Mar 2012 01:19:51 +0000 (18:19 -0700)]
sparc32: Add -Av8 to assembler command line.
commit
e0adb9902fb338a9fe634c3c2a3e474075c733ba upstream.
Newer version of binutils are more strict about specifying the
correct options to enable certain classes of instructions.
The sparc32 build is done for v7 in order to support sun4c systems
which lack hardware integer multiply and divide instructions.
So we have to pass -Av8 when building the assembler routines that
use these instructions and get patched into the kernel when we find
out that we have a v8 capable cpu.
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Sat, 25 Feb 2012 00:03:10 +0000 (00:03 +0000)]
sfc: Fix assignment of ip_summed for pre-allocated skbs
commit
ff3bc1e7527504a93710535611b2f812f3bb89bf upstream.
When pre-allocating skbs for received packets, we set ip_summed =
CHECKSUM_UNNCESSARY. We used to change it back to CHECKSUM_NONE when
the received packet had an incorrect checksum or unhandled protocol.
Commit
bc8acf2c8c3e43fcc192762a9f964b3e9a17748b ('drivers/net: avoid
some skb->ip_summed initializations') mistakenly replaced the latter
assignment with a DEBUG-only assertion that ip_summed ==
CHECKSUM_NONE. This assertion is always false, but it seems no-one
has exercised this code path in a DEBUG build.
Fix this by moving our assignment of CHECKSUM_UNNECESSARY into
efx_rx_packet_gro().
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 2 Mar 2012 09:51:00 +0000 (10:51 +0100)]
Block: use a freezable workqueue for disk-event polling
commit
62d3c5439c534b0e6c653fc63e6d8c67be3a57b1 upstream.
This patch (as1519) fixes a bug in the block layer's disk-events
polling. The polling is done by a work routine queued on the
system_nrt_wq workqueue. Since that workqueue isn't freezable, the
polling continues even in the middle of a system sleep transition.
Obviously, polling a suspended drive for media changes and such isn't
a good thing to do; in the case of USB mass-storage devices it can
lead to real problems requiring device resets and even re-enumeration.
The patch fixes things by creating a new system-wide, non-reentrant,
freezable workqueue and using it for disk-events polling.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Fri, 2 Mar 2012 09:43:28 +0000 (10:43 +0100)]
block: fix __blkdev_get and add_disk race condition
commit
9f53d2fe815b4011ff930a7b6db98385d45faa68 upstream.
The following situation might occur:
__blkdev_get: add_disk:
register_disk()
get_gendisk()
disk_block_events()
disk->ev == NULL
disk_add_events()
__disk_unblock_events()
disk->ev != NULL
--ev->block
Then we unblock events, when they are suppose to be blocked. This can
trigger events related block/genhd.c warnings, but also can crash in
sd_check_events() or other places.
I'm able to reproduce crashes with the following scripts (with
connected usb dongle as sdb disk).
<snip>
DEV=/dev/sdb
ENABLE=/sys/bus/usb/devices/1-2/bConfigurationValue
function stop_me()
{
for i in `jobs -p` ; do kill $i 2> /dev/null ; done
exit
}
trap stop_me SIGHUP SIGINT SIGTERM
for ((i = 0; i < 10; i++)) ; do
while true; do fdisk -l $DEV 2>&1 > /dev/null ; done &
done
while true ; do
echo 1 > $ENABLE
sleep 1
echo 0 > $ENABLE
done
</snip>
I use the script to verify patch fixing oops in sd_revalidate_disk
http://marc.info/?l=linux-scsi&m=
132935572512352&w=2
Without Jun'ichi Nomura patch titled "Fix NULL pointer dereference in
sd_revalidate_disk" or this one, script easily crash kernel within
a few seconds. With both patches applied I do not observe crash.
Unfortunately after some time (dozen of minutes), script will hung in:
[ 1563.906432] [<
c08354f5>] schedule_timeout_uninterruptible+0x15/0x20
[ 1563.906437] [<
c04532d5>] msleep+0x15/0x20
[ 1563.906443] [<
c05d60b2>] blk_drain_queue+0x32/0xd0
[ 1563.906447] [<
c05d6e00>] blk_cleanup_queue+0xd0/0x170
[ 1563.906454] [<
c06d278f>] scsi_free_queue+0x3f/0x60
[ 1563.906459] [<
c06d7e6e>] __scsi_remove_device+0x6e/0xb0
[ 1563.906463] [<
c06d4aff>] scsi_forget_host+0x4f/0x60
[ 1563.906468] [<
c06cd84a>] scsi_remove_host+0x5a/0xf0
[ 1563.906482] [<
f7f030fb>] quiesce_and_remove_host+0x5b/0xa0 [usb_storage]
[ 1563.906490] [<
f7f03203>] usb_stor_disconnect+0x13/0x20 [usb_storage]
Anyway I think this patch is some step forward.
As drawback, I do not teardown on sysfs file create error, because I do
not know how to nullify disk->ev (since it can be used). However add_disk
error handling practically does not exist too, and things will work
without this sysfs file, except events will not be exported to user
space.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sat, 3 Mar 2012 11:09:17 +0000 (12:09 +0100)]
block, sx8: fix pointer math issue getting fw version
commit
ea5f4db8ece896c2ab9eafa0924148a2596c52e4 upstream.
"mem" is type u8. We need parenthesis here or it screws up the pointer
math probably leading to an oops.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jun'ichi Nomura [Fri, 2 Mar 2012 09:38:33 +0000 (10:38 +0100)]
block: Fix NULL pointer dereference in sd_revalidate_disk
commit
fe316bf2d5847bc5dd975668671a7b1067603bc7 upstream.
Since 2.6.39 (1196f8b), when a driver returns -ENOMEDIUM for open(),
__blkdev_get() calls rescan_partitions() to remove
in-kernel partition structures and raise KOBJ_CHANGE uevent.
However it ends up calling driver's revalidate_disk without open
and could cause oops.
In the case of SCSI:
process A process B
----------------------------------------------
sys_open
__blkdev_get
sd_open
returns -ENOMEDIUM
scsi_remove_device
<scsi_device torn down>
rescan_partitions
sd_revalidate_disk
<oops>
Oopses are reported here:
http://marc.info/?l=linux-scsi&m=
132388619710052
This patch separates the partition invalidation from rescan_partitions()
and use it for -ENOMEDIUM case.
Reported-by: Huajun Li <huajun.li.lee@gmail.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Thu, 8 Mar 2012 02:02:17 +0000 (10:02 +0800)]
regulator: Fix setting selector in tps6524x set_voltage function
commit
f03570cf1709397ebe656608266b44ec772960c2 upstream.
Don't assign the voltage to selector.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Mon, 5 Mar 2012 13:06:38 +0000 (14:06 +0100)]
compat: Re-add missing asm/compat.h include to fix compile breakage on s390
For kernels <= 3.0 the backport of
048cd4e51d24ebf7f3552226d03c769d6ad91658
"compat: fix compile breakage on s390" will break compilation...
Re-add a single #include <asm/compat.h> in order to fix this.
This patch is _not_ necessary for upstream, only for stable kernels
which include the "build fix" mentioned above.
Reported-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Joerg Neikes [Thu, 8 Mar 2012 22:44:03 +0000 (22:44 +0000)]
usb: asix: Patch for Sitecom LN-031
commit
4e50391968849860dff1aacde358b4eb14aa5127 upstream.
This patch adds support for the Sitecom LN-031 USB adapter with a AX88178 chip.
Added USB id to find correct driver for AX88178 1000 Ethernet adapter.
Signed-off-by: Joerg Neikes <j.neikes@midlandgate.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 15 Feb 2012 20:43:11 +0000 (20:43 +0000)]
atl1c: dont use highprio tx queue
[ Upstream commit
11aad99af6ef629ff3b05d1c9f0936589b204316 ]
This driver attempts to use two TX rings but lacks proper support :
1) IRQ handler only takes care of TX completion on first TX ring
2) the stop/start logic uses the legacy functions (for non multiqueue
drivers)
This means all packets witk skb mark set to 1 are sent through high
queue but are never cleaned and queue eventualy fills and block the
device, triggering the infamous "NETDEV WATCHDOG" message.
Lets use a single TX ring to fix the problem, this driver is not a real
multiqueue one yet.
Minimal fix for stable kernels.
Reported-by: Thomas Meyer <thomas@m3y3r.de>
Tested-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jay Cliburn <jcliburn@gmail.com>
Cc: Chris Snook <chris.snook@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Wei [Mon, 5 Mar 2012 14:45:17 +0000 (14:45 +0000)]
IPv6: Fix not join all-router mcast group when forwarding set.
[ Upstream commit
d6ddef9e641d1229d4ec841dc75ae703171c3e92 ]
When forwarding was set and a new net device is register,
we need add this device to the all-router mcast group.
Signed-off-by: Li Wei <lw@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neal Cardwell [Mon, 5 Mar 2012 19:35:04 +0000 (19:35 +0000)]
tcp: fix tcp_shift_skb_data() to not shift SACKed data below snd_una
[ Upstream commit
4648dc97af9d496218a05353b0e442b3dfa6aaab ]
This commit fixes tcp_shift_skb_data() so that it does not shift
SACKed data below snd_una.
This fixes an issue whose symptoms exactly match reports showing
tp->sacked_out going negative since 3.3.0-rc4 (see "WARNING: at
net/ipv4/tcp_input.c:3418" thread on netdev).
Since 2008 (
832d11c5cd076abc0aa1eaf7be96c81d1a59ce41)
tcp_shift_skb_data() had been shifting SACKed ranges that were below
snd_una. It checked that the *end* of the skb it was about to shift
from was above snd_una, but did not check that the end of the actual
shifted range was above snd_una; this commit adds that check.
Shifting SACKed ranges below snd_una is problematic because for such
ranges tcp_sacktag_one() short-circuits: it does not declare anything
as SACKed and does not increase sacked_out.
Before the fixes in commits
cc9a672ee522d4805495b98680f4a3db5d0a0af9
and
daef52bab1fd26e24e8e9578f8fb33ba1d0cb412, shifting SACKed ranges
below snd_una happened to work because tcp_shifted_skb() was always
(incorrectly) passing in to tcp_sacktag_one() an skb whose end_seq
tcp_shift_skb_data() had already guaranteed was beyond snd_una. Hence
tcp_sacktag_one() never short-circuited and always increased
tp->sacked_out in this case.
After those two fixes, my testing has verified that shifting SACKed
ranges below snd_una could cause tp->sacked_out to go negative with
the following sequence of events:
(1) tcp_shift_skb_data() sees an skb whose end_seq is beyond snd_una,
then shifts a prefix of that skb that is below snd_una
(2) tcp_shifted_skb() increments the packet count of the
already-SACKed prev sk_buff
(3) tcp_sacktag_one() sees the end of the new SACKed range is below
snd_una, so it short-circuits and doesn't increase tp->sacked_out
(5) tcp_clean_rtx_queue() sees the SACKed skb has been ACKed,
decrements tp->sacked_out by this "inflated" pcount that was
missing a matching increase in tp->sacked_out, and hence
tp->sacked_out underflows to a u32 like 0xFFFFFFFF, which casted
to s32 is negative.
(6) this leads to the warnings seen in the recent "WARNING: at
net/ipv4/tcp_input.c:3418" thread on the netdev list; e.g.:
tcp_input.c:3418 WARN_ON((int)tp->sacked_out < 0);
More generally, I think this bug can be tickled in some cases where
two or more ACKs from the receiver are lost and then a DSACK arrives
that is immediately above an existing SACKed skb in the write queue.
This fix changes tcp_shift_skb_data() to abort this sequence at step
(1) in the scenario above by noticing that the bytes are below snd_una
and not shifting them.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ulrich Weber [Mon, 5 Mar 2012 04:52:44 +0000 (04:52 +0000)]
bridge: check return value of ipv6_dev_get_saddr()
[ Upstream commit
d1d81d4c3dd886d5fa25a2c4fa1e39cb89613712 ]
otherwise source IPv6 address of ICMPV6_MGM_QUERY packet
might be random junk if IPv6 is disabled on interface or
link-local address is not yet ready (DAD).
Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neal Cardwell [Fri, 2 Mar 2012 21:36:51 +0000 (21:36 +0000)]
tcp: don't fragment SACKed skbs in tcp_mark_head_lost()
[ Upstream commit
c0638c247f559e1a16ee79e54df14bca2cb679ea ]
In tcp_mark_head_lost() we should not attempt to fragment a SACKed skb
to mark the first portion as lost. This is for two primary reasons:
(1) tcp_shifted_skb() coalesces adjacent regions of SACKed skbs. When
doing this, it preserves the sum of their packet counts in order to
reflect the real-world dynamics on the wire. But given that skbs can
have remainders that do not align to MSS boundaries, this packet count
preservation means that for SACKed skbs there is not necessarily a
direct linear relationship between tcp_skb_pcount(skb) and
skb->len. Thus tcp_mark_head_lost()'s previous attempts to fragment
off and mark as lost a prefix of length (packets - oldcnt)*mss from
SACKed skbs were leading to occasional failures of the WARN_ON(len >
skb->len) in tcp_fragment() (which used to be a BUG_ON(); see the
recent "crash in tcp_fragment" thread on netdev).
(2) there is no real point in fragmenting off part of a SACKed skb and
calling tcp_skb_mark_lost() on it, since tcp_skb_mark_lost() is a NOP
for SACKed skbs.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Nandita Dukkipati <nanditad@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shreyas Bhatewara [Tue, 28 Feb 2012 22:17:38 +0000 (22:17 +0000)]
vmxnet3: Fix transport header size
[ Upstream commit
efead8710aad9e384730ecf25eae0287878840d7 ]
Fix transport header size
Fix the transpoert header size for UDP packets.
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neal Cardwell [Sun, 26 Feb 2012 10:06:19 +0000 (10:06 +0000)]
tcp: fix false reordering signal in tcp_shifted_skb
[ Upstream commit
4c90d3b30334833450ccbb02f452d4972a3c3c3f ]
When tcp_shifted_skb() shifts bytes from the skb that is currently
pointed to by 'highest_sack' then the increment of
TCP_SKB_CB(skb)->seq implicitly advances tcp_highest_sack_seq(). This
implicit advancement, combined with the recent fix to pass the correct
SACKed range into tcp_sacktag_one(), caused tcp_sacktag_one() to think
that the newly SACKed range was before the tcp_highest_sack_seq(),
leading to a call to tcp_update_reordering() with a degree of
reordering matching the size of the newly SACKed range (typically just
1 packet, which is a NOP, but potentially larger).
This commit fixes this by simply calling tcp_sacktag_one() before the
TCP_SKB_CB(skb)->seq advancement that can advance our notion of the
highest SACKed sequence.
Correspondingly, we can simplify the code a little now that
tcp_shifted_skb() should update the lost_cnt_hint in all cases where
skb == tp->lost_skb_hint.
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben McKeegan [Fri, 24 Feb 2012 06:33:56 +0000 (06:33 +0000)]
ppp: fix 'ppp_mp_reconstruct bad seq' errors
[ Upstream commit
8a49ad6e89feb5015e77ce6efeb2678947117e20 ]
This patch fixes a (mostly cosmetic) bug introduced by the patch
'ppp: Use SKB queue abstraction interfaces in fragment processing'
found here: http://www.spinics.net/lists/netdev/msg153312.html
The above patch rewrote and moved the code responsible for cleaning
up discarded fragments but the new code does not catch every case
where this is necessary. This results in some discarded fragments
remaining in the queue, and triggering a 'bad seq' error on the
subsequent call to ppp_mp_reconstruct. Fragments are discarded
whenever other fragments of the same frame have been lost.
This can generate a lot of unwanted and misleading log messages.
This patch also adds additional detail to the debug logging to
make it clearer which fragments were lost and which other fragments
were discarded as a result of losses. (Run pppd with 'kdebug 1'
option to enable debug logging.)
Signed-off-by: Ben McKeegan <ben@netservers.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>