OSDN Git Service
Jiri Slaby [Tue, 29 Mar 2011 22:10:56 +0000 (00:10 +0200)]
serial: core, do not set DTR/RTS twice on startup
commit
303a7a1199c20f7c9452f024a6e17bf348b6b398 upstream.
In .dtr_rts we do:
uart_set_mctrl(uport, TIOCM_DTR | TIOCM_RTS)
and call uart_update_termios. It does:
uart_set_mctrl(port, TIOCM_DTR | TIOCM_RTS)
once again. As the only callsite of uart_update_termios is .dtr_rts,
remove the uart_set_mctrl from uart_update_termios to not set it twice.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jiri Slaby [Tue, 29 Mar 2011 22:10:55 +0000 (00:10 +0200)]
serial: core, move termios handling to uart_startup
commit
c7d7abff40c27f82fe78b1091ab3fad69b2546f9 upstream.
We should not fiddle with speed and cflags in .dtr_rts hook. Actually
we might not have tty at that moment already.
So move the console cflag copy and speed setup into uart_startup.
Actually the speed setup is already there, but we need to call it
unconditionally (uart_startup is called from uart_open with hw_init =
0).
This means we move uart_change_speed before dtr/rts setup in .dtr_rts.
But this should not matter as the setup should be called after
uart_change_speed anyway.
Before: After:
dtr/rts setup (dtr_rts) uart_change_speed (startup)
uart_change_speed (update_termios) dtr/rts setup (dtr_rts)
dtr/rts setup (update_termios) dtr/rts setup (update_termios)
The second setup will dismiss with the next patch.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hugh Dickins [Mon, 6 Jun 2011 05:03:13 +0000 (22:03 -0700)]
mm: fix ENOSPC returned by handle_mm_fault()
commit
e0dcd8a05be438b3d2e49ef61441ea3a463663f8 upstream.
Al Viro observes that in the hugetlb case, handle_mm_fault() may return
a value of the kind ENOSPC when its caller is expecting a value of the
kind VM_FAULT_SIGBUS: fix alloc_huge_page()'s failure returns.
Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jussi Kivilinna [Mon, 30 May 2011 07:15:47 +0000 (10:15 +0300)]
zd1211rw: fix to work on OHCI
commit
59342f6a6bc35df623fb44784daa5e1077063b8f upstream.
zd1211 devices register 'EP 4 OUT' endpoint as Interrupt type on USB 2.0:
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
However on USB 1.1 endpoint becomes Bulk:
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Commit
37939810b937aba830dd751291fcdc51cae1a6cb assumed that endpoint is
always interrupt type and changed usb_bulk_msg() calls to usb_interrupt_msg().
Problem here is that usb_bulk_msg() on interrupt endpoint selfcorrects the
call and changes requested pipe to interrupt type (see usb_bulk_msg).
However with usb_interrupt_msg() on bulk endpoint does not correct the
pipe type to bulk, but instead URB is submitted with interrupt type pipe.
So pre-2.6.39 used usb_bulk_msg() and therefore worked with both endpoint
types, however in 2.6.39 usb_interrupt_msg() with bulk endpoint causes
ohci_hcd to fail submitted URB instantly with -ENOSPC and preventing zd1211rw
from working with OHCI.
Fix this by detecting endpoint type and using correct endpoint/pipe types
for URB. Also fix asynchronous zd_usb_iowrite16v_async() to use right
URB type on 'EP 4 OUT'.
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Wed, 1 Jun 2011 15:17:57 +0000 (17:17 +0200)]
iwl4965: correctly validate temperature value
commit
dfe21582ac5ebc460dda98c67e8589dd506d02cd upstream.
In some cases we can read wrong temperature value. If after that
temperature value will not be updated to good one, we badly configure
tx power parameters and device is unable to send a data.
Resolves:
https://bugzilla.kernel.org/show_bug.cgi?id=35932
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Stanislaw Gruszka [Tue, 24 May 2011 14:28:55 +0000 (16:28 +0200)]
iwl4965: fix 5GHz operation
commit
aac11c1b351413aa3412e258e2b2dcba31777209 upstream.
rx_status.band is used uninitialized, what disallow to work on 5GHz .
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Tue, 31 May 2011 19:50:51 +0000 (15:50 -0400)]
hwmon: (coretemp) Relax target temperature range check
commit
4c6e0f8101e62d8b2d01dc94b835a98b191a1454 upstream.
The current temperature range check of MSR_IA32_TEMPERATURE_TARGET
seems too strict to me, some TjMax values documented in
Documentation/hwmon/coretemp wouldn't pass. Relax the check so that
all the documented values pass.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Carsten Emde <C.Emde@osadl.org>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Guenter Roeck [Tue, 31 May 2011 13:54:21 +0000 (06:54 -0700)]
hwmon: (coretemp) Fix TjMax detection for older CPUs
commit
4f5f71a7abe329bdad81ee6a8e4545054a7cc30a upstream.
Commit
a321cedb12904114e2ba5041a3673ca24deb09c9 excludes CPU models 0xe, 0xf,
0x16, and 0x1a from TjMax temperature adjustment, even though several of those
CPUs are known to have TiMax other than 100 degrees C, and even though the code
in adjust_tjmax() explicitly handles those CPUs and points to a Web document
listing several of the affected CPU IDs.
Reinstate original TjMax adjustment if TjMax can not be determined using the
IA32_TEMPERATURE_TARGET register.
https://bugzilla.kernel.org/show_bug.cgi?id=32582
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Cc: Huaxu Wan <huaxu.wan@linux.intel.com>
Cc: Carsten Emde <C.Emde@osadl.org>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Yong Wang <yong.y.wang@linux.intel.com>
Cc: Rudolf Marek <r.marek@assembler.cz>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Tested-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Halperin [Tue, 31 May 2011 18:59:30 +0000 (11:59 -0700)]
ath9k: fix two more bugs in tx power
commit
21fdc87248d1d28492c775e05fa92b3c8c7bc8db upstream.
This is the same fix as
commit
841051602e3fa18ea468fe5a177aa92b6eb44b56
Author: Matteo Croce <technoboy85@gmail.com>
Date: Fri Dec 3 02:25:08 2010 +0100
The ath9k driver subtracts 3 dBm to the txpower as with two radios the
signal power is doubled.
The resulting value is assigned in an u16 which overflows and makes
the card work at full power.
in two more places. I grepped the ath tree and didn't find any others.
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rajkumar Manoharan [Fri, 20 May 2011 12:22:14 +0000 (17:52 +0530)]
ath9k: set 40 Mhz rate only if hw is configured in ht40
commit
41e2b05b9598d6bdf91fc20280bfc538d853f769 upstream.
Whenever there is a channel width change from 40 Mhz to 20 Mhz,
the hardware is reconfigured to ht20. Meantime before doing
the rate control updation, the packets are being transmitted are
selected rate with IEEE80211_TX_RC_40_MHZ_WIDTH.
While transmitting ht40 rate packets in ht20 mode is causing
baseband panic with AR9003 based chips.
==== BB update: BB status=0x02001109 ====
ath: ** BB state: wd=1 det=1 rdar=0 rOFDM=1 rCCK=1 tOFDM=0 tCCK=0 agc=2
src=0 **
ath: ** BB WD cntl: cntl1=0xffff0085 cntl2=0x00000004 **
ath: ** BB mode: BB_gen_controls=0x000033c0 **
ath: ** BB busy times: rx_clear=99%, rx_frame=0%, tx_frame=0% **
ath: ==== BB update: done ====
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rajkumar Manoharan [Fri, 20 May 2011 12:22:10 +0000 (17:52 +0530)]
ath9k: Reset chip on baseband hang
commit
a4d86d953b8593791cb29cf2acffd48f9ee6c4f9 upstream.
Resetting hardware helps to recover from baseband
hang/panic for AR9003 based chips.
Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
James Bottomley [Wed, 25 May 2011 20:52:14 +0000 (15:52 -0500)]
Fix oops caused by queue refcounting failure
commit
e73e079bf128d68284efedeba1fbbc18d78610f9 upstream.
In certain circumstances, we can get an oops from a torn down device.
Most notably this is from CD roms trying to call scsi_ioctl. The root
cause of the problem is the fact that after scsi_remove_device() has
been called, the queue is fully torn down. This is actually wrong
since the queue can be used until the sdev release function is called.
Therefore, we add an extra reference to the queue which is released in
sdev->release, so the queue always exists.
Reported-by: Parag Warudkar <parag.lkml@gmail.com>
Signed-off-by: James Bottomley <jbottomley@parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Sat, 28 May 2011 12:44:46 +0000 (14:44 +0200)]
nbd: limit module parameters to a sane value
commit
3b2710824e00d238554c13b5add347e6c701ab1a upstream.
The 'max_part' parameter controls the number of maximum partition
a nbd device can have. However if a user specifies very large
value it would exceed the limitation of device minor number and
can cause a kernel oops (or, at least, produce invalid device
nodes in some cases).
In addition, specifying large 'nbds_max' value causes same
problem for the same reason.
On my desktop, following command results to the kernel bug:
$ sudo modprobe nbd max_part=100000
kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/nbd4/range
CPU 1
Modules linked in: nbd(+) bridge stp llc kvm_intel kvm asus_atk0110 sg sr_mod cdrom
Pid: 2522, comm: modprobe Tainted: G W 2.6.39-leonard+ #159 System manufacturer System Product Name/P5G41TD-M PRO
RIP: 0010:[<
ffffffff8115aa08>] [<
ffffffff8115aa08>] internal_create_group+0x2f/0x166
RSP: 0018:
ffff8801009f1de8 EFLAGS:
00010246
RAX:
00000000ffffffef RBX:
ffff880103920478 RCX:
00000000000a7bd3
RDX:
ffffffff81a2dbe0 RSI:
0000000000000000 RDI:
ffff880103920478
RBP:
ffff8801009f1e38 R08:
ffff880103920468 R09:
ffff880103920478
R10:
ffff8801009f1de8 R11:
ffff88011eccbb68 R12:
ffffffff81a2dbe0
R13:
ffff880103920468 R14:
0000000000000000 R15:
ffff880103920400
FS:
00007f3c49de9700(0000) GS:
ffff88011f800000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
00007f3b7fe7c000 CR3:
00000000cd58d000 CR4:
00000000000406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process modprobe (pid: 2522, threadinfo
ffff8801009f0000, task
ffff8801009a93a0)
Stack:
ffff8801009f1e58 ffffffff812e8f6e ffff8801009f1e58 ffffffff812e7a80
ffff880000000010 ffff880103920400 ffff8801002fd0c0 ffff880103920468
0000000000000011 ffff880103920400 ffff8801009f1e48 ffffffff8115ab6a
Call Trace:
[<
ffffffff812e8f6e>] ? device_add+0x4f1/0x5e4
[<
ffffffff812e7a80>] ? dev_set_name+0x41/0x43
[<
ffffffff8115ab6a>] sysfs_create_group+0x13/0x15
[<
ffffffff810b857e>] blk_trace_init_sysfs+0x14/0x16
[<
ffffffff811ee58b>] blk_register_queue+0x4c/0xfd
[<
ffffffff811f3bdf>] add_disk+0xe4/0x29c
[<
ffffffffa007e2ab>] nbd_init+0x2ab/0x30d [nbd]
[<
ffffffffa007e000>] ? 0xffffffffa007dfff
[<
ffffffff8100020f>] do_one_initcall+0x7f/0x13e
[<
ffffffff8107ab0a>] sys_init_module+0xa1/0x1e3
[<
ffffffff814f3542>] system_call_fastpath+0x16/0x1b
Code: 41 57 41 56 41 55 41 54 53 48 83 ec 28 0f 1f 44 00 00 48 89 fb 41 89 f6 49 89 d4 48 85 ff 74 0b 85 f6 75 0b 48 83
7f 30 00 75 14 <0f> 0b eb fe b9 ea ff ff ff 48 83 7f 30 00 0f 84 09 01 00 00 49
RIP [<
ffffffff8115aa08>] internal_create_group+0x2f/0x166
RSP <
ffff8801009f1de8>
---[ end trace
753285ffbf72c57c ]---
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: Paul Clements <Paul.Clements@steeleye.com>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Wed, 1 Jun 2011 06:27:41 +0000 (08:27 +0200)]
block: blkdev_get() should access ->bd_disk only after success
commit
4c49ff3fe128ca68dabd07537415c419ad7f82f9 upstream.
d4dc210f69 (block: don't block events on excl write for non-optical
devices) added dereferencing of bdev->bd_disk to test
GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE; however, bdev->bd_disk can be
%NULL if open failed which can lead to an oops.
Test the flag after testing open was successful, not before.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: David Miller <davem@davemloft.net>
Tested-by: David Miller <davem@davemloft.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Artem Bityutskiy [Tue, 31 May 2011 05:40:40 +0000 (08:40 +0300)]
UBIFS: fix memory leak on error path
commit
812eb258311f89bcd664a34a620f249d54a2cd83 upstream.
UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write
failure because it forgets to free the 'struct ubifs_dent_node *dent' object.
Although the object is small, the alignment can make it large - e.g., 2KiB
if the min. I/O unit is 2KiB.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Artem Bityutskiy [Tue, 31 May 2011 04:03:21 +0000 (07:03 +0300)]
UBIFS: fix shrinker object count reports
commit
cf610bf4199770420629d3bc273494bd27ad6c1d upstream.
Sometimes VM asks the shrinker to return amount of objects it can shrink,
and we return the ubifs_clean_zn_cnt in that case. However, it is possible
that this counter is negative for a short period of time, due to the way
UBIFS TNC code updates it. And I can observe the following warnings sometimes:
shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-
8541616642706119788
This patch makes sure UBIFS never returns negative count of objects.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Metcalf [Tue, 17 May 2011 19:25:21 +0000 (15:25 -0400)]
arch/tile: allocate PCI IRQs later in boot
commit
f4de51de2edcd26ec77bfc71b1f00b1de5a5dc20 upstream.
This change became required due to some recent reworking in the
platform-independent IRQ code. It is required for 2.6.38 and later.
Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kerstin jonsson [Tue, 17 May 2011 23:57:11 +0000 (23:57 +0000)]
powerpc/4xx: Fix regression in SMP on 476
commit
c560bbceaf6b06e52f1ef20131b76a3fdc0a2c19 upstream.
commit
c56e58537d504706954a06570b4034c04e5b7500 breaks SMP support in PPC_47x chip.
secondary_ti must be set to current thread info before callin kick_cpu or else
start_secondary_47x will jump into void when trying to return to c-code.
In the current setup secondary_ti is initialized before the CPU idle task is started
and only the boot core will start. I am not sure this is the correct solution, but it
makes SMP possible in my chip.
Note! The HOTPLUG support probably need some fixing to, There is no trampoline code
available in head_44x.S - start_secondary_resume?
Signed-off-by: Kerstin Jonsson <kerstin.jonsson@ericsson.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Habeck [Sat, 28 May 2011 18:15:07 +0000 (13:15 -0500)]
intel-iommu: Add domain check in domain_remove_one_dev_info
commit
8519dc4401ddf8a5399f979870bbeeadbc111186 upstream.
The comment in domain_remove_one_dev_info() states "No need to compare
PCI domain; it has to be the same". But for the si_domain that isn't
going to be true, as it consists of all the PCI devices that are
identity mapped thus multiple PCI domains can be in si_domain. The
code needs to validate the PCI domain too.
Signed-off-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: Mike Travis <travis@sgi.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Travis [Sat, 28 May 2011 18:15:06 +0000 (13:15 -0500)]
intel-iommu: Remove Host Bridge devices from identity mapping
commit
825507d6d059f1cbe2503e0e5a3926225b983aec upstream.
When using the 1:1 (identity) PCI DMA remapping, PCI Host Bridge devices
that do not use the IOMMU causes a kernel panic. Fix that by not
inserting those devices into the si_domain.
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Travis [Sat, 28 May 2011 18:15:05 +0000 (13:15 -0500)]
intel-iommu: Use coherent DMA mask when requested
commit
c681d0ba1252954208220ad32248a3e8e2fc98e4 upstream.
The __intel_map_single function is not honoring the passed in DMA mask.
This results in not using the coherent DMA mask when called from
intel_alloc_coherent().
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Reviewed-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Wright [Sat, 28 May 2011 18:15:04 +0000 (13:15 -0500)]
intel-iommu: Dont cache iova above 32bit
commit
1c9fc3d11b84fbd0c4f4aa7855702c2a1f098ebb upstream.
Mike Travis and Mike Habeck reported an issue where iova allocation
would return a range that was larger than a device's dma mask.
https://lkml.org/lkml/2011/3/29/423
The dmar initialization code will reserve all PCI MMIO regions and copy
those reservations into a domain specific iova tree. It is possible for
one of those regions to be above the dma mask of a device. It is typical
to allocate iovas with a 32bit mask (despite device's dma mask possibly
being larger) and cache the result until it exhausts the lower 32bit
address space. Freeing the iova range that is >= the last iova in the
lower 32bit range when there is still an iova above the 32bit range will
corrupt the cached iova by pointing it to a region that is above 32bit.
If that region is also larger than the device's dma mask, a subsequent
allocation will return an unusable iova and cause dma failure.
Simply don't cache an iova that is above the 32bit caching boundary.
Reported-by: Mike Travis <travis@sgi.com>
Reported-by: Mike Habeck <habeck@sgi.com>
Acked-by: Mike Travis <travis@sgi.com>
Tested-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Travis [Sat, 28 May 2011 18:15:03 +0000 (13:15 -0500)]
intel-iommu: Speed up processing of the identity_mapping function
commit
cb452a4040bb051d92e85d6e7eb60c11734c1781 upstream.
When there are a large count of PCI devices, and the pass through
option for iommu is set, much time is spent in the identity_mapping
function hunting though the iommu domains to check if a specific
device is "identity mapped".
Speed up the function by checking the cached info to see if
it's mapped to the static identity domain.
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Chris Wright [Sat, 28 May 2011 18:15:02 +0000 (13:15 -0500)]
intel-iommu: Check for identity mapping candidate using system dma mask
commit
8fcc5372fbac085199d84a880503ed67aba3fe49 upstream.
The identity mapping code appears to make the assumption that if the
devices dma_mask is greater than 32bits the device can use identity
mapping. But that is not true: take the case where we have a 40bit
device in a 44bit architecture. The device can potentially receive a
physical address that it will truncate and cause incorrect addresses
to be used.
Instead check to see if the device's dma_mask is large enough
to address the system's dma_mask.
Signed-off-by: Mike Travis <travis@sgi.com>
Reviewed-by: Mike Habeck <habeck@sgi.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Williamson [Tue, 24 May 2011 16:19:04 +0000 (12:19 -0400)]
intel-iommu: Only unlink device domains from iommu
commit
9b4554b21ed07e8556405510638171f0c787742a upstream.
Commit
a97590e5 added unlinking domains from iommus to reciprocate the
iommu from domains unlinking that was already done. We actually want
to only do this for device domains and never for the static
identity map domain or VM domains. The SI domain is special and
never freed, while VM domain->id lives in their own special address
space, separate from iommu->domain_ids.
In the current code, a VM can get domain->id zero, then mark that
domain unused when unbound from pci-stub. This leads to DMAR
write faults when the device is re-bound to the host driver.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Williamson [Tue, 24 May 2011 11:02:41 +0000 (12:02 +0100)]
intel-iommu: Flush unmaps at domain_exit
commit
7b668357810ecb5fdda4418689d50f5d95aea6a8 upstream.
We typically batch unmaps to be lazily flushed out at
regular intervals. When we destroy a domain, we need
to force a flush of these lazy unmaps to be sure none
reference the domain we're about to free.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=35062
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Rusty Russell [Mon, 30 May 2011 17:14:08 +0000 (11:14 -0600)]
lguest: fix timer interrupt setup
commit
15517f7c213442e4d8a098cf0732b237f764c576 upstream.
Without an IRQ chip set, we now get a WARN_ON and no timer interrupt. This
prevents booting.
Fortunately, the fix is a one-liner: set up the timer IRQ like everything
else.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman [Fri, 3 Jun 2011 00:34:20 +0000 (09:34 +0900)]
Linux 2.6.39.1
Kees Cook [Tue, 31 May 2011 18:31:41 +0000 (11:31 -0700)]
AppArmor: fix oops in apparmor_setprocattr
commit
a5b2c5b2ad5853591a6cac6134cd0f599a720865 upstream.
When invalid parameters are passed to apparmor_setprocattr a NULL deref
oops occurs when it tries to record an audit message. This is because
it is passing NULL for the profile parameter for aa_audit. But aa_audit
now requires that the profile passed is not NULL.
Fix this by passing the current profile on the task that is trying to
setprocattr.
Signed-off-by: Kees Cook <kees@ubuntu.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Lukas Czerner [Fri, 20 May 2011 17:49:04 +0000 (13:49 -0400)]
ext4: Use schedule_timeout_interruptible() for waiting in lazyinit thread
commit
4ed5c033c11b33149d993734a6a8de1016e8f03f upstream.
In order to make lazyinit eat approx. 10% of io bandwidth at max, we
are sleeping between zeroing each single inode table. For that purpose
we are using timer which wakes up thread when it expires. It is set
via add_timer() and this may cause troubles in the case that thread
has been woken up earlier and in next iteration we call add_timer() on
still running timer hence hitting BUG_ON in add_timer(). We could fix
that by using mod_timer() instead however we can use
schedule_timeout_interruptible() for waiting and hence simplifying
things a lot.
This commit exchange the old "waiting mechanism" with simple
schedule_timeout_interruptible(), setting the time to sleep. Hence we
do not longer need li_wait_daemon waiting queue and others, so get rid
of it.
Addresses-Red-Hat-Bugzilla: #699708
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Lukas Czerner [Fri, 20 May 2011 17:55:29 +0000 (13:55 -0400)]
ext4: fix possible use-after-free in ext4_remove_li_request()
commit
1bb933fb1fa8e4cb337a0d5dfd2ff4c0dc2073e8 upstream.
We need to take reference to the s_li_request after we take a mutex,
because it might be freed since then, hence result in accessing old
already freed memory. Also we should protect the whole
ext4_remove_li_request() because ext4_li_info might be in the process of
being freed in ext4_lazyinit_thread().
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tejun Heo [Thu, 21 Apr 2011 18:54:46 +0000 (20:54 +0200)]
block: don't block events on excl write for non-optical devices
commit
d4dc210f69bcb0b4bef5a83b1c323817be89bad1 upstream.
Disk event code automatically blocks events on excl write. This is
primarily to avoid issuing polling commands while burning is in
progress. This behavior doesn't fit other types of devices with
removeable media where polling commands don't have adverse side
effects and door locking usually doesn't exist.
This patch introduces new genhd flag which controls the auto-blocking
behavior and uses it to enable auto-blocking only on optical devices.
Note for stable: 2.6.38 and later only
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tian, Kevin [Thu, 12 May 2011 02:56:08 +0000 (10:56 +0800)]
xen mmu: fix a race window causing leave_mm BUG()
commit
7899891c7d161752f29abcc9bc0a9c6c3a3af26c upstream.
There's a race window in xen_drop_mm_ref, where remote cpu may exit
dirty bitmap between the check on this cpu and the point where remote
cpu handles drop request. So in drop_other_mm_ref we need check
whether TLB state is still lazy before calling into leave_mm. This
bug is rarely observed in earlier kernel, but exaggerated by the
commit
831d52bc153971b70e64eccfbed2b232394f22f8
("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm")
which clears bitmap after changing the TLB state. the call trace is as below:
---------------------------------
kernel BUG at arch/x86/mm/tlb.c:61!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
CPU 1
Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285
RIP: e030:[<
ffffffff8103a3cb>] [<
ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP: e02b:
ffff88002805be48 EFLAGS:
00010046
RAX:
0000000000000000 RBX:
0000000000000001 RCX:
ffff88015f8e2da0
RDX:
ffff88002805be78 RSI:
0000000000000000 RDI:
0000000000000001
RBP:
ffff88002805be48 R08:
ffff88009d662000 R09:
dead000000200200
R10:
dead000000100100 R11:
ffffffff814472b2 R12:
ffff88009bfc1880
R13:
ffff880028063020 R14:
00000000000004f6 R15:
0000000000000000
FS:
00007f62362d66e0(0000) GS:
ffff880028058000(0000) knlGS:
0000000000000000
CS: e033 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000003aabc11909 CR3:
000000009b8ca000 CR4:
0000000000002660
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
00000000000000 00
DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
Process khelper (pid: 25581, threadinfo
ffff88007691e000, task
ffff88009b92db40)
Stack:
ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88
<0>
ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78
<0>
ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108
Call Trace:
<IRQ>
[<
ffffffff8100e4ae>] drop_other_mm_ref+0x2a/0x53
[<
ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc
[<
ffffffff81010108>] xen_call_function_single_interrupt+0x13/0x28
[<
ffffffff810a936a>] handle_IRQ_event+0x66/0x120
[<
ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e
[<
ffffffff8128c1c0>] __xen_evtchn_do_upcall+0x1ab/0x27d
[<
ffffffff8128dd11>] xen_evtchn_do_upcall+0x33/0x46
[<
ffffffff81013efe>] xen_do_hyper visor_callback+0x1e/0x30
<EOI>
[<
ffffffff814472b2>] ? _spin_unlock_irqrestore+0x15/0x17
[<
ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
[<
ffffffff81113f71>] ? flush_old_exec+0x3ac/0x500
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff8115115d>] ? load_elf_binary+0x398/0x17ef
[<
ffffffff81042fcf>] ? need_resched+0x23/0x2d
[<
ffffffff811f4648>] ? process_measurement+0xc0/0xd7
[<
ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
[<
ffffffff81113094>] ? search_binary_handler+0xc8/0x255
[<
ffffffff81114362>] ? do_execve+0x1c3/0x29e
[<
ffffffff8101155d>] ? sys_execve+0x43/0x5d
[<
ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff81013e28>] ? kernel_execve+0x68/0xd0
[<
ffffffff 8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
[<
ffffffff8106fb64>] ? ____call_usermodehelper+0x113/0x11e
[<
ffffffff81013daa>] ? child_rip+0xa/0x20
[<
ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
[<
ffffffff81012f91>] ? int_ret_from_sys_call+0x7/0x1b
[<
ffffffff8101371d>] ? retint_restore_args+0x5/0x6
[<
ffffffff81013da0>] ? child_rip+0x0/0x20
Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8
RIP [<
ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP <
ffff88002805be48>
---[ end trace
ce9cee6832a9c503 ]---
Tested-by: Maoxiaoyun<tinnycloud@hotmail.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
[v1: Fleshed out the git description a bit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Konrad Rzeszutek Wilk [Tue, 12 Apr 2011 11:57:15 +0000 (07:57 -0400)]
xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.
commit
15bfc094517db2ddf38ca7ed47f3a1c0ad24f7c4 upstream.
When we parse the raw E820, the Xen hypervisor can set "E820_RAM"
to "E820_UNUSABLE" if the mem=X argument is used. As such we
should _not_ consider the E820_UNUSABLE as an 1-1 identity
mapping, but instead use the same case as for E820_RAM.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Kiper [Wed, 11 May 2011 20:34:38 +0000 (22:34 +0200)]
xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit
commit
0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3 upstream.
git commit
24bdb0b62cc82120924762ae6bc85afc8c3f2b26 (xen: do not create
the extra e820 region at an addr lower than 4G) does not take into
account that ifdef CONFIG_X86_32 instead of e820_end_of_low_ram_pfn()
find_low_pfn_range() is called (both calls are from arch/x86/kernel/setup.c).
find_low_pfn_range() behaves correctly and does not require change in
xen_extra_mem_start initialization. Additionally, if xen_extra_mem_start
is initialized in the same way as ifdef CONFIG_X86_64 then memory hotplug
support for Xen balloon driver (under development) is broken.
Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Konrad Rzeszutek Wilk [Fri, 1 Apr 2011 19:18:48 +0000 (15:18 -0400)]
xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings
commit
8c5950881c3b5e6e350e4b0438a8ccc513d90df9 upstream.
.. when applicable. We need to track in the p2m_mfn and
p2m_mfn_p the MFNs and pointers, respectivly, for the P2M entries
that are allocated for the identity mappings. Without this,
a PV domain with an E820 that triggers the 1-1 mapping to kick in,
won't be able to be restored as the P2M won't have the identity
mappings.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hemant Pedanekar [Tue, 5 Apr 2011 07:02:50 +0000 (12:32 +0530)]
PCI: Add quirk for setting valid class for TI816X Endpoint
commit
63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream.
TI816X (common name for DM816x/C6A816x/AM389x family) devices configured
to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus
code to skip allocating BARs to these devices resulting into following
type of error when trying to enable them:
"Device 0000:01:00.0 not available because of resource collisions"
The device cannot be operated because of the above issue.
This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based)
'early' fixup quirk to replace class code with
PCI_CLASS_MULTIMEDIA_VIDEO as class.
Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vitaliy Gusev [Thu, 19 May 2011 21:34:46 +0000 (01:34 +0400)]
nfs41: Correct offset for LAYOUTCOMMIT
commit
4b8ee2b82e8b0b6e17ee33feb74fcdb5c6d8dbdd upstream.
A client sends offset to MDS as it was seen by DS. As result,
file size after copy is only half of original file size in case
of 2 DS.
Signed-off-by: Vitaliy Gusev <gusev.vitaliy@nexenta.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Thu, 26 May 2011 18:26:35 +0000 (14:26 -0400)]
NFSv4.1: Fix the handling of NFS4ERR_SEQ_MISORDERED errors
commit
444f72fe7e7b5f4db34cee933fa3546ebb8e9122 upstream.
Currently, the call to nfs4_schedule_session_recovery() will actually just
result in a test of the lease when what we really want is to force a
session reset.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Thu, 26 May 2011 18:26:35 +0000 (14:26 -0400)]
NFSv4: Handle expired stateids when the lease is still valid
commit
0ced63d1a245ac11241a5d37932e6d04d9c8040d upstream.
Currently, if the server returns NFS4ERR_EXPIRED in reply to a READ or
WRITE, but the RENEW test determines that the lease is still active, we
fail to recover and end up looping forever in a READ/WRITE + RENEW death
spiral.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Trond Myklebust [Sat, 19 Mar 2011 00:21:23 +0000 (20:21 -0400)]
SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback...
commit
fe19a96b10032035a35779f42ad59e35d6dd8ffd upstream.
The TCP connection state code depends on the state_change() callback
being called when the SYN_SENT state is set. However the networking layer
doesn't actually call us back in that case.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Thu, 19 May 2011 04:14:43 +0000 (14:14 +1000)]
drm/radeon/kms: add wait idle ioctl for eg->cayman
commit
97bfd0acd32e9639c9136e03955d574655d5cc2b upstream.
None of the latest GPUs had this hooked up, this is necessary for
correct operation in a lot of cases, however we should test this on a few
GPUs in these families as we've had problems in this area before.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Thu, 19 May 2011 04:14:41 +0000 (14:14 +1000)]
drm/radeon/kms: fix tile_config value reported to userspace on cayman.
commit
cde5083b051e9c66c99a8764aefbc13349e7730d upstream.
cayman is reporting the wrong tile config value to userspace, this
causes piglit mipmap generation tests to fail.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Thu, 19 May 2011 04:14:40 +0000 (14:14 +1000)]
drm/radeon/kms: fix incorrect comparison in cayman setup code.
commit
c289cff10a265ec4afe4396425297ff979a840b5 upstream.
This was leading to a bogus value being programmed to the backend
routing register.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alex Deucher [Thu, 19 May 2011 15:07:57 +0000 (11:07 -0400)]
drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked
commit
f25a5c63bfa017498c9adecb24d649ae96ba5c68 upstream.
This needs to be explicitly set on btc. It's set by default
on evergreen/fusion, so it fine to just unconditionally enable it for
all chips.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dave Airlie [Thu, 19 May 2011 04:14:42 +0000 (14:14 +1000)]
drm/radeon/cayman: setup hdp to invalidate and flush when asked
commit
0b65f83f9d2fab47b9b6040fe75fc2cfc73032d4 upstream.
On cayman we need to set the bit to cause HDP flushes to invalidate the
HDP cache also.
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Boqun Feng [Mon, 16 May 2011 08:02:39 +0000 (16:02 +0800)]
drm/i915: fix user irq miss in BSD ring on g4x
commit
5bfa1063a775836a84f97e4df863fc36e1f856ad upstream.
On g4x, user interrupt in BSD ring is missed.
This is because though g4x and ironlake share the same bsd_ring,
their interrupt control interfaces have _two_ differences.
1.different irq enable/disable functions:
On g4x are i915_enable_irq and i915_disable_irq.
On ironlake are ironlake_enable_irq and ironlake_disable_irq.
2.different irq flag:
On g4x user interrupt flag in BSD ring on is I915_BSD_USER_INTERRUPT.
On ironlake is GT_BSD_USER_INTERRUPT
Old bsd_ring_get/put_irq call ring_get_irq and ring_get_irq.
ring_get_irq and ring_put_irq only call ironlake_enable/disable_irq.
So comes the irq miss on g4x.
To fix this, as other rings' code do, conditionally call different
functions(i915_enable/disable_irq and ironlake_enable/disable_irq)
and use different interrupt flags in bsd_ring_get/put_irq.
Signed-off-by: Boqun Feng <boqun.feng@intel.com>
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: handle on-demand devices correctly
commit
af46566885a373b0a526932484cd8fef8de7b598 upstream.
When finding or allocating a ram disk device, brd_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4
for simplicity) :
$ sudo modprobe brd max_part=15
$ ls -l /dev/ram*
brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
$ sudo mknod /dev/ram4 b 1 64
$ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256
256+0 records in
256+0 records out
1048576 bytes (1.0 MB) copied, 0.
00215578 s, 486 MB/s
namhyung@leonhard:linux$ ls -l /dev/ram*
brw-rw---- 1 root disk 1, 0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
brw-r--r-- 1 root root 1, 64 2011-05-25 15:45 /dev/ram4
brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64
After this patch, /dev/ram4 - instead of /dev/ram64 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that RAMDISK_MAJOR can address.
It does not need to be limited by partition numbers unless
'rd_nr' param was specified.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: limit 'max_part' module param to DISK_MAX_PARTS
commit
315980c8688c4b06713c1a5fe9d64cdf8ab57a72 upstream.
The 'max_part' parameter controls the number of maximum partition
a brd device can have. However if a user specifies very large
value it would exceed the limitation of device minor number and
can cause a kernel panic (or, at least, produce invalid device
nodes in some cases).
On my desktop system, following command kills the kernel. On qemu,
it triggers similar oops but the kernel was alive:
$ sudo modprobe brd max_part=100000
BUG: unable to handle kernel NULL pointer dereference at
0000000000000058
IP: [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
PGD
7af1067 PUD
7b19067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in: brd(+)
Pid: 44, comm: insmod Tainted: G W 2.6.39-qemu+ #158 Bochs Bochs
RIP: 0010:[<
ffffffff81110a9a>] [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
RSP: 0018:
ffff880007b15d78 EFLAGS:
00000286
RAX:
ffff880007b05478 RBX:
ffff880007a52760 RCX:
ffff880007b15dc8
RDX:
ffff880007a4f900 RSI:
ffff880007b15e48 RDI:
ffff880007a52760
RBP:
ffff880007b15da8 R08:
0000000000000002 R09:
0000000000000000
R10:
ffff880007b15e48 R11:
ffff880007b05478 R12:
0000000000000000
R13:
ffff880007b05478 R14:
0000000000400920 R15:
0000000000000063
FS:
0000000002160880(0063) GS:
ffff880007c00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000058 CR3:
0000000007b1c000 CR4:
00000000000006b0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
0000000000000000 DR7:
0000000000000000
Process insmod (pid: 44, threadinfo
ffff880007b14000, task
ffff880007acb980)
Stack:
ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe
ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a
0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000
Call Trace:
[<
ffffffff81143c0a>] kobject_add_internal+0xdf/0x1a0
[<
ffffffff81143da1>] kobject_add_varg+0x41/0x50
[<
ffffffff81143e6b>] kobject_add+0x64/0x66
[<
ffffffff8113bbe7>] blk_register_queue+0x5f/0xb8
[<
ffffffff81140f72>] add_disk+0xdf/0x289
[<
ffffffffa00040df>] brd_init+0xdf/0x1aa [brd]
[<
ffffffffa0004000>] ? 0xffffffffa0003fff
[<
ffffffffa0004000>] ? 0xffffffffa0003fff
[<
ffffffff8100020a>] do_one_initcall+0x7a/0x12e
[<
ffffffff8108516c>] sys_init_module+0x9c/0x1dc
[<
ffffffff812ff4bb>] system_call_fastpath+0x16/0x1b
Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30
8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89
RIP [<
ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
RSP <
ffff880007b15d78>
CR2:
0000000000000058
---[ end trace
aebb1175ce1f6739 ]---
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Dan Williams [Fri, 27 May 2011 04:51:54 +0000 (04:51 +0000)]
atm: expose ATM device index in sysfs
commit
e7a46b4d0839c2a3aa2e0ae0b145f293f6738498 upstream.
It's currently exposed only through /proc which, besides requiring
screen-scraping, doesn't allow userspace to distinguish between two
identical ATM adapters with different ATM indexes. The ATM device index
is required when using PPPoATM on a system with multiple ATM adapters.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hugh Dickins [Sat, 28 May 2011 20:14:09 +0000 (13:14 -0700)]
tmpfs: fix race between truncate and writepage
commit
826267cf1e6c6899eda1325a19f1b1d15c558b20 upstream.
While running fsx on tmpfs with a memhog then swapoff, swapoff was hanging
(interruptibly), repeatedly failing to locate the owner of a 0xff entry in
the swap_map.
Although shmem_writepage() does abandon when it sees incoming page index
is beyond eof, there was still a window in which shmem_truncate_range()
could come in between writepage's dropping lock and updating swap_map,
find the half-completed swap_map entry, and in trying to free it,
leave it in a state that swap_shmem_alloc() could not correct.
Arguably a bug in __swap_duplicate()'s and swap_entry_free()'s handling
of the different cases, but easiest to fix by moving swap_shmem_alloc()
under cover of the lock.
More interesting than the bug: it's been there since 2.6.33, why could
I not see it with earlier kernels? The mmotm of two weeks ago seems to
have some magic for generating races, this is just one of three I found.
With yesterday's git I first saw this in mainline, bisected in search of
that magic, but the easy reproducibility evaporated. Oh well, fix the bug.
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Will Deacon [Thu, 26 May 2011 10:20:19 +0000 (11:20 +0100)]
ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area
commit
a248b13b21ae00b97638b4f435c8df3075808b5d upstream.
The v6 and v7 implementations of flush_kern_dcache_area do not align
the passed MVA to the size of a cacheline in the data cache. If a
misaligned address is used, only a subset of the requested area will
be flushed. This has been observed to cause failures in SMP boot where
the secondary_data initialised by the primary CPU is not cacheline
aligned, causing the secondary CPUs to read incorrect values for their
pgd and stack pointers.
This patch ensures that the base address is cacheline aligned before
flushing the d-cache.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Martin K. Petersen [Sun, 29 May 2011 12:02:55 +0000 (13:02 +0100)]
dm mpath: do not fail paths after integrity errors
commit
6f13f6fba76edc7d0e7580c5deee829d59a41b2f upstream.
Integrity errors need to be passed to the owner of the integrity
metadata for processing. Consequently EILSEQ should be passed up the
stack.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Milan Broz [Sun, 29 May 2011 12:02:52 +0000 (13:02 +0100)]
dm table: reject devices without request fns
commit
f4808ca99a203f20b4475601748e44b25a65bdec upstream.
This patch adds a check that a block device has a request function
defined before it is used. Otherwise, misconfiguration can cause an oops.
Because we are allowing devices with zero size e.g. an offline multipath
device as in commit
2cd54d9bedb79a97f014e86c0da393416b264eb3
("dm: allow offline devices") there needs to be an additional check
to ensure devices are initialised. Some block devices, like a loop
device without a backing file, exist but have no request function.
Reproducer is trivial: dm-mirror on unbound loop device
(no backing file on loop devices)
dmsetup create x --table "0 8 mirror core 2 8 sync 2 /dev/loop0 0 /dev/loop1 0"
and mirror resync will immediatelly cause OOps.
BUG: unable to handle kernel NULL pointer dereference at (null)
? generic_make_request+0x2bd/0x590
? kmem_cache_alloc+0xad/0x190
submit_bio+0x53/0xe0
? bio_add_page+0x3b/0x50
dispatch_io+0x1ca/0x210 [dm_mod]
? read_callback+0x0/0xd0 [dm_mirror]
dm_io+0xbb/0x290 [dm_mod]
do_mirror+0x1e0/0x748 [dm_mirror]
Signed-off-by: Milan Broz <mbroz@redhat.com>
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tim Chen [Fri, 11 Feb 2011 20:49:04 +0000 (12:49 -0800)]
idle governor: Avoid lock acquisition to read pm_qos before entering idle
commit
333c5ae9948194428fe6c5ef5c088304fc98263b upstream.
Thanks to the reviews and comments by Rafael, James, Mark and Andi.
Here's version 2 of the patch incorporating your comments and also some
update to my previous patch comments.
I noticed that before entering idle state, the menu idle governor will
look up the current pm_qos target value according to the list of qos
requests received. This look up currently needs the acquisition of a
lock to access the list of qos requests to find the qos target value,
slowing down the entrance into idle state due to contention by multiple
cpus to access this list. The contention is severe when there are a lot
of cpus waking and going into idle. For example, for a simple workload
that has 32 pair of processes ping ponging messages to each other, where
64 cpu cores are active in test system, I see the following profile with
37.82% of cpu cycles spent in contention of pm_qos_lock:
- 37.82% swapper [kernel.kallsyms] [k]
_raw_spin_lock_irqsave
- _raw_spin_lock_irqsave
- 95.65% pm_qos_request
menu_select
cpuidle_idle_call
- cpu_idle
99.98% start_secondary
A better approach will be to cache the updated pm_qos target value so
reading it does not require lock acquisition as in the patch below.
With this patch the contention for pm_qos_lock is removed and I saw a
2.2X increase in throughput for my message passing workload.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Acked-by: James Bottomley <James.Bottomley@suse.de>
Acked-by: mark gross <markgross@thegnar.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tero Kristo [Thu, 24 Feb 2011 15:19:23 +0000 (17:19 +0200)]
cpuidle: menu: fixed wrapping timers at 4.294 seconds
commit
7467571f4480b273007517b26297c07154c73924 upstream.
Cpuidle menu governor is using u32 as a temporary datatype for storing
nanosecond values which wrap around at 4.294 seconds. This causes errors
in predicted sleep times resulting in higher than should be C state
selection and increased power consumption. This also breaks cpuidle
state residency statistics.
Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Guenter Roeck [Tue, 24 May 2011 19:16:40 +0000 (12:16 -0700)]
hwmon: (pmbus) Initialize sysfs attributes
commit
eec752b2b99c794766926a9bac59b0d7df5b09c2 upstream.
Initialize sysfs attrs before device_create_file() call to suppress
lockdep_init_map() warning:
WARNING: at kernel/lockdep.c:2701 lockdep_init_map+0x12d/0x140()
Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Luca Tettamanti [Wed, 25 May 2011 18:43:31 +0000 (20:43 +0200)]
i8k: Avoid lahf in 64-bit code
commit
bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream.
i8k uses lahf to read the flag register in 64-bit code; early x86-64
CPUs, however, lack this instruction and we get an invalid opcode
exception at runtime.
Use pushf to load the flag register into the stack instead.
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Reported-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Harry G McGavran Jr <w5pny@arrl.net>
Cc: Massimo Dal Zotto <dz@debian.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Serge E. Hallyn [Thu, 26 May 2011 20:25:05 +0000 (15:25 -0500)]
Set cred->user_ns in key_replace_session_keyring
commit
f7285b5d631fd6096b11c6af0058ed3a2b30ef4e upstream.
Since this cred was not created with copy_creds(), it needs to get
initialized. Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
can lead to a NULL deref. Thanks to Robert for finding this.
But introduced by commit
47a150edc2a ("Cache user_ns in struct cred").
Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Reported-by: Robert Święcki <robert@swiecki.net>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kevin Cernekee [Tue, 10 May 2011 22:47:16 +0000 (15:47 -0700)]
kbuild: Fix GNU make v3.80 compatibility
commit
43f67c98161c65f1b2e3af3a9ce6741850072c06 upstream.
According to Documentation/Changes, the kernel should be buildable with
GNU make 3.80+. Commit
88d7be031f9f975bb3f50a0b5ef3796a671e7edf (kbuild:
Use a single clean rule for kernel and external modules) introduced the
"$(or" construct, which requires make 3.81. This causes "make clean" to
malfunction when it is used with external modules.
Replace "$(or" with an equivalent "$(if" expression, to restore backward
compatibility.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Artem Bityutskiy [Fri, 6 May 2011 14:08:56 +0000 (17:08 +0300)]
UBIFS: fix a rare memory leak in ro to rw remounting path
commit
eaeee242c531cd4b0a4a46e8b5dd7ef504380c42 upstream.
When re-mounting from R/O mode to R/W mode and the LEB count in the superblock
is not up-to date, because for the underlying UBI volume became larger, we
re-write the superblock. We allocate RAM for these purposes, but never free it.
So this is a memory leak, although very rare one.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tyler Hicks [Tue, 17 May 2011 05:50:33 +0000 (00:50 -0500)]
eCryptfs: Allow 2 scatterlist entries for encrypted filenames
commit
8d08dab786ad5cc2aca2bf870de370144b78c85a upstream.
The buffers allocated while encrypting and decrypting long filenames can
sometimes straddle two pages. In this situation, virt_to_scatterlist()
will return -ENOMEM, causing the operation to fail and the user will get
scary error messages in their logs:
kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting
to convert filename memory to scatterlist; expected rc = 1; got rc =
[-12]. block_aligned_filename_size = [272]
kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70
packet; rc = [-12]
kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to
encrypt filename; rc = [-12]
kernel: ecryptfs_lookup: Error attempting to encrypt and encode
filename; rc = [-12]
The solution is to allow up to 2 scatterlist entries to be used.
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tyler Hicks [Fri, 29 Apr 2011 21:26:27 +0000 (16:26 -0500)]
eCryptfs: Clear i_nlink in rmdir
commit
07850552b92b3637fa56767b5e460b4238014447 upstream.
eCryptfs wasn't clearing the eCryptfs inode's i_nlink after a successful
vfs_rmdir() on the lower directory. This resulted in the inode evict and
destroy paths to be missed.
https://bugs.launchpad.net/ecryptfs/+bug/723518
Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Christian Lamparter [Fri, 13 May 2011 19:47:23 +0000 (21:47 +0200)]
p54usb: add zoom 4410 usbid
commit
9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream.
Reported-by: Mark Davis <marked86@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Keshava Munegowda [Mon, 16 May 2011 08:54:58 +0000 (14:24 +0530)]
mfd: Fix omap usbhs crash when rmmoding ehci or ohci
commit
6eb6fbbf3eca6dfba73e72de5ab2eeb52ae41f7a upstream.
The disabling of clocks and freeing GPIO are changed
to fix the occurrence of the crash of rmmod of ehci and ohci
drivers. The GPIOs should be freed after the spin locks are
unlocked.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kuninori Morimoto [Fri, 15 Apr 2011 07:44:27 +0000 (16:44 +0900)]
sh: fixup fpu.o compile order
commit
a375b15164dd9264f724ad941825e52c90145151 upstream.
arch_ptrace() was modified to reference init_fpu() to fix up xstate
initialization, which overlooked the fact that there are configurations
that don't enable any of hard FPU support or emulation, resulting in
build errors on DSP parts.
Given that init_fpu() simply sets up the xstate slab cache and is
side-stepped entirely for the DSP case, we can simply always build in the
helper and fix up the references.
Reported-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kuninori Morimoto [Thu, 14 Apr 2011 08:13:53 +0000 (17:13 +0900)]
sh: clkfwk: fixup clk_rate_table_build parameter in div6 clock
commit
52c10ad22b7e317960b4d411c9a9ddeaf3d5ae39 upstream.
div6 clock should not use arch_flags for clk_rate_table_build,
because SH_CLK_DIV6_EXT doesn't care .arch_flags.
clk->freq_table[] will be all CPUFREQ_ENTRY_INVALID without this patch.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Nieder [Sun, 1 May 2011 09:29:56 +0000 (06:29 -0300)]
cx88: hold device lock during sub-driver initialization
commit
1d6213ab995c61f7d1d81cf6cf876acf15d6e714 upstream.
cx8802_blackbird_probe makes a device node for the mpeg sub-device
before it has been added to dev->drvlist. If the device is opened
during that time, the open succeeds but request_acquire cannot be
called, so the reference count remains zero. Later, when the device
is closed, the reference count becomes negative --- uh oh.
Close the race by holding core->lock during probe and not releasing
until the device is in drvlist and initialization finished.
Previously the BKL prevented this race.
Reported-by: Andreas Huber <hobrom@gmx.at>
Tested-by: Andi Huber <hobrom@gmx.at>
Tested-by: Marlon de Boer <marlon@hyves.nl>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Nieder [Sun, 1 May 2011 09:29:37 +0000 (06:29 -0300)]
cx88: fix locking of sub-driver operations
commit
1fe70e963028f34ba5e32488a7870ff4b410b19b upstream.
The BKL conversion of this driver seems to have gone wrong.
Loading the cx88-blackbird driver deadlocks.
The cause: mpeg_ops::open in the cx2388x blackbird driver acquires the
device lock and calls the sub-driver's request_acquire, which tries to
acquire the lock again. Fix it by clarifying the semantics of
request_acquire, request_release, advise_acquire, and advise_release:
now all will rely on the caller to acquire the device lock.
Based on work by Ben Hutchings <ben@decadent.org.uk>.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=31962
Reported-by: Andi Huber <hobrom@gmx.at>
Tested-by: Andi Huber <hobrom@gmx.at>
Tested-by: Marlon de Boer <marlon@hyves.nl>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Nieder [Sun, 1 May 2011 09:29:16 +0000 (06:29 -0300)]
cx88: protect per-device driver list with device lock
commit
8a317a8760cfffa8185b56ff59fb4b6c58488d79 upstream.
The BKL conversion of this driver seems to have gone wrong. Various
uses of the sub-device and driver lists appear to be subject to race
conditions.
In particular, some functions access drvlist without a relevant lock
held, which will race against removal of drivers. Let's start with
that --- clean up by consistently protecting dev->drvlist with
dev->core->lock, noting driver functions that require the device lock
to be held or not to be held.
After this patch, there are still some races --- e.g.,
cx8802_blackbird_remove can run between the time the blackbird driver
is acquired and the time it is used in mpeg_release, and there's a
similar race in cx88_dvb_bus_ctrl. Later patches will address the
remaining known races and the deadlock noticed by Andi. This patch
just makes the semantics clearer in preparation for those later
changes.
Based on work by Ben Hutchings <ben@decadent.org.uk>.
Tested-by: Andi Huber <hobrom@gmx.at>
Tested-by: Marlon de Boer <marlon@hyves.nl>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Olivier Grenie [Tue, 3 May 2011 15:27:33 +0000 (12:27 -0300)]
DiBxxxx: get rid of DMA buffer on stack
commit
5a0deeed5741117ee8625d6305d0034e219f102c upstream.
This patch removes the remaining on-stack buffer for USB DMA transfer.
This patch also reduces the stack memory usage.
Cc: Florian Mickler <florian@mickler.org>
Signed-off-by: Olivier Grenie <olivier.grenie@dibcom.fr>
Signed-off-by: Patrick Boettcher <patrick.boettcher@dibcom.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Tue, 17 May 2011 21:27:12 +0000 (17:27 -0400)]
USB: remove remaining usages of hcd->state from usbcore and fix regression
commit
69fff59de4d844f8b4c2454c3c23d32b69dcbfd7 upstream.
This patch (as1467) removes the last usages of hcd->state from
usbcore. We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().
This fixes a regression introduced by commit
9b37596a2e860404503a3f2a6513db60c296bfdc (USB: move usbcore away from
hcd->state). It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped. The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped. The solution is to ignore HC_STATE_HALT
following the handler's return.
As a consequence of this change, several of the host controller
drivers need to be modified. They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.
The patch also changes a few of the interrupt handlers. They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive. Early returns were added to avoid any
confusion.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Mon, 16 May 2011 16:15:19 +0000 (12:15 -0400)]
OHCI: fix regression caused by nVidia shutdown workaround
commit
2b7aaf503d56216b847c8265421d2a7d9b42df3e upstream.
This patch (as1463) fixes a regression caused by commit
3df7169e73fc1d71a39cffeacc969f6840cdf52b (OHCI: work around for nVidia
shutdown problem).
The original problem encountered by people using NVIDIA chipsets was
that USB devices were not turning off when the system shut down. For
example, the LED on an optical mouse would remain on, draining a
laptop's battery. The problem was caused by a bug in the chipset; an
OHCI controller in the Reset state would continue to drive a bus reset
signal even after system shutdown. The workaround was to put the
controllers into the Suspend state instead.
It turns out that later NVIDIA chipsets do not suffer from this bug.
Instead some have the opposite bug: If a system is shut down while an
OHCI controller is in the Suspend state, USB devices remain powered!
On other systems, shutting down with a Suspended controller causes the
system to reboot immediately. Thus, working around the original bug
on some machines exposes other bugs on other machines.
The best solution seems to be to limit the workaround to OHCI
controllers with a low-numbered PCI product ID. I don't know exactly
at what point NVIDIA changed their chipsets; the value used here is a
guess. So far it was worked out okay for all the people who have
tested it.
This fixes Bugzilla #35032.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Yury Siamashka <yurand2@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marcin Gałczyński [Sun, 15 May 2011 09:41:54 +0000 (11:41 +0200)]
USB: option: add support for Huawei E353 device
commit
610ba42f29c3dfa46a05ff8c2cadc29f544ff76d upstream.
I am sharing patch to the devices/usb/serial/option.c. This allows
operation of Huawei E353 broadband modem using the “option” driver. The
patch simply adds new constant with proper product ID and an entry to
usb_device_id. I worked on the 2.6.38.6 sources. Tested on Dell inspiron
1764 (i3 core cpu) and brand new Huawei E353 modem, Fedora 15 beta.
Looking at the type of change, i doubt it has potential to introduce
problems in other parts of kernel or the driver itself.
Signed-off-by: Marcin Galczynski <marcin@galczynski.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Fri, 13 May 2011 01:06:37 +0000 (18:06 -0700)]
xhci: Fix memory leak bug when dropping endpoints
commit
834cb0fc4712a3b21c6b8c5cb55bd13607191311 upstream.
When the USB core wants to change to an alternate interface setting that
doesn't include an active endpoint, or de-configuring the device, the xHCI
driver needs to issue a Configure Endpoint command to tell the host to
drop some endpoints from the schedule. After the command completes, the
xHCI driver needs to free rings for any endpoints that were dropped.
Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
for dropped endpoints. The rings would be freed if the endpoint's
information was simply changed (and a new ring was installed), but dropped
endpoints never had their rings freed. This caused errors when the ring
segment DMA pool was freed when the xHCI driver was unloaded:
[ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments,
ffff88003371d000 busy
[ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments,
ffff880033716000 busy
[ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments,
ffff880033455000 busy
[ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
[ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
[ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
[ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
[ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
[ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
[ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled
Fix this issue and free endpoint rings when their endpoints are
successfully dropped.
This patch should be backported to kernels as old as 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Mon, 16 May 2011 20:09:08 +0000 (13:09 -0700)]
xhci: Fix memory leak in ring cache deallocation.
commit
30f89ca021c3e584b61bc5a14eede89f74b2e826 upstream.
When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full. If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented. The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.
Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0. This was caused by the second assignment to rings_cached:
rings_cached = virt_dev->num_rings_cached;
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
virt_dev->num_rings_cached++;
rings_cached = virt_dev->num_rings_cached;
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed. When the driver was unloaded, this caused interesting messages
like:
xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments,
ffff880063040000 busy
This should be queued to stable kernels back to 2.6.33.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Fri, 13 May 2011 20:10:01 +0000 (13:10 -0700)]
xhci: Fix full speed bInterval encoding.
commit
b513d44751bfb609a3c20463f764c8ce822d63e9 upstream.
Dmitry's patch
dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev
ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev
ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Felipe Balbi [Fri, 13 May 2011 13:53:48 +0000 (16:53 +0300)]
usb: gadget: rndis: don't test against req->length
commit
472b91274a6c6857877b5caddb875dcb5ecdfcb8 upstream.
composite.c always sets req->length to zero
and expects function driver's setup handlers
to return the amount of bytes to be used
on req->length. If we test against req->length
w_length will always be greater than req->length
thus making us always stall that particular
SEND_ENCAPSULATED_COMMAND request.
Tested against a Windows XP SP3.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean-Christophe PLAGNIOL-VILLARD [Fri, 13 May 2011 15:03:02 +0000 (17:03 +0200)]
usb/gadget: at91sam9g20 fix end point max packet size
commit
bf1f0a05d472e33dda8e5e69525be1584cdbd03a upstream.
on 9g20 they are the same as the 9260
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Sarah Sharp [Fri, 6 May 2011 02:08:09 +0000 (19:08 -0700)]
xhci: Fix bug in control transfer cancellation.
commit
3abeca998a44205cfd837fa0bf1f7c24f8294acb upstream.
When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing. The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs). The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.
Unfortunately, there is a long-standing bug in the control transfer
completion code. It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed. So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel. It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs. Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.
It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior. Fix this
behavior.
This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Erik Slagter [Wed, 11 May 2011 10:06:55 +0000 (12:06 +0200)]
USB: cdc_acm: Fix oops when Droids MuIn LCD is connected
commit
fd5054c169d29747a44b4e1419ff47f57ae82dbc upstream.
The Droids MuIn LCD operates like a serial remote terminal.
Data received are displayed directly on the LCD. This patch
fixes the kernel null pointer oops when it is plugged in.
Add NO_DATA_INTERFACE quirk to tell the driver that "control"
and "data" interfaces are not separated for this device, which
prevents dereferencing a null pointer in the device probe code.
Signed-off-by: Erik Slagter <erik@slagter.name>
Signed-off-by: Maxin B. John <maxin.john@gmail.com>
Tested-by: Erik Slagter <erik@slagter.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Marius B. Kotsbak [Mon, 21 Mar 2011 22:27:21 +0000 (23:27 +0100)]
Bind only modem AT command endpoint to option module.
commit
15b2f3204a5c878c32939094775fb7349f707263 upstream.
Network interface is handled by upcoming gt_b3730 module.
Removed "GT-B3710" from comment, it is another modem with another USB ID.
Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hermann Kneissel [Fri, 29 Apr 2011 06:58:43 +0000 (08:58 +0200)]
USB: gamin_gps: Fix for data transfer problems in native mode
commit
b4026c4584cd70858d4d3450abfb1cd0714d4f32 upstream.
This patch fixes a problem where data received from the gps is sometimes
transferred incompletely to the serial port. If used in native mode now
all data received via the bulk queue will be forwarded to the serial
port.
Signed-off-by: Hermann Kneissel <herkne@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Michal Nazarewicz [Tue, 26 Apr 2011 17:08:36 +0000 (19:08 +0200)]
USB: gadget: g_multi: fixed vendor and product ID in inf files
commit
7701846fd52f86dffe50715e0e63154088b7c982 upstream.
Commit
1c6529e92b "USB: gadget: g_multi: fixed vendor and
product ID" replaced g_multi's vendor and product ID with
proper ID's from Linux Foundation. This commit now updates
INF files in the Documentation/usb directory which were
omitted in the original commit.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Benedek László [Wed, 20 Apr 2011 01:22:21 +0000 (03:22 +0200)]
USB: serial: ftdi_sio: adding support for TavIR STK500
commit
37909fe588c9e09ab57cd267e98678a17ceda64a upstream.
Adding support for the TavIR STK500 (id 0403:FA33)
Atmel AVR programmer device based on FTDI FT232RL.
Signed-off-by: Benedek László <benedekl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Elizabeth Jennifer Myers [Sat, 16 Apr 2011 18:49:51 +0000 (14:49 -0400)]
USB: moto_modem: Add USB identifier for the Motorola VE240.
commit
3938a0b32dc12229e76735679b37095bc2bc1578 upstream.
Tested on my phone, the ttyUSB device is created and is fully
functional.
Signed-off-by: Elizabeth Jennifer Myers <elizabeth@sporksirc.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Craig Shelley [Sun, 20 Mar 2011 13:51:13 +0000 (13:51 +0000)]
USB: CP210x Add 4 Device IDs for AC-Services Devices
commit
4eff0b40a7174896b860312910e0db51f2dcc567 upstream.
This patch adds 4 device IDs for CP2102 based devices manufactured by
AC-Services. See http://www.ac-services.eu for further info.
Signed-off-by: Craig Shelley <craig@microtron.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Vikram Narayanan [Tue, 24 May 2011 18:58:48 +0000 (20:58 +0200)]
i2c/writing-clients: Fix foo_driver.id_table
commit
3116c86033079a1d4d4e84c40028f96b614843b8 upstream.
The i2c_device_id structure variable's name is not used in the
i2c_driver structure.
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Kenneth Waters [Mon, 25 Apr 2011 18:29:54 +0000 (12:29 -0600)]
i2c: tegra: Enable new slave mode.
commit
65a1a0ace554d61ea5a90377a54df1505275c1b1 upstream.
For Tegra i2c controller to function properly new slave mode must be
enabled.
swarren notes:
In particular, I found this was needed when working on enabling the
Tegra audio driver on the Seaboard board. There are two different PCB
layouts for this board; a "clamshell" version, which works just fine
without this change, and the original non-clamshell version, which needs
this change in order for I2C to operate correctly. Without it, I2C
probing fails for some devices, e.g. with:
wm8903 0-001a: Device with ID register 0 is not a WM8903
wm8903 0-001a: asoc: failed to probe CODEC wm8903.0-001a: -19
asoc: failed to instantiate card tegra-wm8903: -19
ALSA device list:
No soundcards found.
Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Tue, 24 May 2011 14:48:55 +0000 (16:48 +0200)]
loop: handle on-demand devices correctly
commit
a1c15c59feee36267c43142a41152fbf7402afb6 upstream.
When finding or allocating a loop device, loop_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example:
$ sudo modprobe loop max_part=15
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
$ sudo mknod /dev/loop8 b 7 128
$ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img
$ sudo losetup -a
/dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img)
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7, 0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7, 16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128
brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1
brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2
brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3
brw-rw---- 1 root disk 7, 32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7, 48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7, 64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7, 80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7, 96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
brw-r--r-- 1 root root 7, 128 2011-05-24 22:17 /dev/loop8
After this patch, /dev/loop8 - instead of /dev/loop128 - was
accessed correctly.
In addition, 'range' passed to blk_register_region() should
include all range of dev_t that LOOP_MAJOR can address. It does
not need to be limited by partition numbers unless 'max_loop'
param was specified.
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Namhyung Kim [Tue, 24 May 2011 14:48:54 +0000 (16:48 +0200)]
loop: limit 'max_part' module param to DISK_MAX_PARTS
commit
78f4bb367fd147a0e7e3998ba6e47109999d8814 upstream.
The 'max_part' parameter controls the number of maximum partition
a loop block device can have. However if a user specifies very
large value it would exceed the limitation of device minor number
and can cause a kernel panic (or, at least, produce invalid
device nodes in some cases).
On my desktop system, following command kills the kernel. On qemu,
it triggers similar oops but the kernel was alive:
$ sudo modprobe loop max_part0000
------------[ cut here ]------------
kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
invalid opcode: 0000 [#1] SMP
last sysfs file:
CPU 0
Modules linked in: loop(+)
Pid: 43, comm: insmod Tainted: G W 2.6.39-qemu+ #155 Bochs Bochs
RIP: 0010:[<
ffffffff8113ce61>] [<
ffffffff8113ce61>] internal_create_group=
+0x2a/0x170
RSP: 0018:
ffff880007b3fde8 EFLAGS:
00000246
RAX:
00000000ffffffef RBX:
ffff880007b3d878 RCX:
00000000000007b4
RDX:
ffffffff8152da50 RSI:
0000000000000000 RDI:
ffff880007b3d878
RBP:
ffff880007b3fe38 R08:
ffff880007b3fde8 R09:
0000000000000000
R10:
ffff88000783b4a8 R11:
ffff880007b3d878 R12:
ffffffff8152da50
R13:
ffff880007b3d868 R14:
0000000000000000 R15:
ffff880007b3d800
FS:
0000000002137880(0063) GS:
ffff880007c00000(0000) knlGS:
00000000000000=
00
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000422680 CR3:
0000000007b50000 CR4:
00000000000006b0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
0000000000000000 DR7:
0000000000000000
Process insmod (pid: 43, threadinfo
ffff880007b3e000, task
ffff880007afb9c=
0)
Stack:
ffff880007b3fe58 ffffffff811e66dd ffff880007b3fe58 ffffffff811e570b
0000000000000010 ffff880007b3d800 ffff880007a7b390 ffff880007b3d868
0000000000400920 ffff880007b3d800 ffff880007b3fe48 ffffffff8113cfc8
Call Trace:
[<
ffffffff811e66dd>] ? device_add+0x4bc/0x5af
[<
ffffffff811e570b>] ? dev_set_name+0x3c/0x3e
[<
ffffffff8113cfc8>] sysfs_create_group+0xe/0x12
[<
ffffffff810b420e>] blk_trace_init_sysfs+0x14/0x16
[<
ffffffff8116a090>] blk_register_queue+0x47/0xf7
[<
ffffffff8116f527>] add_disk+0xdf/0x290
[<
ffffffffa00060eb>] loop_init+0xeb/0x1b8 [loop]
[<
ffffffffa0006000>] ? 0xffffffffa0005fff
[<
ffffffff8100020a>] do_one_initcall+0x7a/0x12e
[<
ffffffff81096804>] sys_init_module+0x9c/0x1e0
[<
ffffffff813329bb>] system_call_fastpath+0x16/0x1b
Code: c3 55 48 89 e5 41 57 41 56 41 89 f6 41 55 41 54 49 89 d4 53 48 89 fb=
48 83 ec 28 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe =
48 83 7f 30 00 b9 ea ff ff ff 0f 84 18 01 00 00 49
RIP [<
ffffffff8113ce61>] internal_create_group+0x2a/0x170
RSP <
ffff880007b3fde8>
---[ end trace
a123eb592043acad ]---
Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Barry [Wed, 25 May 2011 00:12:52 +0000 (17:12 -0700)]
mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath()
commit
cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream.
I believe I found a problem in __alloc_pages_slowpath, which allows a
process to get stuck endlessly looping, even when lots of memory is
available.
Running an I/O and memory intensive stress-test I see a 0-order page
allocation with __GFP_IO and __GFP_WAIT, running on a system with very
little free memory. Right about the same time that the stress-test gets
killed by the OOM-killer, the utility trying to allocate memory gets stuck
in __alloc_pages_slowpath even though most of the systems memory was freed
by the oom-kill of the stress-test.
The utility ends up looping from the rebalance label down through the
wait_iff_congested continiously. Because order=0,
__alloc_pages_direct_compact skips the call to get_page_from_freelist.
Because all of the reclaimable memory on the system has already been
reclaimed, __alloc_pages_direct_reclaim skips the call to
get_page_from_freelist. Since there is no __GFP_FS flag, the block with
__alloc_pages_may_oom is skipped. The loop hits the wait_iff_congested,
then jumps back to rebalance without ever trying to
get_page_from_freelist. This loop repeats infinitely.
The test case is pretty pathological. Running a mix of I/O stress-tests
that do a lot of fork() and consume all of the system memory, I can pretty
reliably hit this on 600 nodes, in about 12 hours. 32GB/node.
Signed-off-by: Andrew Barry <abarry@cray.com>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: Rik van Riel<riel@redhat.com>
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@suse.de>
Jiri Kosina [Thu, 19 May 2011 15:58:07 +0000 (17:58 +0200)]
HID: magicmouse: ignore 'ivalid report id' while switching modes
commit
23746a66d7d9e73402c68ef00d708796b97ebd72 upstream.
The device reponds with 'invalid report id' when feature report switching it
into multitouch mode is sent to it.
This has been silently ignored before
0825411ade ("HID: bt: Wait for ACK
on Sent Reports"), but since this commit, it propagates -EIO from the _raw
callback .
So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's
how the device reacts in normal mode.
Sad, but following reality.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022
Tested-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Mack [Tue, 24 May 2011 12:10:32 +0000 (14:10 +0200)]
ASoC: fix raumfeld platform
commit
477a66948ef8683f182682cc68e8520baf8a5b43 upstream.
Commit
f0fba2ad (ASoC: multi-component - ASoC Multi-Component Support)
broke support for Raumfeld platforms as it didn't take into account the
different hardware features on individual devices.
In particular, Raumfeld speakers have no S/PDIF output, so the members
of the snd_soc_card struct must be set dynamically.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Sun, 15 May 2011 19:18:38 +0000 (12:18 -0700)]
ASoC: Add some missing volume update bit sets for wm_hubs devices
commit
fb5af53d421d80725172427e9076f6e889603df6 upstream.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mark Brown [Sun, 15 May 2011 00:21:28 +0000 (17:21 -0700)]
ASoC: Ensure output PGA is enabled for line outputs in wm_hubs
commit
d0b48af6c2b887354d0893e598d92911ce52620e upstream.
Also fix a left/right typo while we're at it.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Takashi Iwai [Fri, 20 May 2011 14:29:09 +0000 (16:29 +0200)]
ALSA: hda - Use LPIB for ATI/AMD chipsets as default
commit
50e3bbf9898840eead86f90a43b3625a2b2f4112 upstream.
ATI and AMD chipsets seem not providing the proper position-buffer
information, and it also doesn't provide FIFO register required by
VIACOMBO fix. It's better to use LPIB for these.
Reported-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Adrian Wilkins [Thu, 19 May 2011 20:52:38 +0000 (21:52 +0100)]
ALSA: hda - Fix input-src parse in patch_analog.c
commit
5a2d227fdc7a02ed1b4cebba391d8fb9ad57caaf upstream.
Compare pin type enum to the pin type and not the array index.
Fixes bug#
0005368.
Signed-off-by: Adrian Wilkins <adrian.wilkins@nhs.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Henningsson [Mon, 23 May 2011 06:26:16 +0000 (08:26 +0200)]
ALSA: HDA: Add quirk for Lenovo U350
commit
d2859fd49200f1f3efd8acdb54b6d51d3ab82302 upstream.
Add model=asus quirk for Lenovo Ideapad U350 to make internal mic
work correctly.
BugLink: http://bugs.launchpad.net/bugs/751681
Reported-by: Kent Baxley <kent.baxley@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Henningsson [Mon, 16 May 2011 10:09:29 +0000 (12:09 +0200)]
ALSA: HDA: Use one dmic only for Dell Studio 1558
commit
e033ebfb399227e01686260ac271029011bc6b47 upstream.
There are no signs of a dmic at node 0x0b, so the user is left with
an additional internal mic which does not exist. This commit removes
that non-existing mic.
BugLink: http://bugs.launchpad.net/bugs/731706
Reported-by: James Page <james.page@canonical.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>