commit 382ae9d02089c819f93d64f86e433bb95574bff9 Author: Ben Hutchings Date: Sun May 18 14:58:10 2014 +0100 Linux 3.2.59 commit 629cbea2961ec001a85a4ac8821dcd45226dd29c Author: Matthew Daley Date: Mon Apr 28 19:05:21 2014 +1200 floppy: don't write kernel-only members to FDRAWCMD ioctl output commit 2145e15e0557a01b9195d1c7199a1b92cb9be81f upstream. Do not leak kernel-only floppy_raw_cmd structure members to userspace. This includes the linked-list pointer and the pointer to the allocated DMA space. Signed-off-by: Matthew Daley Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit d79119d4089defc81a49c6a7e26ff5ff86f4b342 Author: Matthew Daley Date: Mon Apr 28 19:05:20 2014 +1200 floppy: ignore kernel-only members in FDRAWCMD ioctl input commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c upstream. Always clear out these floppy_raw_cmd struct members after copying the entire structure from userspace so that the in-kernel version is always valid and never left in an interdeterminate state. Signed-off-by: Matthew Daley Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 1e5099713cefc67aa562f6d8fe43444f41baf52d Author: Peter Hurley Date: Sat May 3 14:04:59 2014 +0200 n_tty: Fix n_tty_write crash when echoing in raw mode commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream. The tty atomic_write_lock does not provide an exclusion guarantee for the tty driver if the termios settings are LECHO & !OPOST. And since it is unexpected and not allowed to call TTY buffer helpers like tty_insert_flip_string concurrently, this may lead to crashes when concurrect writers call pty_write. In that case the following two writers: * the ECHOing from a workqueue and * pty_write from the process race and can overflow the corresponding TTY buffer like follows. If we look into tty_insert_flip_string_fixed_flag, there is: int space = __tty_buffer_request_room(port, goal, flags); struct tty_buffer *tb = port->buf.tail; ... memcpy(char_buf_ptr(tb, tb->used), chars, space); ... tb->used += space; so the race of the two can result in something like this: A B __tty_buffer_request_room __tty_buffer_request_room memcpy(buf(tb->used), ...) tb->used += space; memcpy(buf(tb->used), ...) ->BOOM B's memcpy is past the tty_buffer due to the previous A's tb->used increment. Since the N_TTY line discipline input processing can output concurrently with a tty write, obtain the N_TTY ldisc output_lock to serialize echo output with normal tty writes. This ensures the tty buffer helper tty_insert_flip_string is not called concurrently and everything is fine. Note that this is nicely reproducible by an ordinary user using forkpty and some setup around that (raw termios + ECHO). And it is present in kernels at least after commit d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to use the normal buffering logic) in 2.6.31-rc3. js: add more info to the commit log js: switch to bool js: lock unconditionally js: lock only the tty->ops->write call References: CVE-2014-0196 Reported-and-tested-by: Jiri Slaby Signed-off-by: Peter Hurley Signed-off-by: Jiri Slaby Cc: Linus Torvalds Cc: Alan Cox Cc: Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: output_lock is a member of struct tty_struct] Signed-off-by: Ben Hutchings commit 11e835193b386b219260cc97ca01158d0e4ff58f Author: Ben Hutchings Date: Sat Apr 19 14:36:43 2014 +0100 rtl8192ce: Fix null dereference in watchdog Dmitry Semyonov reported that after upgrading from 3.2.54 to 3.2.57 the rtl8192ce driver will crash when its interface is brought up. The oops message shows: [ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 1833.611455] IP: [] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce] ... [ 1833.613326] Call Trace: [ 1833.613346] [] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common] [ 1833.613391] [] ? process_one_work+0x161/0x269 [ 1833.613425] [] ? worker_thread+0xc2/0x145 [ 1833.613458] [] ? manage_workers.isra.25+0x15b/0x15b [ 1833.613496] [] ? kthread+0x76/0x7e [ 1833.613527] [] ? kernel_thread_helper+0x4/0x10 [ 1833.613563] [] ? kthread_worker_fn+0x139/0x139 [ 1833.613598] [] ? gs_change+0x13/0x13 Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta' parameter was null. None of the changes to the rtlwifi family between 3.2.54 and 3.2.57 seem to directly cause this, and reverting commit f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs') doesn't fix it. rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the call trace as it was inlined. That function has been completely removed upstream which may explain why this crash wasn't seen there. I'm not sure that it is sensible to completely remove rtl92c_dm_refresh_rate_adaptive_mask() without making other compensating changes elsewhere, so try to work around this for 3.2 by checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask() and then skipping the call to rtl92ce_update_hal_rate_tbl(). References: https://bugs.debian.org/745137 References: https://bugs.debian.org/745462 Reported-by: Dmitry Semyonov Signed-off-by: Ben Hutchings Cc: Larry Finger Cc: Chaoming Li commit 74627ab15f07468eab311749ce4e225135daaa8b Author: Bjørn Mork Date: Fri Apr 25 18:49:20 2014 +0200 usb: option: add and update a number of CMOTech devices commit 34f972d6156fe9eea2ab7bb418c71f9d1d5c8e7b upstream. A number of older CMOTech modems are based on Qualcomm chips. The blacklisted interfaces are QMI/wwan. Reported-by: Lars Melin Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 809d883333e08d5f4da99a32ec8cabbf6f6cce8e Author: Bjørn Mork Date: Fri Apr 25 18:49:19 2014 +0200 usb: option: add Alcatel L800MA commit dd6b48ecec2ea7d15f28d5e5474388681899a5e1 upstream. Device interface layout: 0: ff/ff/ff - serial 1: ff/00/00 - serial AT+PPP 2: ff/ff/ff - QMI/wwan 3: 08/06/50 - storage Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit c0d47d94f551705439b22348dbe33189fc7ca0df Author: Bjørn Mork Date: Fri Apr 25 18:49:18 2014 +0200 usb: option: add Olivetti Olicard 500 commit 533b3994610f316e5cd61b56d0c4daa15c830f89 upstream. Device interface layout: 0: ff/ff/ff - serial 1: ff/ff/ff - serial AT+PPP 2: 08/06/50 - storage 3: ff/ff/ff - serial 4: ff/ff/ff - QMI/wwan Reported-by: Julio Araujo Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 83ad4b788fc49cdc9fce56e4147c7cfde3d97c6a Author: Johan Hovold Date: Fri Apr 25 15:23:03 2014 +0200 USB: io_ti: fix firmware download on big-endian machines commit 5509076d1b4485ce9fb07705fcbcd2695907ab5b upstream. During firmware download the device expects memory addresses in big-endian byte order. As the wIndex parameter which hold the address is sent in little-endian byte order regardless of host byte order, we need to use swab16 rather than cpu_to_be16. Also make sure to handle the struct ti_i2c_desc size parameter which is returned in little-endian byte order. Reported-by: Ludovic Drolez Tested-by: Ludovic Drolez Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 42eb6ec92202136f18b50f69d1bec89c14badc60 Author: David Cohen Date: Fri Apr 25 19:20:16 2014 +0300 usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM commit 01bb59ebffdec314da8da66266edf29529372f9b upstream. When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this warning: drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined but not used [-Wunused-function] Instead of creating nested #ifdefs, this patch fixes it by defining the xHCI PCI stubs as inline. This warning has been in since 3.2 kernel and was caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed until 3.13 when a configuration with these options was tried Signed-off-by: David Cohen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit b9c6d6dae2dc8dc5fe991eb3bdc34233d9262b80 Author: Julius Werner Date: Fri Apr 25 19:20:13 2014 +0300 usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb commit 1f81b6d22a5980955b01e08cf27fb745dc9b686f upstream. We have observed a rare cycle state desync bug after Set TR Dequeue Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that doesn't fetch new TRBs and thus an unresponsive USB device). It always triggers when a previous Set TR Dequeue Pointer command has set the pointer to the final Link TRB of a segment, and then another URB gets enqueued and cancelled again before it can be completed. Further investigation showed that the xHC had returned the Link TRB in the TRB Pointer field of the Transfer Event (CC == Stopped -- Length Invalid), but when xhci_find_new_dequeue_state() later accesses the Endpoint Context's TR Dequeue Pointer field it is set to the first TRB of the next segment. The driver expects those two values to be the same in this situation, and uses the cycle state of the latter together with the address of the former. This should be fine according to the XHCI specification, since the endpoint ring should be stopped when returning the Transfer Event and thus should not advance over the Link TRB before it gets restarted. However, real-world XHCI implementations apparently don't really care that much about these details, so the driver should follow a more defensive approach to try to work around HC spec violations. This patch removes the stopped_trb variable that had been used to store the TRB Pointer from the last Transfer Event of a stopped TRB. Instead, xhci_find_new_dequeue_state() now relies only on the Endpoint Context, requiring a small amount of additional processing to find the virtual address corresponding to the TR Dequeue Pointer. Some other parts of the function were slightly rearranged to better fit into this model. This patch should be backported to kernels as old as 2.6.31 that contain the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB cancellation support." Signed-off-by: Julius Werner Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 8723390b1062a845b02aa4666a2b565773f673ad Author: Hans de Goede Date: Fri Oct 4 00:29:47 2013 +0200 xhci: For streams the css flag most be read from the stream-ctx on ep stop commit c4bedb77ec4cb42f37cae4cbfddda8283161f7c8 upstream. Signed-off-by: Hans de Goede Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit d6db8ad79435e2bf42e446cc13ad135dd5ca1f71 Author: Miao Xie Date: Wed Apr 23 19:33:36 2014 +0800 Btrfs: fix inode caching vs tree log commit 1c70d8fb4dfa95bee491816b2a6767b5ca1080e7 upstream. Currently, with inode cache enabled, we will reuse its inode id immediately after unlinking file, we may hit something like following: |->iput inode |->return inode id into inode cache |->create dir,fsync |->power off An easy way to reproduce this problem is: mkfs.btrfs -f /dev/sdb mount /dev/sdb /mnt -o inode_cache,commit=100 dd if=/dev/zero of=/mnt/data bs=1M count=10 oflag=sync inode_id=`ls -i /mnt/data | awk '{print $1}'` rm -f /mnt/data i=1 while [ 1 ] do mkdir /mnt/dir_$i test1=`stat /mnt/dir_$i | grep Inode: | awk '{print $4}'` if [ $test1 -eq $inode_id ] then dd if=/dev/zero of=/mnt/dir_$i/data bs=1M count=1 oflag=sync echo b > /proc/sysrq-trigger fi sleep 1 i=$(($i+1)) done mount /dev/sdb /mnt umount /dev/sdb btrfs check /dev/sdb We fix this problem by adding unlinked inode's id into pinned tree, and we can not reuse them until committing transaction. Signed-off-by: Miao Xie Signed-off-by: Wang Shilong Signed-off-by: Chris Mason [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 8bbfb31d6b0eef58364978299a90bb37dc8e01f0 Author: Stefan Behrens Date: Tue Oct 15 20:08:15 2013 +0200 Btrfs: Don't allocate inode that is already in use commit ff76b0565523319d7c1c0b51d5a5a8915d33efab upstream. Due to an off-by-one error, it is possible to reproduce a bug when the inode cache is used. The same inode number is assigned twice, the second time this leads to an EEXIST in btrfs_insert_empty_items(). The issue can happen when a file is removed right after a subvolume is created and then a new inode number is created before the inodes in free_inode_pinned are processed. unlink() calls btrfs_return_ino() which calls start_caching() in this case which adds [highest_ino + 1, BTRFS_LAST_FREE_OBJECTID] by searching for the highest inode (which already cannot find the unlinked one anymore in btrfs_find_free_objectid()). So if this unlinked inode's number is equal to the highest_ino + 1 (or >= this value instead of > this value which was the off-by-one error), we mustn't add the inode number to free_ino_pinned (caching_thread() does it right). In this case we need to try directly to add the number to the inode_cache which will fail in this case. When this inode number is allocated while it is still in free_ino_pinned, it is allocated and still added to the free inode cache when the pinned inodes are processed, thus one of the following inode number allocations will get an inode that is already in use and fail with EEXIST in btrfs_insert_empty_items(). One example which was created with the reproducer below: Create a snapshot, work in the newly created snapshot for the rest. In unlink(inode 34284) call btrfs_return_ino() which calls start_caching(). start_caching() calls add_free_space [34284, 18446744073709517077]. In btrfs_return_ino(), call start_caching pinned [34284, 1] which is wrong. mkdir() call btrfs_find_ino_for_alloc() which returns the number 34284. btrfs_unpin_free_ino calls add_free_space [34284, 1]. mkdir() call btrfs_find_ino_for_alloc() which returns the number 34284. EEXIST when the new inode is inserted. One possible reproducer is this one: #!/bin/sh # preparation TEST_DEV=/dev/sdc1 TEST_MNT=/mnt umount ${TEST_MNT} 2>/dev/null || true mkfs.btrfs -f ${TEST_DEV} mount ${TEST_DEV} ${TEST_MNT} -o \ rw,relatime,compress=lzo,space_cache,inode_cache btrfs subv create ${TEST_MNT}/s1 for i in `seq 34027`; do touch ${TEST_MNT}/s1/${i}; done btrfs subv snap ${TEST_MNT}/s1 ${TEST_MNT}/s2 FILENAME=`find ${TEST_MNT}/s1/ -inum 4085 | sed 's|^.*/\([^/]*\)$|\1|'` rm ${TEST_MNT}/s2/$FILENAME touch ${TEST_MNT}/s2/$FILENAME # the following steps can be repeated to reproduce the issue again and again [ -e ${TEST_MNT}/s3 ] && btrfs subv del ${TEST_MNT}/s3 btrfs subv snap ${TEST_MNT}/s2 ${TEST_MNT}/s3 rm ${TEST_MNT}/s3/$FILENAME touch ${TEST_MNT}/s3/$FILENAME ls -alFi ${TEST_MNT}/s?/$FILENAME touch ${TEST_MNT}/s3/_1 || logger FAILED ls -alFi ${TEST_MNT}/s?/_1 touch ${TEST_MNT}/s3/_2 || logger FAILED ls -alFi ${TEST_MNT}/s?/_2 touch ${TEST_MNT}/s3/__1 || logger FAILED ls -alFi ${TEST_MNT}/s?/__1 touch ${TEST_MNT}/s3/__2 || logger FAILED ls -alFi ${TEST_MNT}/s?/__2 # if the above is not enough, add the following loop: for i in `seq 3 9`; do touch ${TEST_MNT}/s3/__${i} || logger FAILED; done #for i in `seq 3 34027`; do touch ${TEST_MNT}/s3/__${i} || logger FAILED; done # one of the touch(1) calls in s3 fail due to EEXIST because the inode is # already in use that btrfs_find_ino_for_alloc() returns. Signed-off-by: Stefan Behrens Reviewed-by: Jan Schmidt Signed-off-by: Josef Bacik Signed-off-by: Chris Mason Signed-off-by: Ben Hutchings commit 27b34b28a13e98b2e61559afd00ae5d9d18c5e82 Author: Johan Hovold Date: Wed Apr 23 11:32:19 2014 +0200 USB: serial: fix sysfs-attribute removal deadlock commit 10164c2ad6d2c16809f6c09e278f946e47801b3a upstream. Fix driver new_id sysfs-attribute removal deadlock by making sure to not hold any locks that the attribute operations grab when removing the attribute. Specifically, usb_serial_deregister holds the table mutex when deregistering the driver, which includes removing the new_id attribute. This can lead to a deadlock as writing to new_id increments the attribute's active count before trying to grab the same mutex in usb_serial_probe. The deadlock can easily be triggered by inserting a sleep in usb_serial_deregister and writing the id of an unbound device to new_id during module unload. As the table mutex (in this case) is used to prevent subdriver unload during probe, it should be sufficient to only hold the lock while manipulating the usb-serial driver list during deregister. A racing probe will then either fail to find a matching subdriver or fail to get the corresponding module reference. Since v3.15-rc1 this also triggers the following lockdep warning: ====================================================== [ INFO: possible circular locking dependency detected ] 3.15.0-rc2 #123 Tainted: G W ------------------------------------------------------- modprobe/190 is trying to acquire lock: (s_active#4){++++.+}, at: [] kernfs_remove_by_name_ns+0x4c/0x94 but task is already holding lock: (table_lock){+.+.+.}, at: [] usb_serial_deregister+0x3c/0x78 [usbserial] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (table_lock){+.+.+.}: [] __lock_acquire+0x1694/0x1ce4 [] lock_acquire+0xb4/0x154 [] _raw_spin_lock+0x4c/0x5c [] usb_store_new_id+0x14c/0x1ac [] new_id_store+0x68/0x70 [usbserial] [] drv_attr_store+0x30/0x3c [] sysfs_kf_write+0x5c/0x60 [] kernfs_fop_write+0xd4/0x194 [] vfs_write+0xbc/0x198 [] SyS_write+0x4c/0xa0 [] ret_fast_syscall+0x0/0x48 -> #0 (s_active#4){++++.+}: [] print_circular_bug+0x68/0x2f8 [] __lock_acquire+0x1928/0x1ce4 [] lock_acquire+0xb4/0x154 [] __kernfs_remove+0x254/0x310 [] kernfs_remove_by_name_ns+0x4c/0x94 [] remove_files.isra.1+0x48/0x84 [] sysfs_remove_group+0x58/0xac [] sysfs_remove_groups+0x34/0x44 [] driver_remove_groups+0x1c/0x20 [] bus_remove_driver+0x3c/0xe4 [] driver_unregister+0x38/0x58 [] usb_serial_bus_deregister+0x84/0x88 [usbserial] [] usb_serial_deregister+0x6c/0x78 [usbserial] [] usb_serial_deregister_drivers+0x2c/0x4c [usbserial] [] usb_serial_module_exit+0x14/0x1c [sierra] [] SyS_delete_module+0x184/0x210 [] ret_fast_syscall+0x0/0x48 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(table_lock); lock(s_active#4); lock(table_lock); lock(s_active#4); *** DEADLOCK *** 1 lock held by modprobe/190: #0: (table_lock){+.+.+.}, at: [] usb_serial_deregister+0x3c/0x78 [usbserial] stack backtrace: CPU: 0 PID: 190 Comm: modprobe Tainted: G W 3.15.0-rc2 #123 [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [] (show_stack) from [] (dump_stack+0x24/0x28) [] (dump_stack) from [] (print_circular_bug+0x2ec/0x2f8) [] (print_circular_bug) from [] (__lock_acquire+0x1928/0x1ce4) [] (__lock_acquire) from [] (lock_acquire+0xb4/0x154) [] (lock_acquire) from [] (__kernfs_remove+0x254/0x310) [] (__kernfs_remove) from [] (kernfs_remove_by_name_ns+0x4c/0x94) [] (kernfs_remove_by_name_ns) from [] (remove_files.isra.1+0x48/0x84) [] (remove_files.isra.1) from [] (sysfs_remove_group+0x58/0xac) [] (sysfs_remove_group) from [] (sysfs_remove_groups+0x34/0x44) [] (sysfs_remove_groups) from [] (driver_remove_groups+0x1c/0x20) [] (driver_remove_groups) from [] (bus_remove_driver+0x3c/0xe4) [] (bus_remove_driver) from [] (driver_unregister+0x38/0x58) [] (driver_unregister) from [] (usb_serial_bus_deregister+0x84/0x88 [usbserial]) [] (usb_serial_bus_deregister [usbserial]) from [] (usb_serial_deregister+0x6c/0x78 [usbserial]) [] (usb_serial_deregister [usbserial]) from [] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial]) [] (usb_serial_deregister_drivers [usbserial]) from [] (usb_serial_module_exit+0x14/0x1c [sierra]) [] (usb_serial_module_exit [sierra]) from [] (SyS_delete_module+0x184/0x210) [] (SyS_delete_module) from [] (ret_fast_syscall+0x0/0x48) Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 747a78bdf6391a8da32cdb806b4a6eed744c1e01 Author: Xiangyu Lu Date: Tue Apr 15 09:38:17 2014 +0100 ARM: 8027/1: fix do_div() bug in big-endian systems commit 80bb3ef109ff40a7593d9481c17de9bbc4d7c0e2 upstream. In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result. When viewing ftrace record in big-endian ARM systems, we found that the timestamp errors: swapper-0 [001] 1325.970000: 0:120:R ==> [001] 16:120:R events/1 events/1-16 [001] 1325.970000: 16:120:S ==> [001] 0:120:R swapper swapper-0 [000] 1325.1000000: 0:120:R + [000] 15:120:R events/0 swapper-0 [000] 1325.1000000: 0:120:R ==> [000] 15:120:R events/0 swapper-0 [000] 1326.030000: 0:120:R + [000] 1150:120:R sshd swapper-0 [000] 1326.030000: 0:120:R ==> [000] 1150:120:R sshd When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n = 10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2". Reviewed-by: Dave Martin Reviewed-by: Nicolas Pitre Signed-off-by: Alex Wu Signed-off-by: Xiangyu Lu Signed-off-by: Russell King Signed-off-by: Ben Hutchings commit 649c4c004e5f04f5424ac3021d8312c3abc75010 Author: Linus Torvalds Date: Tue Apr 22 13:49:40 2014 -0700 mm: make fixup_user_fault() check the vma access rights too commit 1b17844b29ae042576bea588164f2f1e9590a8bc upstream. fixup_user_fault() is used by the futex code when the direct user access fails, and the futex code wants it to either map in the page in a usable form or return an error. It relied on handle_mm_fault() to map the page, and correctly checked the error return from that, but while that does map the page, it doesn't actually guarantee that the page will be mapped with sufficient permissions to be then accessed. So do the appropriate tests of the vma access rights by hand. [ Side note: arguably handle_mm_fault() could just do that itself, but we have traditionally done it in the caller, because some callers - notably get_user_pages() - have been able to access pages even when they are mapped with PROT_NONE. Maybe we should re-visit that design decision, but in the meantime this is the minimal patch. ] Found by Dave Jones running his trinity tool. Reported-by: Dave Jones Acked-by: Hugh Dickins Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 53a58d9f5dbd90df5a2c7d8ad78fd812af126d34 Author: Hans de Goede Date: Sat Apr 19 22:31:18 2014 -0700 Input: synaptics - add min/max quirk for ThinkPad T431s, L440, L540, S1 Yoga and X1 commit 46a2986ebbe18757c2d8c352f8fb6e0f4f0754e3 upstream. We expect that all the Haswell series will need such quirks, sigh. The T431s seems to be T430 hardware in a T440s case, using the T440s touchpad, with the same min/max issue. The X1 Carbon 3rd generation name says 2nd while it is a 3rd generation. The X1 and T431s share a PnPID with the T540p, but the reported ranges are closer to those of the T440s. HdG: Squashed 5 quirk patches into one. T431s + L440 + L540 are written by me, S1 Yoga and X1 are written by Benjamin Tissoires. Hdg: Standardized S1 Yoga and X1 values, Yoga uses the same touchpad as the X240, X1 uses the same touchpad as the T440. Signed-off-by: Benjamin Tissoires Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit f632e3515cdb3463fb1ad6f4b6f0f8525fb41a25 Author: Jani Nikula Date: Wed Jul 3 15:05:02 2013 -0700 dmi: add support for exact DMI matches in addition to substring matching commit 5017b2851373ee15c7035151853bb1448800cae2 upstream. dmi_match() considers a substring match to be a successful match. This is not always sufficient to distinguish between DMI data for different systems. Add support for exact string matching using strcmp() in addition to the substring matching using strstr(). The specific use case in the i915 driver is to allow us to use an exact match for D510MO, without also incorrectly matching D510MOV: { .ident = "Intel D510MO", .matches = { DMI_MATCH(DMI_BOARD_VENDOR, "Intel"), DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"), }, } Signed-off-by: Jani Nikula Cc: Cc: Chris Wilson Cc: Cornel Panceac Acked-by: Daniel Vetter Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit b8309464fb222570eadd3e9d4668dd1f01ad8189 Author: Mizuma, Masayoshi Date: Fri Apr 18 15:07:18 2014 -0700 mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages() commit 7848a4bf51b34f41fcc9bd77e837126d99ae84e3 upstream. soft lockup in freeing gigantic hugepage fixed in commit 55f67141a892 "mm: hugetlb: fix softlockup when a large number of hugepages are freed." can happen in return_unused_surplus_pages(), so let's fix it. Signed-off-by: Masayoshi Mizuma Signed-off-by: Naoya Horiguchi Cc: Joonsoo Kim Cc: Michal Hocko Cc: Aneesh Kumar Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit f9a65249cf4ed11170dadd3d5b61c6864bdf7df7 Author: Dan Williams Date: Thu Apr 17 11:48:21 2014 -0700 libata/ahci: accommodate tag ordered controllers commit 8a4aeec8d2d6a3edeffbdfae451cdf05cbf0fefd upstream. The AHCI spec allows implementations to issue commands in tag order rather than FIFO order: 5.3.2.12 P:SelectCmd HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1) or HBA selects the command to issue that has had the PxCI bit set to '1' longer than any other command pending to be issued. The result is that commands posted sequentially (time-wise) may play out of sequence when issued by hardware. This behavior has likely been hidden by drives that arrange for commands to complete in issue order. However, it appears recent drives (two from different vendors that we have found so far) inflict out-of-order completions as a matter of course. So, we need to take care to maintain ordered submission, otherwise we risk triggering a drive to fall out of sequential-io automation and back to random-io processing, which incurs large latency and degrades throughput. This issue was found in simple benchmarks where QD=2 seq-write performance was 30-50% *greater* than QD=32 seq-write performance. Tagging for -stable and making the change globally since it has a low risk-to-reward ratio. Also, word is that recent versions of an unnamed OS also does it this way now. So, drives in the field are already experienced with this tag ordering scheme. Cc: Dave Jiang Cc: Ed Ciechanowski Reviewed-by: Matthew Wilcox Signed-off-by: Dan Williams Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings commit 9b492e65e428b1246074f04702bf4b81ad11efd0 Author: Jeff Layton Date: Tue Apr 15 08:51:48 2014 -0400 nfsd: set timeparms.to_maxval in setup_callback_client commit 3758cf7e14b753838fe754ede3862af10b35fdac upstream. ...otherwise the logic in the timeout handling doesn't work correctly. Spotted-by: Trond Myklebust Signed-off-by: Jeff Layton Signed-off-by: J. Bruce Fields [bwh: Backported to 3.2: max_cb_time() takes no parameters] Signed-off-by: Ben Hutchings commit 0d71d4e468519901c84933d1c627f96626d5d023 Author: Michael Ulbricht Date: Tue Mar 25 10:34:18 2014 +0100 USB: cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver commit 895d240d1db0b2736d779200788e4c4aea28a0c6 upstream. By specifying NO_UNION_NORMAL the ACM driver does only use the first two USB interfaces (modem data & control). The AT Port, Diagnostic and NMEA interfaces are left to the USB serial driver. Signed-off-by: Michael Ulbricht Signed-off-by: Alexander Stein Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 9296342c21dafefa83f2dade1edd102dce88b556 Author: Aaron Sanders Date: Mon Mar 31 15:54:21 2014 +0200 USB: pl2303: add ids for Hewlett-Packard HP POS pole displays commit b16c02fbfb963fa2941b7517ebf1f8a21946775e upstream. Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays: LD960: 03f0:0B39 LCM220: 03f0:3139 LCM960: 03f0:3239 [ Johan: fix indentation and sort PIDs numerically ] Signed-off-by: Aaron Sanders Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 38036481802f3f740f843660e264bf8d53b7202c Author: Tristan Bruns Date: Sun Apr 13 23:57:16 2014 +0200 USB: cp210x: Add 8281 (Nanotec Plug & Drive) commit 72b3007951010ce1bbf950e23b19d9839fa905a5 upstream. Signed-off-by: Tristan Bruns Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 065ca1982b521cf6e4c841af0e3cc6f78816ec75 Author: Daniele Palmas Date: Wed Apr 2 11:19:48 2014 +0200 usb: option driver, add support for Telit UE910v2 commit d6de486bc22255779bd54b0fceb4c240962bf146 upstream. option driver, added VID/PID for Telit UE910v2 modem Signed-off-by: Daniele Palmas Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 52752b3fcf5cc0a8f0add78984d20b29b77b1e72 Author: Johan Hovold Date: Fri Mar 28 18:05:10 2014 +0100 Revert "USB: serial: add usbid for dell wwan card to sierra.c" commit 2e01280d2801c72878cf3a7119eac30077b463d5 upstream. This reverts commit 1ebca9dad5abe8b2ed4dbd186cd657fb47c1f321. This device was erroneously added to the sierra driver even though it's not a Sierra device and was already handled by the option driver. Cc: Richard Farina Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 7b788101ed3ef4ee3afbf6d6973a3d7ab4391c2e Author: Michele Baldessari Date: Mon Mar 31 10:51:00 2014 +0200 USB: serial: ftdi_sio: add id for Brainboxes serial cards commit efe26e16b1d93ac0085e69178cc18811629e8fc5 upstream. Custom VID/PIDs for Brainboxes cards as reported in https://bugzilla.redhat.com/show_bug.cgi?id=1071914 Signed-off-by: Michele Baldessari Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit a7503c195a2dd9eabde252b8f1f197ed30b2e5ac Author: Larry Finger Date: Wed Apr 16 14:49:33 2014 -0500 staging: r8712u: Fix case where ethtype was never obtained and always be checked against 0 commit f764cd68d9036498f08fe8834deb6a367b5c2542 upstream. Zero-initializing ether_type masked that the ether type would never be obtained for 8021x packets and the comparison against eapol_type would always fail. Reported-by: Jes Sorensen Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit ef70c6017f97d09111515ac2d6d98d07559794e1 Author: Chris Mason Date: Tue Apr 15 18:09:24 2014 -0400 mlx4_en: don't use napi_synchronize inside mlx4_en_netpoll commit c98235cb8584a72e95786e17d695a8e5fafcd766 upstream. The mlx4 driver is triggering schedules while atomic inside mlx4_en_netpoll: spin_lock_irqsave(&cq->lock, flags); napi_synchronize(&cq->napi); ^^^^^ msleep here mlx4_en_process_rx_cq(dev, cq, 0); spin_unlock_irqrestore(&cq->lock, flags); This was part of a patch by Alexander Guller from Mellanox in 2011, but it still isn't upstream. Signed-off-by: Chris Mason Acked-By: Amir Vadai Signed-off-by: David S. Miller [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 48633e72d8546a791ac3d0d8c72f7629c9643ef7 Author: Jeff Layton Date: Tue Apr 15 06:17:49 2014 -0400 locks: allow __break_lease to sleep even when break_time is 0 commit f1c6bb2cb8b81013e8979806f8e15e3d53efb96d upstream. A fl->fl_break_time of 0 has a special meaning to the lease break code that basically means "never break the lease". knfsd uses this to ensure that leases don't disappear out from under it. Unfortunately, the code in __break_lease can end up passing this value to wait_event_interruptible as a timeout, which prevents it from going to sleep at all. This makes __break_lease to spin in a tight loop and causes soft lockups. Fix this by ensuring that we pass a minimum value of 1 as a timeout instead. Cc: J. Bruce Fields Reported-by: Terry Barnaby Signed-off-by: Jeff Layton Signed-off-by: Ben Hutchings commit a87ba5f15618cc01185242f93c33042775a03fe2 Author: Helge Deller Date: Sun Apr 13 00:03:55 2014 +0200 parisc: fix epoll_pwait syscall on compat kernel commit ab3e55b119c9653b19ea4edffb86f04db867ac98 upstream. This bug was detected with the libio-epoll-perl debian package where the test case IO-Ppoll-compat.t failed. Signed-off-by: Helge Deller Signed-off-by: Ben Hutchings commit 0289029f8bbdada97ee659ff4d9ac17940b56844 Author: Theodore Ts'o Date: Sat Apr 12 12:45:25 2014 -0400 ext4: use i_size_read in ext4_unaligned_aio() commit 6e6358fc3c3c862bfe9a5bc029d3f8ce43dc9765 upstream. We haven't taken i_mutex yet, so we need to use i_size_read(). Signed-off-by: "Theodore Ts'o" Signed-off-by: Ben Hutchings commit 81692a1db0ee5276e3dcae9335346ba9712b93ce Author: Matthew Wilcox Date: Mon Apr 7 10:54:20 2014 -0400 ext4: note the error in ext4_end_bio() commit 9503c67c93ed0b95ba62d12d1fd09da6245dbdd6 upstream. ext4_end_bio() currently throws away the error that it receives. Chances are this is part of a spate of errors, one of which will end up getting the error returned to userspace somehow, but we shouldn't take that risk. Also print out the errno to aid in debug. Signed-off-by: Matthew Wilcox Signed-off-by: "Theodore Ts'o" Reviewed-by: Jan Kara [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings commit 5e76e584d0b4e24eed04871d807b3081e97bcfb2 Author: Kazuya Mio Date: Mon Apr 7 10:53:28 2014 -0400 ext4: FIBMAP ioctl causes BUG_ON due to handle EXT_MAX_BLOCKS commit 4adb6ab3e0fa71363a5ef229544b2d17de6600d7 upstream. When we try to get 2^32-1 block of the file which has the extent (ee_block=2^32-2, ee_len=1) with FIBMAP ioctl, it causes BUG_ON in ext4_ext_put_gap_in_cache(). To avoid the problem, ext4_map_blocks() needs to check the file logical block number. ext4_ext_put_gap_in_cache() called via ext4_map_blocks() cannot handle 2^32-1 because the maximum file logical block number is 2^32-2. Note that ext4_ind_map_blocks() returns -EIO when the block number is invalid. So ext4_map_blocks() should also return the same errno. Signed-off-by: Kazuya Mio Signed-off-by: "Theodore Ts'o" [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings