summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2011-06-26dcdbas: force SMI to happen when expectedStuart Hayes1-1/+3
commit dd65c736d1b5312c80c88a64bf521db4959eded5 upstream. The dcdbas driver can do an I/O write to cause a SMI to occur. The SMI handler looks at certain registers and memory locations, so the SMI needs to happen immediately. On some systems I/O writes are posted, though, causing the SMI to happen well after the "outb" occurred, which causes random failures. Following the "outb" with an "inb" forces the write to go through even if it is posted. Signed-off-by: Stuart Hayes <stuart_hayes@yahoo.com> Acked-by: Doug Warzecha <douglas_warzecha@dell.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26agp: fix OOM and buffer overflowVasiliy Kulikov1-1/+7
commit b522f02184b413955f3bc952e3776ce41edc6355 upstream. page_count is copied from userspace. agp_allocate_memory() tries to check whether this number is too big, but doesn't take into account the wrap case. Also agp_create_user_memory() doesn't check whether alloc_size is calculated from num_agp_pages variable without overflow. This may lead to allocation of too small buffer with following buffer overflow. Another problem in agp code is not addressed in the patch - kernel memory exhaustion (AGPIOC_RESERVE and AGPIOC_ALLOCATE ioctls). It is not checked whether requested pid is a pid of the caller (no check in agpioc_reserve_wrap()). Each allocation is limited to 16KB, though, there is no per-process limit. This might lead to OOM situation, which is not even solved in case of the caller death by OOM killer - the memory is allocated for another (faked) process. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26agp: fix arbitrary kernel memory writesVasiliy Kulikov1-3/+8
commit 194b3da873fd334ef183806db751473512af29ce upstream. pg_start is copied from userspace on AGPIOC_BIND and AGPIOC_UNBIND ioctl cmds of agp_ioctl() and passed to agpioc_bind_wrap(). As said in the comment, (pg_start + mem->page_count) may wrap in case of AGPIOC_BIND, and it is not checked at all in case of AGPIOC_UNBIND. As a result, user with sufficient privileges (usually "video" group) may generate either local DoS or privilege escalation. Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26mpt2sas: prevent heap overflows and unchecked readsDan Rosenberg1-2/+21
commit a1f74ae82d133ebb2aabb19d181944b4e83e9960 upstream. At two points in handling device ioctls via /dev/mpt2ctl, user-supplied length values are used to copy data from userspace into heap buffers without bounds checking, allowing controllable heap corruption and subsequently privilege escalation. Additionally, user-supplied values are used to determine the size of a copy_to_user() as well as the offset into the buffer to be read, with no bounds checking, allowing users to read arbitrary kernel memory. Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com> Acked-by: Eric Moore <eric.moore@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26PCI: return correct value when writing to the "reset" attributeMichal Schmidt1-1/+6
commit 447c5dd7338638f526e9bcf7dcf69b4da5835c7d upstream. A successful write() to the "reset" sysfs attribute should return the number of bytes written, not 0. Otherwise userspace (bash) retries the write over and over again. Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Michal Schmidt <mschmidt@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26fbcon: Bugfix soft cursor detection in Tile BlittingHenry Nestler1-1/+1
commit d6244bc0ed0c52a795e6f4dcab3886daf3e74fac upstream. Use mask 0x10 for "soft cursor" detection on in function tile_cursor. (Tile Blitting Operation in framebuffer console). The old mask 0x01 for vc_cursor_type detects CUR_NONE, CUR_LOWER_THIRD and every second mode value as "software cursor". This hides the cursor for these modes (cursor.mode = 0). But, only CUR_NONE or "software cursor" should hide the cursor. See also 0x10 in functions add_softcursor, bit_cursor and cw_cursor. Signed-off-by: Henry Nestler <henry.nestler@gmail.com> Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26uvcvideo: Fix uvc_fixup_video_ctrl() format searchStephan Lachowsky1-5/+9
commit 38a66824d96de8aeeb915e6f46f0d3fe55828eb1 upstream. The scheme used to index format in uvc_fixup_video_ctrl() is not robust: format index is based on descriptor ordering, which does not necessarily match bFormatIndex ordering. Searching for first matching format will prevent uvc_fixup_video_ctrl() from using the wrong format/frame to make adjustments. Signed-off-by: Stephan Lachowsky <stephan.lachowsky@maxim-ic.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26ehci-hcd: Bug fix: don't set a QH's Halt bitAlan Stern1-12/+0
commit b5a3b3d985493c173925907adfebf3edab236fe7 upstream. This patch (as1453) fixes a long-standing bug in the ehci-hcd driver. There is no need to set the Halt bit in the overlay region for an unlinked or blocked QH. Contrary to what the comment says, setting the Halt bit does not cause the QH to be patched later; that decision (made in qh_refresh()) depends only on whether the QH is currently pointing to a valid qTD. Likewise, setting the Halt bit does not prevent completions from activating the QH while it is "stopped"; they are prevented by the fact that qh_completions() temporarily changes qh->qh_state to QH_STATE_COMPLETING. On the other hand, there are circumstances in which the QH will be reactivated _without_ being patched; this happens after an URB beyond the head of the queue is unlinked. Setting the Halt bit will then cause the hardware to see the QH with both the Active and Halt bits set, an invalid combination that will prevent the queue from advancing and may even crash some controllers. Apparently the only reason this hasn't been reported before is that unlinking URBs from the middle of a running queue is quite uncommon. However Test 17, recently added to the usbtest driver, does exactly this, and it confirms the presence of the bug. In short, there is no reason to set the Halt bit for an unlinked or blocked QH, and there is a very good reason not to set it. Therefore the code that sets it is removed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Andiry Xu <andiry.xu@amd.com> CC: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26USB: uss720 fixup refcount positionPeter Holik1-4/+3
commit adaa3c6342b249548ea830fe8e02aa5b45be8688 upstream. My testprog do a lot of bitbang - after hours i got following warning and my machine lockups: WARNING: at /build/buildd/linux-2.6.38/lib/kref.c:34 After debugging uss720 driver i discovered that the completion callback was called before usb_submit_urb returns. The callback frees the request structure that is krefed on return by usb_submit_urb. Signed-off-by: Peter Holik <peter@holik.at> Acked-by: Thomas Sailer <t.sailer@alumni.ethz.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26USB: cdc-acm: fix memory corruption / panicJohan Hovold1-0/+2
commit 23b80550e2aa61d0ba3af98b831b9195be0db9ee upstream. Prevent read urbs from being resubmitted from tasklet after port close. The receive tasklet was not disabled on port close, which could lead to corruption of receive lists on consecutive port open. In particular, read urbs could be re-submitted before port open, added to free list in open, and then added a second time to the free list in the completion handler. cdc-acm.c: Entering acm_tty_open. cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0 cdc-acm.c: Entering acm_rx_tasklet cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64 cdc-acm.c: set line: 115200 0 0 8 cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7 cdc-acm.c: acm_tty_close cdc-acm.c: acm_port_down cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0 cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50 cdc-acm.c: Entering acm_read_bulk with status -2 cdc_acm 4-1:1.1: Aborting, acm not ready cdc-acm.c: Entering acm_read_bulk with status -2 cdc_acm 4-1:1.1: Aborting, acm not ready cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da400, rcv 0xf57fbbe8, buf 0xf57fbd28 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da480, rcv 0xf57fbbd4, buf 0xf57fbd14 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da900, rcv 0xf57fbbc0, buf 0xf57fbd00 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da980, rcv 0xf57fbbac, buf 0xf57fbcec cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa00, rcv 0xf57fbb98, buf 0xf57fbcd8 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa80, rcv 0xf57fbb84, buf 0xf57fbcc4 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab00, rcv 0xf57fbb70, buf 0xf57fbcb0 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab80, rcv 0xf57fbb5c, buf 0xf57fbc9c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac00, rcv 0xf57fbb48, buf 0xf57fbc88 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac80, rcv 0xf57fbb34, buf 0xf57fbc74 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad00, rcv 0xf57fbb20, buf 0xf57fbc60 cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad80, rcv 0xf57fbb0c, buf 0xf57fbc4c cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da880, rcv 0xf57fbaf8, buf 0xf57fbc38 cdc-acm.c: Entering acm_tty_open. cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0 cdc-acm.c: Entering acm_rx_tasklet cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64 cdc-acm.c: Entering acm_tty_write to write 3 bytes, cdc-acm.c: Get 3 bytes... cdc-acm.c: acm_write_start susp_count: 0 cdc-acm.c: Entering acm_read_bulk with status 0 ------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120() Hardware name: Vostro 1520 list_del corruption. next->prev should be f57fbc10, but was f57fbaf8 Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd8ac>] list_del+0x10c/0x120 [<f8051dbf>] acm_rx_tasklet+0xef/0x3e0 [cdc_acm] [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f0082e ]--- ------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120() Hardware name: Vostro 1520 list_del corruption. next->prev should be f57fbd50, but was f57fbdb0 Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c11dd8ac>] ? list_del+0x10c/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd8ac>] list_del+0x10c/0x120 [<f8051dd6>] acm_rx_tasklet+0x106/0x3e0 [cdc_acm] [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f0082f ]--- cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50 cdc-acm.c: disconnected from network cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c cdc-acm.c: Entering acm_rx_tasklet ------------[ cut here ]------------ WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:48 list_del+0xd5/0x120() Hardware name: Vostro 1520 list_del corruption, next is LIST_POISON1 (00100100) Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 Call Trace: [<c103c7e2>] warn_slowpath_common+0x72/0xa0 [<c11dd875>] ? list_del+0xd5/0x120 [<c11dd875>] ? list_del+0xd5/0x120 [<c103c8b3>] warn_slowpath_fmt+0x33/0x40 [<c11dd875>] list_del+0xd5/0x120 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 ---[ end trace efd9a11434f00830 ]--- BUG: unable to handle kernel paging request at 00200200 IP: [<c11dd7bd>] list_del+0x1d/0x120 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/tty/ttyACM0/uevent Modules linked in: cdc_acm Pid: 3, comm: ksoftirqd/0 Tainted: G W 2.6.37+ #39 0T816J/Vostro 1520 EIP: 0060:[<c11dd7bd>] EFLAGS: 00010046 CPU: 0 EIP is at list_del+0x1d/0x120 EAX: f57fbd3c EBX: f57fb800 ECX: ffff8000 EDX: 00200200 ESI: f57fbe90 EDI: f57fbd3c EBP: f600bf54 ESP: f600bf3c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process ksoftirqd/0 (pid: 3, ti=f600a000 task=f60791c0 task.ti=f6082000) Stack: c1527e84 00000030 c1527e54 00100100 f57fb800 f57fbd3c f600bf98 f8051fac f8053104 f8052b94 f600bf6c c106dbab f600bf80 00000286 f60791c0 c1042b30 f57fbda8 f57f5800 f57fbdb0 f57fbd80 f57fbe7c c1656b04 00000000 f600bfb0 Call Trace: [<f8051fac>] ? acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] ? tasklet_action+0xe6/0x140 [<c104342f>] ? __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 Code: ff 48 14 e9 57 ff ff ff 90 90 90 90 90 90 55 89 e5 83 ec 18 81 38 00 01 10 00 0f 84 9c 00 00 00 8b 50 04 81 fa 00 02 20 00 74 33 <8b> 12 39 d0 75 5c 8b 10 8b 4a 04 39 c8 0f 85 b5 00 00 00 8b 48 EIP: [<c11dd7bd>] list_del+0x1d/0x120 SS:ESP 0068:f600bf3c CR2: 0000000000200200 ---[ end trace efd9a11434f00831 ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 3, comm: ksoftirqd/0 Tainted: G D W 2.6.37+ #39 Call Trace: [<c13fede1>] ? printk+0x1d/0x24 [<c13fecce>] panic+0x66/0x15c [<c10067df>] oops_end+0x8f/0x90 [<c1025476>] no_context+0xc6/0x160 [<c10255a8>] __bad_area_nosemaphore+0x98/0x140 [<c103cf68>] ? release_console_sem+0x1d8/0x210 [<c1025667>] bad_area_nosemaphore+0x17/0x20 [<c1025a49>] do_page_fault+0x279/0x420 [<c1006a8f>] ? show_trace+0x1f/0x30 [<c13fede1>] ? printk+0x1d/0x24 [<c10257d0>] ? do_page_fault+0x0/0x420 [<c140333b>] error_code+0x5f/0x64 [<c103007b>] ? select_task_rq_fair+0x37b/0x6a0 [<c10257d0>] ? do_page_fault+0x0/0x420 [<c11dd7bd>] ? list_del+0x1d/0x120 [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm] [<c106dbab>] ? trace_hardirqs_on+0xb/0x10 [<c1042b30>] ? tasklet_action+0x60/0x140 [<c1042bb6>] tasklet_action+0xe6/0x140 [<c104342f>] __do_softirq+0xaf/0x210 [<c1043380>] ? __do_softirq+0x0/0x210 <IRQ> [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0 [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0 [<c105ac24>] ? kthread+0x74/0x80 [<c105abb0>] ? kthread+0x0/0x80 [<c100337a>] ? kernel_thread_helper+0x6/0x10 panic occurred, switching back to text console ------------[ cut here ]------------ Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26USB: cdc-acm: fix potential null-pointer dereferenceJohan Hovold1-0/+2
commit 15e5bee33ffc11d0e5c6f819a65e7881c5c407be upstream. Must check return value of tty_port_tty_get. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26USB: cdc-acm: fix potential null-pointer dereference on disconnectJohan Hovold1-1/+2
commit 7e7797e7f6f7bfab73fca02c65e40eaa5bb9000c upstream. Fix potential null-pointer exception on disconnect introduced by commit 11ea859d64b69a747d6b060b9ed1520eab1161fe (USB: additional power savings for cdc-acm devices that support remote wakeup). Only access acm->dev after making sure it is non-null in control urb completion handler. Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26Input: xen-kbdfront - fix mouse getting stuck after save/restoreIgor Mammedov1-1/+12
commit c36b58e8a9112017c2bcc322cc98e71241814303 upstream. Mouse gets "stuck" after restore of PV guest but buttons are in working condition. If driver has been configured for ABS coordinates at start it will get XENKBD_TYPE_POS events and then suddenly after restore it'll start getting XENKBD_TYPE_MOTION events, that will be dropped later and they won't get into user-space. Regression was introduced by hunk 5 and 6 of 5ea5254aa0ad269cfbd2875c973ef25ab5b5e9db ("Input: xen-kbdfront - advertise either absolute or relative coordinates"). Driver on restore should ask xen for request-abs-pointer again if it is available. So restore parts that did it before 5ea5254. Acked-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Igor Mammedov <imammedo@redhat.com> [v1: Expanded the commit description] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26Input: xen-kbdfront - advertise either absolute or relative coordinatesOlaf Hering1-21/+24
commit 8c3c283e6bf463ab498d6e7823aff6c4762314b6 upstream. A virtualized display device is usually viewed with the vncviewer application, either by 'xm vnc domU' or with vncviewer localhost:port. vncviewer and the RFB protocol provides absolute coordinates to the virtual display. These coordinates are either passed through to a PV guest or converted to relative coordinates for a HVM guest. A PV guest receives these coordinates and passes them to the kernels evdev driver. There it can be picked up by applications such as the xorg-input drivers. Using absolute coordinates avoids issues such as guest mouse pointer not tracking host mouse pointer due to wrong mouse acceleration settings in the guests X display. Advertise either absolute or relative coordinates to the input system and the evdev driver, depending on what dom0 provides. The xorg-input driver prefers relative coordinates even if a devices provides both. Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26hwmon: (sht15) Fix integer overflow in humidity calculationVivien Didelot1-2/+2
commit ccd32e735de7a941906e093f8dca924bb05c5794 upstream. An integer overflow occurs in the calculation of RHlinear when the relative humidity is greater than around 30%. The consequence is a subtle (but noticeable) error in the resulting humidity measurement. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Cc: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26mmc: sdio: remember new card RCA when redetecting cardStefan Nilsson XK1-0/+8
commit 0aab3995485b8a994bf29a995a008c9ea4a28054 upstream. During redetection of a SDIO card, a request for a new card RCA was submitted to the card, but was then overwritten by the old RCA. This caused the card to be deselected instead of selected when using the incorrect RCA. This bug's been present since the "oldcard" handling was introduced in 2.6.32. Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com> Reviewed-by: Ulf Hansson <ulf.hansson@stericsson.com> Reviewed-by: Pawel Wieczorkiewicz <pawel.wieczorkiewicz@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26isdn: avoid calling tty_ldisc_flush() in atomic contextTilman Schmidt1-6/+0
commit bc10f96757bd6ab3721510df8defa8f21c32f974 upstream. Remove the call to tty_ldisc_flush() from the RESULT_NO_CARRIER branch of isdn_tty_modem_result(), as already proposed in commit 00409bb045887ec5e7b9e351bc080c38ab6bfd33. This avoids a "sleeping function called from invalid context" BUG when the hardware driver calls the statcallb() callback with command==ISDN_STAT_DHUP in atomic context, which in turn calls isdn_tty_modem_result(RESULT_NO_CARRIER, ~), and from there, tty_ldisc_flush() which may sleep. Signed-off-by: Tilman Schmidt <tilman@imap.cc> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26PCI: sysfs: Fix failure path for addition of "vpd" attributeBen Hutchings1-1/+1
commit 0f12a4e29368a9476076515881d9ef4e5876c6e2 upstream. Commit 280c73d ("PCI: centralize the capabilities code in pci-sysfs.c") changed the initialisation of the "rom" and "vpd" attributes, and made the failure path for the "vpd" attribute incorrect. We must free the new attribute structure (attr), but instead we currently free dev->vpd->attr. That will normally be NULL, resulting in a memory leak, but it might be a stale pointer, resulting in a double-free. Found by inspection; compile-tested only. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICHJiri Slaby1-8/+24
commit 87e3dc3855430bd254370afc79f2ed92250f5b7c upstream. Some broken BIOSes on ICH4 chipset report an ACPI region which is in conflict with legacy IDE ports when ACPI is disabled. Even though the regions overlap, IDE ports are working correctly (we cannot find out the decoding rules on chipsets). So the only problem is the reported region itself, if we don't reserve the region in the quirk everything works as expected. This patch avoids reserving any quirk regions below PCIBIOS_MIN_IO which is 0x1000. Some regions might be (and are by a fast google query) below this border, but the only difference is that they won't be reserved anymore. They should still work though the same as before. The conflicts look like (1f.0 is bridge, 1f.1 is IDE ctrl): pci 0000:00:1f.1: address space collision: [io 0x0170-0x0177] conflicts with 0000:00:1f.0 [io 0x0100-0x017f] At 0x0100 a 128 bytes long ACPI region is reported in the quirk for ICH4. ata_piix then fails to find disks because the IDE legacy ports are zeroed: ata_piix 0000:00:1f.1: device not available (can't reserve [io 0x0000-0x0007]) References: https://bugzilla.novell.com/show_bug.cgi?id=558740 Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26PCI: add more checking to ICH region quirksJiri Slaby1-8/+37
commit cdb9755849fbaf2bb9c0a009ba5baa817a0f152d upstream. Per ICH4 and ICH6 specs, ACPI and GPIO regions are valid iff ACPI_EN and GPIO_EN bits are set to 1. Add checks for these bits into the quirks prior to the region creation. While at it, name the constants by macros. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26PCI: remove quirk for pre-production systemsBrandeburg, Jesse1-52/+0
commit b99af4b002e4908d1a5cdaf424529bdf1dc69768 upstream. Revert commit 7eb93b175d4de9438a4b0af3a94a112cb5266944 Author: Yu Zhao <yu.zhao@intel.com> Date: Fri Apr 3 15:18:11 2009 +0800 PCI: SR-IOV quirk for Intel 82576 NIC If BIOS doesn't allocate resources for the SR-IOV BARs, zero the Flash BAR and program the SR-IOV BARs to use the old Flash Memory Space. Please refer to Intel 82576 Gigabit Ethernet Controller Datasheet section 7.9.2.14.2 for details. http://download.intel.com/design/network/datashts/82576_Datasheet.pdf Signed-off-by: Yu Zhao <yu.zhao@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> This quirk was added before SR-IOV was in production and now all machines that originally had this issue alreayd have bios updates to correct the issue. The quirk itself is no longer needed and in fact causes bugs if run. Remove it. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> CC: Yu Zhao <yu.zhao@intel.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26xhci: Fix cycle bit calculation during stall handling.Sarah Sharp1-0/+14
commit 01a1fdb9a7afa5e3c14c9316d6f380732750b4e4 upstream. When an endpoint stalls, we need to update the xHCI host's internal dequeue pointer to move it past the stalled transfer. This includes updating the cycle bit (TRB ownership bit) if we have moved the dequeue pointer past a link TRB with the toggle cycle bit set. When we're trying to find the new dequeue segment, find_trb_seg() is supposed to keep track of whether we've passed any link TRBs with the toggle cycle bit set. However, this while loop's body while (cur_seg->trbs > trb || &cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) { Will never get executed if the ring only contains one segment. find_trb_seg() will return immediately, without updating the new cycle bit. Since find_trb_seg() has no idea where in the segment the TD that stalled was, make the caller, xhci_find_new_dequeue_state(), check for this special case and update the cycle bit accordingly. This patch should be queued to kernels all the way back to 2.6.31. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26USB: serial: ch341: add new idwangyanqing1-0/+1
commit d0781383038e983a63843a9a6a067ed781db89c1 upstream. I picked up a new DAK-780EX(professional digitl reverb/mix system), which use CH341T chipset to communication with computer on 3/2011 and the CH341T's vendor code is 1a86 Looking up the CH341T's vendor and product id's I see: 1a86 QinHeng Electronics 5523 CH341 in serial mode, usb to serial port converter CH341T,CH341 are the products of the same company, maybe have some common hardware, and I test the ch341.c works well with CH341T Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26USB: serial/kobil_sct, fix potential tty NULL dereferenceJiri Slaby1-1/+1
commit 6960f40a954619857e7095a6179eef896f297077 upstream. Make sure that we check the return value of tty_port_tty_get. Sometimes it may return NULL and we later dereference that. The only place here is in kobil_read_int_callback, so fix it. Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26ath9k_hw: Fix incorrect macversion and macrev checksSenthil Balasubramanian1-2/+2
commit ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e upstream. There are few places where we are checking for macversion and revsions before RTC is powered ON. However we are reading the macversion and revisions only after RTC is powered ON and so both macversion and revisions are actully zero and this leads to incorrect srev checks Incorrect srev checks can cause registers to be configured wrongly and can cause unexpected behavior. Fixing this seems to address the ASPM issue that we have observed. The laptop becomes very slow and hangs mostly with ASPM L1 enabled without this fix. fix this by reading the macversion and revisisons even before we start using them. There is no reason why should we delay reading this info until RTC is powered on as this is just a register information. Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26IB/cm: Bump reference count on cm_id before invoking callbackSean Hefty1-0/+1
commit 29963437a48475036353b95ab142bf199adb909e upstream. When processing a SIDR REQ, the ib_cm allocates a new cm_id. The refcount of the cm_id is initialized to 1. However, cm_process_work will decrement the refcount after invoking all callbacks. The result is that the cm_id will end up with refcount set to 0 by the end of the sidr req handler. If a user tries to destroy the cm_id, the destruction will proceed, under the incorrect assumption that no other threads are referencing the cm_id. This can lead to a crash when the cm callback thread tries to access the cm_id. This problem was noticed as part of a larger investigation with kernel crashes in the rdma_cm when running on a real time OS. Signed-off-by: Sean Hefty <sean.hefty@intel.com> Acked-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26RDMA/cma: Fix crash in request handlersSean Hefty1-0/+15
commit 25ae21a10112875763c18b385624df713a288a05 upstream. Doug Ledford and Red Hat reported a crash when running the rdma_cm on a real-time OS. The crash has the following call trace: cm_process_work cma_req_handler cma_disable_callback rdma_create_id kzalloc init_completion cma_get_net_info cma_save_net_info cma_any_addr cma_zero_addr rdma_translate_ip rdma_copy_addr cma_acquire_dev rdma_addr_get_sgid ib_find_cached_gid cma_attach_to_dev ucma_event_handler kzalloc ib_copy_ah_attr_to_user cma_comp [ preempted ] cma_write copy_from_user ucma_destroy_id copy_from_user _ucma_find_context ucma_put_ctx ucma_free_ctx rdma_destroy_id cma_exch cma_cancel_operation rdma_node_get_transport rt_mutex_slowunlock bad_area_nosemaphore oops_enter They were able to reproduce the crash multiple times with the following details: Crash seems to always happen on the: mutex_unlock(&conn_id->handler_mutex); as conn_id looks to have been freed during this code path. An examination of the code shows that a race exists in the request handlers. When a new connection request is received, the rdma_cm allocates a new connection identifier. This identifier has a single reference count on it. If a user calls rdma_destroy_id() from another thread after receiving a callback, rdma_destroy_id will proceed to destroy the id and free the associated memory. However, the request handlers may still be in the process of running. When control returns to the request handlers, they can attempt to access the newly created identifiers. Fix this by holding a reference on the newly created rdma_cm_id until the request handler is through accessing it. Signed-off-by: Sean Hefty <sean.hefty@intel.com> Acked-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26ahci: AHCI mode SATA patch for Intel Patsburg SATA RAID controllerSeth Heasley1-0/+1
commit 64a3903d0885879ba8706a8bcf71c5e3e7664db2 upstream. This patch adds an updated SATA RAID DeviceID for the Intel Patsburg PCH. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26ahci: AHCI mode SATA patch for Intel DH89xxCC DeviceIDsSeth Heasley1-0/+1
commit a4a461a6df6c0481d5a3d61660ed97f5b539cf16 upstream. This patch adds the AHCI-mode SATA DeviceID for the Intel DH89xxCC PCH. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26ahci: AHCI and RAID mode SATA patch for Intel Patsburg DeviceIDsSeth Heasley1-0/+3
commit 992b3fb9b5391bc4de5b42bb810dc6dd583a6c4a upstream. This patch adds the Intel Patsburg (PCH) SATA AHCI and RAID Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26libata: no special completion processing for EH commandsTejun Heo1-9/+15
commit f08dc1ac6b15c681f4643d8da1700e06c3855608 upstream. ata_qc_complete() contains special handling for certain commands. For example, it schedules EH for device revalidation after certain configurations are changed. These shouldn't be applied to EH commands but they were. In most cases, it doesn't cause an actual problem because EH doesn't issue any command which would trigger special handling; however, ACPI can issue such commands via _GTF which can cause weird interactions. Restructure ata_qc_complete() such that EH commands are always passed on to __ata_qc_complete(). stable: Please apply to -stable only after 2.6.38 is released. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26mtd: add "platform:" prefix for platform modaliasAxel Lin3-3/+3
commit c804c733846572ca85c2bba60c7fe6fa024dff18 upstream. Since 43cc71eed1250755986da4c0f9898f9a635cb3bf (platform: prefix MODALIAS with "platform:"), the platform modalias is prefixed with "platform:". Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26hwmon/f71882fg: Set platform drvdata to NULL laterHans de Goede1-1/+1
commit d9ebaa45472c92704f4814682eec21455edcfa1f upstream. This avoids a possible race leading to trying to dereference NULL. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26r8169: use RxFIFO overflow workaround for 8168c chipset.Ivan Vecera1-2/+4
commit b5ba6d12bdac21bc0620a5089e0f24e362645efd upstream. I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts generating RxFIFO overflow errors. The result is an infinite loop in interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11. With the workaround everything goes fine. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes <hayeswang@realtek.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26ixgbe: fix for 82599 erratum on Header SplittingDon Skidmore1-2/+9
commit a124339ad28389093ed15eca990d39c51c5736cc upstream. We have found a hardware erratum on 82599 hardware that can lead to unpredictable behavior when Header Splitting mode is enabled. So we are no longer enabling this feature on affected hardware. Please see the 82599 Specification Update for more information. Signed-off-by: Don Skidmore <donald.c.skidmore@intel.com> Tested-by: Stephen Ko <stephen.s.ko@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26keyboard: integer underflow bugDan Carpenter1-1/+2
commit b652277b09d3d030cb074cc6a98ba80b34244c03 upstream. The "ct" variable should be an unsigned int. Both struct kbdiacrs ->kb_cnt and struct kbd_data ->accent_table_size are unsigned ints. Making it signed causes a problem in KBDIACRUC because the user could set the signed bit and cause a buffer overflow. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26usb: iowarrior: don't trust report_size for buffer sizeKees Cook1-1/+1
commit 3ed780117dbe5acb64280d218f0347f238dafed0 upstream. If the iowarrior devices in this case statement support more than 8 bytes per report, it is possible to write past the end of a kernel heap allocation. This will probably never be possible, but change the allocation to be more defensive anyway. Signed-off-by: Kees Cook <kees.cook@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26r8169: disable ASPMStanislaw Gruszka1-0/+6
commit ba04c7c93bbcb48ce880cf75b6e9dffcd79d4c7b upstream. For some time is known that ASPM is causing troubles on r8169, i.e. make device randomly stop working without any errors in dmesg. Currently Tomi Leppikangas reports that system with r8169 device hangs with MCE errors when ASPM is enabled: https://bugzilla.redhat.com/show_bug.cgi?id=642861#c4 Lets disable ASPM for r8169 devices at all, to avoid problems with r8169 PCIe devices at least for some users. Reported-by: Tomi Leppikangas <tomi.leppikangas@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26e1000e: disable broken PHY wakeup for ICH10 LOMs, use MAC wakeup insteadBruce Allan1-1/+2
commit 4def99bbfd46e05c5e03b5b282cb4ee30e27ff19 upstream. When support for 82577/82578 was added[1] in 2.6.31, PHY wakeup was in- advertently enabled (even though it does not function properly) on ICH10 LOMs. This patch makes it so that the ICH10 LOMs use MAC wakeup instead as was done with the initial support for those devices (i.e. 82567LM-3, 82567LF-3 and 82567V-4). [1] commit a4f58f5455ba0efda36fb33c37074922d1527a10 Reported-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26p54usb: add Senao NUB-350 usbidChristian Lamparter1-0/+1
commit 2b799a6b25bb9f9fbc478782cd9503e8066ab618 upstream. Reported-by: Mark Davis Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26mfd: Fix NULL pointer due to non-initialized ucb1x00-ts absinfoJochen Friedrich1-3/+9
commit 9063f1f15eec35e5fd608879cef8be5728f2d12a upstream. Call input_set_abs_params instead of manually setting absbit only. This fixes this oops: Unable to handle kernel NULL pointer dereference at virtual address 00000024 Internal error: Oops: 41b67017 [#1] CPU: 0 Not tainted (2.6.37 #4) pc : [<c016d1fc>] lr : [<00000000>] psr: 20000093 sp : c19e5f30 ip : c19e5e6c fp : c19e5f58 r10: 00000000 r9 : c19e4000 r8 : 00000003 r7 : 000001e4 r6 : 00000001 r5 : c1854400 r4 : 00000003 r3 : 00000018 r2 : 00000018 r1 : 00000018 r0 : c185447c Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: c1b6717f Table: c1b6717f DAC: 00000017 Stack: (0xc19e5f30 to 0xc19e6000) 5f20: 00000003 00000003 c1854400 00000013 5f40: 00000001 000001e4 000001c5 c19e5f80 c19e5f5c c016d5e8 c016cf5c 000001e4 5f60: c1854400 c18b5860 00000000 00000171 000001e4 c19e5fc4 c19e5f84 c01559a4 5f80: c016d584 c18b5868 00000000 c1bb5c40 c0035afc c18b5868 c18b5868 c1a55d54 5fa0: c18b5860 c0155750 00000013 00000000 00000000 00000000 c19e5ff4 c19e5fc8 5fc0: c0050174 c015575c 00000000 c18b5860 00000000 c19e5fd4 c19e5fd4 c1a55d54 5fe0: c00500f0 c003b464 00000000 c19e5ff8 c003b464 c00500fc 04000400 04000400 Backtrace: Function entered at [<c016cf50>] from [<c016d5e8>] Function entered at [<c016d578>] from [<c01559a4>] r8:000001e4 r7:00000171 r6:00000000 r5:c18b5860 r4:c1854400 Function entered at [<c0155750>] from [<c0050174>] Function entered at [<c00500f0>] from [<c003b464>] r6:c003b464 r5:c00500f0 r4:c1a55d54 Code: e59520fc e1a03286 e0433186 e0822003 (e592000c) >>PC; c016d1fc <input_handle_event+2ac/5a0> <===== Trace; c016cf50 <input_handle_event+0/5a0> Trace; c016d5e8 <input_event+70/88> Trace; c016d578 <input_event+0/88> Trace; c01559a4 <ucb1x00_thread+254/2dc> Trace; c0155750 <ucb1x00_thread+0/2dc> Trace; c0050174 <kthread+84/8c> Trace; c00500f0 <kthread+0/8c> Trace; c003b464 <do_exit+0/624> Signed-off-by: Jochen Friedrich <jochen@scram.de> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26xhci: Fix an error in count_sg_trbs_needed()Paul Zimmerman1-1/+1
commit bcd2fde05341cef0052e49566ec88b406a521cf3 upstream. The expression while (running_total < sg_dma_len(sg)) does not take into account that the remaining data length can be less than sg_dma_len(sg). In that case, running_total can end up being greater than the total data length, so an extra TRB is counted. Changing the expression to while (running_total < sg_dma_len(sg) && running_total < temp) fixes that. This patch should be queued for stable kernels back to 2.6.31. Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26xhci: Fix errors in the running total calculations in the TRB mathPaul Zimmerman1-0/+2
commit 5807795bd4dececdf553719cc02869e633395787 upstream. Calculations like running_total = TRB_MAX_BUFF_SIZE - (sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1)); if (running_total != 0) num_trbs++; are incorrect, because running_total can never be zero, so the if() expression will never be true. I think the intention was that running_total be in the range of 0 to TRB_MAX_BUFF_SIZE-1, not 1 to TRB_MAX_BUFF_SIZE. So adding a running_total &= TRB_MAX_BUFF_SIZE - 1; fixes the problem. This patch should be queued for stable kernels back to 2.6.31. [PG: 34 doesn't have count_isoc_trbs_needed() hence this has only two of the three upstream running_total changes.] Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26xhci: Clarify some expressions in the TRB mathPaul Zimmerman1-10/+9
commit a2490187011cc2263117626615a581927d19f1d3 upstream. This makes it easier to spot some problems, which will be fixed by the next patch in the series. Also change dev_dbg to dev_err in check_trb_math(), so any math errors will be visible even when running with debug disabled. Note: This patch changes the expressions containing "((1 << TRB_MAX_BUFF_SHIFT) - 1)" to use the equivalent "(TRB_MAX_BUFF_SIZE - 1)". No change in behavior is intended for those expressions. This patch should be queued for stable kernels back to 2.6.31. [PG: 34 doesn't have count_isoc_trbs_needed() hence this has one less instance to change vs. the originating release] Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26xhci: Avoid BUG() in interrupt contextPaul Zimmerman1-4/+9
commit 68e41c5d032668e2905404afbef75bc58be179d6 upstream. Change the BUGs in xhci_find_new_dequeue_state() to WARN_ONs, to avoid bringing down the box if one of them is hit This patch should be queued for stable kernels back to 2.6.31. Signed-off-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26md: correctly handle probe of an 'mdp' device.NeilBrown1-0/+3
commit 8f5f02c460b7ca74ce55ce126ce0c1e58a3f923d upstream. 'mdp' devices are md devices with preallocated device numbers for partitions. As such it is possible to mknod and open a partition before opening the whole device. this causes md_probe() to be called with a device number of a partition, which in-turn calls mddev_find with such a number. However mddev_find expects the number of a 'whole device' and does the wrong thing with partition numbers. So add code to mddev_find to remove the 'partition' part of a device number and just work with the 'whole device'. This patch addresses https://bugzilla.kernel.org/show_bug.cgi?id=28652 Reported-by: hkmaly@bigfoot.com Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26staging: usbip: vhci: use urb->dev->portnum to find portMax Vozeler2-6/+1
commit 01446ef5af4e8802369bf4d257806e24345a9371 upstream. The access to pending_port was racy when two devices were being attached at the same time. Signed-off-by: Max Vozeler <max@vozeler.com> Tested-by: Mark Wehby <MWehby@luxotticaRetail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26staging: usbip: vhci: refuse to enqueue for dead connectionsMax Vozeler1-2/+13
commit 6d212153a838354078cc7d96f9bb23b7d1fd3d1b upstream. There can be requests to enqueue URBs while we are shutting down a connection. Signed-off-by: Max Vozeler <max@vozeler.com> Tested-by: Mark Wehby <MWehby@luxotticaRetail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26staging: usbip: vhci: give back URBs from in-flight unlink requestsMax Vozeler3-7/+35
commit b92a5e23737172c52656a090977408a80d7f06d1 upstream. If we never received a RET_UNLINK because the TCP connection broke the pending URBs still need to be unlinked and given back. Previously processes would be stuck trying to kill the URB even after the device was detached. Signed-off-by: Max Vozeler <max@vozeler.com> Tested-by: Mark Wehby <MWehby@luxotticaRetail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-06-26staging: usbip: vhci: update reference count for usb_deviceMax Vozeler1-3/+10
commit 7606ee8aa33287dd3e6eb44c78541b87a413a325 upstream. This fixes an oops observed when reading status during removal of a device: [ 1706.648285] general protection fault: 0000 [#1] SMP [ 1706.648294] last sysfs file: /sys/devices/platform/vhci_hcd/status [ 1706.648297] CPU 1 [ 1706.648300] Modules linked in: binfmt_misc microcode fuse loop vhci_hcd(N) usbip(N) usbcore usbip_common_mod(N) rtc_core rtc_lib joydev dm_mirror dm_region_hash dm_log linear dm_snapshot xennet dm_mod ext3 mbcache jbd processor thermal_sys hwmon xenblk cdrom [ 1706.648324] Supported: Yes [ 1706.648327] Pid: 10422, comm: usbip Tainted: G N 2.6.32.12-0.7-xen #1 [ 1706.648330] RIP: e030:[<ffffffff801b10d5>] [<ffffffff801b10d5>] strnlen+0x5/0x40 [ 1706.648340] RSP: e02b:ffff8800a994dd30 EFLAGS: 00010286 [ 1706.648343] RAX: ffffffff80481ec1 RBX: 0000000000000000 RCX: 0000000000000002 [ 1706.648347] RDX: 00200d1d4f1c001c RSI: ffffffffffffffff RDI: 00200d1d4f1c001c [ 1706.648350] RBP: ffff880129a1c0aa R08: ffffffffa01901c4 R09: 0000000000000006 [ 1706.648353] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800a9a1c0ab [ 1706.648357] R13: 00200d1d4f1c001c R14: 00000000ffffffff R15: ffff880129a1c0aa [ 1706.648363] FS: 00007f2f2e9ca700(0000) GS:ffff880001018000(0000) knlGS:0000000000000000 [ 1706.648367] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1706.648370] CR2: 000000000071b048 CR3: 00000000b4b68000 CR4: 0000000000002660 [ 1706.648374] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1706.648378] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1706.648381] Process usbip (pid: 10422, threadinfo ffff8800a994c000, task ffff88007b170200) [ 1706.648385] Stack: [ 1706.648387] ffffffff801b28c9 0000000000000002 ffffffffa01901c4 ffff8800a9a1c0ab [ 1706.648391] <0> ffffffffa01901c6 ffff8800a994de08 ffffffff801b339b 0000000000000004 [ 1706.648397] <0> 0000000affffffff ffffffffffffffff 00000000000067c0 0000000000000000 [ 1706.648404] Call Trace: [ 1706.648413] [<ffffffff801b28c9>] string+0x39/0xe0 [ 1706.648419] [<ffffffff801b339b>] vsnprintf+0x1eb/0x620 [ 1706.648423] [<ffffffff801b3813>] sprintf+0x43/0x50 [ 1706.648429] [<ffffffffa018d719>] show_status+0x1b9/0x220 [vhci_hcd] [ 1706.648438] [<ffffffff8024a2b7>] dev_attr_show+0x27/0x60 [ 1706.648445] [<ffffffff80144821>] sysfs_read_file+0x101/0x1d0 [ 1706.648451] [<ffffffff800da4a7>] vfs_read+0xc7/0x130 [ 1706.648457] [<ffffffff800da613>] sys_read+0x53/0xa0 [ 1706.648462] [<ffffffff80007458>] system_call_fastpath+0x16/0x1b [ 1706.648468] [<00007f2f2de40f30>] 0x7f2f2de40f30 [ 1706.648470] Code: 66 0f 1f 44 00 00 48 83 c2 01 80 3a 00 75 f7 48 89 d0 48 29 f8 f3 c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 85 f6 74 29 <80> 3f 00 74 24 48 8d 56 ff 48 89 f8 eb 0e 0f 1f 44 00 00 48 83 [ 1706.648507] RIP [<ffffffff801b10d5>] strnlen+0x5/0x40 [ 1706.648511] RSP <ffff8800a994dd30> [ 1706.649575] ---[ end trace b4eb72bf2e149593 ]--- Signed-off-by: Max Vozeler <max@vozeler.com> Tested-by: Mark Wehby <MWehby@luxotticaRetail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-23 13:51:26 +0000