commit 8b5ed99a4f9f2969c47501530da6dcd5a91f8f3d Author: Ben Hutchings Date: Sat Oct 26 21:06:14 2013 +0100 Linux 3.2.52 commit 9203ceb63af1d8a2c1557ff01cbb2d75e960d2ef Author: Marc Kleine-Budde Date: Fri Oct 4 10:52:36 2013 +0200 can: flexcan: flexcan_chip_start: fix regression, mark one MB for TX and abort pending TX commit d5a7b406c529e4595ce03dc8f6dcf7fa36f106fa upstream. In patch 0d1862e can: flexcan: fix flexcan_chip_start() on imx6 the loop in flexcan_chip_start() that iterates over all mailboxes after the soft reset of the CAN core was removed. This loop put all mailboxes (even the ones marked as reserved 1...7) into EMPTY/INACTIVE mode. On mailboxes 8...63, this aborts any pending TX messages. After a cold boot there is random garbage in the mailboxes, which leads to spontaneous transmit of CAN frames during first activation. Further if the interface was disabled with a pending message (usually due to an error condition on the CAN bus), this message is retransmitted after enabling the interface again. This patch fixes the regression by: 1) Limiting the maximum number of used mailboxes to 8, 0...7 are used by the RX FIFO, 8 is used by TX. 2) Marking the TX mailbox as EMPTY/INACTIVE, so that any pending TX of that mailbox is aborted. Cc: Lothar Waßmann Signed-off-by: Marc Kleine-Budde [bwh: Backported to 3.2: - Adjust context - Hardware local echo is still enabled] Signed-off-by: Ben Hutchings commit c23e05d637c461d13e473bee595ae781622b5ebf Author: Claudiu Manoil Date: Sun Sep 23 22:39:08 2012 +0000 gianfar: Change default HW Tx queue scheduling mode commit b98b8babd6e3370fadb7c6eaacb00eb2f6344a6c upstream. This is primarily to address transmission timeout occurrences, when multiple H/W Tx queues are being used concurrently. Because in the priority scheduling mode the controller does not service the Tx queues equally (but in ascending index order), Tx timeouts are being triggered rightaway for a basic test with multiple simultaneous connections like: iperf -c -n 100M -P 8 resulting in kernel trace: NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue timed out ------------[ cut here ]------------ WARNING: at net/sched/sch_generic.c:255 ... and controller reset during intense traffic, and possibly further complications. This patch changes the default H/W Tx scheduling setting (TXSCHED) for multi-queue devices, from priority scheduling mode to a weighted round robin mode with equal weights for all H/W Tx queues, and addresses the issue above. Signed-off-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 7c617fda8c72a55a65cc5320cadb916f5981cfeb Author: David Rientjes Date: Mon Apr 29 15:06:11 2013 -0700 mm, show_mem: suppress page counts in non-blockable contexts commit 4b59e6c4730978679b414a8da61514a2518da512 upstream. On large systems with a lot of memory, walking all RAM to determine page types may take a half second or even more. In non-blockable contexts, the page allocator will emit a page allocation failure warning unless __GFP_NOWARN is specified. In such contexts, irqs are typically disabled and such a lengthy delay may even result in NMI watchdog timeouts. To fix this, suppress the page walk in such contexts when printing the page allocation failure warning. Signed-off-by: David Rientjes Cc: Mel Gorman Acked-by: Michal Hocko Cc: Dave Hansen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit dffcc9dc54d22e3c5eadd5d42835fa47ee25b071 Author: Lv Zheng Date: Fri Sep 13 13:13:23 2013 +0800 ACPI / IPMI: Fix atomic context requirement of ipmi_msg_handler() commit 06a8566bcf5cf7db9843a82cde7a33c7bf3947d9 upstream. This patch fixes the issues indicated by the test results that ipmi_msg_handler() is invoked in atomic context. BUG: scheduling while atomic: kipmi0/18933/0x10000100 Modules linked in: ipmi_si acpi_ipmi ... CPU: 3 PID: 18933 Comm: kipmi0 Tainted: G AW 3.10.0-rc7+ #2 Hardware name: QCI QSSC-S4R/QSSC-S4R, BIOS QSSC-S4R.QCI.01.00.0027.070120100606 07/01/2010 ffff8838245eea00 ffff88103fc63c98 ffffffff814c4a1e ffff88103fc63ca8 ffffffff814bfbab ffff88103fc63d28 ffffffff814c73e0 ffff88103933cbd4 0000000000000096 ffff88103fc63ce8 ffff88102f618000 ffff881035c01fd8 Call Trace: [] dump_stack+0x19/0x1b [] __schedule_bug+0x46/0x54 [] __schedule+0x83/0x59c [] __cond_resched+0x22/0x2d [] _cond_resched+0x14/0x1d [] mutex_lock+0x11/0x32 [] ? __default_send_IPI_dest_field.constprop.0+0x53/0x58 [] ipmi_msg_handler+0x23/0x166 [ipmi_si] [] deliver_response+0x55/0x5a [] handle_new_recv_msgs+0xb67/0xc65 [] ? read_tsc+0x9/0x19 [] ? _raw_spin_lock_irq+0xa/0xc [] ipmi_thread+0x5c/0x146 [ipmi_si] ... Also Tony Camuso says: We were getting occasional "Scheduling while atomic" call traces during boot on some systems. Problem was first seen on a Cisco C210 but we were able to reproduce it on a Cisco c220m3. Setting CONFIG_LOCKDEP and LOCKDEP_SUPPORT to 'y' exposed a lockdep around tx_msg_lock in acpi_ipmi.c struct acpi_ipmi_device. ================================= [ INFO: inconsistent lock state ] 2.6.32-415.el6.x86_64-debug-splck #1 --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/3/17 [HC0[0]:SC1[1]:HE1:SE0] takes: (&ipmi_device->tx_msg_lock){+.?...}, at: [] ipmi_msg_handler+0x71/0x126 {SOFTIRQ-ON-W} state was registered at: [] __lock_acquire+0x63c/0x1570 [] lock_acquire+0xa4/0x120 [] __mutex_lock_common+0x4c/0x400 [] mutex_lock_nested+0x4a/0x60 [] acpi_ipmi_space_handler+0x11b/0x234 [] acpi_ev_address_space_dispatch+0x170/0x1be The fix implemented by this change has been tested by Tony: Tested the patch in a boot loop with lockdep debug enabled and never saw the problem in over 400 reboots. Reported-and-tested-by: Tony Camuso Signed-off-by: Lv Zheng Reviewed-by: Huang Ying Signed-off-by: Rafael J. Wysocki Signed-off-by: Ben Hutchings commit 7b376352641ccc12b53a3aa555b9a477a8c0f44e Author: Ian Abbott Date: Wed Oct 2 14:57:51 2013 +0100 staging: comedi: ni_65xx: (bug fix) confine insn_bits to one subdevice commit 677a31565692d596ef42ea589b53ba289abf4713 upstream. The `insn_bits` handler `ni_65xx_dio_insn_bits()` has a `for` loop that currently writes (optionally) and reads back up to 5 "ports" consisting of 8 channels each. It reads up to 32 1-bit channels but can only read and write a whole port at once - it needs to handle up to 5 ports as the first channel it reads might not be aligned on a port boundary. It breaks out of the loop early if the next port it handles is beyond the final port on the card. It also breaks out early on the 5th port in the loop if the first channel was aligned. Unfortunately, it doesn't check that the current port it is dealing with belongs to the comedi subdevice the `insn_bits` handler is acting on. That's a bug. Redo the `for` loop to terminate after the final port belonging to the subdevice, changing the loop variable in the process to simplify things a bit. The `for` loop could now try and handle more than 5 ports if the subdevice has more than 40 channels, but the test `if (bitshift >= 32)` ensures it will break out early after 4 or 5 ports (depending on whether the first channel is aligned on a port boundary). (`bitshift` will be between -7 and 7 inclusive on the first iteration, increasing by 8 for each subsequent operation.) Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman [Ian Abbott: This patch applies to kernels 2.6.34.y through to 3.5.y inclusive.] Signed-off-by: Ben Hutchings commit 0cf9986114ab4e16bf36a51814a0f688c79961a7 Author: Theodore Ts'o Date: Thu Dec 27 01:42:50 2012 -0500 ext4: avoid hang when mounting non-journal filesystems with orphan list commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream. When trying to mount a file system which does not contain a journal, but which does have a orphan list containing an inode which needs to be truncated, the mount call with hang forever in ext4_orphan_cleanup() because ext4_orphan_del() will return immediately without removing the inode from the orphan list, leading to an uninterruptible loop in kernel code which will busy out one of the CPU's on the system. This can be trivially reproduced by trying to mount the file system found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs source tree. If a malicious user were to put this on a USB stick, and mount it on a Linux desktop which has automatic mounts enabled, this could be considered a potential denial of service attack. (Not a big deal in practice, but professional paranoids worry about such things, and have even been known to allocate CVE numbers for such problems.) -js: This is a fix for CVE-2013-2015. Signed-off-by: "Theodore Ts'o" Reviewed-by: Zheng Liu Acked-by: Jan Kara Signed-off-by: Jiri Slaby Signed-off-by: Ben Hutchings commit c60ce91cc52e53619bb919ad5ff8891b75c2a4dd Author: Henrik Rydberg Date: Thu Jan 26 06:08:41 2012 -0500 hwmon: (applesmc) Silence uninitialized warnings commit 0fc86eca1b338d06ec500b34ef7def79c32b602b upstream. Some error paths do not set a result, leading to the (false) assumption that the value may be used uninitialized. Set results for those paths as well. Signed-off-by: Henrik Rydberg Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 47fa3c9b8352d4f403118b01f8a97fff1353c30b Author: Florian Wolter Date: Wed Aug 14 10:33:16 2013 +0200 xhci: Fix race between ep halt and URB cancellation commit 526867c3ca0caa2e3e846cb993b0f961c33c2abb upstream. The halted state of a endpoint cannot be cleared over CLEAR_HALT from a user process, because the stopped_td variable was overwritten in the handle_stopped_endpoint() function. So the xhci_endpoint_reset() function will refuse the reset and communication with device can not run over this endpoint. https://bugzilla.kernel.org/show_bug.cgi?id=60699 Signed-off-by: Florian Wolter Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit 4ecc545c9a903910bd23e40b6492d7b4f7ec03bc Author: Dan Carpenter Date: Tue Sep 24 15:27:45 2013 -0700 cciss: fix info leak in cciss_ioctl32_passthru() commit 58f09e00ae095e46ef9edfcf3a5fd9ccdfad065e upstream. The arg64 struct has a hole after ->buf_size which isn't cleared. Or if any of the calls to copy_from_user() fail then that would cause an information leak as well. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter Acked-by: Mike Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit e1fd636836ca3c883c172dc619a909e988a2f4b5 Author: Dan Carpenter Date: Tue Sep 24 15:27:44 2013 -0700 cpqarray: fix info leak in ida_locked_ioctl() commit 627aad1c01da6f881e7f98d71fd928ca0c316b1a upstream. The pciinfo struct has a two byte hole after ->dev_fn so stack information could be leaked to the user. This was assigned CVE-2013-2147. Signed-off-by: Dan Carpenter Acked-by: Mike Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit aa7b08adf6ba9f5e5434c23181fdfee46eab979e Author: Sasha Levin Date: Wed Jan 25 22:16:16 2012 -0500 iscsi: don't hang in endless loop if no targets present commit 46a7c17d26967922092f3a8291815ffb20f6cabe upstream. iscsi_if_send_reply() may return -ESRCH if there were no targets to send data to. Currently we're ignoring this value and looping in attempt to do it over and over, which will usually lead in a hung task like this one: [ 4920.817298] INFO: task trinity:9074 blocked for more than 120 seconds. [ 4920.818527] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 4920.819982] trinity D 0000000000000000 5504 9074 2756 0x00000004 [ 4920.825374] ffff880003961a98 0000000000000086 ffff8800001aa000 ffff8800001aa000 [ 4920.826791] 00000000001d4340 ffff880003961fd8 ffff880003960000 00000000001d4340 [ 4920.828241] 00000000001d4340 00000000001d4340 ffff880003961fd8 00000000001d4340 [ 4920.833231] [ 4920.833519] Call Trace: [ 4920.834010] [] schedule+0x3a/0x50 [ 4920.834953] [] __mutex_lock_common+0x209/0x5b0 [ 4920.836226] [] ? iscsi_if_rx+0x2d/0x990 [ 4920.837281] [] ? sched_clock+0x13/0x20 [ 4920.838305] [] ? iscsi_if_rx+0x2d/0x990 [ 4920.839336] [] mutex_lock_nested+0x40/0x50 [ 4920.840423] [] iscsi_if_rx+0x2d/0x990 [ 4920.841434] [] ? sub_preempt_count+0x9d/0xd0 [ 4920.842548] [] ? _raw_read_unlock+0x30/0x60 [ 4920.843666] [] netlink_unicast+0x1ae/0x1f0 [ 4920.844751] [] netlink_sendmsg+0x227/0x350 [ 4920.845850] [] ? sock_update_netprioidx+0xdd/0x1b0 [ 4920.847060] [] ? sock_update_netprioidx+0x52/0x1b0 [ 4920.848276] [] sock_aio_write+0x166/0x180 [ 4920.849348] [] ? get_parent_ip+0x11/0x50 [ 4920.850428] [] do_sync_write+0xda/0x120 [ 4920.851465] [] ? sub_preempt_count+0x9d/0xd0 [ 4920.852579] [] ? get_parent_ip+0x11/0x50 [ 4920.853608] [] ? security_file_permission+0x27/0xb0 [ 4920.854821] [] vfs_write+0x16c/0x180 [ 4920.855781] [] sys_write+0x4f/0xa0 [ 4920.856798] [] system_call_fastpath+0x16/0x1b [ 4920.877487] 1 lock held by trinity/9074: [ 4920.878239] #0: (rx_queue_mutex){+.+...}, at: [] iscsi_if_rx+0x2d/0x990 [ 4920.880005] Kernel panic - not syncing: hung_task: blocked tasks Signed-off-by: Sasha Levin Acked-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings commit 177c417ca4d861640b35ecf4fcd0f7563543e01f Author: Ben Hutchings Date: Sun Oct 20 17:06:39 2013 +0100 Revert "sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()" This reverts commit de77b7955c3985ca95f64af3cb10557eb17eacee, which was commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec upstream. This fix was only appropriate for Linux 3.7 onward, and introduced a regression when applied to earlier versions. Signed-off-by: Ben Hutchings commit b1455ca9e8c44171e550980c82295162e7e31646 Author: Jan Kara Date: Thu Jul 25 11:49:11 2013 +0200 isofs: Refuse RW mount of the filesystem instead of making it RO commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a upstream. Refuse RW mount of isofs filesystem. So far we just silently changed it to RO mount but when the media is writeable, block layer won't notice this change and thus will think device is used RW and will block eject button of the drive. That is unexpected by users because for non-writeable media eject button works just fine. Userspace mount(8) command handles this just fine and retries mounting with MS_RDONLY set so userspace shouldn't see any regression. Plus any tool mounting isofs is likely confronted with the case of read-only media where block layer already refuses to mount the filesystem without MS_RDONLY set so our behavior shouldn't be anything new for it. Reported-by: Hui Wang Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings commit 04f82ec3a0a5399c17eb2053fa6833de064216b3 Author: Vasily Titskiy Date: Fri Aug 30 18:25:04 2013 -0400 HID: usbhid: quirk for N-Trig DuoSense Touch Screen commit 9e0bf92c223dabe0789714f8f85f6e26f8f9cda4 upstream. The DuoSense touchscreen device causes a 10 second timeout. This fix removes the delay. Signed-off-by: Vasily Titskiy Signed-off-by: Jiri Kosina [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 297c511a4b6c6cff190525aec83b0d2de39fc3d8 Author: Stefan Kriwanek Date: Sun Aug 25 10:46:13 2013 +0200 HID: Fix Speedlink VAD Cezanne support for some devices commit 06bb5219118fb098f4b0c7dcb484b28a52bf1c14 upstream. Some devices of the "Speedlink VAD Cezanne" model need more aggressive fixing than already done. I made sure through testing that this patch would not interfere with the proper working of a device that is bug-free. (The driver drops EV_REL events with abs(val) >= 256, which are not achievable even on the highest laser resolution hardware setting.) Signed-off-by: Stefan Kriwanek Signed-off-by: Jiri Kosina Signed-off-by: Ben Hutchings commit a6c756ccc62d4b6168f70fc5a3da5004a5f56751 Author: Lino Sanfilippo Date: Fri Mar 23 02:42:23 2012 +0100 fanotify: dont merge permission events commit 03a1cec1f17ac1a6041996b3e40f96b5a2f90e1b upstream. Boyd Yang reported a problem for the case that multiple threads of the same thread group are waiting for a reponse for a permission event. In this case it is possible that some of the threads are never woken up, even if the response for the event has been received (see http://marc.info/?l=linux-kernel&m=131822913806350&w=2). The reason is that we are currently merging permission events if they belong to the same thread group. But we are not prepared to wake up more than one waiter for each event. We do wait_event(group->fanotify_data.access_waitq, event->response || atomic_read(&group->fanotify_data.bypass_perm)); and after that event->response = 0; which is the reason that even if we woke up all waiters for the same event some of them may see event->response being already set 0 again, then go back to sleep and block forever. With this patch we avoid that more than one thread is waiting for a response by not merging permission events for the same thread group any more. Reported-by: Boyd Yang Signed-off-by: Lino Sanfilippo Signed-off-by: Eric Paris Signed-off-by: Ben Hutchings commit 7ed1d8009cc6f1b534ed94388cb7980b4a55797e Author: Andi Kleen Date: Wed Apr 24 17:03:02 2013 -0700 perf tools: Handle JITed code in shared memory commit 89365e6c9ad4c0e090e4c6a4b67a3ce319381d89 upstream. Need to check for /dev/zero. Most likely more strings are missing too. Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1366848182-30449-1-git-send-email-andi@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ben Hutchings commit 49a58f5fa9d71155be5b6211030c281084f336a3 Author: Peter Zijlstra Date: Tue Oct 2 15:41:23 2012 +0200 perf: Fix perf_cgroup_switch for sw-events commit 95cf59ea72331d0093010543b8951bb43f262cac upstream. Jiri reported that he could trigger the WARN_ON_ONCE() in perf_cgroup_switch() using sw-events. This is because sw-events share a cpuctx with multiple PMUs. Use the ->unique_pmu pointer to limit the pmu iteration to unique cpuctx instances. Reported-and-Tested-by: Jiri Olsa Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-so7wi2zf3jjzrwcutm2mkz0j@git.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 6272221247a80adf0c36bf4f6ac8a4d7dcfb7e5b Author: Peter Zijlstra Date: Tue Oct 2 15:38:52 2012 +0200 perf: Clarify perf_cpu_context::active_pmu usage by renaming it to ::unique_pmu commit 3f1f33206c16c7b3839d71372bc2ac3f305aa802 upstream. Stephane thought the perf_cpu_context::active_pmu name confusing and suggested using 'unique_pmu' instead. This pointer is a pointer to a 'random' pmu sharing the cpuctx instance, therefore limiting a for_each_pmu loop to those where cpuctx->unique_pmu matches the pmu we get a loop over unique cpuctx instances. Suggested-by: Stephane Eranian Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-kxyjqpfj2fn9gt7kwu5ag9ks@git.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 31e0470e9906c42edfc4cf00404d4eb3a99dac7e Author: Li Zefan Date: Mon Feb 18 14:13:35 2013 +0800 cgroup: fail if monitored file and event_control are in different cgroup commit f169007b2773f285e098cb84c74aac0154d65ff7 upstream. If we pass fd of memory.usage_in_bytes of cgroup A to cgroup.event_control of cgroup B, then we won't get memory usage notification from A but B! What's worse, if A and B are in different mount hierarchy, we'll end up accessing NULL pointer! Disallow this kind of invalid usage. Signed-off-by: Li Zefan Acked-by: Kirill A. Shutemov Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 5f7f65dae41a2f2ba134b880d2b9a8bc459ba01b Author: Ben Hutchings Date: Fri Sep 6 22:39:20 2013 +0100 sfc: Fix efx_rx_buf_offset() for recycled pages This bug fix is only for stable branches older than 3.10. The bug was fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA mapping/unmapping costs'), but that change is totally unsuitable for stable. Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of swiotlb') added an explicit page_offset member to struct efx_rx_buffer, which must be set consistently with the u.page and dma_addr fields. However, it failed to add the necessary assignment in efx_resurrect_rx_buffer(). It also did not correct the calculation of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes that DMA-mapping a page will result in a page-aligned DMA address (exactly what swiotlb violates). Add the assignment of efx_rx_buffer::page_offset and change the calculation of dma_addr to make use of it. Signed-off-by: Ben Hutchings commit 068d848f7f3d3db8c68e517ba93cb170914a64d8 Author: Jason Wang Date: Thu Jul 18 10:55:16 2013 +0800 macvtap: do not zerocopy if iov needs more pages than MAX_SKB_FRAGS commit ece793fcfc417b3925844be88a6a6dc82ae8f7c6 upstream. We try to linearize part of the skb when the number of iov is greater than MAX_SKB_FRAGS. This is not enough since each single vector may occupy more than one pages, so zerocopy_sg_fromiovec() may still fail and may break the guest network. Solve this problem by calculate the pages needed for iov before trying to do zerocopy and switch to use copy instead of zerocopy if it needs more than MAX_SKB_FRAGS. This is done through introducing a new helper to count the pages for iov, and call uarg->callback() manually when switching from zerocopy to copy to notify vhost. We can do further optimization on top. This bug were introduced from b92946e2919134ebe2a4083e4302236295ea2a73 (macvtap: zerocopy: validate vectors before building skb). Cc: Michael S. Tsirkin Signed-off-by: Jason Wang Signed-off-by: David S. Miller [bwh: Backported to 3.2: callback only takes one argument] Signed-off-by: Ben Hutchings commit 98ed9120b030962558276d8fd602eabb41a57d05 Author: Ben Hutchings Date: Sun Oct 20 13:37:39 2013 +0100 Revert "zram: use zram->lock to protect zram_free_page() in swap free notify path" This reverts commit 9e443904906ca2b5b3ae71f34ac4a4fa6905623e, which was commit 57ab048532c0d975538cebd4456491b5c34248f4 upstream. Taking the semaphore here leads to sleeping in atomic context. This was fixed in mainline commit a0c516cbfc74 ("zram: don't grab mutex in zram_slot_free_noity") but that is too difficult to backport. Signed-off-by: Ben Hutchings commit 8f0ce108f5e1c6a443548746b6f01b450f71a407 Author: Chen Gang Date: Mon Apr 22 17:12:54 2013 +0000 powerpc/pseries/lparcfg: Fix possible overflow are more than 1026 commit 5676005acf26ab7e924a8438ea4746e47d405762 upstream. need set '\0' for 'local_buffer'. SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096. so the contents of rtas_data_buf may truncated in memcpy. if contents are really truncated. the splpar_strlen is more than 1026. the next while loop checking will not find the end of buffer. that will cause memory access violation. Signed-off-by: Chen Gang Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit f362f08b46213452508f76bac4b74a4e5f5c4294 Author: Greg Ungerer Date: Thu Jan 5 15:51:13 2012 +1000 m68knommu: clean up linker script commit f84f52a5c15db7d14a534815f27253b001735183 upstream. There is a lot of years of collected cruft in the m68knommu linker script. Clean it all up and use the well defined linker script support macros. Support is maintained for building both ROM/FLASH based and RAM based setups. No major changes to section layouts, though the rodata section is now lumped in with the read/write data section. Signed-off-by: Greg Ungerer Signed-off-by: Ben Hutchings commit 5e4063bdbee2ead4042b6caf4f603ed0cb6c0fc6 Author: Greg Ungerer Date: Wed Oct 19 13:50:35 2011 +1000 m68k: use non-MMU linker script for ColdFire MMU builds commit ed865e31a8273be200db9ddcdb6b844e48777abd upstream. Use the non-MMU linker script for ColdFire builds when we are building for MMU enabled. The image layout is correct for loading on existing ColdFire dev boards. The only addition required to the current non-MMU linker script is to add support for the fixup section. Signed-off-by: Greg Ungerer Acked-by: Geert Uytterhoeven Acked-by: Matt Waddel Acked-by: Kurt Mahan Signed-off-by: Ben Hutchings commit 2187004fa49f190aa89eb1e3cc01623d62f480a8 Author: Greg Ungerer Date: Thu Dec 8 15:39:05 2011 +1000 m68k: consolidate the vmlinux.lds linker scripts commit 40c1b9cfeedf79b909c961e0e00a13497e80bc82 upstream. The merge of m68knommu left the linker scripts a little disorganized. Some consistent naming and squashing two of scripts that just include others can simplify things a lot. So merge the two simple including scripts, and rename the nommu script to be consistent with the existing m68k linker scripts. Signed-off-by: Greg Ungerer Signed-off-by: Ben Hutchings commit 38e57772a96d382cc6783f26cb152702f686b25f Author: Julius Werner Date: Tue Jul 30 19:51:20 2013 -0700 usb: core: don't try to reset_device() a port that got just disconnected commit 481f2d4f89f87a0baa26147f323380e31cfa7c44 upstream. The USB hub driver's event handler contains a check to catch SuperSpeed devices that transitioned into the SS.Inactive state and tries to fix them with a reset. It decides whether to do a plain hub port reset or call the usb_reset_device() function based on whether there was a device attached to the port. However, there are device/hub combinations (found with a JetFlash Transcend mass storage stick (8564:1000) on the root hub of an Intel LynxPoint PCH) which can transition to the SS.Inactive state on disconnect (and stay there long enough for the host to notice). In this case, above-mentioned reset check will call usb_reset_device() on the stale device data structure. The kernel will send pointless LPM control messages to the no longer connected device address and can even cause several 5 second khubd stalls on some (buggy?) host controllers, before finally accepting the device's fate amongst a flurry of error messages. This patch makes the choice of reset dependent on the port status that has just been read from the hub in addition to the existence of an in-kernel data structure for the device, and only proceeds with the more extensive reset if both are valid. Signed-off-by: Julius Werner Signed-off-by: Sarah Sharp Signed-off-by: Ben Hutchings commit 93d9de3ace93eebf680fbf8e3ae1ab27b85410e9 Author: Oleg Nesterov Date: Fri Jul 26 17:12:56 2013 +0200 debugfs: debugfs_remove_recursive() must not rely on list_empty(d_subdirs) commit 776164c1faac4966ab14418bb0922e1820da1d19 upstream. debugfs_remove_recursive() is wrong, 1. it wrongly assumes that !list_empty(d_subdirs) means that this dir should be removed. This is not that bad by itself, but: 2. if d_subdirs does not becomes empty after __debugfs_remove() it gives up and silently fails, it doesn't even try to remove other entries. However ->d_subdirs can be non-empty because it still has the already deleted !debugfs_positive() entries. 3. simple_release_fs() is called even if __debugfs_remove() fails. Suppose we have dir1/ dir2/ file2 file1 and someone opens dir1/dir2/file2. Now, debugfs_remove_recursive(dir1/dir2) succeeds, and dir1/dir2 goes away. But debugfs_remove_recursive(dir1) silently fails and doesn't remove this directory. Because it tries to delete (the already deleted) dir1/dir2/file2 again and then fails due to "Avoid infinite loop" logic. Test-case: #!/bin/sh cd /sys/kernel/debug/tracing echo 'p:probe/sigprocmask sigprocmask' >> kprobe_events sleep 1000 < events/probe/sigprocmask/id & echo -n >| kprobe_events [ -d events/probe ] && echo "ERR!! failed to rm probe" And after that it is not possible to create another probe entry. With this patch debugfs_remove_recursive() skips !debugfs_positive() files although this is not strictly needed. The most important change is that it does not try to make ->d_subdirs empty, it simply scans the whole list(s) recursively and removes as much as possible. Link: http://lkml.kernel.org/r/20130726151256.GC19472@redhat.com Acked-by: Greg Kroah-Hartman Signed-off-by: Oleg Nesterov Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings commit fa59eed8556c7f149f8ab9cea0f42f7843eecc81 Author: Salman Qazi Date: Thu Jun 14 15:31:09 2012 -0700 perf: Use css_tryget() to avoid propping up css refcount commit 9c5da09d266ca9b32eb16cf940f8161d949c2fe5 upstream. An rmdir pushes css's ref count to zero. However, if the associated directory is open at the time, the dentry ref count is non-zero. If the fd for this directory is then passed into perf_event_open, it does a css_get(). This bounces the ref count back up from zero. This is a problem by itself. But what makes it turn into a crash is the fact that we end up doing an extra dput, since we perform a dput when css_put sees the ref count go down to zero. css_tryget() does not fall into that trap. So, we use that instead. Reproduction test-case for the bug: #include #include #include #include #include #include #include #include #include #define PERF_FLAG_PID_CGROUP (1U << 2) int perf_event_open(struct perf_event_attr *hw_event_uptr, pid_t pid, int cpu, int group_fd, unsigned long flags) { return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu, group_fd, flags); } /* * Directly poke at the perf_event bug, since it's proving hard to repro * depending on where in the kernel tree. what moved? */ int main(int argc, char **argv) { int fd; struct perf_event_attr attr; memset(&attr, 0, sizeof(attr)); attr.exclude_kernel = 1; attr.size = sizeof(attr); mkdir("/dev/cgroup/perf_event/blah", 0777); fd = open("/dev/cgroup/perf_event/blah", O_RDONLY); perror("open"); rmdir("/dev/cgroup/perf_event/blah"); sleep(2); perf_event_open(&attr, fd, 0, -1, PERF_FLAG_PID_CGROUP); perror("perf_event_open"); close(fd); return 0; } Signed-off-by: Salman Qazi Signed-off-by: Peter Zijlstra Acked-by: Tejun Heo Link: http://lkml.kernel.org/r/20120614223108.1025.2503.stgit@dungbeetle.mtv.corp.google.com Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit d8d7b731f1f799f225f0c968ccb0508397657d87 Author: Daniel Santos Date: Thu Oct 4 17:15:05 2012 -0700 kernel-doc: bugfix - multi-line macros commit 654784284430bf2739985914b65e09c7c35a7273 upstream. Prior to this patch the following code breaks: /** * multiline_example - this breaks kernel-doc */ #define multiline_example( \ myparam) Producing this error: Error(somefile.h:983): cannot understand prototype: 'multiline_example( \ ' This patch fixes the issue by appending all lines ending in a blackslash (optionally followed by whitespace), removing the backslash and any whitespace after it prior to appending (just like the C pre-processor would). This fixes a break in kerel-doc introduced by the additions to rbtree.h. Signed-off-by: Daniel Santos Cc: Randy Dunlap Cc: Michal Marek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 587e5bf9a64470d080aab287d95c11a43b777cc5 Author: Kirill Tkhai Date: Fri Jul 26 01:17:15 2013 +0400 sparc32: Fix exit flag passed from traced sys_sigreturn [ Upstream commit 7a3b0f89e3fea680f93932691ca41a68eee7ab5e ] Pass 1 in %o1 to indicate that syscall_trace accounts exit. Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 7af4fd8cf2529729f2981f10a83f7c277c1ec684 Author: Kirill Tkhai Date: Fri Jul 26 17:21:12 2013 +0400 sparc64: Fix not SRA'ed %o5 in 32-bit traced syscall [ Upstream commit ab2abda6377723e0d5fbbfe5f5aa16a5523344d1 ] (From v1 to v2: changed comment) On the way linux_sparc_syscall32->linux_syscall_trace32->goto 2f, register %o5 doesn't clear its second 32-bit. Fix that. Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e1b92701b2b5e1b2ee1f181075ca6df4cef667e4 Author: David S. Miller Date: Thu Aug 22 16:38:46 2013 -0700 sparc64: Fix off by one in trampoline TLB mapping installation loop. [ Upstream commit 63d499662aeec1864ec36d042aca8184ea6a938e ] Reported-by: Kirill Tkhai Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit b108c975f4d210be89eacdec93bf8d34e7edbcc6 Author: Kirill Tkhai Date: Mon Aug 12 16:02:24 2013 +0400 sparc64: Remove RWSEM export leftovers [ Upstream commit 61d9b9355b0d427bd1e732bd54628ff9103e496f ] The functions __down_read __down_read_trylock __down_write __down_write_trylock __up_read __up_write __downgrade_write are implemented inline, so remove corresponding EXPORT_SYMBOLs (They lead to compile errors on RT kernel). Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 19452ae3b32db6b1c33f9248f36f188fb439cc77 Author: Kirill Tkhai Date: Fri Aug 2 19:23:18 2013 +0400 sparc64: Fix ITLB handler of null page [ Upstream commit 1c2696cdaad84580545a2e9c0879ff597880b1a9 ] 1)Use kvmap_itlb_longpath instead of kvmap_dtlb_longpath. 2)Handle page #0 only, don't handle page #1: bleu -> blu (KERNBASE is 0x400000, so #1 does not exist too. But everything is possible in the future. Fix to not to have problems later.) 3)Remove unused kvmap_itlb_nonlinear. Signed-off-by: Kirill Tkhai CC: David Miller Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 49e3d709efa929fc179531a0bff55df92520b432 Author: David S. Miller Date: Thu Aug 1 18:08:34 2013 -0700 esp_scsi: Fix tag state corruption when autosensing. [ Upstream commit 21af8107f27878813d0364733c0b08813c2c192a ] Meelis Roos reports a crash in esp_free_lun_tag() in the presense of a disk which has died. The issue is that when we issue an autosense command, we do so by hijacking the original command that caused the check-condition. When we do so we clear out the ent->tag[] array when we issue it via find_and_prep_issuable_command(). This is so that the autosense command is forced to be issued non-tagged. That is problematic, because it is the value of ent->tag[] which determines whether we issued the original scsi command as tagged vs. non-tagged (see esp_alloc_lun_tag()). And that, in turn, is what trips up the sanity checks in esp_free_lun_tag(). That function needs the original ->tag[] values in order to free up the tag slot properly. Fix this by remembering the original command's tag values, and having esp_alloc_lun_tag() and esp_free_lun_tag() use them. Reported-by: Meelis Roos Tested-by: Meelis Roos Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit a82dc4e1e4c628f23c14fc48ce72ae0b56a68db8 Author: Ricardo Ribalda Date: Tue Oct 1 08:17:10 2013 +0200 ll_temac: Reset dma descriptors indexes on ndo_open [ Upstream commit 7167cf0e8cd10287b7912b9ffcccd9616f382922 ] The dma descriptors indexes are only initialized on the probe function. If a packet is on the buffer when temac_stop is called, the dma descriptors indexes can be left on a incorrect state where no other package can be sent. So an interface could be left in an usable state after ifdow/ifup. This patch makes sure that the descriptors indexes are in a proper status when the device is open. Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 765844f8edd831563fc646c7f747abf89eef4d4d Author: Salam Noureddine Date: Sun Sep 29 13:41:34 2013 -0700 ipv6 mcast: use in6_dev_put in timer handlers instead of __in6_dev_put [ Upstream commit 9260d3e1013701aa814d10c8fc6a9f92bd17d643 ] It is possible for the timer handlers to run after the call to ipv6_mc_down so use in6_dev_put instead of __in6_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the inet6_dev being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by: Salam Noureddine Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 003efcca2ad3e471e9103688a715bd33e29cb37b Author: Salam Noureddine Date: Sun Sep 29 13:39:42 2013 -0700 ipv4 igmp: use in_dev_put in timer handlers instead of __in_dev_put [ Upstream commit e2401654dd0f5f3fb7a8d80dad9554d73d7ca394 ] It is possible for the timer handlers to run after the call to ip_mc_down so use in_dev_put instead of __in_dev_put in the handler function in order to do proper cleanup when the refcnt reaches 0. Otherwise, the refcnt can reach zero without the in_device being destroyed and we end up leaking a reference to the net_device and see messages like the following, unregister_netdevice: waiting for eth0 to become free. Usage count = 1 Tested on linux-3.4.43. Signed-off-by: Salam Noureddine Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 1d49f0ffe3731e90677c3a1cab524f144a06c48f Author: Neil Horman Date: Fri Sep 27 12:22:15 2013 -0400 bonding: Fix broken promiscuity reference counting issue [ Upstream commit 5a0068deb611109c5ba77358be533f763f395ee4 ] Recently grabbed this report: https://bugzilla.redhat.com/show_bug.cgi?id=1005567 Of an issue in which the bonding driver, with an attached vlan encountered the following errors when bond0 was taken down and back up: dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of device might be broken. The error occurs because, during __bond_release_one, if we release our last slave, we take on a random mac address and issue a NETDEV_CHANGEADDR notification. With an attached vlan, the vlan may see that the vlan and bond mac address were in sync, but no longer are. This triggers a call to dev_uc_add and dev_set_rx_mode, which enables IFF_PROMISC on the bond device. Then, when we complete __bond_release_one, we use the current state of the bond flags to determine if we should decrement the promiscuity of the releasing slave. But since the bond changed promiscuity state during the release operation, we incorrectly decrement the slave promisc count when it wasn't in promiscuous mode to begin with, causing the above error Fix is pretty simple, just cache the bonding flags at the start of the function and use those when determining the need to set promiscuity. This is also needed for the ALLMULTI flag CC: Jay Vosburgh CC: Andy Gospodarek CC: Mark Wu CC: "David S. Miller" Reported-by: Mark Wu Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 710cfab1cd10b1c227ddd20df646bd9e5494aa46 Author: Peter Korsgaard Date: Mon Sep 30 23:28:20 2013 +0200 dm9601: fix IFF_ALLMULTI handling [ Upstream commit bf0ea6380724beb64f27a722dfc4b0edabff816e ] Pass-all-multicast is controlled by bit 3 in RX control, not bit 2 (pass undersized frames). Reported-by: Joseph Chang Signed-off-by: Peter Korsgaard Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 10c25bb9fa4fe65ccf6492c8d8e77b2ce5b634f3 Author: Roger Luethi Date: Sat Sep 21 14:24:11 2013 +0200 via-rhine: fix VLAN priority field (PCP, IEEE 802.1p) [ Upstream commit 207070f5221e2a901d56a49df9cde47d9b716cd7 ] Outgoing packets sent by via-rhine have their VLAN PCP field off by one (when hardware acceleration is enabled). The TX descriptor expects only VID and PCP (without a CFI/DEI bit). Peter Boström noticed and reported the bug. Signed-off-by: Roger Luethi Cc: Peter Boström Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit e381c716ed158b0b77879625fa58929f1a59a940 Author: Hannes Frederic Sowa Date: Sat Sep 21 06:27:00 2013 +0200 ipv6: udp packets following an UFO enqueued packet need also be handled by UFO [ Upstream commit 2811ebac2521ceac84f2bdae402455baa6a7fb47 ] In the following scenario the socket is corked: If the first UDP packet is larger then the mtu we try to append it to the write queue via ip6_ufo_append_data. A following packet, which is smaller than the mtu would be appended to the already queued up gso-skb via plain ip6_append_data. This causes random memory corruptions. In ip6_ufo_append_data we also have to be careful to not queue up the same skb multiple times. So setup the gso frame only when no first skb is available. This also fixes a shortcoming where we add the current packet's length to cork->length but return early because of a packet > mtu with dontfrag set (instead of sutracting it again). Found with trinity. Cc: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Reported-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit dee5590a22d03d7e974ef6956747d717ef5de061 Author: Ansis Atteka Date: Wed Sep 18 15:29:53 2013 -0700 ip: generate unique IP identificator if local fragmentation is allowed [ Upstream commit 703133de331a7a7df47f31fb9de51dc6f68a9de8 ] If local fragmentation is allowed, then ip_select_ident() and ip_select_ident_more() need to generate unique IDs to ensure correct defragmentation on the peer. For example, if IPsec (tunnel mode) has to encrypt large skbs that have local_df bit set, then all IP fragments that belonged to different ESP datagrams would have used the same identificator. If one of these IP fragments would get lost or reordered, then peer could possibly stitch together wrong IP fragments that did not belong to the same datagram. This would lead to a packet loss or data corruption. Signed-off-by: Ansis Atteka Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 669c81001fd0bd914fb2a1c15ddbb427de8a8373 Author: Chris Healy Date: Wed Sep 11 21:37:47 2013 -0700 resubmit bridge: fix message_age_timer calculation [ Upstream commit 9a0620133ccce9dd35c00a96405c8d80938c2cc0 ] This changes the message_age_timer calculation to use the BPDU's max age as opposed to the local bridge's max age. This is in accordance with section 8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification. With the current implementation, when running with very large bridge diameters, convergance will not always occur even if a root bridge is configured to have a longer max age. Tested successfully on bridge diameters of ~200. Signed-off-by: Chris Healy Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit af7e0f4a91ca9049ee9e541f8a98e762a12e9b9b Author: Daniel Borkmann Date: Wed Sep 11 16:58:36 2013 +0200 net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit [ Upstream commit 95ee62083cb6453e056562d91f597552021e6ae7 ] Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport does not seem to have the desired effect: SCTP + IPv4: 22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116) 192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72 22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340) 192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1): SCTP + IPv6: 22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364) fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp 1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10] Moreover, Alan says: This problem was seen with both Racoon and Racoon2. Other people have seen this with OpenSwan. When IPsec is configured to encrypt all upper layer protocols the SCTP connection does not initialize. After using Wireshark to follow packets, this is because the SCTP packet leaves Box A unencrypted and Box B believes all upper layer protocols are to be encrypted so it drops this packet, causing the SCTP connection to fail to initialize. When IPsec is configured to encrypt just SCTP, the SCTP packets are observed unencrypted. In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext" string on the other end, results in cleartext on the wire where SCTP eventually does not report any errors, thus in the latter case that Alan reports, the non-paranoid user might think he's communicating over an encrypted transport on SCTP although he's not (tcpdump ... -X): ... 0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000 ]p.......}.l.... 0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000 ....plaintext... Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the receiver side. Initial follow-up analysis from Alan's bug report was done by Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this. SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit(). This has the implication that it probably never really got updated along with changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers. SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since a call to inet6_csk_xmit() would solve this problem, but result in unecessary route lookups, let us just use the cached flowi6 instead that we got through sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(), we do the route lookup / flow caching in sctp_transport_route(), hold it in tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst() instead to get the correct source routed dst entry, which we assign to the skb. Also source address routing example from 625034113 ("sctp: fix sctp to work with ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095 it is actually 'recommended' to not use that anyway due to traffic amplification [1]. So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if we overwrite the flow destination here, the lower IPv6 layer will be unable to put the correct destination address into IP header, as routing header is added in ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside, result of this patch is that we do not have any XfrmInTmplMismatch increase plus on the wire with this patch it now looks like: SCTP + IPv6: 08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba: AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72 08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a: AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296 This fixes Kernel Bugzilla 24412. This security issue seems to be present since 2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have its fun with that. lksctp-tools IPv6 regression test suite passes as well with this patch. [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf Reported-by: Alan Chester Reported-by: Alexey Dobriyan Signed-off-by: Daniel Borkmann Cc: Steffen Klassert Cc: Hannes Frederic Sowa Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 2eb90b30797b3c908b597e4a2a700d6ef9ae0196 Author: Nikolay Aleksandrov Date: Thu Sep 19 15:02:35 2013 +0200 netpoll: fix NULL pointer dereference in netpoll_cleanup [ Upstream commit d0fe8c888b1fd1a2f84b9962cabcb98a70988aec ] I've been hitting a NULL ptr deref while using netconsole because the np->dev check and the pointer manipulation in netpoll_cleanup are done without rtnl and the following sequence happens when having a netconsole over a vlan and we remove the vlan while disabling the netconsole: CPU 1 CPU2 removes vlan and calls the notifier enters store_enabled(), calls netdev_cleanup which checks np->dev and then waits for rtnl executes the netconsole netdev release notifier making np->dev == NULL and releases rtnl continues to dereference a member of np->dev which at this point is == NULL Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 836f6cb46716e36cb8d31a402c6661af5c895135 Author: Daniel Borkmann Date: Sat Sep 7 20:51:21 2013 +0200 net: sctp: fix smatch warning in sctp_send_asconf_del_ip [ Upstream commit 88362ad8f9a6cea787420b57cc27ccacef000dbe ] This was originally reported in [1] and posted by Neil Horman [2], he said: Fix up a missed null pointer check in the asconf code. If we don't find a local address, but we pass in an address length of more than 1, we may dereference a NULL laddr pointer. Currently this can't happen, as the only users of the function pass in the value 1 as the addrcnt parameter, but its not hot path, and it doesn't hurt to check for NULL should that ever be the case. The callpath from sctp_asconf_mgmt() looks okay. But this could be triggered from sctp_setsockopt_bindx() call with SCTP_BINDX_REM_ADDR and addrcnt > 1 while passing all possible addresses from the bind list to SCTP_BINDX_REM_ADDR so that we do *not* find a single address in the association's bind address list that is not in the packed array of addresses. If this happens when we have an established association with ASCONF-capable peers, then we could get a NULL pointer dereference as we only check for laddr == NULL && addrcnt == 1 and call later sctp_make_asconf_update_ip() with NULL laddr. BUT: this actually won't happen as sctp_bindx_rem() will catch such a case and return with an error earlier. As this is incredably unintuitive and error prone, add a check to catch at least future bugs here. As Neil says, its not hot path. Introduced by 8a07eb0a5 ("sctp: Add ASCONF operation on the single-homed host"). [1] http://www.spinics.net/lists/linux-sctp/msg02132.html [2] http://www.spinics.net/lists/linux-sctp/msg02133.html Reported-by: Dan Carpenter Signed-off-by: Neil Horman Signed-off-by: Daniel Borkmann Cc: Michio Honda Acked-By: Neil Horman Acked-by: Vlad Yasevich Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit b7def7d7b236bd3e90df969ac9b3540777619c57 Author: Dave Jones Date: Thu Sep 5 00:11:19 2013 -0400 caif: Add missing braces to multiline if in cfctrl_linkup_request [ Upstream commit 0c1db731bfcf3a9fd6c58132134f8b0f423552f0 ] The indentation here implies this was meant to be a multi-line if. Introduced several years back in commit c85c2951d4da1236e32f1858db418221e624aba5 ("caif: Handle dev_queue_xmit errors.") Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit 21958b854649fcd3a7b50db4f00573d488da1edb Author: Nishanth Aravamudan Date: Tue Oct 1 14:04:53 2013 -0700 powerpc/iommu: Use GFP_KERNEL instead of GFP_ATOMIC in iommu_init_table() commit 1cf389df090194a0976dc867b7fffe99d9d490cb upstream. Under heavy (DLPAR?) stress, we tripped this panic() in arch/powerpc/kernel/iommu.c::iommu_init_table(): page = alloc_pages_node(nid, GFP_ATOMIC, get_order(sz)); if (!page) panic("iommu_init_table: Can't allocate %ld bytes\n", sz); Before the panic() we got a page allocation failure for an order-2 allocation. There appears to be memory free, but perhaps not in the ATOMIC context. I looked through all the call-sites of iommu_init_table() and didn't see any obvious reason to need an ATOMIC allocation. Most call-sites in fact have an explicit GFP_KERNEL allocation shortly before the call to iommu_init_table(), indicating we are not in an atomic context. There is some indirection for some paths, but I didn't see any locks indicating that GFP_KERNEL is inappropriate. With this change under the same conditions, we have not been able to reproduce the panic. Signed-off-by: Nishanth Aravamudan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit 28cfcc851d5c8a7075ea8bb9b8695bb376f6872d Author: Madhavan Srinivasan Date: Wed Oct 2 00:34:10 2013 +0530 powerpc/sysfs: Disable writing to PURR in guest mode commit d1211af3049f4c9c1d8d4eb8f8098cc4f4f0d0c7 upstream. arch/powerpc/kernel/sysfs.c exports PURR with write permission. This may be valid for kernel in phyp mode. But writing to the file in guest mode causes crash due to a priviledge violation Signed-off-by: Madhavan Srinivasan Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: - Adjust context - CPUs are sysdev and we must use the sysdev API] Signed-off-by: Ben Hutchings commit 0b2d10f8f2e686c9f4b718251765f09f77ee8088 Author: Paul E. McKenney Date: Tue Oct 1 17:11:35 2013 +1000 powerpc: Restore registers on error exit from csum_partial_copy_generic() commit 8f21bd0090052e740944f9397e2be5ac7957ded7 upstream. The csum_partial_copy_generic() function saves the PowerPC non-volatile r14, r15, and r16 registers for the main checksum-and-copy loop. Unfortunately, it fails to restore them upon error exit from this loop, which results in silent corruption of these registers in the presumably rare event of an access exception within that loop. This commit therefore restores these register on error exit from the loop. Signed-off-by: Paul E. McKenney Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt [bwh: Backported to 3.2: register name macros use lower-case 'r'] Signed-off-by: Ben Hutchings commit 13ce0c4a399a654effc40a9a57e87ac23cf19267 Author: Paul E. McKenney Date: Tue Oct 1 16:54:05 2013 +1000 powerpc: Fix parameter clobber in csum_partial_copy_generic() commit d9813c3681a36774b254c0cdc9cce53c9e22c756 upstream. The csum_partial_copy_generic() uses register r7 to adjust the remaining bytes to process. Unfortunately, r7 also holds a parameter, namely the address of the flag to set in case of access exceptions while reading the source buffer. Lacking a quantum implementation of PowerPC, this commit instead uses register r9 to do the adjusting, leaving r7's pointer uncorrupted. Signed-off-by: Paul E. McKenney Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Ben Hutchings commit 408318734877aca9f11a8d7d1835456305c61f4d Author: Michal Malý Date: Sat Sep 28 19:50:27 2013 +0200 USB: serial: option: Ignore card reader interface on Huawei E1750 commit eb2addd4044b4b2ce77693bde5bc810536dd96ee upstream. Hi, my Huawei 3G modem has an embedded Smart Card reader which causes trouble when the modem is being detected (a bunch of " (ttyUSBx): open blocked by driver for more than 7 seconds!" in messages.log). This trivial patch corrects the problem for me. The modem identifies itself as "12d1:1406 Huawei Technologies Co., Ltd. E1750" in lsusb although the description on the body says "Model E173u-1" Signed-off-by: Michal Malý Cc: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ccebcc74c81d8399c7b204aea47c1f33b09c2b17 Author: Vyacheslav Dubeyko Date: Mon Sep 30 13:45:12 2013 -0700 nilfs2: fix issue with race condition of competition between segments for dirty blocks commit 7f42ec3941560f0902fe3671e36f2c20ffd3af0a upstream. Many NILFS2 users were reported about strange file system corruption (for example): NILFS: bad btree node (blocknr=185027): level = 0, flags = 0x0, nchildren = 768 NILFS error (device sda4): nilfs_bmap_last_key: broken bmap (inode number=11540) But such error messages are consequence of file system's issue that takes place more earlier. Fortunately, Jerome Poulin and Anton Eliasson were reported about another issue not so recently. These reports describe the issue with segctor thread's crash: BUG: unable to handle kernel paging request at 0000000000004c83 IP: nilfs_end_page_io+0x12/0xd0 [nilfs2] Call Trace: nilfs_segctor_do_construct+0xf25/0x1b20 [nilfs2] nilfs_segctor_construct+0x17b/0x290 [nilfs2] nilfs_segctor_thread+0x122/0x3b0 [nilfs2] kthread+0xc0/0xd0 ret_from_fork+0x7c/0xb0 These two issues have one reason. This reason can raise third issue too. Third issue results in hanging of segctor thread with eating of 100% CPU. REPRODUCING PATH: One of the possible way or the issue reproducing was described by Jermoe me Poulin : 1. init S to get to single user mode. 2. sysrq+E to make sure only my shell is running 3. start network-manager to get my wifi connection up 4. login as root and launch "screen" 5. cd /boot/log/nilfs which is a ext3 mount point and can log when NILFS dies. 6. lscp | xz -9e > lscp.txt.xz 7. mount my snapshot using mount -o cp=3360839,ro /dev/vgUbuntu/root /mnt/nilfs 8. start a screen to dump /proc/kmsg to text file since rsyslog is killed 9. start a screen and launch strace -f -o find-cat.log -t find /mnt/nilfs -type f -exec cat {} > /dev/null \; 10. start a screen and launch strace -f -o apt-get.log -t apt-get update 11. launch the last command again as it did not crash the first time 12. apt-get crashes 13. ps aux > ps-aux-crashed.log 13. sysrq+W 14. sysrq+E wait for everything to terminate 15. sysrq+SUSB Simplified way of the issue reproducing is starting kernel compilation task and "apt-get update" in parallel. REPRODUCIBILITY: The issue is reproduced not stable [60% - 80%]. It is very important to have proper environment for the issue reproducing. The critical conditions for successful reproducing: (1) It should have big modified file by mmap() way. (2) This file should have the count of dirty blocks are greater that several segments in size (for example, two or three) from time to time during processing. (3) It should be intensive background activity of files modification in another thread. INVESTIGATION: First of all, it is possible to see that the reason of crash is not valid page address: NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82 NILFS [nilfs_segctor_complete_write]:2101 segbuf->sb_segnum 6783 Moreover, value of b_page (0x1a82) is 6786. This value looks like segment number. And b_blocknr with b_size values look like block numbers. So, buffer_head's pointer points on not proper address value. Detailed investigation of the issue is discovered such picture: [-----------------------------SEGMENT 6783-------------------------------] NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111149024, segbuf->sb_segnum 6783 [-----------------------------SEGMENT 6784-------------------------------] NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff8802174a6798, bh->b_assoc_buffers.prev ffff880221cffee8 NILFS [nilfs_segctor_do_construct]:2336 nilfs_segctor_assign NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 1, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6784 NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50 NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111150080, segbuf->sb_segnum 6784, segbuf->sb_nbio 0 [----------] ditto NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111164416, segbuf->sb_segnum 6784, segbuf->sb_nbio 15 [-----------------------------SEGMENT 6785-------------------------------] NILFS [nilfs_segctor_do_construct]:2310 nilfs_segctor_begin_construction NILFS [nilfs_segctor_do_construct]:2321 nilfs_segctor_collect NILFS [nilfs_lookup_dirty_data_buffers]:782 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_lookup_dirty_data_buffers]:783 bh->b_assoc_buffers.next ffff880219277e80, bh->b_assoc_buffers.prev ffff880221cffc88 NILFS [nilfs_segctor_do_construct]:2367 nilfs_segctor_update_segusage NILFS [nilfs_segctor_do_construct]:2371 nilfs_segctor_prepare_write NILFS [nilfs_segctor_do_construct]:2376 nilfs_add_checksums_on_logs NILFS [nilfs_segctor_do_construct]:2381 nilfs_segctor_write NILFS [nilfs_segbuf_submit_bh]:575 bh->b_count 2, bh->b_page ffffea000709b000, page->index 0, i_ino 1033103, i_size 25165824 NILFS [nilfs_segbuf_submit_bh]:576 segbuf->sb_segnum 6785 NILFS [nilfs_segbuf_submit_bh]:577 bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8 NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111165440, segbuf->sb_segnum 6785, segbuf->sb_nbio 0 [----------] ditto NILFS [nilfs_segbuf_submit_bio]:464 bio->bi_sector 111177728, segbuf->sb_segnum 6785, segbuf->sb_nbio 12 NILFS [nilfs_segctor_do_construct]:2399 nilfs_segctor_wait NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6783 NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6784 NILFS [nilfs_segbuf_wait]:676 segbuf->sb_segnum 6785 NILFS [nilfs_segctor_complete_write]:2100 bh->b_count 0, bh->b_blocknr 13895680, bh->b_size 13897727, bh->b_page 0000000000001a82 BUG: unable to handle kernel paging request at 0000000000001a82 IP: [] nilfs_end_page_io+0x12/0xd0 [nilfs2] Usually, for every segment we collect dirty files in list. Then, dirty blocks are gathered for every dirty file, prepared for write and submitted by means of nilfs_segbuf_submit_bh() call. Finally, it takes place complete write phase after calling nilfs_end_bio_write() on the block layer. Buffers/pages are marked as not dirty on final phase and processed files removed from the list of dirty files. It is possible to see that we had three prepare_write and submit_bio phases before segbuf_wait and complete_write phase. Moreover, segments compete between each other for dirty blocks because on every iteration of segments processing dirty buffer_heads are added in several lists of payload_buffers: [SEGMENT 6784]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880218bcdf50 [SEGMENT 6785]: bh->b_assoc_buffers.next ffff880218a0d5f8, bh->b_assoc_buffers.prev ffff880222cc7ee8 The next pointer is the same but prev pointer has changed. It means that buffer_head has next pointer from one list but prev pointer from another. Such modification can be made several times. And, finally, it can be resulted in various issues: (1) segctor hanging, (2) segctor crashing, (3) file system metadata corruption. FIX: This patch adds: (1) setting of BH_Async_Write flag in nilfs_segctor_prepare_write() for every proccessed dirty block; (2) checking of BH_Async_Write flag in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_dirty_node_buffers(); (3) clearing of BH_Async_Write flag in nilfs_segctor_complete_write(), nilfs_abort_logs(), nilfs_forget_buffer(), nilfs_clear_dirty_page(). Reported-by: Jerome Poulin Reported-by: Anton Eliasson Cc: Paul Fertser Cc: ARAI Shun-ichi Cc: Piotr Szymaniak Cc: Juan Barry Manuel Canham Cc: Zahid Chowdhury Cc: Elmer Zhang Cc: Kenneth Langga Signed-off-by: Vyacheslav Dubeyko Acked-by: Ryusuke Konishi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: nilfs_clear_dirty_page() has not been separated from nilfs_clear_dirty_pages()] Signed-off-by: Ben Hutchings commit 4ec4a1dc57b7822ff5fc2cbe8aa19d0b4eaa70bd Author: Marc Kleine-Budde Date: Fri Sep 27 12:15:05 2013 +0200 can: flexcan: fix flexcan_chip_start() on imx6 commit 0d1862ea1a5bb876cf05555a7307080cb75bf379 upstream. In the flexcan_chip_start() function first the flexcan core is going through the soft reset sequence, then the RX FIFO is enabled. With the hardware is put into FIFO mode, message buffers 1...7 are reserved by the FIFO engine. The remaining message buffers are in reset default values. This patch removes the bogus initialization of the message buffers, as it causes an imprecise external abort on imx6. Reported-by: Lothar Waßmann Tested-by: Lothar Waßmann Signed-off-by: Marc Kleine-Budde Signed-off-by: Ben Hutchings commit 798761949ee8ddb4a25888cf7c0722fbacbc70cc Author: David Cohen Date: Thu Sep 26 13:01:44 2013 -0700 usb: dwc3: add support for Merrifield commit 85601f8cf67c56a561a6dd5e130e65fdc179047d upstream. Add PCI id for Intel Merrifield Signed-off-by: David Cohen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 47bd9ac912fe4b2f1f38efec89c3fe19628d6287 Author: Heikki Krogerus Date: Tue Sep 17 10:38:13 2013 +0300 usb: dwc3: pci: add support for BayTrail commit b62cd96de3161dfb125a769030eec35a4cab3d3a upstream. Add PCI id for Intel BayTrail. Signed-off-by: Heikki Krogerus Signed-off-by: Felipe Balbi Signed-off-by: Ben Hutchings commit 6f95357cb8bba2debf6b29347f4334e3cc12f897 Author: Christian Lamparter Date: Tue Sep 24 21:56:46 2013 +0200 p54usb: add USB ID for Corega WLUSB2GTST USB adapter commit 1e43692cdb7cc445d6347d8a5207d9cef0c71434 upstream. Added USB ID for Corega WLUSB2GTST USB adapter. Reported-by: Joerg Kalisch Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit e9c2770cfd8038419657e596410ce42bdb2e1a5b Author: Larry Finger Date: Wed Sep 18 21:21:35 2013 -0500 rtlwifi: Align private space in rtl_priv struct commit 60ce314d1750fef843e9db70050e09e49f838b69 upstream. The private array at the end of the rtl_priv struct is not aligned. On ARM architecture, this causes an alignment trap and is fixed by aligning that array with __align(sizeof(void *)). That should properly align that space according to the requirements of all architectures. Reported-by: Jason Andrews Tested-by: Jason Andrews Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings commit 571d473b0b99c8035fa8df8d1fbbac5b00814bb6 Author: Henrik Rydberg Date: Thu Sep 26 08:33:16 2013 +0200 hwmon: (applesmc) Check key count before proceeding commit 5f4513864304672e6ea9eac60583eeac32e679f2 upstream. After reports from Chris and Josh Boyer of a rare crash in applesmc, Guenter pointed at the initialization problem fixed below. The patch has not been verified to fix the crash, but should be applied regardless. Reported-by: Suggested-by: Guenter Roeck Signed-off-by: Henrik Rydberg Signed-off-by: Guenter Roeck Signed-off-by: Ben Hutchings commit 29003506beae5ad634f002d16cd73543337e2a26 Author: Kurt Garloff Date: Tue Sep 24 14:13:48 2013 +0200 usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit commit 831abf76643555a99b80a3b54adfa7e4fa0a3259 upstream. Trying to read data from the Pegasus Technologies NoteTaker (0e20:0101) [1] with the Windows App (EasyNote) works natively but fails when Windows is running under KVM (and the USB device handed to KVM). The reason is a USB control message usb 4-2.2: control urb: bRequestType=22 bRequest=09 wValue=0200 wIndex=0001 wLength=0008 This goes to endpoint address 0x01 (wIndex); however, endpoint address 0x01 does not exist. There is an endpoint 0x81 though (same number, but other direction); the app may have meant that endpoint instead. The kernel thus rejects the IO and thus we see the failure. Apparently, Linux is more strict here than Windows ... we can't change the Win app easily, so that's a problem. It seems that the Win app/driver is buggy here and the driver does not behave fully according to the USB HID class spec that it claims to belong to. The device seems to happily deal with that though (and seems to not really care about this value much). So the question is whether the Linux kernel should filter here. Rejecting has the risk that somewhat non-compliant userspace apps/ drivers (most likely in a virtual machine) are prevented from working. Not rejecting has the risk of confusing an overly sensitive device with such a transfer. Given the fact that Windows does not filter it makes this risk rather small though. The patch makes the kernel more tolerant: If the endpoint address in wIndex does not exist, but an endpoint with toggled direction bit does, it will let the transfer through. (It does NOT change the message.) With attached patch, the app in Windows in KVM works. usb 4-2.2: check_ctrlrecip: process 13073 (qemu-kvm) requesting ep 01 but needs 81 I suspect this will mostly affect apps in virtual environments; as on Linux the apps would have been adapted to the stricter handling of the kernel. I have done that for mine[2]. [1] http://www.pegatech.com/ [2] https://sourceforge.net/projects/notetakerpen/ Signed-off-by: Kurt Garloff Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit c9e34fa1d28f3e04e9fbe4cdce5aa9a70c4952f6 Author: Alan Stern Date: Tue Sep 24 15:45:25 2013 -0400 USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd commit f875fdbf344b9fde207f66b392c40845dd7e5aa6 upstream. Since uhci-hcd, ehci-hcd, and xhci-hcd support runtime PM, the .pm field in their pci_driver structures should be protected by CONFIG_PM rather than CONFIG_PM_SLEEP. The corresponding change has already been made for ohci-hcd. Without this change, controllers won't do runtime suspend if system suspend or hibernation isn't enabled. Signed-off-by: Alan Stern CC: Sarah Sharp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 7db4eda80eb05f7b0a6c7771920a2eea011b4f80 Author: Malcolm Priestley Date: Sun Sep 22 19:48:54 2013 +0100 staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier. commit e3eb270fab7734427dd8171a93e4946fe28674bc upstream. The vt6656 is prone to resetting on the usb bus. It seems there is a race condition and wpa supplicant is trying to open the device via iw_handlers before its actually closed at a stage that the buffers are being removed. The device is longer considered open when the buffers are being removed. So move ~DEVICE_FLAGS_OPENED flag to before freeing the device buffers. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 5c1a25b78eb6480c0c708e21fd746cf8b4dae9e7 Author: Jani Nikula Date: Fri Sep 20 16:42:15 2013 +0300 drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER commit 8d16f258217f2f583af1fd57c5144aa4bbe73e48 upstream. There is no clear cut rules or specs for the retry interval, as there are many factors that affect overall response time. Increase the interval, and even more so on branch devices which may have limited i2c bit rates. Signed-off-by: Jani Nikula Reference: https://bugs.freedesktop.org/show_bug.cgi?id=60263 Tested-by: Nicolas Suzor Reviewed-by: Todd Previte Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings commit e69de31ca0e0517bee4a99556b443fbde75ede6a Author: Alex Deucher Date: Mon Sep 23 10:38:26 2013 -0400 drm/radeon: disable tests/benchmarks if accel is disabled commit 4a1132a023eb48cf10522d84c5908d43b612c041 upstream. The tests are only usable if the acceleration engines have been successfully initialized. Based on an initial patch from: Alex Ivanov Signed-off-by: Alex Deucher [bwh: Backported to 3.2: there is only one test: radeon_test_moves()] Signed-off-by: Ben Hutchings commit f3986574eb0563e306cd88d529700a4eef4fb330 Author: Masoud Sharbiani Date: Fri Sep 20 15:59:07 2013 -0700 x86/reboot: Add quirk to make Dell C6100 use reboot=pci automatically commit 4f0acd31c31f03ba42494c8baf6c0465150e2621 upstream. Dell PowerEdge C6100 machines fail to completely reboot about 20% of the time. Signed-off-by: Masoud Sharbiani Signed-off-by: Vinson Lee Cc: Robin Holt Cc: Russell King Cc: Guan Xuetao Link: http://lkml.kernel.org/r/1379717947-18042-1-git-send-email-vlee@freedesktop.org Signed-off-by: Ingo Molnar