commit 49f9ae92af54217fd9821a7613342178893a72af Author: Greg Kroah-Hartman Date: Fri Feb 19 14:35:24 2016 -0800 Linux 4.3.6 commit 1c141a118520e7a61a6f189164f07c512b828dea Author: Benjamin Tissoires Date: Tue Dec 1 12:41:38 2015 +0100 HID: multitouch: fix input mode switching on some Elan panels commit 73e7d63efb4d774883a338997943bfa59e127085 upstream. as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481 This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature reports on demand for Win8 devices") as the origin of the problem but this commit actually masked 2 firmware bugs that are annihilating each other: The report descriptor declares two features in reports 3 and 5: 0x05, 0x0d, // Usage Page (Digitizers) 318 0x09, 0x0e, // Usage (Device Configuration) 320 0xa1, 0x01, // Collection (Application) 322 0x85, 0x03, // Report ID (3) 324 0x09, 0x22, // Usage (Finger) 326 0xa1, 0x00, // Collection (Physical) 328 0x09, 0x52, // Usage (Inputmode) 330 0x15, 0x00, // Logical Minimum (0) 332 0x25, 0x0a, // Logical Maximum (10) 334 0x75, 0x08, // Report Size (8) 336 0x95, 0x02, // Report Count (2) 338 0xb1, 0x02, // Feature (Data,Var,Abs) 340 0xc0, // End Collection 342 0x09, 0x22, // Usage (Finger) 343 0xa1, 0x00, // Collection (Physical) 345 0x85, 0x05, // Report ID (5) 347 0x09, 0x57, // Usage (Surface Switch) 349 0x09, 0x58, // Usage (Button Switch) 351 0x15, 0x00, // Logical Minimum (0) 353 0x75, 0x01, // Report Size (1) 355 0x95, 0x02, // Report Count (2) 357 0x25, 0x03, // Logical Maximum (3) 359 0xb1, 0x02, // Feature (Data,Var,Abs) 361 0x95, 0x0e, // Report Count (14) 363 0xb1, 0x03, // Feature (Cnst,Var,Abs) 365 0xc0, // End Collection 367 The report ID 3 presents 2 input mode features, while only the first one is handled by the device. Given that we did not checked if one was previously assigned, we were dealing with the ignored featured and we should never have been able to switch this panel into the multitouch mode. However, the firmware presents an other bugs which allowed 6d4f5440 to counteract the faulty report descriptor. When we request the values of the feature 5, the firmware answers "03 03 00". The fields are correct but the report id is wrong. Before 6d4f5440, we retrieved all the features and injected them in the system. So when we called report 5, we injected in the system the report 3 with the values "03 00". Setting the second input mode to 03 in this report changed it to "03 03" and the touchpad switched to the mt mode. We could have set anything in the second field because the actual value (the first 03 in this report) was given by the query of report ID 5. To sum up: 2 bugs in the firmware were hiding that we were accessing the wrong feature. Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 3123ba71b297b439ce7112f1075a71d2f35385bf Author: Tetsuo Handa Date: Fri Feb 5 15:36:30 2016 -0800 mm, vmstat: fix wrong WQ sleep when memory reclaim doesn't make any progress commit 564e81a57f9788b1475127012e0fd44e9049e342 upstream. Jan Stancek has reported that system occasionally hanging after "oom01" testcase from LTP triggers OOM. Guessing from a result that there is a kworker thread doing memory allocation and the values between "Node 0 Normal free:" and "Node 0 Normal:" differs when hanging, vmstat is not up-to-date for some reason. According to commit 373ccbe59270 ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress"), it meant to force the kworker thread to take a short sleep, but it by error used schedule_timeout(1). We missed that schedule_timeout() in state TASK_RUNNING doesn't do anything. Fix it by using schedule_timeout_uninterruptible(1) which forces the kworker thread to take a short sleep in order to make sure that vmstat is up-to-date. Fixes: 373ccbe59270 ("mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress") Signed-off-by: Tetsuo Handa Reported-by: Jan Stancek Acked-by: Michal Hocko Cc: Tejun Heo Cc: Cristopher Lameter Cc: Joonsoo Kim Cc: Arkadiusz Miskiewicz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 881a1fbe415b3514e416c676ca2d12fa5e2c9426 Author: Maciej W. Rozycki Date: Mon Oct 26 15:48:19 2015 +0000 binfmt_elf: Don't clobber passed executable's file header commit b582ef5c53040c5feef4c96a8f9585b6831e2441 upstream. Do not clobber the buffer space passed from `search_binary_handler' and originally preloaded by `prepare_binprm' with the executable's file header by overwriting it with its interpreter's file header. Instead keep the buffer space intact and directly use the data structure locally allocated for the interpreter's file header, fixing a bug introduced in 2.1.14 with loadable module support (linux-mips.org commit beb11695 [Import of Linux/MIPS 2.1.14], predating kernel.org repo's history). Adjust the amount of data read from the interpreter's file accordingly. This was not an issue before loadable module support, because back then `load_elf_binary' was executed only once for a given ELF executable, whether the function succeeded or failed. With loadable module support supported and enabled, upon a failure of `load_elf_binary' -- which may for example be caused by architecture code rejecting an executable due to a missing hardware feature requested in the file header -- a module load is attempted and then the function reexecuted by `search_binary_handler'. With the executable's file header replaced with its interpreter's file header the executable can then be erroneously accepted in this subsequent attempt. Signed-off-by: Maciej W. Rozycki Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit dc0f7c58ecaff61e587153a0a6bc4884846f1e8b Author: Eric Biggers Date: Sat Oct 17 16:26:09 2015 -0500 fs/pipe.c: return error code rather than 0 in pipe_write() commit 6ae08069939f17422835448acae76bda8d96b16a upstream. pipe_write() would return 0 if it failed to merge the beginning of the data to write with the last, partially filled pipe buffer. It should return an error code instead. Userspace programs could be confused by write() returning 0 when called with a nonzero 'count'. The EFAULT error case was a regression from f0d1bec9d5 ("new helper: copy_page_from_iter()"), while the ops->confirm() error case was a much older bug. Test program: #include #include #include int main(void) { int fd[2]; char data[1] = {0}; assert(0 == pipe(fd)); assert(1 == write(fd[1], data, 1)); /* prior to this patch, write() returned 0 here */ assert(-1 == write(fd[1], NULL, 1)); assert(errno == EFAULT); } Signed-off-by: Eric Biggers Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit d5c7bab6f3b5dfd8a656dfc17ca5fec770118e6b Author: Junil Lee Date: Wed Jan 20 14:58:18 2016 -0800 zsmalloc: fix migrate_zspage-zs_free race condition commit c102f07ca0b04f2cb49cfc161c83f6239d17f491 upstream. record_obj() in migrate_zspage() does not preserve handle's HANDLE_PIN_BIT, set by find_aloced_obj()->trypin_tag(), and implicitly (accidentally) un-pins the handle, while migrate_zspage() still performs an explicit unpin_tag() on the that handle. This additional explicit unpin_tag() introduces a race condition with zs_free(), which can pin that handle by this time, so the handle becomes un-pinned. Schematically, it goes like this: CPU0 CPU1 migrate_zspage find_alloced_obj trypin_tag set HANDLE_PIN_BIT zs_free() pin_tag() obj_malloc() -- new object, no tag record_obj() -- remove HANDLE_PIN_BIT set HANDLE_PIN_BIT unpin_tag() -- remove zs_free's HANDLE_PIN_BIT The race condition may result in a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 00000000 CPU: 0 PID: 19001 Comm: CookieMonsterCl Tainted: PC is at get_zspage_mapping+0x0/0x24 LR is at obj_free.isra.22+0x64/0x128 Call trace: get_zspage_mapping+0x0/0x24 zs_free+0x88/0x114 zram_free_page+0x64/0xcc zram_slot_free_notify+0x90/0x108 swap_entry_free+0x278/0x294 free_swap_and_cache+0x38/0x11c unmap_single_vma+0x480/0x5c8 unmap_vmas+0x44/0x60 exit_mmap+0x50/0x110 mmput+0x58/0xe0 do_exit+0x320/0x8dc do_group_exit+0x44/0xa8 get_signal+0x538/0x580 do_signal+0x98/0x4b8 do_notify_resume+0x14/0x5c This patch keeps the lock bit in migration path and update value atomically. Signed-off-by: Junil Lee Signed-off-by: Minchan Kim Acked-by: Vlastimil Babka Cc: Sergey Senozhatsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b3143ec6ddea62344574cce2ebf2633eb1958727 Author: Jerome Marchand Date: Fri Jan 15 16:54:48 2016 -0800 zram: don't call idr_remove() from zram_remove() commit 17ec4cd985780a7e30aa45bb8f272237c12502a4 upstream. The use of idr_remove() is forbidden in the callback functions of idr_for_each(). It is therefore unsafe to call idr_remove in zram_remove(). This patch moves the call to idr_remove() from zram_remove() to hot_remove_store(). In the detroy_devices() path, idrs are removed by idr_destroy(). This solves an use-after-free detected by KASan. [akpm@linux-foundation.org: fix coding stype, per Sergey] Signed-off-by: Jerome Marchand Acked-by: Sergey Senozhatsky Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5b243a2947d98973ba553af9a9b6858d3f59f62f Author: Kyeongdon Kim Date: Thu Jan 14 15:22:29 2016 -0800 zram: try vmalloc() after kmalloc() commit d913897abace843bba20249f3190167f7895e9c3 upstream. When we're using LZ4 multi compression streams for zram swap, we found out page allocation failure message in system running test. That was not only once, but a few(2 - 5 times per test). Also, some failure cases were continually occurring to try allocation order 3. In order to make parallel compression private data, we should call kzalloc() with order 2/3 in runtime(lzo/lz4). But if there is no order 2/3 size memory to allocate in that time, page allocation fails. This patch makes to use vmalloc() as fallback of kmalloc(), this prevents page alloc failure warning. After using this, we never found warning message in running test, also It could reduce process startup latency about 60-120ms in each case. For reference a call trace : Binder_1: page allocation failure: order:3, mode:0x10c0d0 CPU: 0 PID: 424 Comm: Binder_1 Tainted: GW 3.10.49-perf-g991d02b-dirty #20 Call trace: dump_backtrace+0x0/0x270 show_stack+0x10/0x1c dump_stack+0x1c/0x28 warn_alloc_failed+0xfc/0x11c __alloc_pages_nodemask+0x724/0x7f0 __get_free_pages+0x14/0x5c kmalloc_order_trace+0x38/0xd8 zcomp_lz4_create+0x2c/0x38 zcomp_strm_alloc+0x34/0x78 zcomp_strm_multi_find+0x124/0x1ec zcomp_strm_find+0xc/0x18 zram_bvec_rw+0x2fc/0x780 zram_make_request+0x25c/0x2d4 generic_make_request+0x80/0xbc submit_bio+0xa4/0x15c __swap_writepage+0x218/0x230 swap_writepage+0x3c/0x4c shrink_page_list+0x51c/0x8d0 shrink_inactive_list+0x3f8/0x60c shrink_lruvec+0x33c/0x4cc shrink_zone+0x3c/0x100 try_to_free_pages+0x2b8/0x54c __alloc_pages_nodemask+0x514/0x7f0 __get_free_pages+0x14/0x5c proc_info_read+0x50/0xe4 vfs_read+0xa0/0x12c SyS_read+0x44/0x74 DMA: 3397*4kB (MC) 26*8kB (RC) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 13796kB [minchan@kernel.org: change vmalloc gfp and adding comment about gfp] [sergey.senozhatsky@gmail.com: tweak comments and styles] Signed-off-by: Kyeongdon Kim Signed-off-by: Minchan Kim Acked-by: Sergey Senozhatsky Sergey Senozhatsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1e200f644e368658a072d0d0d9cd3859dd6063c1 Author: Sergey Senozhatsky Date: Thu Jan 14 15:22:26 2016 -0800 zram/zcomp: use GFP_NOIO to allocate streams commit 3d5fe03a3ea013060ebba2a811aeb0f23f56aefa upstream. We can end up allocating a new compression stream with GFP_KERNEL from within the IO path, which may result is nested (recursive) IO operations. That can introduce problems if the IO path in question is a reclaimer, holding some locks that will deadlock nested IOs. Allocate streams and working memory using GFP_NOIO flag, forbidding recursive IO and FS operations. An example: inconsistent {IN-RECLAIM_FS-W} -> {RECLAIM_FS-ON-W} usage. git/20158 [HC0[0]:SC0[0]:HE1:SE1] takes: (jbd2_handle){+.+.?.}, at: start_this_handle+0x4ca/0x555 {IN-RECLAIM_FS-W} state was registered at: __lock_acquire+0x8da/0x117b lock_acquire+0x10c/0x1a7 start_this_handle+0x52d/0x555 jbd2__journal_start+0xb4/0x237 __ext4_journal_start_sb+0x108/0x17e ext4_dirty_inode+0x32/0x61 __mark_inode_dirty+0x16b/0x60c iput+0x11e/0x274 __dentry_kill+0x148/0x1b8 shrink_dentry_list+0x274/0x44a prune_dcache_sb+0x4a/0x55 super_cache_scan+0xfc/0x176 shrink_slab.part.14.constprop.25+0x2a2/0x4d3 shrink_zone+0x74/0x140 kswapd+0x6b7/0x930 kthread+0x107/0x10f ret_from_fork+0x3f/0x70 irq event stamp: 138297 hardirqs last enabled at (138297): debug_check_no_locks_freed+0x113/0x12f hardirqs last disabled at (138296): debug_check_no_locks_freed+0x33/0x12f softirqs last enabled at (137818): __do_softirq+0x2d3/0x3e9 softirqs last disabled at (137813): irq_exit+0x41/0x95 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(jbd2_handle); lock(jbd2_handle); *** DEADLOCK *** 5 locks held by git/20158: #0: (sb_writers#7){.+.+.+}, at: [] mnt_want_write+0x24/0x4b #1: (&type->i_mutex_dir_key#2/1){+.+.+.}, at: [] lock_rename+0xd9/0xe3 #2: (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [] lock_two_nondirectories+0x3f/0x6b #3: (&sb->s_type->i_mutex_key#11/4){+.+.+.}, at: [] lock_two_nondirectories+0x66/0x6b #4: (jbd2_handle){+.+.?.}, at: [] start_this_handle+0x4ca/0x555 stack backtrace: CPU: 2 PID: 20158 Comm: git Not tainted 4.1.0-rc7-next-20150615-dbg-00016-g8bdf555-dirty #211 Call Trace: dump_stack+0x4c/0x6e mark_lock+0x384/0x56d mark_held_locks+0x5f/0x76 lockdep_trace_alloc+0xb2/0xb5 kmem_cache_alloc_trace+0x32/0x1e2 zcomp_strm_alloc+0x25/0x73 [zram] zcomp_strm_multi_find+0xe7/0x173 [zram] zcomp_strm_find+0xc/0xe [zram] zram_bvec_rw+0x2ca/0x7e0 [zram] zram_make_request+0x1fa/0x301 [zram] generic_make_request+0x9c/0xdb submit_bio+0xf7/0x120 ext4_io_submit+0x2e/0x43 ext4_bio_write_page+0x1b7/0x300 mpage_submit_page+0x60/0x77 mpage_map_and_submit_buffers+0x10f/0x21d ext4_writepages+0xc8c/0xe1b do_writepages+0x23/0x2c __filemap_fdatawrite_range+0x84/0x8b filemap_flush+0x1c/0x1e ext4_alloc_da_blocks+0xb8/0x117 ext4_rename+0x132/0x6dc ? mark_held_locks+0x5f/0x76 ext4_rename2+0x29/0x2b vfs_rename+0x540/0x636 SyS_renameat2+0x359/0x44d SyS_rename+0x1e/0x20 entry_SYSCALL_64_fastpath+0x12/0x6f [minchan@kernel.org: add stable mark] Signed-off-by: Sergey Senozhatsky Acked-by: Minchan Kim Cc: Kyeongdon Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 233ffe57007a91dd2f517ac60aa668979c404dbd Author: Alexandre Courbot Date: Thu Sep 3 17:39:52 2015 +0900 drm/nouveau/pmu: do not assume a PMU is present commit 579b7c58215329803ce184704463de09f0f310ac upstream. Some devices may not have a PMU. Avoid a NULL pointer dereference in such cases by checking whether the pointer given to nvkm_pmu_pgob() is valid. Signed-off-by: Alexandre Courbot Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit fee906f035f0bd18ff12d84d58766c44a2ab0918 Author: Mika Westerberg Date: Wed Oct 7 15:33:43 2015 +0300 HID: multitouch: Fetch feature reports on demand for Win8 devices commit 6d4f5440a3a2bb2e9d0d582bbf98234e9e9bb095 upstream. Some newer Intel Skylake based Dell laptops with Win8 precision touchpad fail when initial feature reports are fetched from it. Below is an example output with some additional debug included: i2c_hid i2c-DLL0704:01: Fetching the HID descriptor i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=20 00 i2c_hid i2c-DLL0704:01: HID Descriptor: 1e 00 00 01 99 02 21 00 24 ... ... i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 38 02 23 00 i2c_hid i2c-DLL0704:01: report (len=4): 04 00 08 05 i2c_hid i2c-DLL0704:01: report id 13 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 3d 02 23 00 i2c_hid i2c-DLL0704:01: failed to retrieve report from device. i2c_hid i2c-DLL0704:01: report id 7 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 37 02 23 00 i2c_hid i2c-DLL0704:01: report (len=259): 03 01 07 fc 28 fe 84 40 ... i2c_hid i2c-DLL0704:01: report id 4 i2c_hid i2c-DLL0704:01: i2c_hid_get_report i2c_hid i2c-DLL0704:01: __i2c_hid_command: cmd=22 00 34 02 23 00 We manage to fetch few reports but then the touchpad dies: i2c_designware i2c_designware.1: i2c_dw_handle_tx_abort: lost arbitration i2c_hid i2c-DLL0704:01: failed to retrieve report from device. it eventually pulls the whole I2C bus low: i2c_designware i2c_designware.1: controller timed out i2c_hid i2c-DLL0704:01: failed to set a report to device. Fix this by preventing initial feature report retrieval for Win8 devices. Instead we fetch reports as needed in mt_feature_mapping(). This prevents fetching reports which might cause problems with the device in question. Suggested-by: Benjamin Tissoires Signed-off-by: Mika Westerberg Reviewed-by: Benjamin Tissoires Tested-by: Seth Forshee Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4a8e6c9fdbd6d22dad15c9b00df569ca93eea515 Author: Larry Finger Date: Tue Nov 10 10:46:11 2015 -0600 rtlwifi: rtl8821ae: Fix lockups on boot commit eeec5d0ef7ee54a75e09e861c3cc44177b8752c7 upstream. In commit 54328e64047a5 ("rtlwifi: rtl8821ae: Fix system lockups on boot"), an attempt was made to fix a regression introduced in commit 1277fa2ab2f9 ("rtlwifi: Remove the clear interrupt routine from all drivers"). Unfortunately, there were logic errors in that patch that prevented affected boxes from booting even after that patch was applied. The actual cause of the original problem is unknown as none of the developers have systems that are affected. Fixes: 54328e64047a ("rtlwifi: rtl8821ae: Fix system lockups on boot") Signed-off-by: Larry Finger Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 5f341b0ae40162d8bb5586fa62b4166cbbd6fdde Author: Geert Uytterhoeven Date: Thu Nov 12 11:46:23 2015 +0000 FS-Cache: Add missing initialization of ret in cachefiles_write_page() commit cf89752645e47d86ba8a4157f4b121fcb33434c5 upstream. fs/cachefiles/rdwr.c: In function ‘cachefiles_write_page’: fs/cachefiles/rdwr.c:882: warning: ‘ret’ may be used uninitialized in this function If the jump to label "error" is taken, "ret" will indeed be uninitialized, and random stack data may be printed by the debug code. Fixes: 102f4d900c9c8f5e ("FS-Cache: Handle a write to the page immediately beyond the EOF marker") Signed-off-by: Geert Uytterhoeven Signed-off-by: David Howells Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 0b8c6bb125172685d9cc27cf189604915e468145 Author: David Howells Date: Wed Nov 4 15:20:42 2015 +0000 FS-Cache: Handle a write to the page immediately beyond the EOF marker commit 102f4d900c9c8f5ed89ae4746d493fe3ebd7ba64 upstream. Handle a write being requested to the page immediately beyond the EOF marker on a cache object. Currently this gets an assertion failure in CacheFiles because the EOF marker is used there to encode information about a partial page at the EOF - which could lead to an unknown blank spot in the file if we extend the file over it. The problem is actually in fscache where we check the index of the page being written against store_limit. store_limit is set to the number of pages that we're allowed to store by fscache_set_store_limit() - which means it's one more than the index of the last page we're allowed to store. The problem is that we permit writing to a page with an index _equal_ to the store limit - when we should reject that case. Whilst we're at it, change the triggered assertion in CacheFiles to just return -ENOBUFS instead. The assertion failure looks something like this: CacheFiles: Assertion failed 1000 < 7b1 is false ------------[ cut here ]------------ kernel BUG at fs/cachefiles/rdwr.c:962! ... RIP: 0010:[] [] cachefiles_write_page+0x273/0x2d0 [cachefiles] Signed-off-by: David Howells Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit b09f7baa2bb8adb715a06b288ad8057215bfa90d Author: Kinglong Mee Date: Wed Nov 4 15:20:24 2015 +0000 FS-Cache: Don't override netfs's primary_index if registering failed commit b130ed5998e62879a66bad08931a2b5e832da95c upstream. Only override netfs->primary_index when registering success. Signed-off-by: Kinglong Mee Signed-off-by: David Howells Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 51121b4e0c37a012a909744e9bcd62509b66b17b Author: Kinglong Mee Date: Wed Nov 4 15:20:15 2015 +0000 FS-Cache: Increase reference of parent after registering, netfs success commit 86108c2e34a26e4bec3c6ddb23390bf8cedcf391 upstream. If netfs exist, fscache should not increase the reference of parent's usage and n_children, otherwise, never be decreased. v2: thanks David's suggest, move increasing reference of parent if success use kmem_cache_free() freeing primary_index directly v3: don't move "netfs->primary_index->parent = &fscache_fsdef_index;" Signed-off-by: Kinglong Mee Signed-off-by: David Howells Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 28f946db2752d9681844bce847cebb9c438a33e0 Author: Boris BREZILLON Date: Fri Feb 5 17:45:48 2016 +0100 crypto: marvell/cesa - fix test in mv_cesa_dev_dma_init() commit 8a3978ad55fb4c0564d285fb2f6cdee2313fce01 upstream. We are checking twice if dma->cache_pool is not NULL but are never testing dma->padding_pool value. Signed-off-by: Boris Brezillon Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 987734524287a0c1e0713558d9a9ca59275f07b8 Author: Herbert Xu Date: Wed Feb 3 21:39:27 2016 +0800 crypto: algif_skcipher - Do not set MAY_BACKLOG on the async path commit dad41997063723eaf5f77bc2015606a5a9bce320 upstream. The async path cannot use MAY_BACKLOG because it is not meant to block, which is what MAY_BACKLOG does. On the other hand, both the sync and async paths can make use of MAY_SLEEP. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit acd490b153dd972b194fdaf2b941902fe815d385 Author: Herbert Xu Date: Wed Feb 3 21:39:26 2016 +0800 crypto: algif_skcipher - Do not dereference ctx without socket lock commit 6454c2b83f719057069777132b13949e4c6b6350 upstream. Any access to non-constant bits of the private context must be done under the socket lock, in particular, this includes ctx->req. This patch moves such accesses under the lock, and fetches the tfm from the parent socket which is guaranteed to be constant, rather than from ctx->req. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3cc285f29844b00b0c02b7e048e134fcee56e051 Author: Herbert Xu Date: Wed Feb 3 21:39:24 2016 +0800 crypto: algif_skcipher - Do not assume that req is unchanged commit ec69bbfb9902c32a5c1492f2b1b8ad032a66d724 upstream. The async path in algif_skcipher assumes that the crypto completion function will be called with the original request. This is not necessarily the case. In fact there is no need for this anyway since we already embed information into the request with struct skcipher_async_req. This patch adds a pointer to that struct and then passes it as the data to the callback function. Signed-off-by: Herbert Xu Tested-by: Tadeusz Struk Signed-off-by: Greg Kroah-Hartman commit c1bce85f6736ea0a5c1fe6ca4168825e35806c1f Author: Mathias Krause Date: Mon Feb 1 14:27:30 2016 +0100 crypto: user - lock crypto_alg_list on alg dump commit 63e41ebc6630f39422d87f8a4bade1e793f37a01 upstream. We miss to take the crypto_alg_sem semaphore when traversing the crypto_alg_list for CRYPTO_MSG_GETALG dumps. This allows a race with crypto_unregister_alg() removing algorithms from the list while we're still traversing it, thereby leading to a use-after-free as show below: [ 3482.071639] general protection fault: 0000 [#1] SMP [ 3482.075639] Modules linked in: aes_x86_64 glue_helper lrw ablk_helper cryptd gf128mul ipv6 pcspkr serio_raw virtio_net microcode virtio_pci virtio_ring virtio sr_mod cdrom [last unloaded: aesni_intel] [ 3482.075639] CPU: 1 PID: 11065 Comm: crconf Not tainted 4.3.4-grsec+ #126 [ 3482.075639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 3482.075639] task: ffff88001cd41a40 ti: ffff88001cd422c8 task.ti: ffff88001cd422c8 [ 3482.075639] RIP: 0010:[] [] strncpy+0x13/0x30 [ 3482.075639] RSP: 0018:ffff88001f713b60 EFLAGS: 00010202 [ 3482.075639] RAX: ffff88001f6c4430 RBX: ffff88001f6c43a0 RCX: ffff88001f6c4430 [ 3482.075639] RDX: 0000000000000040 RSI: fefefefefefeff16 RDI: ffff88001f6c4430 [ 3482.075639] RBP: ffff88001f713b60 R08: ffff88001f6c4470 R09: ffff88001f6c4480 [ 3482.075639] R10: 0000000000000002 R11: 0000000000000246 R12: ffff88001ce2aa28 [ 3482.075639] R13: ffff880000093700 R14: ffff88001f5e4bf8 R15: 0000000000003b20 [ 3482.075639] FS: 0000033826fa2700(0000) GS:ffff88001e900000(0000) knlGS:0000000000000000 [ 3482.075639] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3482.075639] CR2: ffffffffff600400 CR3: 00000000139ec000 CR4: 00000000001606f0 [ 3482.075639] Stack: [ 3482.075639] ffff88001f713bd8 ffffffff936ccd00 ffff88001e5c4200 ffff880000093700 [ 3482.075639] ffff88001f713bd0 ffffffff938ef4bf 0000000000000000 0000000000003b20 [ 3482.075639] ffff88001f5e4bf8 ffff88001f5e4848 0000000000000000 0000000000003b20 [ 3482.075639] Call Trace: [ 3482.075639] [] crypto_report_alg+0xc0/0x3e0 [ 3482.075639] [] ? __alloc_skb+0x16f/0x300 [ 3482.075639] [] crypto_dump_report+0x6a/0x90 [ 3482.075639] [] netlink_dump+0x147/0x2e0 [ 3482.075639] [] __netlink_dump_start+0x159/0x190 [ 3482.075639] [] crypto_user_rcv_msg+0xc3/0x130 [ 3482.075639] [] ? crypto_report_alg+0x3e0/0x3e0 [ 3482.075639] [] ? alg_test_crc32c+0x120/0x120 [ 3482.075639] [] ? __netlink_lookup+0xd5/0x120 [ 3482.075639] [] ? crypto_add_alg+0x1d0/0x1d0 [ 3482.075639] [] netlink_rcv_skb+0xe1/0x130 [ 3482.075639] [] crypto_netlink_rcv+0x28/0x40 [ 3482.075639] [] netlink_unicast+0x108/0x180 [ 3482.075639] [] netlink_sendmsg+0x541/0x770 [ 3482.075639] [] sock_sendmsg+0x21/0x40 [ 3482.075639] [] SyS_sendto+0xf3/0x130 [ 3482.075639] [] ? bad_area_nosemaphore+0x13/0x20 [ 3482.075639] [] ? __do_page_fault+0x80/0x3a0 [ 3482.075639] [] entry_SYSCALL_64_fastpath+0x12/0x6e [ 3482.075639] Code: 88 4a ff 75 ed 5d 48 0f ba 2c 24 3f c3 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 85 d2 48 89 f8 48 89 f9 4c 8d 04 17 48 89 e5 74 15 <0f> b6 16 80 fa 01 88 11 48 83 de ff 48 83 c1 01 4c 39 c1 75 eb [ 3482.075639] RIP [] strncpy+0x13/0x30 To trigger the race run the following loops simultaneously for a while: $ while : ; do modprobe aesni-intel; rmmod aesni-intel; done $ while : ; do crconf show all > /dev/null; done Fix the race by taking the crypto_alg_sem read lock, thereby preventing crypto_unregister_alg() from modifying the algorithm list during the dump. This bug has been detected by the PaX memory sanitize feature. Signed-off-by: Mathias Krause Cc: Steffen Klassert Cc: PaX Team Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 310e1b339cbc72c5cf1055c14ce942393bde189a Author: Ryan Ware Date: Thu Feb 11 15:58:44 2016 -0800 EVM: Use crypto_memneq() for digest comparisons commit 613317bd212c585c20796c10afe5daaa95d4b0a1 upstream. This patch fixes vulnerability CVE-2016-2085. The problem exists because the vm_verify_hmac() function includes a use of memcmp(). Unfortunately, this allows timing side channel attacks; specifically a MAC forgery complexity drop from 2^128 to 2^12. This patch changes the memcmp() to the cryptographically safe crypto_memneq(). Reported-by: Xiaofei Rex Guo Signed-off-by: Ryan Ware Signed-off-by: Mimi Zohar Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit e63603a97493e328fef08ef26acb8eb31da88e26 Author: Wang, Rui Y Date: Wed Jan 27 17:08:37 2016 +0800 crypto: algif_hash - wait for crypto_ahash_init() to complete commit fe09786178f9df713a4b2dd6b93c0a722346bf5e upstream. hash_sendmsg/sendpage() need to wait for the completion of crypto_ahash_init() otherwise it can cause panic. Signed-off-by: Rui Wang Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit b3208bf4b67e216b0310818c61d072bd98d26ac6 Author: Herbert Xu Date: Wed Jan 27 00:16:37 2016 +0800 crypto: shash - Fix has_key setting commit 00420a65fa2beb3206090ead86942484df2275f3 upstream. The has_key logic is wrong for shash algorithms as they always have a setkey function. So we should instead be testing against shash_no_setkey. Fixes: a5596d633278 ("crypto: hash - Add crypto_ahash_has_setkey") Reported-by: Stephan Mueller Signed-off-by: Herbert Xu Tested-by: Stephan Mueller Signed-off-by: Greg Kroah-Hartman commit 180b8dcc9c9183740dfb9f9df20bc03fbee2790c Author: Eli Cooper Date: Fri Jan 22 00:24:08 2016 +0800 crypto: chacha20-ssse3 - Align stack pointer to 64 bytes commit cbe09bd51bf23b42c3a94c5fb6815e1397c5fc3f upstream. This aligns the stack pointer in chacha20_4block_xor_ssse3 to 64 bytes. Fixes general protection faults and potential kernel panics. Signed-off-by: Eli Cooper Acked-by: Martin Willi Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a64021e87e736f7c52dfcf79c016c5b742b48ad6 Author: Horia Geant? Date: Tue Jan 12 17:59:29 2016 +0200 crypto: caam - make write transactions bufferable on PPC platforms commit e7a7104e432c0db8469ca3568daf4f1d1afe3e73 upstream. Previous change (see "Fixes" tag) to the MCFGR register clears AWCACHE[0] ("bufferable" AXI3 attribute) (which is "1" at POR). This makes all writes non-bufferable, causing a ~ 5% performance drop for PPC-based platforms. Rework previous change such that MCFGR[AWCACHE]=4'b0011 (bufferable + cacheable) for all platforms. Note: For ARM-based platforms, AWCACHE[0] is ignored by the interconnect IP. Fixes: f10967495144 ("crypto: caam - fix snooping for write transactions") Signed-off-by: Horia Geant? Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 4bbf076a84d0c8581b447d237b5112e39637f36d Author: Herbert Xu Date: Tue Jan 19 21:23:57 2016 +0800 crypto: algif_skcipher - sendmsg SG marking is off by one commit 202736d99b7f29279db9da61587f11a08a04a9c6 upstream. We mark the end of the SG list in sendmsg and sendpage and unmark it on the next send call. Unfortunately the unmarking in sendmsg is off-by-one, leading to an SG list that is too short. Fixes: 0f477b655a52 ("crypto: algif - Mark sgl end at the end of data") Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7420844c60979fe94b2a6fb1b1b5ee2147fbe71b Author: Herbert Xu Date: Mon Jan 18 18:46:10 2016 +0800 crypto: algif_skcipher - Load TX SG list after waiting commit 4f0414e54e4d1893c6f08260693f8ef84c929293 upstream. We need to load the TX SG list in sendmsg(2) after waiting for incoming data, not before. Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Tested-by: Dmitry Vyukov Signed-off-by: Greg Kroah-Hartman commit cd614251ffa61463c49a3a9a1c16257a83a175de Author: Jean Delvare Date: Mon Jan 18 17:06:05 2016 +0100 crypto: crc32c - Fix crc32c soft dependency commit fd7f6727102a1ccf6b4c1dfcc631f9b546526b26 upstream. I don't think it makes sense for a module to have a soft dependency on itself. This seems quite cyclic by nature and I can't see what purpose it could serve. OTOH libcrc32c calls crypto_alloc_shash("crc32c", 0, 0) so it pretty much assumes that some incarnation of the "crc32c" hash algorithm has been loaded. Therefore it makes sense to have the soft dependency there (as crc-t10dif does.) Cc: Tim Chen Cc: "David S. Miller" Signed-off-by: Jean Delvare Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 379b8645fcb1f8cb89959c4f4bc122617107698f Author: Herbert Xu Date: Fri Jan 15 22:02:20 2016 +0800 crypto: algif_skcipher - Fix race condition in skcipher_check_key commit 1822793a523e5d5730b19cc21160ff1717421bc8 upstream. We need to lock the child socket in skcipher_check_key as otherwise two simultaneous calls can cause the parent socket to be freed. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9b1f316a4af707548bd6519081557c4f1a5bf12f Author: Herbert Xu Date: Fri Jan 15 22:01:08 2016 +0800 crypto: algif_hash - Fix race condition in hash_check_key commit ad46d7e33219218605ea619e32553daf4f346b9f upstream. We need to lock the child socket in hash_check_key as otherwise two simultaneous calls can cause the parent socket to be freed. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit f0ab97887fdd61894eab1155aca040c9bff96524 Author: Herbert Xu Date: Wed Jan 13 15:03:32 2016 +0800 crypto: af_alg - Forbid bind(2) when nokey child sockets are present commit a6a48c565f6f112c6983e2a02b1602189ed6e26e upstream. This patch forbids the calling of bind(2) when there are child sockets created by accept(2) in existence, even if they are created on the nokey path. This is needed as those child sockets have references to the tfm object which bind(2) will destroy. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 3528b542effc9f9ac57788ee606ccd799dc09c94 Author: Herbert Xu Date: Wed Jan 13 15:01:06 2016 +0800 crypto: algif_skcipher - Remove custom release parent function commit d7b65aee1e7b4c87922b0232eaba56a8a143a4a0 upstream. This patch removes the custom release parent function as the generic af_alg_release_parent now works for nokey sockets too. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit cffc99216f9246ea484dd9c4930ead321f8e687e Author: Herbert Xu Date: Wed Jan 13 15:00:36 2016 +0800 crypto: algif_hash - Remove custom release parent function commit f1d84af1835846a5a2b827382c5848faf2bb0e75 upstream. This patch removes the custom release parent function as the generic af_alg_release_parent now works for nokey sockets too. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 5807098f55bab640c09d6cd97282914b9ff5b387 Author: Herbert Xu Date: Wed Jan 13 14:59:03 2016 +0800 crypto: af_alg - Allow af_af_alg_release_parent to be called on nokey path commit 6a935170a980024dd29199e9dbb5c4da4767a1b9 upstream. This patch allows af_alg_release_parent to be called even for nokey sockets. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 620277ffdbc0177b5793718faea7663c4c45f576 Author: Alexandra Yates Date: Fri Feb 5 15:27:49 2016 -0800 ahci: Intel DNV device IDs SATA commit 342decff2b846b46fa61eb5ee40986fab79a9a32 upstream. Adding Intel codename DNV platform device IDs for SATA. Signed-off-by: Alexandra Yates Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit c11ed676129aba8d2a9f0bca03f21e03198c0e41 Author: Tejun Heo Date: Fri Jan 15 15:13:05 2016 -0500 libata: disable forced PORTS_IMPL for >= AHCI 1.3 commit 566d1827df2ef0cbe921d3d6946ac3007b1a6938 upstream. Some early controllers incorrectly reported zero ports in PORTS_IMPL register and the ahci driver fabricates PORTS_IMPL from the number of ports in those cases. This hasn't mattered but with the new nvme controllers there are cases where zero PORTS_IMPL is valid and should be honored. Disable the workaround for >= AHCI 1.3. Signed-off-by: Tejun Heo Reported-by: Andy Lutomirski Link: http://lkml.kernel.org/g/CALCETrU7yMvXEDhjAUShoHEhDwifJGapdw--BKxsP0jmjKGmRw@mail.gmail.com Cc: Sergei Shtylyov Signed-off-by: Greg Kroah-Hartman commit b81c867b0b23a949cedca2dc4ac67bdc857062d3 Author: Xiangliang Yu Date: Thu Nov 26 20:27:02 2015 +0800 AHCI: Fix softreset failed issue of Port Multiplier commit 023113d24ef9e1d2b44cb2446872b17e2b01d8b1 upstream. Current code doesn't update port value of Port Multiplier(PM) when sending FIS of softreset to device, command will fail if FBS is enabled. There are two ways to fix the issue: the first is to disable FBS before sending softreset command to PM device and the second is to update port value of PM when sending command. For the first way, i can't find any related rule in AHCI Spec. The second way can avoid disabling FBS and has better performance. Signed-off-by: Xiangliang Yu Signed-off-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman commit 38c3e0d5568453c519ae53e1a67cc7e3501274d7 Author: Herbert Xu Date: Mon Jan 11 21:29:41 2016 +0800 crypto: algif_skcipher - Add key check exception for cipher_null commit 6e8d8ecf438792ecf7a3207488fb4eebc4edb040 upstream. This patch adds an exception to the key check so that cipher_null users may continue to use algif_skcipher without setting a key. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit cdbd71838c8ccda502234560484a10b3aefabf82 Author: Herbert Xu Date: Mon Jan 11 21:26:50 2016 +0800 crypto: skcipher - Add crypto_skcipher_has_setkey commit a1383cd86a062fc798899ab20f0ec2116cce39cb upstream. This patch adds a way for skcipher users to determine whether a key is required by a transform. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1a2a01e2ca4e656e64cc1d65ea7950751d04573e Author: Herbert Xu Date: Fri Jan 8 21:31:04 2016 +0800 crypto: algif_hash - Require setkey before accept(2) commit 6de62f15b581f920ade22d758f4c338311c2f0d4 upstream. Hash implementations that require a key may crash if you use them without setting a key. This patch adds the necessary checks so that if you do attempt to use them without a key that we return -ENOKEY instead of proceeding. This patch also adds a compatibility path to support old applications that do acept(2) before setkey. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0859efc0b4488bb10cc46466d91a01aeb802ea3f Author: Herbert Xu Date: Fri Jan 8 21:28:26 2016 +0800 crypto: hash - Add crypto_ahash_has_setkey commit a5596d6332787fd383b3b5427b41f94254430827 upstream. This patch adds a way for ahash users to determine whether a key is required by a crypto_ahash transform. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 0449310ed98cdfda5d8f0773d5c49a092bb1882a Author: Herbert Xu Date: Mon Jan 4 13:36:12 2016 +0900 crypto: algif_skcipher - Add nokey compatibility path commit a0fa2d037129a9849918a92d91b79ed6c7bd2818 upstream. This patch adds a compatibility path to support old applications that do acept(2) before setkey. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 2d3ffc15936bfa396485d9b2a93a8b0ca654c7d3 Author: Herbert Xu Date: Mon Jan 4 13:35:18 2016 +0900 crypto: af_alg - Add nokey compatibility path commit 37766586c965d63758ad542325a96d5384f4a8c9 upstream. This patch adds a compatibility path to support old applications that do acept(2) before setkey. Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9a9fcb9cd1e0ce7df2729e1ab7a95ccdff2322ae Author: Herbert Xu Date: Wed Dec 30 20:24:17 2015 +0800 crypto: af_alg - Fix socket double-free when accept fails commit a383292c86663bbc31ac62cc0c04fc77504636a6 upstream. When we fail an accept(2) call we will end up freeing the socket twice, once due to the direct sk_free call and once again through newsock. This patch fixes this by removing the sk_free call. Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 44566ad6cb5d72f5018443923d66b30e86765080 Author: Herbert Xu Date: Wed Dec 30 11:47:53 2015 +0800 crypto: af_alg - Disallow bind/setkey/... after accept(2) commit c840ac6af3f8713a71b4d2363419145760bd6044 upstream. Each af_alg parent socket obtained by socket(2) corresponds to a tfm object once bind(2) has succeeded. An accept(2) call on that parent socket creates a context which then uses the tfm object. Therefore as long as any child sockets created by accept(2) exist the parent socket must not be modified or freed. This patch guarantees this by using locks and a reference count on the parent socket. Any attempt to modify the parent socket will fail with EBUSY. Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ca3b842758312a5a3d7e1dc21ab451f03912cc27 Author: Herbert Xu Date: Fri Dec 25 15:40:05 2015 +0800 crypto: algif_skcipher - Require setkey before accept(2) commit dd504589577d8e8e70f51f997ad487a4cb6c026f upstream. Some cipher implementations will crash if you try to use them without calling setkey first. This patch adds a check so that the accept(2) call will fail with -ENOKEY if setkey hasn't been done on the socket yet. Reported-by: Dmitry Vyukov Signed-off-by: Herbert Xu Tested-by: Dmitry Vyukov Signed-off-by: Greg Kroah-Hartman commit bdc189233c2a914b2954a43bd3d6a013496dd5a1 Author: Raghavendra K T Date: Sat Jan 16 00:31:23 2016 +0530 sched: Fix crash in sched_init_numa() commit 9c03ee147193645be4c186d3688232fa438c57c7 upstream. The following PowerPC commit: c118baf80256 ("arch/powerpc/mm/numa.c: do not allocate bootmem memory for non existing nodes") avoids allocating bootmem memory for non existent nodes. But when DEBUG_PER_CPU_MAPS=y is enabled, my powerNV system failed to boot because in sched_init_numa(), cpumask_or() operation was done on unallocated nodes. Fix that by making cpumask_or() operation only on existing nodes. [ Tested with and w/o DEBUG_PER_CPU_MAPS=y on x86 and PowerPC. ] Reported-by: Jan Stancek Tested-by: Jan Stancek Signed-off-by: Raghavendra K T Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Link: http://lkml.kernel.org/r/1452884483-11676-1-git-send-email-raghavendra.kt@linux.vnet.ibm.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit b5508f03599af61c1511cc09419b282cbc9a1a52 Author: Al Viro Date: Thu Nov 26 15:20:50 2015 -0500 ext4: fix an endianness bug in ext4_encrypted_follow_link() commit 5a1c7f47da9b32d0671e776b0f388095b7f91e2e upstream. applying le32_to_cpu() to 16bit value is a bad idea... Signed-off-by: Al Viro Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 8a744287bd6b9cccd25423112ea7322bb47c4c01 Author: Al Viro Date: Thu Nov 26 15:20:19 2015 -0500 ext4: fix an endianness bug in ext4_encrypted_zeroout() commit e2c9e0b28e146c9a3bce21408f3c02e24ac7ac31 upstream. ex->ee_block is not host-endian (note that accesses of other fields of *ex right next to that line go through the helpers that do proper conversion from little-endian to host-endian; it might make sense to add similar for ->ee_block to avoid reintroducing that kind of bugs...) Signed-off-by: Al Viro Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a97f1a5a270b6633961588c64d532e1c0808c4f5 Author: David Turner Date: Tue Nov 24 14:34:37 2015 -0500 ext4: Fix handling of extended tv_sec commit a4dad1ae24f850410c4e60f22823cba1289b8d52 upstream. In ext4, the bottom two bits of {a,c,m}time_extra are used to extend the {a,c,m}time fields, deferring the year 2038 problem to the year 2446. When decoding these extended fields, for times whose bottom 32 bits would represent a negative number, sign extension causes the 64-bit extended timestamp to be negative as well, which is not what's intended. This patch corrects that issue, so that the only negative {a,c,m}times are those between 1901 and 1970 (as per 32-bit signed timestamps). Some older kernels might have written pre-1970 dates with 1,1 in the extra bits. This patch treats those incorrectly-encoded dates as pre-1970, instead of post-2311, until kernel 4.20 is released. Hopefully by then e2fsck will have fixed up the bad data. Also add a comment explaining the encoding of ext4's extra {a,c,m}time bits. Signed-off-by: David Turner Signed-off-by: Theodore Ts'o Reported-by: Mark Harris Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=23732 Signed-off-by: Greg Kroah-Hartman commit e940b91711d33f91f999ee62af14f9eb7664b3c3 Author: Dan Williams Date: Tue Sep 29 15:48:11 2015 -0400 ext2, ext4: warn when mounting with dax enabled commit ef83b6e8f40bb24b92ad73b5889732346e54a793 upstream. Similar to XFS warn when mounting DAX while it is still considered under development. Also, aspects of the DAX implementation, for example synchronization against multiple faults and faults causing block allocation, depend on the correct implementation in the filesystem. The maturity of a given DAX implementation is filesystem specific. Cc: "Theodore Ts'o" Cc: Matthew Wilcox Cc: linux-ext4@vger.kernel.org Cc: Kirill A. Shutemov Reported-by: Dave Chinner Acked-by: Jan Kara Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 949d865fff8a6a863216f71df6061cc78cd4cd53 Author: Tadeusz Struk Date: Wed Jan 13 20:57:40 2016 -0800 crypto: fix test vector for rsa After the fix to the asn1_decoder in commit: 0d62e9dd "ASN.1: Fix non-match detection failure on data overrun" the rsa algorithm is failing to register in 4.3 stable kernels with error: "alg: rsa: test failed on vector 4, err=-74" This happens because the asn1 definition for the rsa key that has been added in 4.2 defined all 3 components of the key as non-optional, as the asn1_decoder before the fix was working fine for both the private and public keys. This patch adds the missing (fake) component to one key vector to allow the algorithm to successfully register and be used with a valid private keys later. This is only to make the asn1_decoder successfully parse the key and the fake component is never used in the test as the vector is marked as public key. This patch applies only to 4.3 kernels as the 4.2 version of asn1_decoder works fine with the asn1 definition. 4.4 is also ok because the akcipher interface has been changed, and the set_key function has been split into set_public_key and set_priv_key and there are two separate asn1 definitions for the two key formats with all the required components correctly defined (commit 22287b0). Signed-off-by: Tadeusz Struk Acked-by: Herbert Xu commit fedc457a9a6dbe62db206bae1487a1da9bb0d217 Author: Mathias Nyman Date: Fri Dec 11 14:38:06 2015 +0200 xhci: fix usb2 resume timing and races. commit f69115fdbc1ac0718e7d19ad3caa3da2ecfe1c96 upstream. According to USB 2 specs ports need to signal resume for at least 20ms, in practice even longer, before moving to U0 state. Both host and devices can initiate resume. On device initiated resume, a port status interrupt with the port in resume state in issued. The interrupt handler tags a resume_done[port] timestamp with current time + USB_RESUME_TIMEOUT, and kick roothub timer. Root hub timer requests for port status, finds the port in resume state, checks if resume_done[port] timestamp passed, and set port to U0 state. On host initiated resume, current code sets the port to resume state, sleep 20ms, and finally sets the port to U0 state. This should also be changed to work in a similar way as the device initiated resume, with timestamp tagging, but that is not yet tested and will be a separate fix later. There are a few issues with this approach 1. A host initiated resume will also generate a resume event. The event handler will find the port in resume state, believe it's a device initiated resume, and act accordingly. 2. A port status request might cut the resume signalling short if a get_port_status request is handled during the host resume signalling. The port will be found in resume state. The timestamp is not set leading to time_after_eq(jiffies, timestamp) returning true, as timestamp = 0. get_port_status will proceed with moving the port to U0. 3. If an error, or anything else happens to the port during device initiated resume signalling it will leave all the device resume parameters hanging uncleared, preventing further suspend, returning -EBUSY, and cause the pm thread to busyloop trying to enter suspend. Fix this by using the existing resuming_ports bitfield to indicate that resume signalling timing is taken care of. Check if the resume_done[port] is set before using it for timestamp comparison, and also clear out any resume signalling related variables if port is not in U0 or Resume state This issue was discovered when a PM thread busylooped, trying to runtime suspend the xhci USB 2 roothub on a Dell XPS Reported-by: Daniel J Blueman Tested-by: Daniel J Blueman Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 0f530a36877e262244eacaaba4f6ec39b2501db0 Author: Ard Biesheuvel Date: Mon Nov 16 11:18:14 2015 +0100 arm64: mm: use correct mapping granularity under DEBUG_RODATA commit 4fee9f364b9b99f76732f2a6fd6df679a237fa74 upstream. When booting a 64k pages kernel that is built with CONFIG_DEBUG_RODATA and resides at an offset that is not a multiple of 512 MB, the rounding that occurs in __map_memblock() and fixup_executable() results in incorrect regions being mapped. The following snippet from /sys/kernel/debug/kernel_page_tables shows how, when the kernel is loaded 2 MB above the base of DRAM at 0x40000000, the first 2 MB of memory (which may be inaccessible from non-secure EL1 or just reserved by the firmware) is inadvertently mapped into the end of the module region. ---[ Modules start ]--- 0xfffffdffffe00000-0xfffffe0000000000 2M RW NX ... UXN MEM/NORMAL ---[ Modules end ]--- ---[ Kernel Mapping ]--- 0xfffffe0000000000-0xfffffe0000090000 576K RW NX ... UXN MEM/NORMAL 0xfffffe0000090000-0xfffffe0000200000 1472K ro x ... UXN MEM/NORMAL 0xfffffe0000200000-0xfffffe0000800000 6M ro x ... UXN MEM/NORMAL 0xfffffe0000800000-0xfffffe0000810000 64K ro x ... UXN MEM/NORMAL 0xfffffe0000810000-0xfffffe0000a00000 1984K RW NX ... UXN MEM/NORMAL 0xfffffe0000a00000-0xfffffe00ffe00000 4084M RW NX ... UXN MEM/NORMAL The same issue is likely to occur on 16k pages kernels whose load address is not a multiple of 32 MB (i.e., SECTION_SIZE). So round to SWAPPER_BLOCK_SIZE instead of SECTION_SIZE. Fixes: da141706aea5 ("arm64: add better page protections to arm64") Signed-off-by: Ard Biesheuvel Acked-by: Mark Rutland Acked-by: Laura Abbott Signed-off-by: Catalin Marinas [ard.biesheuvel: add #define of SWAPPER_BLOCK_SIZE for -stable version] Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 84ba3e7dd2dfb617f890f0bd4c27c4f478d13582 Author: Will Deacon Date: Tue Dec 15 16:08:12 2015 +0000 iommu/io-pgtable-arm: Ensure we free the final level on teardown commit 12c2ab09571e8aae3a87da2a4a452632a5fac1e5 upstream. When tearing down page tables, we return early for the final level since we know that we won't have any table pointers to follow. Unfortunately, this also means that we forget to free the final level, so we end up leaking memory. Fix the issue by always freeing the current level, but just don't bother to iterate over the ptes if we're at the final level. Reported-by: Zhang Bo Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 459cd75bada64e377cdeb92f1f76f8c474e73e46 Author: Peter Hurley Date: Sun Jan 10 22:40:55 2016 -0800 tty: Fix unsafe ldisc reference via ioctl(TIOCGETD) commit 5c17c861a357e9458001f021a7afa7aab9937439 upstream. ioctl(TIOCGETD) retrieves the line discipline id directly from the ldisc because the line discipline id (c_line) in termios is untrustworthy; userspace may have set termios via ioctl(TCSETS*) without actually changing the line discipline via ioctl(TIOCSETD). However, directly accessing the current ldisc via tty->ldisc is unsafe; the ldisc ptr dereferenced may be stale if the line discipline is changing via ioctl(TIOCSETD) or hangup. Wait for the line discipline reference (just like read() or write()) to retrieve the "current" line discipline id. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit be883527a34effc3c7d2d851593a587956d0a6d1 Author: Peter Hurley Date: Sat Jan 9 21:13:45 2016 -0800 tty: Retry failed reopen if tty teardown in-progress commit 7f22f6c935cda600660e623a411fe380015d28d9 upstream. A small window exists where a tty reopen will observe the tty just prior to imminent teardown (tty->count == 0); in this case, open() returns EIO to userspace. Instead, retry the open after checking for signals and yielding; this interruptible retry loop allows teardown to commence and initialize a new tty on retry. Never retry the BSD master pty reopen; there is no guarantee the pty pair teardown is imminent since the slave file descriptors may remain open indefinitely. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit a526e121e137bef3aea68a2491c7c48a4fd124f3 Author: Peter Hurley Date: Fri Nov 27 14:25:08 2015 -0500 tty: Fix GPF in flush_to_ldisc() commit 9ce119f318ba1a07c29149301f1544b6c4bea52a upstream. A line discipline which does not define a receive_buf() method can can cause a GPF if data is ever received [1]. Oddly, this was known to the author of n_tracesink in 2011, but never fixed. [1] GPF report BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD 3752d067 PUD 37a7b067 PMD 0 Oops: 0010 [#1] SMP KASAN Modules linked in: CPU: 2 PID: 148 Comm: kworker/u10:2 Not tainted 4.4.0-rc2+ #51 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: events_unbound flush_to_ldisc task: ffff88006da94440 ti: ffff88006db60000 task.ti: ffff88006db60000 RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff88006db67b50 EFLAGS: 00010246 RAX: 0000000000000102 RBX: ffff88003ab32f88 RCX: 0000000000000102 RDX: 0000000000000000 RSI: ffff88003ab330a6 RDI: ffff88003aabd388 RBP: ffff88006db67c48 R08: ffff88003ab32f9c R09: ffff88003ab31fb0 R10: ffff88003ab32fa8 R11: 0000000000000000 R12: dffffc0000000000 R13: ffff88006db67c20 R14: ffffffff863df820 R15: ffff88003ab31fb8 FS: 0000000000000000(0000) GS:ffff88006dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000037938000 CR4: 00000000000006e0 Stack: ffffffff829f46f1 ffff88006da94bf8 ffff88006da94bf8 0000000000000000 ffff88003ab31fb0 ffff88003aabd438 ffff88003ab31ff8 ffff88006430fd90 ffff88003ab32f9c ffffed0007557a87 1ffff1000db6cf78 ffff88003ab32078 Call Trace: [] process_one_work+0x8f1/0x17a0 kernel/workqueue.c:2030 [] worker_thread+0xd4/0x1180 kernel/workqueue.c:2162 [] kthread+0x1cf/0x270 drivers/block/aoe/aoecmd.c:1302 [] ret_from_fork+0x3f/0x70 arch/x86/entry/entry_64.S:468 Code: Bad RIP value. RIP [< (null)>] (null) RSP CR2: 0000000000000000 ---[ end trace a587f8947e54d6ea ]--- Reported-by: Dmitry Vyukov Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 7fd20acac482af099704907925371056c6001861 Author: Peter Hurley Date: Sun Jan 10 22:40:56 2016 -0800 n_tty: Fix unsafe reference to "other" ldisc commit 6d27a63caad3f13e96cf065d2d96828c2006be6b upstream. Although n_tty_check_unthrottle() has a valid ldisc reference (since the tty core gets the ldisc ref in tty_read() before calling the line discipline read() method), it does not have a valid ldisc reference to the "other" pty of a pty pair. Since getting an ldisc reference for tty->link essentially open-codes tty_wakeup(), just replace with the equivalent tty_wakeup(). Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 92a26cac690e946a560e02ca2d7ef7de265175f3 Author: Peter Hurley Date: Fri Nov 27 13:59:20 2015 -0500 n_tty: Fix poll() after buffer-limited eof push read commit ac8f3bf8832a405cc6e4dccb1d26d5cb2994d234 upstream. commit 40d5e0905a03 ("n_tty: Fix EOF push handling") fixed EOF push for reads. However, that approach still allows a condition mismatch between poll() and read(), where poll() returns POLLIN but read() blocks. This state can happen when a previous read() returned because the user buffer was full and the next character was an EOF not at the beginning of the line. While the next read() will properly identify the condition and advance the read buffer tail without improperly indicating an EOF file condition (ie., read() will not mistakenly return 0), poll() will mistakenly indicate POLLIN. Although a possible solution would be to peek at the input buffer in n_tty_poll(), the better solution in this patch is to eat the EOF during the previous read() (ie., fix the problem by eliminating the condition). The current canon line buffer copy limits the scan for next end-of-line to the smaller of either, a. the remaining user buffer size b. completed lines in the input buffer When the remaining user buffer size is exactly one less than the end-of-line marked by EOF push, the EOF is not scanned nor skipped but left for subsequent reads. In the example below, the scan index 'eol' has stopped at the EOF because it is past the scan limit of 5 (not because it has found the next set bit in read_flags) user buffer [*nr = 5] _ _ _ _ _ read_flags 0 0 0 0 0 1 input buffer h e l l o [EOF] ^ ^ / / tail eol result: found = 0, tail += 5, *nr += 5 Instead, allow the scan to peek ahead 1 byte (while still limiting the scan to completed lines in the input buffer). For the example above, result: found = 1, tail += 6, *nr += 5 Because the scan limit is now bumped +1 byte, when the scan is completed, the tail advance and the user buffer copy limit is re-clamped to *nr when EOF is _not_ found. Fixes: 40d5e0905a03 ("n_tty: Fix EOF push handling") Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman commit 69ec187eed0a8e776714dd721944b658efef78e9 Author: Lu Baolu Date: Tue Jan 26 17:50:08 2016 +0200 usb: xhci: apply XHCI_PME_STUCK_QUIRK to Intel Broxton-M platforms commit ccc04afb72cddbdf7c0e1c17e92886405a71b754 upstream. Intel Broxton M was verifed to require XHCI_PME_STUCK_QUIRK quirk as well. Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit 1236d3aa34cc154acd8c73b948bf17239f572369 Author: Lu Baolu Date: Tue Jan 26 17:50:05 2016 +0200 usb: xhci: handle both SSIC ports in PME stuck quirk commit fa89537783cb442263fa5a14df6c7693eaf32f11 upstream. Commit abce329c27b3 ("xhci: Workaround to get D3 working in Intel xHCI") adds a workaround for a limitation of PME storm caused by SSIC port in some Intel SoCs. This commit only handled one SSIC port, while there are actually two SSIC ports in the chips. This patch handles both SSIC ports. Without this fix, users still see PME storm. Signed-off-by: Zhuang Jin Can Signed-off-by: Lu Baolu Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman commit bbad7eb9e862f812841fb00181e70c23a75f7880 Author: Srinivas Kandagatla Date: Wed Jan 13 09:13:10 2016 +0000 usb: phy: msm: fix error handling in probe. commit a38a08dfaaab978dced63aa9cad45f0f62e23a66 upstream. This driver registers for extcon events as part of its probe, but never unregisters them in case of error in the probe path. There were multiple issues noticed due to this missing error handling. One of them is random crashes if the regulators are not ready yet by the time probe is invoked. Ivan's previous attempt [1] to fix this issue, did not really address all the failure cases like regualtor/get_irq failures. [1] https://lkml.org/lkml/2015/9/7/62 Without this patch the kernel would carsh with log: ... Unable to handle kernel paging request at virtual address 17d78410 pgd = ffffffc001a5c000 [17d78410] *pgd=00000000b6806003, *pud=00000000b6806003, *pmd=0000000000000000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.4.0+ #48 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) Workqueue: deferwq deferred_probe_work_func task: ffffffc03686e900 ti: ffffffc0368b0000 task.ti: ffffffc0368b0000 PC is at raw_notifier_chain_register+0x1c/0x44 LR is at extcon_register_notifier+0x88/0xc8 pc : [] lr : [] pstate: 80000085 sp : ffffffc0368b3a70 x29: ffffffc0368b3a70 x28: ffffffc03680c310 x27: ffffffc035518000 x26: ffffffc035518000 x25: ffffffc03bfa20e0 x24: ffffffc035580a18 x23: 0000000000000000 x22: ffffffc035518458 x21: ffffffc0355e9a60 x20: ffffffc035518000 x19: 0000000000000000 x18: 0000000000000028 x17: 0000000000000003 x16: ffffffc0018153c8 x15: 0000000000000001 x14: ffffffc03686f0f8 x13: ffffffc03686f0f8 x12: 0000000000000003 x11: 0000000000000001 x10: 0000000000000001 x9 : ffffffc03686f0f8 x8 : 0000e3872014c1a1 x7 : 0000000000000028 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000000 x3 : 00000000354fb170 x2 : 0000000017d78400 x1 : ffffffc0355e9a60 x0 : ffffffc0354fb268 Fixes: 591fc116f330 ("usb: phy: msm: Use extcon framework for VBUS and ID detection") Signed-off-by: Srinivas Kandagatla Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 0db18daf5660638f656b14dca5e88c0e2abe3553 Author: Lu Baolu Date: Wed Jan 6 15:10:04 2016 +0800 usb: cdc-acm: send zero packet for intel 7260 modem commit ffdb1e369a73b380fce95b05f8498d92c43842b4 upstream. For Intel 7260 modem, it is needed for host side to send zero packet if the BULK OUT size is equal to USB endpoint max packet length. Otherwise, modem side may still wait for more data and cannot give response to host side. Signed-off-by: Konrad Leszczynski Signed-off-by: Lu Baolu Signed-off-by: Greg Kroah-Hartman commit 8b49e8a722ee06124a54a917cfded715eea58310 Author: Lu Baolu Date: Wed Dec 30 12:59:08 2015 +0800 usb: cdc-acm: handle unlinked urb in acm read callback commit 19454462acb1bdef80542061bdc9b410e4ed1ff6 upstream. In current acm driver, the bulk-in callback function ignores the URBs unlinked in usb core. This causes unexpected data loss in some cases. For example, runtime suspend entry will unlinked all urbs and set urb->status to -ENOENT even those urbs might have data not processed yet. Hence, data loss occurs. This patch lets bulk-in callback function handle unlinked urbs to avoid data loss. Signed-off-by: Tang Jian Qiang Signed-off-by: Lu Baolu Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit d81ebb79a2ae8166b848e069ab806cc5e389f35f Author: John Ernberg Date: Mon Jan 25 12:27:17 2016 +0000 USB: option: fix Cinterion AHxx enumeration commit 4152b387da81617c80cb2946b2d56e3958906b3e upstream. In certain kernel configurations where the cdc_ether and option drivers are compiled as modules there can occur a race condition in enumeration. This causes the option driver to enumerate the ethernet(wwan) interface as usb-serial interfaces. usb-devices output for the modem: T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e2d ProdID=0055 Rev=00.00 S: Manufacturer=Cinterion S: Product=AHx C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=10mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option I: If#= 4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether I: If#= 5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether Signed-off-by: John Ernberg Fixes: 1941138e1c02 ("USB: added support for Cinterion's products...") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0a58ede175340aedeea398bce0ade29831781adb Author: Daniele Palmas Date: Tue Jan 12 17:22:06 2016 +0100 USB: serial: option: Adding support for Telit LE922 commit ff4e2494dc17b173468e1713fdf6237fd8578bc7 upstream. This patch adds support for two PIDs of LE922. Signed-off-by: Daniele Palmas Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit cf380929a9fdfe359100263a4796ea05309d4fa4 Author: Peter Dedecker Date: Fri Jan 8 12:34:41 2016 +0100 USB: cp210x: add ID for IAI USB to RS485 adaptor commit f487c54ddd544e1c9172cd510954f697b77b76e3 upstream. Added the USB serial console device ID for IAI Corp. RCB-CV-USB USB to RS485 adaptor. Signed-off-by: Peter Dedecker Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 806926bf3e25ee049aa4524b082f43bbab6648f6 Author: Greg Kroah-Hartman Date: Tue Jan 19 23:43:13 2016 -0800 USB: serial: ftdi_sio: add support for Yaesu SCU-18 cable commit e03cdf22a2727c60307be6a729233edab3bfda9c upstream. Harald Linden reports that the ftdi_sio driver works properly for the Yaesu SCU-18 cable if the device ids are added to the driver. So let's add them. Reported-by: Harald Linden Signed-off-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9932571e08f36fdb83d8a29de5a6b6aeae6dbfb8 Author: Du, Changbin Date: Mon Jan 18 21:02:42 2016 +0800 usb: hub: do not clear BOS field during reset device commit d8f00cd685f5c8e0def8593e520a7fef12c22407 upstream. In function usb_reset_and_verify_device, the old BOS descriptor may still be used before allocating a new one. (usb_unlocked_disable_lpm function uses it under the situation that it fails to disable lpm.) So we cannot set the udev->bos to NULL before that, just keep what it was. It will be overwrite when allocating a new one. Crash log: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [] usb_enable_link_state+0x2d/0x2f0 Call Trace: [] ? usb_set_lpm_timeout+0x12b/0x140 [] usb_enable_lpm+0x81/0xa0 [] usb_disable_lpm+0xa8/0xc0 [] usb_unlocked_disable_lpm+0x2c/0x50 [] usb_reset_and_verify_device+0xc3/0x710 [] ? usb_sg_wait+0x13d/0x190 [] usb_reset_device+0x133/0x280 [] usb_stor_port_reset+0x61/0x70 [] usb_stor_invoke_transport+0x88/0x520 Signed-off-by: Du, Changbin Signed-off-by: Greg Kroah-Hartman commit 52827582844e0a6b951875e64d799e68ed4cceb7 Author: Johan Hovold Date: Tue Jan 12 12:05:20 2016 +0100 USB: visor: fix null-deref at probe commit cac9b50b0d75a1d50d6c056ff65c005f3224c8e0 upstream. Fix null-pointer dereference at probe should a (malicious) Treo device lack the expected endpoints. Specifically, the Treo port-setup hack was dereferencing the bulk-in and interrupt-in urbs without first making sure they had been allocated by core. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ac4589db9b4285b662456715a4c07110bc37370e Author: Vladis Dronov Date: Tue Jan 12 15:10:50 2016 +0100 USB: serial: visor: fix crash on detecting device without write_urbs commit cb3232138e37129e88240a98a1d2aba2187ff57c upstream. The visor driver crashes in clie_5_attach() when a specially crafted USB device without bulk-out endpoint is detected. This fix adds a check that the device has proper configuration expected by the driver. Reported-by: Ralf Spenneberg Signed-off-by: Vladis Dronov Fixes: cfb8da8f69b8 ("USB: visor: fix initialisation of UX50/TH55 devices") Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 16e87ee84a8918c1db87dd775cafd81c750d1a86 Author: Bard Liao Date: Thu Jan 21 13:13:40 2016 +0800 ASoC: rt5645: fix the shift bit of IN1 boost commit b28785fa9cede0d4f47310ca0dd2a4e1d50478b5 upstream. The shift bit of IN1 boost gain control is 12. Signed-off-by: Bard Liao Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a4d744044ae039600b3f0523786fc6cf602a0712 Author: Mauro Carvalho Chehab Date: Thu Feb 4 15:59:43 2016 -0200 saa7134-alsa: Only frees registered sound cards commit ac75fe5d8fe4a0bf063be18fb29684405279e79e upstream. That prevents this bug: [ 2382.269496] BUG: unable to handle kernel NULL pointer dereference at 0000000000000540 [ 2382.270013] IP: [] snd_card_free+0x36/0x70 [snd] [ 2382.270013] PGD 0 [ 2382.270013] Oops: 0002 [#1] SMP [ 2382.270013] Modules linked in: saa7134_alsa(-) tda1004x saa7134_dvb videobuf2_dvb dvb_core tda827x tda8290 tuner saa7134 tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core v4l2_common videodev media auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc tun bridge stp llc ebtables ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack it87 hwmon_vid snd_hda_codec_idt snd_hda_codec_generic iTCO_wdt iTCO_vendor_support snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq pcspkr i2c_i801 snd_seq_device snd_pcm snd_timer lpc_ich snd mfd_core soundcore binfmt_misc i915 video i2c_algo_bit drm_kms_helper drm r8169 ata_generic serio_raw pata_acpi mii i2c_core [last unloaded: videobuf2_memops] [ 2382.270013] CPU: 0 PID: 4899 Comm: rmmod Not tainted 4.5.0-rc1+ #4 [ 2382.270013] Hardware name: PCCHIPS P17G/P17G, BIOS 080012 05/14/2008 [ 2382.270013] task: ffff880039c38000 ti: ffff88003c764000 task.ti: ffff88003c764000 [ 2382.270013] RIP: 0010:[] [] snd_card_free+0x36/0x70 [snd] [ 2382.270013] RSP: 0018:ffff88003c767ea0 EFLAGS: 00010286 [ 2382.270013] RAX: ffff88003c767eb8 RBX: 0000000000000000 RCX: 0000000000006260 [ 2382.270013] RDX: ffffffffa020a060 RSI: ffffffffa0206de1 RDI: ffff88003c767eb0 [ 2382.270013] RBP: ffff88003c767ed8 R08: 0000000000019960 R09: ffffffff811a5412 [ 2382.270013] R10: ffffea0000d7c200 R11: 0000000000000000 R12: ffff88003c767ea8 [ 2382.270013] R13: 00007ffe760617f7 R14: 0000000000000000 R15: 0000557625d7f1e0 [ 2382.270013] FS: 00007f80bb1c0700(0000) GS:ffff88003f400000(0000) knlGS:0000000000000000 [ 2382.270013] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 2382.270013] CR2: 0000000000000540 CR3: 000000003c00f000 CR4: 00000000000006f0 [ 2382.270013] Stack: [ 2382.270013] 000000003c767ed8 ffffffff00000000 ffff880000000000 ffff88003c767eb8 [ 2382.270013] ffff88003c767eb8 ffffffffa049a890 00007ffe76060060 ffff88003c767ef0 [ 2382.270013] ffffffffa049889d ffffffffa049a500 ffff88003c767f48 ffffffff8111079c [ 2382.270013] Call Trace: [ 2382.270013] [] saa7134_alsa_exit+0x1d/0x780 [saa7134_alsa] [ 2382.270013] [] SyS_delete_module+0x19c/0x1f0 [ 2382.270013] [] entry_SYSCALL_64_fastpath+0x12/0x71 [ 2382.270013] Code: 20 a0 48 c7 c6 e1 6d 20 a0 48 89 e5 41 54 53 4c 8d 65 d0 48 89 fb 48 83 ec 28 c7 45 d0 00 00 00 00 49 8d 7c 24 08 e8 7a 55 ed e0 <4c> 89 a3 40 05 00 00 48 89 df e8 eb fd ff ff 85 c0 75 1a 48 8d [ 2382.270013] RIP [] snd_card_free+0x36/0x70 [snd] [ 2382.270013] RSP [ 2382.270013] CR2: 0000000000000540 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 6f2b0ab8f60ebe956fa6dea30ae2d52b0664faad Author: Takashi Iwai Date: Tue Feb 2 15:27:36 2016 +0100 ALSA: dummy: Implement timer backend switching more safely commit ddce57a6f0a2d8d1bfacfa77f06043bc760403c2 upstream. Currently the selected timer backend is referred at any moment from the running PCM callbacks. When the backend is switched, it's possible to lead to inconsistency from the running backend. This was pointed by syzkaller fuzzer, and the commit [7ee96216c31a: ALSA: dummy: Disable switching timer backend via sysfs] disabled the dynamic switching for avoiding the crash. This patch improves the handling of timer backend switching. It keeps the reference to the selected backend during the whole operation of an opened stream so that it won't be changed by other streams. Together with this change, the hrtimer parameter is reenabled as writable now. NOTE: this patch also turned out to fix the still remaining race. Namely, ops was still replaced dynamically at dummy_pcm_open: static int dummy_pcm_open(struct snd_pcm_substream *substream) { .... dummy->timer_ops = &dummy_systimer_ops; if (hrtimer) dummy->timer_ops = &dummy_hrtimer_ops; Since dummy->timer_ops is common among all streams, and when the replacement happens during accesses of other streams, it may lead to a crash. This was actually triggered by syzkaller fuzzer and KASAN. This patch rewrites the code not to use the ops shared by all streams any longer, too. BugLink: http://lkml.kernel.org/r/CACT4Y+aZ+xisrpuM6cOXbL21DuM0yVxPYXf4cD4Md9uw0C3dBQ@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a25dc44fcb8ec926a7fe34a81094b7e4451c37d6 Author: Takashi Iwai Date: Tue Feb 9 10:23:52 2016 +0100 ALSA: hda - Fix bad dereference of jack object commit 2ebab40eb74a0225d5dfba72bfae317dd948fa2d upstream. The hda_jack_tbl entries are managed by snd_array for allowing multiple jacks. It's good per se, but the problem is that struct hda_jack_callback keeps the hda_jack_tbl pointer. Since snd_array doesn't preserve each pointer at resizing the array, we can't keep the original pointer but have to deduce the pointer at each time via snd_array_entry() instead. Actually, this resulted in the deference to the wrong pointer on codecs that have many pins such as CS4208. This patch replaces the pointer to the NID value as the search key. As an unexpected good side effect, this even simplifies the code, as only NID is needed in most cases. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ef29f3c707b8d95dd696342915c4afc5cd807898 Author: Takashi Iwai Date: Sun Feb 7 09:38:26 2016 +0100 ALSA: hda - Fix speaker output from VAIO AiO machines commit c44d9b1181cf34e0860c72cc8a00e0c47417aac0 upstream. Some Sony VAIO AiO models (VGC-JS4EF and VGC-JS25G, both with PCI SSID 104d:9044) need the same quirk to make the speaker working properly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112031 Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2c49047af94572d8ed75036818d7b186a5a04b44 Author: Takashi Iwai Date: Fri Feb 5 20:12:24 2016 +0100 Revert "ALSA: hda - Fix noise on Gigabyte Z170X mobo" commit 6c361d10e0eb859233c71954abcd20d2d8700587 upstream. This reverts commit 0c25ad80408e95e0a4fbaf0056950206e95f726f. The original commit disabled the aamixer path due to the noise problem, but it turned out that some mobo with the same PCI SSID doesn't suffer from the issue, and the disabled function (analog loopback) is still demanded by users. Since the recent commit [e7fdd52779a6: ALSA: hda - Implement loopback control switch for Realtek and other codecs], we have the dynamic mixer switch to enable/disable the aamix path, and we don't have to disable the path statically any longer. So, let's revert the disablement, so that only the user suffering from the noise problem can turn off the aamix on the fly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301 Reported-by: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 49a233653fb2c73745d124ecf66d66bfbb4eedfe Author: David Henningsson Date: Fri Feb 5 09:05:41 2016 +0100 ALSA: hda - Fix static checker warning in patch_hdmi.c commit 360a8245680053619205a3ae10e6bfe624a5da1d upstream. The static checker warning is: sound/pci/hda/patch_hdmi.c:460 hdmi_eld_ctl_get() error: __memcpy() 'eld->eld_buffer' too small (256 vs 512) I have a hard time figuring out if this can ever cause an information leak (I don't think so), but nonetheless it does not hurt to increase the robustness of the code. Fixes: 68e03de98507 ('ALSA: hda - hdmi: Do not expose eld data when eld is invalid') Reported-by: Dan Carpenter Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 8478a658f562ead07e250bc7f7fd9f1ed03e18de Author: Takashi Iwai Date: Wed Feb 3 12:32:51 2016 +0100 ALSA: hda - Add fixup for Mac Mini 7,1 model commit 2154cc0e2d4ae15132d005d17e473327c70c9a06 upstream. Mac Mini 7,1 model with CS4208 codec reports the headphone jack detection wrongly in an inverted way. Moreover, the advertised pins for the audio input and SPDIF output have actually no jack detection. This patch addresses these issues. The inv_jack_detect flag is set for fixing the headphone jack detection, and the pin configs for audio input and SPDIF output are marked as non-detectable. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105161 Report-and-tested-by: moosotc@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 20dfd7a45026e01d1b47b90d795b7d0219444ac1 Author: Takashi Iwai Date: Tue Feb 9 12:02:32 2016 +0100 ALSA: timer: Fix race between stop and interrupt commit ed8b1d6d2c741ab26d60d499d7fbb7ac801f0f51 upstream. A slave timer element also unlinks at snd_timer_stop() but it takes only slave_active_lock. When a slave is assigned to a master, however, this may become a race against the master's interrupt handling, eventually resulting in a list corruption. The actual bug could be seen with a syzkaller fuzzer test case in BugLink below. As a fix, we need to take timeri->timer->lock when timer isn't NULL, i.e. assigned to a master, while the assignment to a master itself is protected by slave_active_lock. BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 29a340ec2ccd8cbabff20f99e70997aa1a6d3454 Author: Takashi Iwai Date: Mon Feb 8 17:36:25 2016 +0100 ALSA: timer: Fix wrong instance passed to slave callbacks commit 117159f0b9d392fb433a7871426fad50317f06f7 upstream. In snd_timer_notify1(), the wrong timer instance was passed for slave ccallback function. This leads to the access to the wrong data when an incompatible master is handled (e.g. the master is the sequencer timer and the slave is a user timer), as spotted by syzkaller fuzzer. This patch fixes that wrong assignment. BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 975d3f3449f53f9caf9f52ea9669bf7cb93e07e5 Author: Takashi Iwai Date: Mon Feb 8 17:26:58 2016 +0100 ALSA: timer: Fix race at concurrent reads commit 4dff5c7b7093b19c19d3a100f8a3ad87cb7cd9e7 upstream. snd_timer_user_read() has a potential race among parallel reads, as qhead and qused are updated outside the critical section due to copy_to_user() calls. Move them into the critical section, and also sanitize the relevant code a bit. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fe12db461a0302361d36013776f0e4f4bb9c0566 Author: Takashi Iwai Date: Sat Jan 30 23:09:08 2016 +0100 ALSA: timer: Fix link corruption due to double start or stop commit f784beb75ce82f4136f8a0960d3ee872f7109e09 upstream. Although ALSA timer code got hardening for races, it still causes use-after-free error. This is however rather a corrupted linked list, not actually the concurrent accesses. Namely, when timer start is triggered twice, list_add_tail() is called twice, too. This ends up with the link corruption and triggers KASAN error. The simplest fix would be replacing list_add_tail() with list_move_tail(), but fundamentally it's the problem that we don't check the double start/stop correctly. So, the right fix here is to add the proper checks to snd_timer_start() and snd_timer_stop() (and their variants). BugLink: http://lkml.kernel.org/r/CACT4Y+ZyPRoMQjmawbvmCEDrkBD2BQuH7R09=eOkf5ESK8kJAw@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d5f5952d2a21f09ccbcd6f639f2fd8a7e4778416 Author: Takashi Iwai Date: Thu Feb 4 17:06:13 2016 +0100 ALSA: timer: Fix leftover link at closing commit 094fd3be87b0f102589e2d5c3fa5d06b7e20496d upstream. In ALSA timer core, the active timer instance is managed in active_list linked list. Each element is added / removed dynamically at timer start, stop and in timer interrupt. The problem is that snd_timer_interrupt() has a thinko and leaves the element in active_list when it's the last opened element. This eventually leads to list corruption or use-after-free error. This hasn't been revealed because we used to delete the list forcibly in snd_timer_stop() in the past. However, the recent fix avoids the double-stop behavior (in commit [f784beb75ce8: ALSA: timer: Fix link corruption due to double start or stop]), and this leak hits reality. This patch fixes the link management in snd_timer_interrupt(). Now it simply unlinks no matter which stream is. BugLink: http://lkml.kernel.org/r/CACT4Y+Yy2aukHP-EDp8-ziNqNNmb-NTf=jDWXMP7jB8HDa2vng@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 51ac0a7a5b1d3fa08639019a721736752914cc77 Author: Takashi Iwai Date: Thu Jan 14 17:01:46 2016 +0100 ALSA: timer: Code cleanup commit c3b1681375dc6e71d89a3ae00cc3ce9e775a8917 upstream. This is a minor code cleanup without any functional changes: - Kill keep_flag argument from _snd_timer_stop(), as all callers pass only it false. - Remove redundant NULL check in _snd_timer_stop(). Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 23e60f5e99b35a69970edd771dffe538ec3f6b3a Author: Takashi Iwai Date: Wed Feb 3 08:32:44 2016 +0100 ALSA: seq: Fix lockdep warnings due to double mutex locks commit 7f0973e973cd74aa40747c9d38844560cd184ee8 upstream. The port subscription code uses double mutex locks for source and destination ports, and this may become racy once when wrongly set up. It leads to lockdep warning splat, typically triggered by fuzzer like syzkaller, although the actual deadlock hasn't been seen, so far. This patch simplifies the handling by reducing to two single locks, so that no lockdep warning will be trigger any longer. By splitting to two actions, a still-in-progress element shall be added in one list while handling another. For ignoring this element, a new check is added in deliver_to_subscribers(). Along with it, the code to add/remove the subscribers list element was cleaned up and refactored. BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cf4fa9310beba9da9d7b9852146a0c2c4f451b74 Author: Takashi Iwai Date: Mon Feb 1 12:06:42 2016 +0100 ALSA: seq: Fix race at closing in virmidi driver commit 2d1b5c08366acd46c35a2e9aba5d650cb5bf5c19 upstream. The virmidi driver has an open race at closing its assigned rawmidi device, and this may lead to use-after-free in snd_seq_deliver_single_event(). Plug the hole by properly protecting the linked list deletion and calling in the right order in snd_virmidi_input_close(). BugLink: http://lkml.kernel.org/r/CACT4Y+Zd66+w12fNN85-425cVQT=K23kWbhnCEcMB8s3us-Frw@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a1f25b12b7079bc695bca53712627028566c30a2 Author: Takashi Iwai Date: Sat Jan 30 23:30:25 2016 +0100 ALSA: seq: Fix yet another races among ALSA timer accesses commit 2cdc7b636d55cbcf42e1e6c8accd85e62d3e9ae8 upstream. ALSA sequencer may open/close and control ALSA timer instance dynamically either via sequencer events or direct ioctls. These are done mostly asynchronously, and it may call still some timer action like snd_timer_start() while another is calling snd_timer_close(). Since the instance gets removed by snd_timer_close(), it may lead to a use-after-free. This patch tries to address such a race by protecting each snd_timer_*() call via the existing spinlock and also by avoiding the access to timer during close call. BugLink: http://lkml.kernel.org/r/CACT4Y+Z6RzW5MBr-HUdV-8zwg71WQfKTdPpYGvOeS7v4cyurNQ@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 974d610af151f75b016d23ba37820534e2c3fd1b Author: Vinod Koul Date: Mon Feb 1 22:26:40 2016 +0530 ASoC: dpcm: fix the BE state on hw_free commit 5e82d2be6ee53275c72e964507518d7964c82753 upstream. While performing hw_free, DPCM checks the BE state but leaves out the suspend state. The suspend state needs to be checked as well, as we might be suspended and then usermode closes rather than resuming the audio stream. This was found by a stress testing of system with playback in loop and killed after few seconds running in background and second script running suspend-resume test in loop Signed-off-by: Vinod Koul Acked-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 311571d3920e74641d2ddcaf2fbe7a6d1b7160ed Author: Takashi Iwai Date: Sun Jan 31 10:32:37 2016 +0100 ALSA: pcm: Fix potential deadlock in OSS emulation commit b248371628aad599a48540962f6b85a21a8a0c3f upstream. There are potential deadlocks in PCM OSS emulation code while accessing read/write and mmap concurrently. This comes from the infamous mmap_sem usage in copy_from/to_user(). Namely, snd_pcm_oss_write() -> &runtime->oss.params_lock -> copy_to_user() -> &mm->mmap_sem mmap() -> &mm->mmap_sem -> snd_pcm_oss_mmap() -> &runtime->oss.params_lock Since we can't avoid taking params_lock from mmap code path, use trylock variant and aborts with -EAGAIN as a workaround of this AB/BA deadlock. BugLink: http://lkml.kernel.org/r/CACT4Y+bVrBKDG0G2_AcUgUQa+X91VKTeS4v+wN7BSHwHtqn3kQ@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5cac180add9f132bcbca844b51d5ae9a20a708d4 Author: Takashi Iwai Date: Wed Feb 3 14:41:22 2016 +0100 ALSA: rawmidi: Fix race at copying & updating the position commit 81f577542af15640cbcb6ef68baa4caa610cbbfc upstream. The rawmidi read and write functions manage runtime stream status such as runtime->appl_ptr and runtime->avail. These point where to copy the new data and how many bytes have been copied (or to be read). The problem is that rawmidi read/write call copy_from_user() or copy_to_user(), and the runtime spinlock is temporarily unlocked and relocked while copying user-space. Since the current code advances and updates the runtime status after the spin unlock/relock, the copy and the update may be asynchronous, and eventually runtime->avail might go to a negative value when many concurrent accesses are done. This may lead to memory corruption in the end. For fixing this race, in this patch, the status update code is performed in the same lock before the temporary unlock. Also, the spinlock is now taken more widely in snd_rawmidi_kernel_read1() for protecting more properly during the whole operation. BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5b68916055c08c0ec26117e708a955dfb15f49b1 Author: Takashi Iwai Date: Mon Feb 1 12:04:55 2016 +0100 ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check commit cc85f7a634cfaf9f0713c6aa06d08817424db37a upstream. NULL user-space buffer can be passed even in a normal path, thus it's not good to spew a kernel warning with stack trace at each time. Just drop snd_BUG_ON() macro usage there. BugLink: http://lkml.kernel.org/r/CACT4Y+YfVJ3L+q0i-4vyQVyyPD7V=OMX0PWPi29x9Bo3QaBLdw@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6824f2eeb92bdee8277616ae163f91bd936e3504 Author: Takashi Iwai Date: Sun Jan 31 11:57:41 2016 +0100 ALSA: rawmidi: Make snd_rawmidi_transmit() race-free commit 06ab30034ed9c200a570ab13c017bde248ddb2a6 upstream. A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by syzkaller fuzzer: WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136 [] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163 [< inline >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273 [] __vfs_write+0x113/0x480 fs/read_write.c:528 [] vfs_write+0x167/0x4a0 fs/read_write.c:577 [< inline >] SYSC_write fs/read_write.c:624 [] SyS_write+0x111/0x220 fs/read_write.c:616 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 Also a similar warning is found but in another path: Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133 [] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163 [] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185 [< inline >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252 [] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302 [] __vfs_write+0x113/0x480 fs/read_write.c:528 [] vfs_write+0x167/0x4a0 fs/read_write.c:577 [< inline >] SYSC_write fs/read_write.c:624 [] SyS_write+0x111/0x220 fs/read_write.c:616 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 In the former case, the reason is that virmidi has an open code calling snd_rawmidi_transmit_ack() with the value calculated outside the spinlock. We may use snd_rawmidi_transmit() in a loop just for consuming the input data, but even there, there is a race between snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack(). Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack() separately without protection, so they are racy as well. The patch tries to address these issues by the following ways: - Introduce the unlocked versions of snd_rawmidi_transmit_peek() and snd_rawmidi_transmit_ack() to be called inside the explicit lock. - Rewrite snd_rawmidi_transmit() to be race-free (the former case). - Make the split calls (the latter case) protected in the rawmidi spin lock. BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com Reported-by: Dmitry Vyukov Tested-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4efd5448e04b54e7c9ad38e9e3e760d4cbbdba57 Author: Takashi Iwai Date: Mon Jan 25 11:24:56 2016 +0100 ALSA: seq: Degrade the error message for too many opens commit da10816e3d923565b470fec78a674baba794ed33 upstream. ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too many applications") when user-space tries to open more than the limit. This means that it can easily fill the log buffer. Since it's merely a normal error, it's safe to suppress it via pr_debug() instead. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 20a24557087fcfce897afe2f30bf6a40ccb29fd2 Author: Takashi Iwai Date: Mon Jan 25 11:01:47 2016 +0100 ALSA: seq: Fix incorrect sanity check at snd_seq_oss_synth_cleanup() commit 599151336638d57b98d92338aa59c048e3a3e97d upstream. ALSA sequencer OSS emulation code has a sanity check for currently opened devices, but there is a thinko there, eventually it spews warnings and skips the operation wrongly like: WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311 Fix this off-by-one error. Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f6e8dd2e3e451e3aeb10bff4b80a1a9612e40838 Author: Takashi Iwai Date: Thu Jan 28 07:54:16 2016 +0100 ALSA: dummy: Disable switching timer backend via sysfs commit 7ee96216c31aabe1eb42fb91ff50dae9fcd014b2 upstream. ALSA dummy driver can switch the timer backend between system timer and hrtimer via its hrtimer module option. This can be also switched dynamically via sysfs, but it may lead to a memory corruption when switching is done while a PCM stream is running; the stream instance for the newly switched timer method tries to access the memory that was allocated by another timer method although the sizes differ. As the simplest fix, this patch just disables the switch via sysfs by dropping the writable bit. BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.com Reported-by: Dmitry Vyukov Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1dacaada4d8e6164cb96a9c3f35301ac31aef791 Author: Takashi Iwai Date: Mon Jan 25 13:59:21 2016 +0100 ALSA: compress: Disable GET_CODEC_CAPS ioctl for some architectures commit 462b3f161beb62eeb290f4ec52f5ead29a2f8ac7 upstream. Some architectures like PowerPC can handle the maximum struct size in an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This problem was revealed recently by a powerpc change, as it's now treated as a fatal build error. This patch is a stop-gap for that: for architectures with less than 14 bit ioctl struct size, get rid of the handling of the relevant ioctl. We should provide an alternative equivalent ioctl code later, but for now just paper over it. Luckily, the compress API hasn't been used on such architectures, so the impact must be effectively zero. Reviewed-by: Mark Brown Acked-by: Sudip Mukherjee Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 37d0208b596f4a405966c1b2cedc4939ea9e9a6f Author: Lucas Tanure Date: Mon Jan 25 19:30:23 2016 -0200 ALSA: bebob: Use a signed return type for get_formation_index commit 07905298e4d5777eb58516cdc242f7ac1ca387a2 upstream. The return type "unsigned int" was used by the get_formation_index function despite of the aspect that it will eventually return a negative error code. So, change to signed int and get index by reference in the parameters. Done with the help of Coccinelle. [Fix the missing braces suggested by Julia Lawall -- tiwai] Signed-off-by: Lucas Tanure Reviewed-by: Takashi Sakamoto Tested-by: Takashi Sakamoto Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2009976a54a59d22521380100747a02a85c12a81 Author: Andrey Konovalov Date: Sat Feb 13 11:08:06 2016 +0300 ALSA: usb-audio: avoid freeing umidi object twice commit 07d86ca93db7e5cdf4743564d98292042ec21af7 upstream. The 'umidi' object will be free'd on the error path by snd_usbmidi_free() when tearing down the rawmidi interface. So we shouldn't try to free it in snd_usbmidi_create() after having registered the rawmidi interface. Found by KASAN. Signed-off-by: Andrey Konovalov Acked-by: Clemens Ladisch Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit be22a8907771ff7dc24f0790043ae28a507cceed Author: Jurgen Kramer Date: Fri Jan 29 14:59:25 2016 +0100 ALSA: usb-audio: Add native DSD support for PS Audio NuWave DAC commit ad678b4ccd41aa51cf5f142c0e8cffe9d61fc2bf upstream. This patch adds native DSD support for the PS Audio NuWave DAC. Signed-off-by: Jurgen Kramer Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a86111dca721df7985d11de432bb5ceea23b600a Author: Jurgen Kramer Date: Fri Jan 29 14:49:55 2016 +0100 ALSA: usb-audio: Fix OPPO HA-1 vendor ID commit 5327d6ba975042fd3da50ac6e94d1e9551ebeaec upstream. In my patch adding native DSD support for the Oppo HA-1, the wrong vendor ID got through. This patch fixes the vendor ID and aligns the comment. Fixes: a4eae3a506ea ('ALSA: usb: Add native DSD support for Oppo HA-1') Signed-off-by: Jurgen Kramer Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d684fb034a986078a96ac02a2e42f29d162f4c21 Author: Lev Lybin Date: Fri Jan 29 22:55:11 2016 +0700 ALSA: usb-audio: Add quirk for Microsoft LifeCam HD-6000 commit 1b3c993a699bed282e47c3f7c49d539c331dae04 upstream. Microsoft LifeCam HD-6000 (045e:076f) requires the similar quirk for avoiding the stall due to the invalid sample rate reads. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111491 Signed-off-by: Lev Lybin Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f759ad659f8265137397c9c501012e82c33986e7 Author: Guillaume Fougnies Date: Tue Jan 26 00:28:27 2016 +0100 ALSA: usb-audio: Fix TEAC UD-501/UD-503/NT-503 usb delay commit 5a4ff9ec8d6edd2ab1cfe8ce6a080d6e57cbea9a upstream. TEAC UD-501/UD-503/NT-503 fail to switch properly between different rate/format. Similar to 'Playback Design', this patch corrects the invalid clock source error for TEAC products and avoids complete freeze of the usb interface of 503 series. Signed-off-by: Guillaume Fougnies Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d4bba1816944f2a0524997c2b69437ef7acd3177 Author: Thomas Gleixner Date: Thu Jan 14 16:54:46 2016 +0000 hrtimer: Handle remaining time proper for TIME_LOW_RES commit 203cbf77de59fc8f13502dcfd11350c6d4a5c95f upstream. If CONFIG_TIME_LOW_RES is enabled we add a jiffie to the relative timeout to prevent short sleeps, but we do not account for that in interfaces which retrieve the remaining time. Helge observed that timerfd can return a remaining time larger than the relative timeout. That's not expected and breaks userland test programs. Store the information that the timer was armed relative and provide functions to adjust the remaining time. To avoid bloating the hrtimer struct make state a u8, which as a bonus results in better code on x86 at least. Reported-and-tested-by: Helge Deller Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: John Stultz Cc: linux-m68k@lists.linux-m68k.org Cc: dhowells@redhat.com Link: http://lkml.kernel.org/r/20160114164159.273328486@linutronix.de Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 0b06c9e84fbd9005a7b2e3b3d83f3d43b8496998 Author: Al Viro Date: Mon Nov 23 21:11:08 2015 -0500 fix sysvfs symlinks commit 0ebf7f10d67a70e120f365018f1c5fce9ddc567d upstream. The thing got broken back in 2002 - sysvfs does *not* have inline symlinks; even short ones have bodies stored in the first block of file. sysv_symlink() handles that correctly; unfortunately, attempting to look an existing symlink up will end up confusing them for inline symlinks, and interpret the block number containing the body as the body itself. Nobody has noticed until now, which says something about the level of testing sysvfs gets ;-/ Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit e4531bab2f0ffcf18fab3eb80a8ab17ddb139554 Author: Artur Paszkiewicz Date: Fri Dec 18 15:19:16 2015 +1100 md/raid10: fix data corruption and crash during resync commit cc57858831e3e9678291de730c4b4d2e52a19f59 upstream. The commit c31df25f20e3 ("md/raid10: make sync_request_write() call bio_copy_data()") replaced manual data copying with bio_copy_data() but it doesn't work as intended. The source bio (fbio) is already processed, so its bvec_iter has bi_size == 0 and bi_idx == bi_vcnt. Because of this, bio_copy_data() either does not copy anything, or worse, copies data from the ->bi_next bio if it is set. This causes wrong data to be written to drives during resync and sometimes lockups/crashes in bio_copy_data(): [ 517.338478] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [md126_raid10:3319] [ 517.347324] Modules linked in: raid10 xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables x86_pkg_temp_thermal coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul cryptd shpchp pcspkr ipmi_si ipmi_msghandler tpm_crb acpi_power_meter acpi_cpufreq ext4 mbcache jbd2 sr_mod cdrom sd_mod e1000e ax88179_178a usbnet mii ahci ata_generic crc32c_intel libahci ptp pata_acpi libata pps_core wmi sunrpc dm_mirror dm_region_hash dm_log dm_mod [ 517.440555] CPU: 0 PID: 3319 Comm: md126_raid10 Not tainted 4.3.0-rc6+ #1 [ 517.448384] Hardware name: Intel Corporation PURLEY/PURLEY, BIOS PLYDCRB1.86B.0055.D14.1509221924 09/22/2015 [ 517.459768] task: ffff880153773980 ti: ffff880150df8000 task.ti: ffff880150df8000 [ 517.468529] RIP: 0010:[] [] bio_copy_data+0xc8/0x3c0 [ 517.478164] RSP: 0018:ffff880150dfbc98 EFLAGS: 00000246 [ 517.484341] RAX: ffff880169356688 RBX: 0000000000001000 RCX: 0000000000000000 [ 517.492558] RDX: 0000000000000000 RSI: ffffea0001ac2980 RDI: ffffea0000d835c0 [ 517.500773] RBP: ffff880150dfbd08 R08: 0000000000000001 R09: ffff880153773980 [ 517.508987] R10: ffff880169356600 R11: 0000000000001000 R12: 0000000000010000 [ 517.517199] R13: 000000000000e000 R14: 0000000000000000 R15: 0000000000001000 [ 517.525412] FS: 0000000000000000(0000) GS:ffff880174a00000(0000) knlGS:0000000000000000 [ 517.534844] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 517.541507] CR2: 00007f8a044d5fed CR3: 0000000169504000 CR4: 00000000001406f0 [ 517.549722] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 517.557929] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 517.566144] Stack: [ 517.568626] ffff880174a16bc0 ffff880153773980 ffff880169356600 0000000000000000 [ 517.577659] 0000000000000001 0000000000000001 ffff880153773980 ffff88016a61a800 [ 517.586715] ffff880150dfbcf8 0000000000000001 ffff88016dd209e0 0000000000001000 [ 517.595773] Call Trace: [ 517.598747] [] raid10d+0xfc5/0x1690 [raid10] [ 517.605610] [] ? __schedule+0x29e/0x8e2 [ 517.611987] [] md_thread+0x106/0x140 [ 517.618072] [] ? wait_woken+0x80/0x80 [ 517.624252] [] ? super_1_load+0x520/0x520 [ 517.630817] [] kthread+0xc9/0xe0 [ 517.636506] [] ? flush_kthread_worker+0x70/0x70 [ 517.643653] [] ret_from_fork+0x3f/0x70 [ 517.649929] [] ? flush_kthread_worker+0x70/0x70 Signed-off-by: Artur Paszkiewicz Reviewed-by: Shaohua Li Fixes: c31df25f20e3 ("md/raid10: make sync_request_write() call bio_copy_data()") Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 440df829ac198daae102921f24dc66e8434b3b45 Author: Vladimir Davydov Date: Tue Dec 29 14:54:10 2015 -0800 mm: memcontrol: fix possible memcg leak due to interrupted reclaim commit 6df38689e0e9a07ff4f42c06b302e203b33667e9 upstream. Memory cgroup reclaim can be interrupted with mem_cgroup_iter_break() once enough pages have been reclaimed, in which case, in contrast to a full round-trip over a cgroup sub-tree, the current position stored in mem_cgroup_reclaim_iter of the target cgroup does not get invalidated and so is left holding the reference to the last scanned cgroup. If the target cgroup does not get scanned again (we might have just reclaimed the last page or all processes might exit and free their memory voluntary), we will leak it, because there is nobody to put the reference held by the iterator. The problem is easy to reproduce by running the following command sequence in a loop: mkdir /sys/fs/cgroup/memory/test echo 100M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs memhog 150M echo $$ > /sys/fs/cgroup/memory/cgroup.procs rmdir test The cgroups generated by it will never get freed. This patch fixes this issue by making mem_cgroup_iter avoid taking reference to the current position. In order not to hit use-after-free bug while running reclaim in parallel with cgroup deletion, we make use of ->css_released cgroup callback to clear references to the dying cgroup in all reclaim iterators that might refer to it. This callback is called right before scheduling rcu work which will free css, so if we access iter->position from rcu read section, we might be sure it won't go away under us. [hannes@cmpxchg.org: clean up css ref handling] Fixes: 5ac8fb31ad2e ("mm: memcontrol: convert reclaim iterator to simple css refcounting") Signed-off-by: Vladimir Davydov Signed-off-by: Johannes Weiner Acked-by: Michal Hocko Acked-by: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 39b3ce18cacb492dd523a46d810669dc44a6245a Author: Mauro Carvalho Chehab Date: Wed Nov 11 09:22:36 2015 -0200 Revert "[media] ivtv: avoid going past input/audio array" commit 823873481b2a17ce5900899f8ef85118f8407b67 upstream. This patch broke ivtv logic, as reported at https://bugzilla.redhat.com/show_bug.cgi?id=1278942 This reverts commit 09290cc885937cab3b2d60a6d48fe3d2d3e04061. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2a72db0375cb37473fb12610e613e03b0eb78b0d Author: Antonio Ospite Date: Wed Oct 14 10:57:32 2015 -0300 media/v4l2-ctrls: fix setting autocluster to manual with VIDIOC_S_CTRL commit 759b26a1d916400a1a20948eb964dea6ad0bd9e9 upstream. Since commit 5d0360a4f027576e5419d4a7c711c9ca0f1be8ca it's not possible anymore to set auto clusters from auto to manual using VIDIOC_S_CTRL. For example, setting autogain to manual with gspca/ov534 driver and this sequence of commands does not work: v4l2-ctl --set-ctrl=gain_automatic=1 v4l2-ctl --list-ctrls | grep gain_automatic # The following does not work v4l2-ctl --set-ctrl=gain_automatic=0 v4l2-ctl --list-ctrls | grep gain_automatic Changing the value using VIDIOC_S_EXT_CTRLS (like qv4l2 does) works fine. The apparent cause by looking at the changes in 5d0360a and comparing with the code path for VIDIOC_S_EXT_CTRLS seems to be that the code in v4l2-ctrls.c::set_ctrl() is not calling user_to_new() anymore after calling update_from_auto_cluster(master). However the root cause of the problem is that calling update_from_auto_cluster(master) overrides also the _master_ control state calling cur_to_new() while it was supposed to only update the volatile controls. Calling user_to_new() after update_from_auto_cluster(master) was just masking the original bug by restoring the correct new value of the master control before making the changes permanent. Fix the original bug by making update_from_auto_cluster() not override the new master control value. Signed-off-by: Antonio Ospite Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 8a1edcf51953ee3f279677e8ace99c9d8dcd4847 Author: Tiffany Lin Date: Thu Sep 24 06:02:36 2015 -0300 media: vb2 dma-sg: Fully cache synchronise buffers in prepare and finish commit 418dae2276065680bde7ae27d2c075e612a54de6 upstream. In videobuf2 dma-sg memory types the prepare and finish ops, instead of passing the number of entries in the original scatterlist as the "nents" parameter to dma_sync_sg_for_device() and dma_sync_sg_for_cpu(), the value returned by dma_map_sg() was used. Albeit this has been suggested in comments of some implementations (which have since been corrected), this is wrong. Fixes: d790b7eda953 ("vb2-dma-sg: move dma_(un)map_sg here") Signed-off-by: Tiffany Lin Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 0b87d9a8d622891fa2a4b33e6225126bf4502e3a Author: Tiffany Lin Date: Thu Sep 24 06:02:36 2015 -0300 media: vb2 dma-contig: Fully cache synchronise buffers in prepare and finish commit d9a985883fa32453d099d6293188c11d75cef1fa upstream. In videobuf2 dma-contig memory type the prepare and finish ops, instead of passing the number of entries in the original scatterlist as the "nents" parameter to dma_sync_sg_for_device() and dma_sync_sg_for_cpu(), the value returned by dma_map_sg() was used. Albeit this has been suggested in comments of some implementations (which have since been corrected), this is wrong. Fixes: 199d101efdba ("v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator") Signed-off-by: Tiffany Lin Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 62f11d578e77ad6d1b2cb46a1f07a25cef72d900 Author: Benoit Parrot Date: Mon Sep 21 13:03:21 2015 -0300 media: v4l2-ctrls: Fix 64bit support in get_ctrl() commit a8077734055f870ba630563868a6349671ca8dfc upstream. When trying to use v4l2_ctrl_g_ctrl_int64() to retrieve a V4L2_CTRL_TYPE_INTEGER64 type value the internal helper function get_ctrl() would prematurely exit because for this control type the 'is_int' flag is not set. This would result in v4l2_ctrl_g_ctrl_int64 always returning 0. Also v4l2_ctrl_g_ctrl_int64() is reading and returning the 32bit value member instead of the 64bit version, so fixing that as well. This patch extends the condition check to allow the V4L2_CTRL_TYPE_INTEGER64 type to continue processing instead of exiting. Signed-off-by: Benoit Parrot Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2952e7fe817d93c8a5b98441ecb119d48d1ed1eb Author: Hans Verkuil Date: Mon Sep 21 06:14:16 2015 -0300 v4l2-ctrls: arrays are also considered compound controls commit 35204e2e84f2dae72012f8ca319659c12f428430 upstream. Array controls weren't skipped when only V4L2_CTRL_FLAG_NEXT_CTRL was provided (so no V4L2_CTRL_FLAG_NEXT_COMPOUND was set). This is wrong since arrays are also considered compound controls (i.e. with more than one value), and applications that do not know about arrays will not be able to handle such controls. Fix the test to include arrays. Signed-off-by: Hans Verkuil Reported-by: Ricardo Ribalda Delgado Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2e1697733f0799a001be519ed73fdccdd6191408 Author: Takashi Iwai Date: Mon Oct 19 04:17:30 2015 -0200 c8sectpfe: Remove select on CONFIG_FW_LOADER_USER_HELPER_FALLBACK commit 79f5b6ae960d380c829fb67d5dadcd1d025d2775 upstream. c8sectpfe driver selects CONFIG_FW_LOADER_USER_HELPER_FALLBACK by some reason, but this option is known to be harmful, leading to minutes of stalls at boot time. The option was intended for only compatibility for an old exotic system that mandates the udev interaction, and not a thing a driver selects by itself. Let's remove it. Fixes: 850a3f7d5911 ('[media] c8sectpfe: Add Kconfig and Makefile for the driver') Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ebe4d269ffba12422ffff380c0a36877da0fc55f Author: Andrzej Hajda Date: Mon Aug 31 08:56:15 2015 -0300 v4l2-compat-ioctl32: fix alignment for ARM64 commit 655e9780ab913a3a06d4a164d55e3b755524186d upstream. Alignment/padding rules on AMD64 and ARM64 differs. To allow properly match compatible ioctls on ARM64 kernels without breaking AMD64 some fields should be aligned using compat_s64 type and in one case struct should be unpacked. Signed-off-by: Andrzej Hajda [hans.verkuil@cisco.com: use compat_u64 instead of compat_s64 in v4l2_input32] Signed-off-by: Hans Verkuil Signed-off-by: Greg Kroah-Hartman Signed-off-by: Mauro Carvalho Chehab commit 3bfcf7dc51cfcdb3c421a780492190396728edd0 Author: Ezequiel Garcia Date: Mon Sep 28 18:36:51 2015 -0300 vivid: Fix iteration in driver removal path commit a5d42b8c3b3ddccd88dc1c70957177d31a6699fb upstream. When the diver is removed and all the resources are deallocated, we should be iterating through the created devices only. Currently, the iteration ends when vivid_devs[i] is NULL. Since the array contains VIVID_MAX_DEVS elements, it will oops if n_devs=VIVID_MAX_DEVS because in that case, no element is NULL. Fixes: c88a96b023d8 ('[media] vivid: add core driver code') Signed-off-by: Ezequiel Garcia Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e266f6c3b75c6b1695483685ab16f2cdb54e47ec Author: Wolfram Sang Date: Wed Dec 16 20:05:18 2015 +0100 i2c: rcar: disable runtime PM correctly in slave mode commit b4cd08aa1f53c831e67dc5c6bc9f9acff27abcba upstream. When we also are I2C slave, we need to disable runtime PM because the address detection mechanism needs to be active all the time. However, we can reenable runtime PM once the slave instance was unregistered. So, use pm_runtime_get_sync/put to achieve this, since it has proper refcounting. pm_runtime_allow/forbid is like a global knob controllable from userspace which is unsuitable here. Signed-off-by: Wolfram Sang Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 42947fa48a86aca9e52a4003af69e6bb753dc7ea Author: Wolfram Sang Date: Wed Nov 25 16:58:18 2015 +0100 i2c: rk3x: populate correct variable for sda_falling_time commit 9abd29e7c13de24ce73213a425d9574b35ac0c6a upstream. Signed-off-by: Wolfram Sang Reviewed-by: Douglas Anderson Signed-off-by: Greg Kroah-Hartman commit 226706fd3918ea3e42c31de2476df3e1155b9296 Author: Hans de Goede Date: Sun Sep 27 16:57:08 2015 +0200 i2c: mv64xxx: The n clockdiv factor is 0 based on sunxi SoCs commit bba61f50f76574ca5b84b310925be7c2e8e64275 upstream. According to the datasheets the n factor for dividing the tclk is 2 to the power n on Allwinner SoCs, not 2 to the power n + 1 as it is on other mv64xxx implementations. I've contacted Allwinner about this and they have confirmed that the datasheet is correct. This commit fixes the clk-divider calculations for Allwinner SoCs accordingly. Signed-off-by: Hans de Goede Acked-by: Maxime Ripard Tested-by: Olliver Schinagl Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit ec6f137eef9c52bdb86924df96ff0f2ba4524ee2 Author: Javier Martinez Canillas Date: Wed Jan 27 12:03:23 2016 -0200 media: i2c: Don't export ir-kbd-i2c module alias commit 329d88da4df9a96da43018aceabd3a06e6a7e7ae upstream. This is a partial revert of commit ed8d1cf07cb16d ("[media] Export I2C module alias information in missing drivers") that exported the module aliases for the I2C drivers that were missing to make autoload to work. But there is a bug report [0] that auto load of the ir-kbd-i2c driver cause the Hauppauge HD-PVR driver to not behave correctly. This is a hdpvr latent bug that was just exposed by ir-kbd-i2c module autoloading working and will also happen if the I2C driver is built-in or a user calls modprobe to load the module and register the driver. But there is a regression experimented by users so until the real bug is fixed, let's not export the module alias for the ir-kbd-i2c driver even when this just masks the actual issue. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810726 Fixes: ed8d1cf07cb1 ("[media] Export I2C module alias information in missing drivers") Signed-off-by: Javier Martinez Canillas Signed-off-by: Greg Kroah-Hartman commit 37afe551d4f1b234176ff5d38edb12cfef678fe5 Author: Grygorii Strashko Date: Thu Nov 12 15:42:26 2015 +0200 i2c: fix wakeup irq parsing commit c18fba23061f16dde128e10d4869ba4e88e0e81a upstream. This patch fixes obvious copy-past error in wake up irq parsing code which leads to the fact that dev_pm_set_wake_irq() will be called with wrong IRQ number when "wakeup" IRQ is not defined in DT. Fixes: 3fffd1283927 ("i2c: allow specifying separate wakeup interrupt in device tree") Signed-off-by: Grygorii Strashko Acked-by: Dmitry Torokhov Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 6868ec4d4d0a54e0627dd562cb357e23c69edd43 Author: Ludovic Desroches Date: Mon Oct 26 10:38:27 2015 +0100 i2c: at91: manage unexpected RXRDY flag when starting a transfer commit a9bed6b10bd117a300cceb9062003f7a2761ef99 upstream. In some cases, we could start a new i2c transfer with the RXRDY flag set. It is not a clean state and it leads to print annoying error messages even if there no real issue. The cause is only having garbage data in the Receive Holding Register because of a weird behavior of the RXRDY flag. Reported-by: Peter Rosin Signed-off-by: Ludovic Desroches Tested-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 93563a6a71bb ("i2c: at91: fix a race condition when using the DMA controller") Signed-off-by: Greg Kroah-Hartman commit 806bac9faf482eb27e9d9f936480a6ff5ab309f2 Author: Cyrille Pitchen Date: Wed Oct 21 15:44:03 2015 +0200 i2c: at91: fix write transfers by clearing pending interrupt first commit 6f6ddbb09d2a5baded0e23add3ad2d9e9417ab30 upstream. In some cases a NACK interrupt may be pending in the Status Register (SR) as a result of a previous transfer. However at91_do_twi_transfer() did not read the SR to clear pending interruptions before starting a new transfer. Hence a NACK interrupt rose as soon as it was enabled again at the I2C controller level, resulting in a wrong sequence of operations and strange patterns of behaviour on the I2C bus, such as a clock stretch followed by a restart of the transfer. This first issue occurred with both DMA and PIO write transfers. Also when a NACK error was detected during a PIO write transfer, the interrupt handler used to wrongly start a new transfer by writing into the Transmit Holding Register (THR). Then the I2C slave was likely to reply with a second NACK. This second issue is fixed in atmel_twi_interrupt() by handling the TXRDY status bit only if both the TXCOMP and NACK status bits are cleared. Tested with a at24 eeprom on sama5d36ek board running a linux-4.1-at91 kernel image. Adapted to linux-next. Reported-by: Peter Rosin Signed-off-by: Cyrille Pitchen Signed-off-by: Ludovic Desroches Tested-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 93563a6a71bb ("i2c: at91: fix a race condition when using the DMA controller") Signed-off-by: Greg Kroah-Hartman commit 2424cd35d22011acd8a3080670fafa5f6010a62d Author: Max Filippov Date: Fri Oct 16 17:01:04 2015 +0300 xtensa: fix secondary core boot in SMP commit ab45fb145096799dabd18afc58bb5f97171017cd upstream. There are multiple factors adding to the issue in different configurations: - commit 17290231df16eeee ("xtensa: add fixup for double exception raised in window overflow") added function window_overflow_restore_a0_fixup to double exception vector overlapping reset vector location of secondary processor cores. - on MMUv2 cores RESET_VECTOR1_VADDR may point to uncached kernel memory making code overlapping depend on cache type and size, so that without cache or with WT cache reset vector code overwrites double exception code, making issue even harder to detect. - on MMUv3 cores RESET_VECTOR1_VADDR may point to unmapped area, as MMUv3 cores change virtual address map to match MMUv2 layout, but reset vector virtual address is given for the original MMUv3 mapping. - physical memory region of the secondary reset vector is not reserved in the physical memory map, and thus may be allocated and overwritten at arbitrary moment. Fix it as follows: - move window_overflow_restore_a0_fixup code to .text section. - define RESET_VECTOR1_VADDR so that it points to reset vector in the cacheable MMUv2 map for cores with MMU. - reserve reset vector region in the physical memory map. Drop separate literal section and build mxhead.S with text section literals. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 9b79a9787485edfa446e1538d9d38ade210539e3 Author: Max Filippov Date: Thu Sep 24 23:11:53 2015 +0300 xtensa: fixes for configs without loop option commit 5029615e25dc5040beb065f36743c127a8e51497 upstream. Build-time fixes: - make lbeg/lend/lcount save/restore conditional on kernel entry; - don't clear lcount in platform_restart functions unconditionally. Run-time fixes: - use correct end of range register in __endla paired with __loopt, not the unused temporary register. This fixes .bss zero-initialization. Update comments in asmmacro.h; - don't clobber a10 in the usercopy that leads to access to unmapped memory. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman commit 4012c255bb47a8cde8ad7ce4fff305066985748f Author: Helge Deller Date: Sun Jan 10 09:30:42 2016 +0100 parisc: Fix __ARCH_SI_PREAMBLE_SIZE commit e60fc5aa608eb38b47ba4ee058f306f739eb70a0 upstream. On a 64bit kernel build the compiler aligns the _sifields union in the struct siginfo_t on a 64bit address. The __ARCH_SI_PREAMBLE_SIZE define compensates for this alignment and thus fixes the wait testcase of the strace package. The symptoms of a wrong __ARCH_SI_PREAMBLE_SIZE value is that _sigchld.si_stime variable is missed to be copied and thus after a copy_siginfo() will have uninitialized values. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 1e1cca34d21839d5ddbbc9f4082e1d540fbf11cd Author: Helge Deller Date: Mon Dec 21 10:03:30 2015 +0100 parisc: Fix syscall restarts commit 71a71fb5374a23be36a91981b5614590b9e722c3 upstream. On parisc syscalls which are interrupted by signals sometimes failed to restart and instead returned -ENOSYS which in the worst case lead to userspace crashes. A similiar problem existed on MIPS and was fixed by commit e967ef02 ("MIPS: Fix restart of indirect syscalls"). On parisc the current syscall restart code assumes that all syscall callers load the syscall number in the delay slot of the ble instruction. That's how it is e.g. done in the unistd.h header file: ble 0x100(%sr2, %r0) ldi #syscall_nr, %r20 Because of that assumption the current code never restored %r20 before returning to userspace. This assumption is at least not true for code which uses the glibc syscall() function, which instead uses this syntax: ble 0x100(%sr2, %r0) copy regX, %r20 where regX depend on how the compiler optimizes the code and register usage. This patch fixes this problem by adding code to analyze how the syscall number is loaded in the delay branch and - if needed - copy the syscall number to regX prior returning to userspace for the syscall restart. Signed-off-by: Helge Deller Cc: Mathieu Desnoyers Signed-off-by: Greg Kroah-Hartman commit 1bff2427a0cb01700a911bde1dbfdf43879077e0 Author: Helge Deller Date: Sun Nov 22 12:14:14 2015 +0100 parisc: Drop unused MADV_xxxK_PAGES flags from asm/mman.h commit dcbf0d299c00ed4f82ea8d6e359ad88a5182f9b8 upstream. Drop the MADV_xxK_PAGES flags, which were never used and were from a proposed API which was never integrated into the generic Linux kernel code. Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit de90adfa1a88b065cfddcb02d4333b219ac31f04 Author: Helge Deller Date: Fri Nov 6 23:36:01 2015 +0100 parisc: Fixes and cleanups in kernel uapi header files commit d0cf62fb63f760e98244d31396b3b58f3a1e326b upstream. This patch fixes some bugs and partly cleans up the parisc uapi header files to what glibc defined: - compat_semid64_ds was wrong and did not take the endianess into account - ipc64_perm exported userspace types which broke building userspace packages on debian (e.g. trinity) - ipc64_perm needs to use a 32bit mode_t on 64bit kernel - msqid64_ds and semid64_ds needs unsigned longs for various struct members - shmid64_ds exported size_t instead of __kernel_size_t And finally add some compile-time checks for the sizes of those structs to avoid future breakage. Runtime-tested with the Linux Test Project (LTP) testsuite. Reviewed-by: Arnd Bergmann Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 2e35c886dd88c9754c92171f13d581075c166310 Author: Mathias Krause Date: Fri Nov 6 16:30:38 2015 -0800 printk: prevent userland from spoofing kernel messages commit 3824657c522f19f85a76bd932821174a5557a382 upstream. The following statement of ABI/testing/dev-kmsg is not quite right: It is not possible to inject messages from userspace with the facility number LOG_KERN (0), to make sure that the origin of the messages can always be reliably determined. Userland actually can inject messages with a facility of 0 by abusing the fact that the facility is stored in a u8 data type. By using a facility which is a multiple of 256 the assignment of msg->facility in log_store() implicitly truncates it to 0, i.e. LOG_KERN, allowing users of /dev/kmsg to spoof kernel messages as shown below: The following call... # printf '<%d>Kernel panic - not syncing: beer empty\n' 0 >/dev/kmsg ...leads to the following log entry (dmesg -x | tail -n 1): user :emerg : [ 66.137758] Kernel panic - not syncing: beer empty However, this call... # printf '<%d>Kernel panic - not syncing: beer empty\n' 0x800 >/dev/kmsg ...leads to the slightly different log entry (note the kernel facility): kern :emerg : [ 74.177343] Kernel panic - not syncing: beer empty Fix that by limiting the user provided facility to 8 bit right from the beginning and catch the truncation early. Fixes: 7ff9554bb578 ("printk: convert byte-buffer to variable-length...") Signed-off-by: Mathias Krause Cc: Greg Kroah-Hartman Cc: Petr Mladek Cc: Alex Elder Cc: Joe Perches Cc: Kay Sievers Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e78789fc2180362a679203a9de5e36af6fa758c5 Author: Andy Leiserson Date: Sun Oct 18 00:36:29 2015 -0400 fix calculation of meta_bg descriptor backups commit 904dad4742d211b7a8910e92695c0fa957483836 upstream. "group" is the group where the backup will be placed, and is initialized to zero in the declaration. This meant that backups for meta_bg descriptors were erroneously written to the backup block group descriptors in groups 1 and (desc_per_block-1). Reproduction information: mke2fs -Fq -t ext4 -b 1024 -O ^resize_inode /tmp/foo.img 16G truncate -s 24G /tmp/foo.img losetup /dev/loop0 /tmp/foo.img mount /dev/loop0 /mnt resize2fs /dev/loop0 umount /dev/loop0 dd if=/dev/zero of=/dev/loop0 bs=1024 count=2 e2fsck -fy /dev/loop0 losetup -d /dev/loop0 Signed-off-by: Andy Leiserson Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit b06d20496d98908746f3127a0131626693cd6377 Author: Junxiao Bi Date: Fri Dec 4 12:29:28 2015 -0500 jbd2: fix null committed data return in undo_access commit 087ffd4eae9929afd06f6a709861df3c3508492a upstream. introduced jbd2_write_access_granted() to improve write|undo_access speed, but missed to check the status of b_committed_data which caused a kernel panic on ocfs2. [ 6538.405938] ------------[ cut here ]------------ [ 6538.406686] kernel BUG at fs/ocfs2/suballoc.c:2400! [ 6538.406686] invalid opcode: 0000 [#1] SMP [ 6538.406686] Modules linked in: ocfs2 nfsd lockd grace nfs_acl auth_rpcgss sunrpc autofs4 ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sd_mod sg ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ppdev xen_kbdfront xen_netfront xen_fbfront parport_pc parport pcspkr i2c_piix4 acpi_cpufreq ext4 jbd2 mbcache xen_blkfront floppy pata_acpi ata_generic ata_piix cirrus ttm drm_kms_helper drm fb_sys_fops sysimgblt sysfillrect i2c_core syscopyarea dm_mirror dm_region_hash dm_log dm_mod [ 6538.406686] CPU: 1 PID: 16265 Comm: mmap_truncate Not tainted 4.3.0 #1 [ 6538.406686] Hardware name: Xen HVM domU, BIOS 4.3.1OVM 05/14/2014 [ 6538.406686] task: ffff88007c2bab00 ti: ffff880075b78000 task.ti: ffff880075b78000 [ 6538.406686] RIP: 0010:[] [] ocfs2_block_group_clear_bits+0x23b/0x250 [ocfs2] [ 6538.406686] RSP: 0018:ffff880075b7b7f8 EFLAGS: 00010246 [ 6538.406686] RAX: ffff8800760c5b40 RBX: ffff88006c06a000 RCX: ffffffffa06e6df0 [ 6538.406686] RDX: 0000000000000000 RSI: ffff88007a6f6ea0 RDI: ffff88007a760430 [ 6538.406686] RBP: ffff880075b7b878 R08: 0000000000000002 R09: 0000000000000001 [ 6538.406686] R10: ffffffffa06769be R11: 0000000000000000 R12: 0000000000000001 [ 6538.406686] R13: ffffffffa06a1750 R14: 0000000000000001 R15: ffff88007a6f6ea0 [ 6538.406686] FS: 00007f17fde30720(0000) GS:ffff88007f040000(0000) knlGS:0000000000000000 [ 6538.406686] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6538.406686] CR2: 0000000000601730 CR3: 000000007aea0000 CR4: 00000000000406e0 [ 6538.406686] Stack: [ 6538.406686] ffff88007c2bb5b0 ffff880075b7b8e0 ffff88007a7604b0 ffff88006c640800 [ 6538.406686] ffff88007a7604b0 ffff880075d77390 0000000075b7b878 ffffffffa06a309d [ 6538.406686] ffff880075d752d8 ffff880075b7b990 ffff880075b7b898 0000000000000000 [ 6538.406686] Call Trace: [ 6538.406686] [] ? ocfs2_read_group_descriptor+0x6d/0xa0 [ocfs2] [ 6538.406686] [] _ocfs2_free_suballoc_bits+0xe4/0x320 [ocfs2] [ 6538.406686] [] ? ocfs2_put_slot+0xf0/0xf0 [ocfs2] [ 6538.406686] [] _ocfs2_free_clusters+0xee/0x210 [ocfs2] [ 6538.406686] [] ? ocfs2_put_slot+0xf0/0xf0 [ocfs2] [ 6538.406686] [] ? ocfs2_put_slot+0xf0/0xf0 [ocfs2] [ 6538.406686] [] ? ocfs2_extend_trans+0x50/0x1a0 [ocfs2] [ 6538.406686] [] ocfs2_free_clusters+0x15/0x20 [ocfs2] [ 6538.406686] [] ocfs2_replay_truncate_records+0xfc/0x290 [ocfs2] [ 6538.406686] [] ? ocfs2_start_trans+0xec/0x1d0 [ocfs2] [ 6538.406686] [] __ocfs2_flush_truncate_log+0x140/0x2d0 [ocfs2] [ 6538.406686] [] ? ocfs2_reserve_blocks_for_rec_trunc.clone.0+0x44/0x170 [ocfs2] [ 6538.406686] [] ocfs2_remove_btree_range+0x374/0x630 [ocfs2] [ 6538.406686] [] ? jbd2_journal_stop+0x25b/0x470 [jbd2] [ 6538.406686] [] ocfs2_commit_truncate+0x305/0x670 [ocfs2] [ 6538.406686] [] ? ocfs2_journal_access_eb+0x20/0x20 [ocfs2] [ 6538.406686] [] ocfs2_truncate_file+0x297/0x380 [ocfs2] [ 6538.406686] [] ? jbd2_journal_begin_ordered_truncate+0x64/0xc0 [jbd2] [ 6538.406686] [] ocfs2_setattr+0x572/0x860 [ocfs2] [ 6538.406686] [] ? current_fs_time+0x3f/0x50 [ 6538.406686] [] notify_change+0x1d7/0x340 [ 6538.406686] [] ? generic_getxattr+0x79/0x80 [ 6538.406686] [] do_truncate+0x66/0x90 [ 6538.406686] [] ? __audit_syscall_entry+0xb0/0x110 [ 6538.406686] [] do_sys_ftruncate.clone.0+0xf3/0x120 [ 6538.406686] [] SyS_ftruncate+0xe/0x10 [ 6538.406686] [] entry_SYSCALL_64_fastpath+0x12/0x71 [ 6538.406686] Code: 28 48 81 ee b0 04 00 00 48 8b 92 50 fb ff ff 48 8b 80 b0 03 00 00 48 39 90 88 00 00 00 0f 84 30 fe ff ff 0f 0b eb fe 0f 0b eb fe <0f> 0b 0f 1f 00 eb fb 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 [ 6538.406686] RIP [] ocfs2_block_group_clear_bits+0x23b/0x250 [ocfs2] [ 6538.406686] RSP [ 6538.691128] ---[ end trace 31cd7011d6770d7e ]--- [ 6538.694492] Kernel panic - not syncing: Fatal exception [ 6538.695484] Kernel Offset: disabled Fixes: de92c8caf16c("jbd2: speedup jbd2_journal_get_[write|undo]_access()") Signed-off-by: Junxiao Bi Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d5ad20c5a9a98f8f875a8adc2703f8f04df9d19a Author: Jan Kara Date: Tue Nov 24 15:34:35 2015 -0500 jbd2: Fix unreclaimed pages after truncate in data=journal mode commit bc23f0c8d7ccd8d924c4e70ce311288cb3e61ea8 upstream. Ted and Namjae have reported that truncated pages don't get timely reclaimed after being truncated in data=journal mode. The following test triggers the issue easily: for (i = 0; i < 1000; i++) { pwrite(fd, buf, 1024*1024, 0); fsync(fd); fsync(fd); ftruncate(fd, 0); } The reason is that journal_unmap_buffer() finds that truncated buffers are not journalled (jh->b_transaction == NULL), they are part of checkpoint list of a transaction (jh->b_cp_transaction != NULL) and have been already written out (!buffer_dirty(bh)). We clean such buffers but we leave them in the checkpoint list. Since checkpoint transaction holds a reference to the journal head, these buffers cannot be released until the checkpoint transaction is cleaned up. And at that point we don't call release_buffer_page() anymore so pages detached from mapping are lingering in the system waiting for reclaim to find them and free them. Fix the problem by removing buffers from transaction checkpoint lists when journal_unmap_buffer() finds out they don't have to be there anymore. Reported-and-tested-by: Namjae Jeon Fixes: de1b794130b130e77ffa975bb58cb843744f9ae5 Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 95a2d5fb5516a6046962f0457f776e033959da40 Author: Jan Kara Date: Sat Oct 17 22:35:09 2015 -0400 jbd2: fix checkpoint list cleanup commit 33d14975e5ac469963d5d63856b61698ad0bff07 upstream. Unlike comments and expectation of callers journal_clean_one_cp_list() returned 1 not only if it freed the transaction but also if it freed some buffers in the transaction. That could make __jbd2_journal_clean_checkpoint_list() skip processing t_checkpoint_io_list and continue with processing the next transaction. This is mostly a cosmetic issue since the only result is we can sometimes free less memory than we could. But it's still worth fixing. Fix journal_clean_one_cp_list() to return 1 only if the transaction was really freed. Fixes: 50849db32a9f529235a84bcc84a6b8e631b1d0ec Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d8cbd6874edaeef44611425b4f3e8aebc4d7bb6a Author: Daniel Borkmann Date: Wed Nov 4 23:33:17 2015 +0100 tracefs: Fix refcount imbalance in start_creating() commit d227c3ae4e94e5eb11dd780a811f59e1a7b74ccd upstream. In tracefs' start_creating(), we pin the file system to safely access its root. When we failed to create a file, we unpin the file system via failed_creating() to release the mount count and eventually the reference of the singleton vfsmount. However, when we run into an error during lookup_one_len() when still in start_creating(), we only release the parent's mutex but not so the reference on the mount. F.e., in securityfs_create_file(), after doing simple_pin_fs() when lookup_one_len() fails there, we infact do simple_release_fs(). This seems necessary here as well. Same issue seen in debugfs due to 190afd81e4a5 ("debugfs: split the beginning and the end of __create_file() off"), which seemed to got carried over into tracefs, too. Noticed during code review. Link: http://lkml.kernel.org/r/68efa86101b778cf7517ed7c6ad573bd69f60ec6.1446672850.git.daniel@iogearbox.net Fixes: 4282d60689d4 ("tracefs: Add new tracefs file system") Signed-off-by: Daniel Borkmann Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 18a08dd9aed5c5e20e4ce722c52ca602859258db Author: Qiu Peiyang Date: Thu Dec 31 13:11:28 2015 +0800 tracing: Fix setting of start_index in find_next() commit f36d1be2930ede0a1947686e1126ffda5d5ee1bb upstream. When we do cat /sys/kernel/debug/tracing/printk_formats, we hit kernel panic at t_show. general protection fault: 0000 [#1] PREEMPT SMP CPU: 0 PID: 2957 Comm: sh Tainted: G W O 3.14.55-x86_64-01062-gd4acdc7 #2 RIP: 0010:[] [] t_show+0x22/0xe0 RSP: 0000:ffff88002b4ebe80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 RDX: 0000000000000004 RSI: ffffffff81fd26a6 RDI: ffff880032f9f7b1 RBP: ffff88002b4ebe98 R08: 0000000000001000 R09: 000000000000ffec R10: 0000000000000000 R11: 000000000000000f R12: ffff880004d9b6c0 R13: 7365725f6d706400 R14: ffff880004d9b6c0 R15: ffffffff82020570 FS: 0000000000000000(0000) GS:ffff88003aa00000(0063) knlGS:00000000f776bc40 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 00000000f6c02ff0 CR3: 000000002c2b3000 CR4: 00000000001007f0 Call Trace: [] seq_read+0x2f6/0x3e0 [] vfs_read+0x9b/0x160 [] SyS_read+0x49/0xb0 [] ia32_do_call+0x13/0x13 ---[ end trace 5bd9eb630614861e ]--- Kernel panic - not syncing: Fatal exception When the first time find_next calls find_next_mod_format, it should iterate the trace_bprintk_fmt_list to find the first print format of the module. However in current code, start_index is smaller than *pos at first, and code will not iterate the list. Latter container_of will get the wrong address with former v, which will cause mod_fmt be a meaningless object and so is the returned mod_fmt->fmt. This patch will fix it by correcting the start_index. After fixed, when the first time calls find_next_mod_format, start_index will be equal to *pos, and code will iterate the trace_bprintk_fmt_list to get the right module printk format, so is the returned mod_fmt->fmt. Link: http://lkml.kernel.org/r/5684B900.9000309@intel.com Fixes: 102c9323c35a8 "tracing: Add __tracepoint_string() to export string pointers" Signed-off-by: Qiu Peiyang Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit fcbeb18d7ae4aae88006890998efad7c6141dc15 Author: Jiaxing Wang Date: Sun Oct 18 19:58:08 2015 +0800 tracing: Update instance_rmdir() to use tracefs_remove_recursive commit 681a4a2f4529517422835b7395df07404dfe2278 upstream. Update instancd_rmdir to use tracefs_remove_recursive instead of debugfs_remove_recursive.This was left in the transition from debugfs to tracefs. Link: http://lkml.kernel.org/r/1445169490-18315-2-git-send-email-hello.wjx@gmail.com Fixes: 8434dc9340cd2 ("tracing: Convert the tracing facility over to use tracefs") Signed-off-by: Jiaxing Wang Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 9401eb353407312bd335d22cf842a98a4fe30252 Author: Christoph Biedl Date: Wed Dec 23 16:51:57 2015 +0100 PCI: Fix minimum allocation address overwrite commit 3460baa620685c20f5ee19afb6d99d26150c382c upstream. Commit 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address") claimed to do no functional changes but unfortunately did: The "min" variable is altered. At least the AVM A1 PCMCIA adapter was no longer detected, breaking ISDN operation. Use a local copy of "min" to restore the previous behaviour. [bhelgaas: avoid gcc "?:" extension for portability and readability] Fixes: 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address") Signed-off-by: Christoph Biedl Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit a03b65d97b4c673210fd81339508f6527febdebf Author: Grygorii Strashko Date: Thu Dec 10 21:18:20 2015 +0200 PCI: host: Mark PCIe/PCI (MSI) IRQ cascade handlers as IRQF_NO_THREAD commit 8ff0ef996ca00028519c70e8d51d32bd37eb51dc upstream. On -RT and if kernel is booting with "threadirqs" cmd line parameter, PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler()) will be forced threaded and, as result, will generate warnings like this: WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174() irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts Backtrace: (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40) (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174) (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8) (handle_irq_event) from (handle_simple_irq+0x90/0x118) (handle_simple_irq) from (generic_handle_irq+0x30/0x44) (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c) (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c) (irq_forced_thread_fn) from (irq_thread+0x128/0x204) This happens because all of them invoke generic_handle_irq() from the requested handler. generic_handle_irq() grabs raw_locks and thus needs to run in raw-IRQ context. This issue was originally reproduced on TI dra7-evem, but, as was identified during discussion [1], other hosts can also suffer from this issue. Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers IRQF_NO_THREAD explicitly. [1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com [bhelgaas: add stable tag, fix typos] Signed-off-by: Grygorii Strashko Signed-off-by: Bjorn Helgaas Acked-by: Lucas Stach CC: Kishon Vijay Abraham I CC: Jingoo Han CC: Kukjin Kim CC: Krzysztof Kozlowski CC: Richard Zhu CC: Thierry Reding CC: Stephen Warren CC: Alexandre Courbot CC: Simon Horman CC: Pratyush Anand CC: Michal Simek CC: "Sören Brinkmann" CC: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman commit c72faa97ec36baa5f61a8ccbf2c1dfe09466b0fd Author: Mathias Krause Date: Mon Nov 9 20:00:27 2015 +0100 PCI: Prevent out of bounds access in numa_node override commit 3dcc8d39cf15fa3ceabedcffcbd3958fe953555a upstream. Commit 1266963170f5 ("PCI: Prevent out of bounds access in numa_node override") missed that the user-provided node could also be negative. Handle this case as well to avoid out-of-bounds accesses to the node_states[] array. However, allow the special value -1, i.e. NUMA_NO_NODE, to be able to set the 'no specific node' configuration. Fixes: 1266963170f5 ("PCI: Prevent out of bounds access in numa_node override") Fixes: 63692df103e9 ("PCI: Allow numa_node override via sysfs") Signed-off-by: Mathias Krause Signed-off-by: Bjorn Helgaas CC: Sasha Levin CC: Prarit Bhargava Signed-off-by: Greg Kroah-Hartman commit 16a7fccaff5101c80f52b799728a0cbbd2892b12 Author: Alexander Duyck Date: Thu Oct 29 16:20:50 2015 -0500 PCI: Set SR-IOV NumVFs to zero after enumeration commit ea9a8854161d9580cfabe011c0ae296ecc0e1d4f upstream. The enumeration path should leave NumVFs set to zero. But after 4449f079722c ("PCI: Calculate maximum number of buses required for VFs"), we call virtfn_max_buses() in the enumeration path, which changes NumVFs. This NumVFs change is visible via lspci and sysfs until a driver enables SR-IOV. Iterate from TotalVFs down to zero so NumVFs is zero when we're finished computing the maximum number of buses. Validate offset and stride in the loop, so we can test it at every possible NumVFs setting. Rename virtfn_max_buses() to compute_max_vf_buses() to hint that it does have a side effect of updating iov->max_VF_buses. [bhelgaas: changelog, rename, allow numVF==1 && stride==0, rework loop, reverse sense of error path] Fixes: 4449f079722c ("PCI: Calculate maximum number of buses required for VFs") Based-on-patch-by: Ethan Zhao Signed-off-by: Alexander Duyck Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 1d9e01c3e770d03bd1be12f17c33d7e3e778c220 Author: Gabriele Paoloni Date: Thu Oct 8 14:27:38 2015 -0500 PCI: spear: Fix dw_pcie_cfg_read/write() usage commit fa3b7cbab548b15da438b0cc13aa515f7f291f4d upstream. The first argument of dw_pcie_cfg_read/write() is a 32-bit aligned address. The second argument is the byte offset into a 32-bit word, and dw_pcie_cfg_read/write() only look at the low two bits. SPEAr13xx used dw_pcie_cfg_read() and dw_pcie_cfg_write() incorrectly: it passed important address bits in the second argument, where they were ignored. Pass the complete 32-bit word address in the first argument and only the 2-bit offset into that word in the second argument. Without this fix, SPEAr13xx host will never work with few buggy gen1 card which connects with only gen1 host and also with any endpoint which would generate a read request of more than 128 bytes. [bhelgaas: changelog] Reported-by: Bjorn Helgaas Signed-off-by: Pratyush Anand Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 5b33b092fd14b468a976cd9c7a560cccd23fe4a5 Author: Sebastian Siewior Date: Thu Nov 26 21:23:49 2015 +0100 mtd: ubi: don't leak e if schedule_erase() fails commit 6b238de189f69dc77d660d4cce62eed15547f4c3 upstream. If __erase_worker() fails to erase the EB and schedule_erase() fails as well to do anything about it then we go RO. But that is not a reason to leak the e argument here. Therefore clean up e. Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit b08e24a592355bc3ed77d4cdb02abd976537b238 Author: Sebastian Siewior Date: Thu Nov 26 21:23:48 2015 +0100 mtd: ubi: fixup error correction in do_sync_erase() commit 1a31b20cd81d5cbc7ec6e24cb08066009a1ca32d upstream. Since fastmap we gained do_sync_erase(). This function can return an error and its error handling isn't obvious. First the memory allocation for struct ubi_work can fail and as such struct ubi_wl_entry is leaked. However if the memory allocation succeeds then the tail function takes care of the struct ubi_wl_entry. A free here could result in a double free. To make the error handling simpler, I split the tail function into one piece which does the work and another which frees the struct ubi_work which is passed as argument. As result do_sync_erase() can keep the struct on stack and we get rid of one error source. Fixes: 8199b901a ("UBI: Add fastmap support to the WL sub-system") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 754b58d96d229b3aa71b2140e8ffd145d5827268 Author: Brian Norris Date: Wed Nov 11 15:36:16 2015 -0800 mtd: jz4740_nand: fix build on jz4740 after removing gpio.h commit 96dd922c198286681fbbc15100e196e0f629e2fb upstream. Fallout from commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") We see errors like this: drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_detect_bank': drivers/mtd/nand/jz4740_nand.c:340:9: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:340:9: note: each undeclared identifier is reported only once for each function it appears in drivers/mtd/nand/jz4740_nand.c:359:2: error: implicit declaration of function 'jz_gpio_set_function' [-Werror=implicit-function-declaration] drivers/mtd/nand/jz4740_nand.c:359:29: error: 'JZ_GPIO_FUNC_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:399:29: error: 'JZ_GPIO_FUNC_NONE' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_probe': drivers/mtd/nand/jz4740_nand.c:528:13: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_remove': drivers/mtd/nand/jz4740_nand.c:555:14: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) Patched similarly to: https://patchwork.linux-mips.org/patch/11089/ Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit 7897886aab954c7e050aeb9e5173a010675dcca5 Author: Brian Norris Date: Mon Nov 9 16:37:28 2015 -0800 mtd: nand: fix shutdown/reboot for multi-chip systems commit 9ca641b0f02a3a1eedbc8c296e695326da9bbaf9 upstream. If multiple NAND chips are registered to the same controller, then when rebooting the system, the first one will grab the controller lock, while the second will wait forever for the first one to release it. i.e., a classic deadlock. This problem was solved for a similar case (suspend/resume) back in commit 6b0d9a841249 ("mtd: nand: fix multi-chip suspend problem"), and the shutdown state really isn't much different for us, so rather than adding a new special case to nand_get_device(), we can just overload the FL_PM_SUSPENDED state. Now, multiple chips can "get" the same controller lock (preventing further I/O), while we still allow other chips to pass through nand_shutdown(). Original report: http://thread.gmane.org/gmane.linux.drivers.mtd/59726 http://lists.infradead.org/pipermail/linux-mtd/2015-July/059992.html Fixes: 72ea403669c7 ("mtd: nand: added nand_shutdown") Reported-by: Andrew E. Mileski Signed-off-by: Brian Norris Cc: Scott Branden Cc: Andrew E. Mileski Acked-by: Scott Branden Reviewed-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit f4d9ae7a93c5d2ad23dd3b007507df177805b164 Author: Brian Norris Date: Mon Oct 26 10:20:23 2015 -0700 mtd: blkdevs: fix potential deadlock + lockdep warnings commit f3c63795e90f0c6238306883b6c72f14d5355721 upstream. Commit 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount") fixed a race condition but due to poor ordering of the mutex acquisition, introduced a potential deadlock. The deadlock can occur, for example, when rmmod'ing the m25p80 module, which will delete one or more MTDs, along with any corresponding mtdblock devices. This could potentially race with an acquisition of the block device as follows. -> blktrans_open() -> mutex_lock(&dev->lock); -> mutex_lock(&mtd_table_mutex); -> del_mtd_device() -> mutex_lock(&mtd_table_mutex); -> blktrans_notify_remove() -> del_mtd_blktrans_dev() -> mutex_lock(&dev->lock); This is a classic (potential) ABBA deadlock, which can be fixed by making the A->B ordering consistent everywhere. There was no real purpose to the ordering in the original patch, AFAIR, so this shouldn't be a problem. This ordering was actually already present in del_mtd_blktrans_dev(), for one, where the function tried to ensure that its caller already held mtd_table_mutex before it acquired &dev->lock: if (mutex_trylock(&mtd_table_mutex)) { mutex_unlock(&mtd_table_mutex); BUG(); } So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so we always acquire mtd_table_mutex first. Snippets of the lockdep output follow: # modprobe -r m25p80 [ 53.419251] [ 53.420838] ====================================================== [ 53.427300] [ INFO: possible circular locking dependency detected ] [ 53.433865] 4.3.0-rc6 #96 Not tainted [ 53.437686] ------------------------------------------------------- [ 53.444220] modprobe/372 is trying to acquire lock: [ 53.449320] (&new->lock){+.+...}, at: [] del_mtd_blktrans_dev+0x80/0xdc [ 53.457271] [ 53.457271] but task is already holding lock: [ 53.463372] (mtd_table_mutex){+.+.+.}, at: [] del_mtd_device+0x18/0x100 [ 53.471321] [ 53.471321] which lock already depends on the new lock. [ 53.471321] [ 53.479856] [ 53.479856] the existing dependency chain (in reverse order) is: [ 53.487660] -> #1 (mtd_table_mutex){+.+.+.}: [ 53.492331] [] blktrans_open+0x34/0x1a4 [ 53.497879] [] __blkdev_get+0xc4/0x3b0 [ 53.503364] [] blkdev_get+0x108/0x320 [ 53.508743] [] do_dentry_open+0x218/0x314 [ 53.514496] [] path_openat+0x4c0/0xf9c [ 53.519959] [] do_filp_open+0x5c/0xc0 [ 53.525336] [] do_sys_open+0xfc/0x1cc [ 53.530716] [] ret_fast_syscall+0x0/0x1c [ 53.536375] -> #0 (&new->lock){+.+...}: [ 53.540587] [] mutex_lock_nested+0x38/0x3cc [ 53.546504] [] del_mtd_blktrans_dev+0x80/0xdc [ 53.552606] [] blktrans_notify_remove+0x7c/0x84 [ 53.558891] [] del_mtd_device+0x74/0x100 [ 53.564544] [] del_mtd_partitions+0x80/0xc8 [ 53.570451] [] mtd_device_unregister+0x24/0x48 [ 53.576637] [] spi_drv_remove+0x1c/0x34 [ 53.582207] [] __device_release_driver+0x88/0x114 [ 53.588663] [] device_release_driver+0x20/0x2c [ 53.594843] [] bus_remove_device+0xd8/0x108 [ 53.600748] [] device_del+0x10c/0x210 [ 53.606127] [] device_unregister+0xc/0x20 [ 53.611849] [] __unregister+0x10/0x20 [ 53.617211] [] device_for_each_child+0x50/0x7c [ 53.623387] [] spi_unregister_master+0x58/0x8c [ 53.629578] [] release_nodes+0x15c/0x1c8 [ 53.635223] [] __device_release_driver+0x90/0x114 [ 53.641689] [] driver_detach+0xb4/0xb8 [ 53.647147] [] bus_remove_driver+0x4c/0xa0 [ 53.652970] [] SyS_delete_module+0x11c/0x1e4 [ 53.658976] [] ret_fast_syscall+0x0/0x1c [ 53.664621] [ 53.664621] other info that might help us debug this: [ 53.664621] [ 53.672979] Possible unsafe locking scenario: [ 53.672979] [ 53.679169] CPU0 CPU1 [ 53.683900] ---- ---- [ 53.688633] lock(mtd_table_mutex); [ 53.692383] lock(&new->lock); [ 53.698306] lock(mtd_table_mutex); [ 53.704658] lock(&new->lock); [ 53.707946] [ 53.707946] *** DEADLOCK *** Fixes: 073db4a51ee4 ("mtd: fix: avoid race condition when accessing mtd->usecount") Reported-by: Felipe Balbi Tested-by: Felipe Balbi Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit b5a93606fa8df9e993809bc956467ea70a1493dd Author: Boris BREZILLON Date: Thu Jul 30 12:18:03 2015 +0200 mtd: mtdpart: fix add_mtd_partitions error path commit e5bae86797141e4a95e42d825f737cb36d7b8c37 upstream. If we fail to allocate a partition structure in the middle of the partition creation process, the already allocated partitions are never removed, which means they are still present in the partition list and their resources are never freed. Signed-off-by: Boris Brezillon Signed-off-by: Brian Norris Signed-off-by: Greg Kroah-Hartman commit e1890d8f9373c4da8a30f7d44f72d283ebb499e0 Author: Dmitry Kasatkin Date: Thu Sep 10 22:06:15 2015 +0300 integrity: prevent loading untrusted certificates on the IMA trusted keyring commit 72e1eed8abb11c79749266d433c817ce36732893 upstream. If IMA_LOAD_X509 is enabled, either directly or indirectly via IMA_APPRAISE_SIGNED_INIT, certificates are loaded onto the IMA trusted keyring by the kernel via key_create_or_update(). When the KEY_ALLOC_TRUSTED flag is provided, certificates are loaded without first verifying the certificate is properly signed by a trusted key on the system keyring. This patch removes the KEY_ALLOC_TRUSTED flag. Signed-off-by: Dmitry Kasatkin Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 30b258e6782fa45e98a761a5b0301ab5b04ad0dd Author: Jarkko Sakkinen Date: Mon Nov 2 19:55:29 2015 +0200 TPM: revert the list handling logic fixed in 398a1e7 commit b1a4144a695ff4a6834a2680600f36f991fa4926 upstream. Mimi reported that afb5abc reverts the fix in 398a1e7. This patch reverts it back. Fixes: afb5abc262e9 ("tpm: two-phase chip management functions") Reported-by: Mimi Zohar Signed-off-by: Jarkko Sakkinen Acked-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 948670bcb1bb63cabbbf7fca762514bea78048de Author: Martin Wilck Date: Thu Nov 5 17:19:09 2015 +0100 tpm_tis: free irq after probing commit 2aef9da60bfdeb68dbcd4f114c098cbaa841b4ee upstream. Release IRQs used for probing only. Otherwise the TPM will end up with all IRQs 3-15 assigned. Fixes: afb5abc262e9 ("tpm: two-phase chip management functions") Signed-off-by: Martin Wilck Reviewed-by: Jarkko Sakkinen Tested-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Acked-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit d75b72ac3e475903bace726f1cd6d7692dafc977 Author: Hon Ching \(Vicky\) Lo Date: Wed Oct 7 20:11:51 2015 -0400 vTPM: fix memory allocation flag for rtce buffer at kernel boot commit 60ecd86c4d985750efa0ea3d8610972b09951715 upstream. At ibm vtpm initialzation, tpm_ibmvtpm_probe() registers its interrupt handler, ibmvtpm_interrupt, which calls ibmvtpm_crq_process to allocate memory for rtce buffer. The current code uses 'GFP_KERNEL' as the type of kernel memory allocation, which resulted a warning at kernel/lockdep.c. This patch uses 'GFP_ATOMIC' instead so that the allocation is high-priority and does not sleep. Signed-off-by: Hon Ching(Vicky) Lo Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit dfa9a12bc1fdb639ebf1cd31f057ddbccfc03a94 Author: Jarkko Sakkinen Date: Tue Sep 15 20:05:40 2015 +0300 tpm, tpm_crb: fix unaligned read of the command buffer address commit 149789ce9d472e6b4fd99336e779ab843754a96c upstream. The command buffer address must be read with exactly two 32-bit reads. Otherwise, on some HW platforms, it seems that HW will abort the read operation, which causes CPU to fill the read bytes with 1's. Therefore, we cannot rely on memcpy_fromio() but must call ioread32() two times instead. Also, this matches the PC Client Platform TPM Profile specification, which defines command buffer address with two 32-bit fields. Signed-off-by: Jarkko Sakkinen Reviewed-by: Peter Huewe Signed-off-by: Peter Huewe Signed-off-by: Greg Kroah-Hartman commit 0b30764fb9e0552e9bb5e00940142d442d041f9d Author: Ricardo Ribalda Delgado Date: Wed Oct 28 16:16:02 2015 +0100 spi/spi-xilinx: Fix race condition on last word read commit eca37c7c117460e2fbe4e32c991bff32a961f688 upstream. Some users have reported that in polled mode the driver fails randomly to read the last word of the transfer. The end condition used for the transmissions (in polled and irq mode) has been the TX_EMPTY flag. But Lars-Peter Clausen has identified a delay from the TX_EMPTY to the actual end of the data rx. I believe that this race condition has not been detected until now because of the latency added by the IRQ handler or the PCIe bridge. This bugs affects setups with low latency access to the spi core. This patch replaces the readout logic: For all the words, except the last one, the TX_EMPTY flag is used (and cached). If !TX_EMPY or is the last word. The status register is read and the RX_EMPTY flag is used. The performance is not affected: there is an extra read of the Status Register, but the readout can start as soon as there is a word in the buffer. Reported-by: Edward Kigwana Initial-fix-by: Lars-Peter Clausen Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ed15766eaf1857ba645cc9685cf094da4dfcfdd Author: Uri Mashiach Date: Thu Dec 24 16:05:00 2015 +0200 wlcore/wl12xx: spi: fix NULL pointer dereference (Oops) commit e47301b06d5a65678690f04c2248fd181db1e59a upstream. Fix the below Oops when trying to modprobe wlcore_spi. The oops occurs because the wl1271_power_{off,on}() function doesn't check the power() function pointer. [ 23.401447] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 23.409954] pgd = c0004000 [ 23.412922] [00000000] *pgd=00000000 [ 23.416693] Internal error: Oops: 80000007 [#1] SMP ARM [ 23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211 musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23 c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon [ 23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted 4.2.0-00002-g951efee-dirty #233 [ 23.461720] Hardware name: Generic AM33XX (Flattened Device Tree) [ 23.468123] Workqueue: events request_firmware_work_func [ 23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000 [ 23.479341] PC is at 0x0 [ 23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore] [ 23.488074] pc : [<00000000>] lr : [] psr: 60000013 [ 23.488074] sp : de4efe50 ip : 00000002 fp : 00000000 [ 23.500162] r10: de7cdd00 r9 : dc848800 r8 : bf27af00 [ 23.505663] r7 : bf27a1a8 r6 : dcbd8a80 r5 : dce0e2e0 r4 : dce0d2e0 [ 23.512536] r3 : 00000000 r2 : 00000000 r1 : 00000001 r0 : dc848810 [ 23.519412] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 23.527109] Control: 10c5387d Table: 9cb78019 DAC: 00000015 [ 23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218) [ 23.539760] Stack: (0xde4efe50 to 0xde4f0000) [...] [ 23.665030] [] (wl12xx_set_power_on [wlcore]) from [] (wlcore_nvs_cb+0x118/0xa4c [wlcore]) [ 23.675604] [] (wlcore_nvs_cb [wlcore]) from [] (request_firmware_work_func+0x30/0x58) [ 23.685784] [] (request_firmware_work_func) from [] (process_one_work+0x1b4/0x4b4) [ 23.695591] [] (process_one_work) from [] (worker_thread+0x3c/0x4a4) [ 23.704124] [] (worker_thread) from [] (kthread+0xd4/0xf0) [ 23.711747] [] (kthread) from [] (ret_from_fork+0x14/0x3c) [ 23.719357] Code: bad PC value [ 23.722760] ---[ end trace 981be8510db9b3a9 ]--- Prevent oops by validationg power() pointer value before calling the function. Signed-off-by: Uri Mashiach Acked-by: Igor Grinberg Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 8837f9bd1d61550d669d87b9adc26d0f03cc6d3d Author: Uri Mashiach Date: Thu Dec 10 15:12:56 2015 +0200 wlcore/wl12xx: spi: fix oops on firmware load commit 9b2761cb72dc41e1948c8a5512b4efd384eda130 upstream. The maximum chunks used by the function is (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE + 1). The original commands array had space for (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) commands. When the last chunk is used (len > 4 * WSPI_MAX_CHUNK_SIZE), the last command is stored outside the bounds of the commands array. Oops 5 (page fault) is generated during current wl1271 firmware load attempt: root@debian-armhf:~# ifconfig wlan0 up [ 294.312399] Unable to handle kernel paging request at virtual address 00203fc4 [ 294.320173] pgd = de528000 [ 294.323028] [00203fc4] *pgd=00000000 [ 294.326916] Internal error: Oops: 5 [#1] SMP ARM [ 294.331789] Modules linked in: bnep rfcomm bluetooth ipv6 arc4 wl12xx wlcore mac80211 musb_dsps cfg80211 musb_hdrc usbcore usb_common wlcore_spi omap_rng rng_core musb_am335x omap_wdt cpufreq_dt thermal_sys hwmon [ 294.351838] CPU: 0 PID: 1827 Comm: ifconfig Not tainted 4.2.0-00002-g3e9ad27-dirty #78 [ 294.360154] Hardware name: Generic AM33XX (Flattened Device Tree) [ 294.366557] task: dc9d6d40 ti: de550000 task.ti: de550000 [ 294.372236] PC is at __spi_validate+0xa8/0x2ac [ 294.376902] LR is at __spi_sync+0x78/0x210 [ 294.381200] pc : [] lr : [] psr: 60000013 [ 294.381200] sp : de551998 ip : de5519d8 fp : 00200000 [ 294.393242] r10: de551c8c r9 : de5519d8 r8 : de3a9000 [ 294.398730] r7 : de3a9258 r6 : de3a9400 r5 : de551a48 r4 : 00203fbc [ 294.405577] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : de3a9000 [ 294.412420] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 294.419918] Control: 10c5387d Table: 9e528019 DAC: 00000015 [ 294.425954] Process ifconfig (pid: 1827, stack limit = 0xde550218) [ 294.432437] Stack: (0xde551998 to 0xde552000) ... [ 294.883613] [] (__spi_validate) from [] (__spi_sync+0x78/0x210) [ 294.891670] [] (__spi_sync) from [] (wl12xx_spi_raw_write+0xfc/0x148 [wlcore_spi]) [ 294.901661] [] (wl12xx_spi_raw_write [wlcore_spi]) from [] (wlcore_boot_upload_firmware+0x1ec/0x458 [wlcore]) [ 294.914038] [] (wlcore_boot_upload_firmware [wlcore]) from [] (wl12xx_boot+0xc10/0xfac [wl12xx]) [ 294.925161] [] (wl12xx_boot [wl12xx]) from [] (wl1271_op_add_interface+0x5b0/0x910 [wlcore]) [ 294.936364] [] (wl1271_op_add_interface [wlcore]) from [] (ieee80211_do_open+0x44c/0xf7c [mac80211]) [ 294.947963] [] (ieee80211_do_open [mac80211]) from [] (__dev_open+0xa8/0x110) [ 294.957307] [] (__dev_open) from [] (__dev_change_flags+0x88/0x148) [ 294.965713] [] (__dev_change_flags) from [] (dev_change_flags+0x18/0x48) [ 294.974576] [] (dev_change_flags) from [] (devinet_ioctl+0x6b4/0x7d0) [ 294.983191] [] (devinet_ioctl) from [] (sock_ioctl+0x1e4/0x2bc) [ 294.991244] [] (sock_ioctl) from [] (do_vfs_ioctl+0x420/0x6b0) [ 294.999208] [] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c) [ 295.006880] [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x54) [ 295.014835] Code: e1550004 e2444034 0a00007d e5953018 (e5942008) [ 295.021544] ---[ end trace 66ed188198f4e24e ]--- Signed-off-by: Uri Mashiach Acked-by: Igor Grinberg Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit ed4c745d35785c4f5501a87f9d214ead4fcef203 Author: Johan Hovold Date: Mon Dec 14 16:16:19 2015 +0100 spi: fix parent-device reference leak commit 157f38f993919b648187ba341bfb05d0e91ad2f6 upstream. Fix parent-device reference leak due to SPI-core taking an unnecessary reference to the parent when allocating the master structure, a reference that was never released. Note that driver core takes its own reference to the parent when the master device is registered. Fixes: 49dce689ad4e ("spi doesn't need class_device") Signed-off-by: Johan Hovold Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6edfb956228a5cfbbb9e5dd9c4488cc93b3cfe91 Author: Vignesh R Date: Mon Oct 12 13:22:02 2015 +0530 spi: ti-qspi: Fix data corruption seen on r/w stress test commit bc27a53928981662079aa243915b443370294a03 upstream. Writing invalid command to QSPI_SPI_CMD_REG will terminate current transfer and de-assert the chip select. This has to be done before calling spi_finalize_current_message(). Because spi_finalize_current_message() will mark the end of current message transfer and schedule the next transfer. If the chipselect is not de-asserted before calling spi_finalize_current_message() then the next transfer will overlap with the previous transfer leading to data corruption. __spi_pump_message() can be called either from kthread worker context or directly from the calling process's context. It is possible that these two calls can race against each other. But race is serialized by checking whether master->cur_msg == NULL (pointer to msg being handled by transfer_one() at present). The master->cur_msg is set to NULL when spi_finalize_current_message() is called on that message, which means calling spi_finalize_current_message() allows __spi_sync() to pump next message in calling process context. Now if spi-ti-qspi calls spi_finalize_current_message() before we terminate transfer at hardware side, if __spi_pump_message() is called from process context then the successive transactions can overlap. Fix this by moving writing invalid command to QSPI_SPI_CMD_REG to before calling spi_finalize_current_message() call. Signed-off-by: Vignesh R Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit d487e49bbf976baa5fa5a2ad582f2c6d0d9bd9e7 Author: David Mosberger-Tang Date: Tue Oct 20 14:26:47 2015 +0200 spi: atmel: Fix DMA-setup for transfers with more than 8 bits per word commit 06515f83908d038d9e12ffa3dcca27a1b67f2de0 upstream. The DMA-slave configuration depends on the whether <= 8 or > 8 bits are transferred per word, so we need to call atmel_spi_dma_slave_config() with the correct value. Signed-off-by: David Mosberger Signed-off-by: Nicolas Ferre Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 865018e2b02e977a24b7069268cb8632787de5ca Author: Neil Armstrong Date: Fri Oct 9 15:47:41 2015 +0200 spi: omap2-mcspi: disable other channels CHCONF_FORCE in prepare_message commit 468a32082b04c7febccfcd55b06ecbc438fcddcc upstream. Since the "Switch driver to use transfer_one" change, the cs_change behavior has changed and a channel chip select can still be asserted when changing channel from a previous last transfer in a message having the cs_change attribute. Since there is no sense having multiple chip select being asserted at the same time, disable all the remaining forced chip selects in a the prepare_message called right before a spi_transfer_one_message call. It ignores the current channel configuration in order to keep the possibility to leave the chip select asserted between messages. It fixes this bug on a DM8168 SoC ES2.1 Soc and an OMAP4 ES2.1 SoC. It was hanging all the other channels transfers when a CHCONF_FORCE is present on the wrong channel. Fixes: b28cb9414db9 ("spi: omap2-mcspi: Switch driver to use transfer_one") Signed-off-by: Neil Armstrong Reviewed-by: Michael Welling Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 3662b6cf126c928f4fc7dbd0ad3e47161968d4a7 Author: Mauricio Faria de Oliveira Date: Thu Oct 29 10:24:23 2015 -0200 Revert "dm mpath: fix stalls when handling invalid ioctls" commit 47796938c46b943d157ac8a6f9ed4e3b98b83cf4 upstream. This reverts commit a1989b330093578ea5470bea0a00f940c444c466. That commit introduced a regression at least for the case of the SG_IO ioctl() running without CAP_SYS_RAWIO capability (e.g., unprivileged users) when there are no active paths: the ioctl() fails with the ENOTTY errno immediately rather than blocking due to queue_if_no_path until a path becomes active, for example. That case happens to be exercised by QEMU KVM guests with 'scsi-block' devices (qemu "-device scsi-block" [1], libvirt "" [2]) from multipath devices; which leads to SCSI/filesystem errors in such a guest. More general scenarios can hit that regression too. The following demonstration employs a SG_IO ioctl() with a standard SCSI INQUIRY command for this objective (some output & user changes omitted for brevity and comments added for clarity). Reverting that commit restores normal operation (queueing) in failing scenarios; tested on linux-next (next-20151022). 1) Test-case is based on sg_simple0 [3] (just SG_IO; remove SG_GET_VERSION_NUM) $ cat sg_simple0.c ... see [3] ... $ sed '/SG_GET_VERSION_NUM/,/}/d' sg_simple0.c > sgio_inquiry.c $ gcc sgio_inquiry.c -o sgio_inquiry 2) The ioctl() works fine with active paths present. # multipath -l 85ag56 85ag56 (...) dm-19 IBM ,2145 size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw |-+- policy='service-time 0' prio=0 status=active | |- 8:0:11:0 sdz 65:144 active undef running | `- 9:0:9:0 sdbf 67:144 active undef running `-+- policy='service-time 0' prio=0 status=enabled |- 8:0:12:0 sdae 65:224 active undef running `- 9:0:12:0 sdbo 68:32 active undef running $ ./sgio_inquiry /dev/mapper/85ag56 Some of the INQUIRY command's response: IBM 2145 0000 INQUIRY duration=0 millisecs, resid=0 3) The ioctl() fails with ENOTTY errno with _no_ active paths present, for unprivileged users (rather than blocking due to queue_if_no_path). # for path in $(multipath -l 85ag56 | grep -o 'sd[a-z]\+'); \ do multipathd -k"fail path $path"; done # multipath -l 85ag56 85ag56 (...) dm-19 IBM ,2145 size=60G features='1 queue_if_no_path' hwhandler='0' wp=rw |-+- policy='service-time 0' prio=0 status=enabled | |- 8:0:11:0 sdz 65:144 failed undef running | `- 9:0:9:0 sdbf 67:144 failed undef running `-+- policy='service-time 0' prio=0 status=enabled |- 8:0:12:0 sdae 65:224 failed undef running `- 9:0:12:0 sdbo 68:32 failed undef running $ ./sgio_inquiry /dev/mapper/85ag56 sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device 4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285); it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl(). $ dmesg <...> [] device-mapper: multipath: Failing path 65:144. [] device-mapper: multipath: Failing path 67:144. [] device-mapper: multipath: Failing path 65:224. [] device-mapper: multipath: Failing path 68:32. [] sgio_inquiry: sending ioctl 2285 to a partition! 5) The ioctl() only works if the SYS_CAP_RAWIO capability is present (then queueing happens -- in this example, queue_if_no_path is set); this is due to a conditional check in scsi_verify_blk_ioctl(). # capsh --drop=cap_sys_rawio -- -c './sgio_inquiry /dev/mapper/85ag56' sg_simple0: Inquiry SG_IO ioctl error: Inappropriate ioctl for device # ./sgio_inquiry /dev/mapper/85ag56 & [1] 72830 # cat /proc/72830/stack [] 0xc00000171c0df700 [] __switch_to+0x204/0x350 [] msleep+0x5c/0x80 [] dm_blk_ioctl+0x70/0x170 [] blkdev_ioctl+0x2b0/0x9b0 [] block_ioctl+0x64/0xd0 [] do_vfs_ioctl+0x490/0x780 [] SyS_ioctl+0xd4/0xf0 [] system_call+0x38/0xd0 6) This is the function call chain exercised in this analysis: SYSCALL_DEFINE3(ioctl, <...>) @ fs/ioctl.c -> do_vfs_ioctl() -> vfs_ioctl() ... error = filp->f_op->unlocked_ioctl(filp, cmd, arg); ... -> dm_blk_ioctl() @ drivers/md/dm.c -> multipath_ioctl() @ drivers/md/dm-mpath.c ... (bdev = NULL, due to no active paths) ... if (!bdev || <...>) { int err = scsi_verify_blk_ioctl(NULL, cmd); if (err) r = err; } ... -> scsi_verify_blk_ioctl() @ block/scsi_ioctl.c ... if (bd && bd == bd->bd_contains) // not taken (bd = NULL) return 0; ... if (capable(CAP_SYS_RAWIO)) // not taken (unprivileged user) return 0; ... printk_ratelimited(KERN_WARNING "%s: sending ioctl %x to a partition!\n" <...>); return -ENOIOCTLCMD; <- ... return r ? : <...> <- ... if (error == -ENOIOCTLCMD) error = -ENOTTY; out: return error; ... Links: [1] http://git.qemu.org/?p=qemu.git;a=commit;h=336a6915bc7089fb20fea4ba99972ad9a97c5f52 [2] https://libvirt.org/formatdomain.html#elementsDisks (see 'disk' -> 'device') [3] http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html (Revision 1.2, 2002-05-03) Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit ac44b98e83b1c6b227e537c44540b91278abab53 Author: Mikulas Patocka Date: Tue Oct 27 19:06:55 2015 -0400 dm: initialize non-blk-mq queue data before queue is used commit ad5f498f610fa3fd8bd265139098bc1405cd2783 upstream. Commit bfebd1cdb497a57757c83f5fbf1a29931591e2a4 ("dm: add full blk-mq support to request-based DM") moves the initialization of the fields backing_dev_info.congested_fn, backing_dev_info.congested_data and queuedata from the function dm_init_md_queue (that is called when the device is created) to dm_init_old_md_queue (that is called after the device type is determined). There is no locking when accessing these variables, thus it is possible for other parts of the kernel to briefly see this data in a transient state (e.g. queue->backing_dev_info.congested_fn initialized and md->queue->backing_dev_info.congested_data uninitialized, resulting in passing an incorrect parameter to the function dm_any_congested). This queue data is left initialized for blk-mq devices even though they that don't use it. Fixes: bfebd1cdb497 ("dm: add full blk-mq support to request-based DM") Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 98216c7c4c771992789308dac9f5ef90eff9ed58 Author: Dmitry V. Levin Date: Fri Dec 11 13:41:06 2015 -0800 sh64: fix __NR_fgetxattr commit 2d33fa1059da4c8e816627a688d950b613ec0474 upstream. According to arch/sh/kernel/syscalls_64.S and common sense, __NR_fgetxattr has to be defined to 259, but it doesn't. Instead, it's defined to 269, which is of course used by another syscall, __NR_sched_setaffinity in this case. This bug was found by strace test suite. Signed-off-by: Dmitry V. Levin Acked-by: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c6a5eba52c0d015cf60b6f1dcd2493001db16487 Author: xuejiufei Date: Fri Feb 5 15:36:47 2016 -0800 ocfs2/dlm: clear refmap bit of recovery lock while doing local recovery cleanup commit c95a51807b730e4681e2ecbdfd669ca52601959e upstream. When recovery master down, dlm_do_local_recovery_cleanup() only remove the $RECOVERY lock owned by dead node, but do not clear the refmap bit. Which will make umount thread falling in dead loop migrating $RECOVERY to the dead node. Signed-off-by: xuejiufei Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 62e3e821ae66900cffff9368164e15653403ac3e Author: xuejiufei Date: Thu Jan 14 15:17:38 2016 -0800 ocfs2/dlm: ignore cleaning the migration mle that is inuse commit bef5502de074b6f6fa647b94b73155d675694420 upstream. We have found that migration source will trigger a BUG that the refcount of mle is already zero before put when the target is down during migration. The situation is as follows: dlm_migrate_lockres dlm_add_migration_mle dlm_mark_lockres_migrating dlm_get_mle_inuse <<<<<< Now the refcount of the mle is 2. dlm_send_one_lockres and wait for the target to become the new master. <<<<<< o2hb detect the target down and clean the migration mle. Now the refcount is 1. dlm_migrate_lockres woken, and put the mle twice when found the target goes down which trigger the BUG with the following message: "ERROR: bad mle: ". Signed-off-by: Jiufei Xue Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 959c944f4b5aaf54aca4ed087d80948fd0d864b7 Author: Joseph Qi Date: Tue Dec 29 14:54:06 2015 -0800 ocfs2: fix BUG when calculate new backup super commit 5c9ee4cbf2a945271f25b89b137f2c03bbc3be33 upstream. When resizing, it firstly extends the last gd. Once it should backup super in the gd, it calculates new backup super and update the corresponding value. But it currently doesn't consider the situation that the backup super is already done. And in this case, it still sets the bit in gd bitmap and then decrease from bg_free_bits_count, which leads to a corrupted gd and trigger the BUG in ocfs2_block_group_set_bits: BUG_ON(le16_to_cpu(bg->bg_free_bits_count) < num_bits); So check whether the backup super is done and then do the updates. Signed-off-by: Joseph Qi Reviewed-by: Jiufei Xue Reviewed-by: Yiwen Jiang Cc: Mark Fasheh Cc: Joel Becker Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit c553fd8087d4b0f5aaa1ddc6e88782e862fd623f Author: Junxiao Bi Date: Fri Dec 11 13:41:03 2015 -0800 ocfs2: fix SGID not inherited issue commit 854ee2e944b4daf795e32562a7d2f9e90ab5a6a8 upstream. Commit 8f1eb48758aa ("ocfs2: fix umask ignored issue") introduced an issue, SGID of sub dir was not inherited from its parents dir. It is because SGID is set into "inode->i_mode" in ocfs2_get_init_inode(), but is overwritten by "mode" which don't have SGID set later. Fixes: 8f1eb48758aa ("ocfs2: fix umask ignored issue") Signed-off-by: Junxiao Bi Cc: Mark Fasheh Cc: Joel Becker Acked-by: Srinivas Eeda Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 11445dc88901427d9b910d7e3cb6f1348317fb6b Author: Mike Kravetz Date: Fri Dec 11 13:40:52 2015 -0800 mm/hugetlb.c: fix resv map memory leak for placeholder entries commit dbe409e4f5e5075bd9ff7f8dd5c627abf3ee38c1 upstream. Dmitry Vyukov reported the following memory leak unreferenced object 0xffff88002eaafd88 (size 32): comm "a.out", pid 5063, jiffies 4295774645 (age 15.810s) hex dump (first 32 bytes): 28 e9 4e 63 00 88 ff ff 28 e9 4e 63 00 88 ff ff (.Nc....(.Nc.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: kmalloc include/linux/slab.h:458 region_chg+0x2d4/0x6b0 mm/hugetlb.c:398 __vma_reservation_common+0x2c3/0x390 mm/hugetlb.c:1791 vma_needs_reservation mm/hugetlb.c:1813 alloc_huge_page+0x19e/0xc70 mm/hugetlb.c:1845 hugetlb_no_page mm/hugetlb.c:3543 hugetlb_fault+0x7a1/0x1250 mm/hugetlb.c:3717 follow_hugetlb_page+0x339/0xc70 mm/hugetlb.c:3880 __get_user_pages+0x542/0xf30 mm/gup.c:497 populate_vma_page_range+0xde/0x110 mm/gup.c:919 __mm_populate+0x1c7/0x310 mm/gup.c:969 do_mlock+0x291/0x360 mm/mlock.c:637 SYSC_mlock2 mm/mlock.c:658 SyS_mlock2+0x4b/0x70 mm/mlock.c:648 Dmitry identified a potential memory leak in the routine region_chg, where a region descriptor is not free'ed on an error path. However, the root cause for the above memory leak resides in region_del. In this specific case, a "placeholder" entry is created in region_chg. The associated page allocation fails, and the placeholder entry is left in the reserve map. This is "by design" as the entry should be deleted when the map is released. The bug is in the region_del routine which is used to delete entries within a specific range (and when the map is released). region_del did not handle the case where a placeholder entry exactly matched the start of the range range to be deleted. In this case, the entry would not be deleted and leaked. The fix is to take these special placeholder entries into account in region_del. The region_chg error path leak is also fixed. Fixes: feba16e25a57 ("mm/hugetlb: add region_del() to delete a specific range of entries") Signed-off-by: Mike Kravetz Reported-by: Dmitry Vyukov Acked-by: Hillf Danton Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0440e1cea5768ebd2741eb5e5e2f7062b3d28d3b Author: Richard Weinberger Date: Fri Nov 20 15:57:21 2015 -0800 kernel/signal.c: unexport sigsuspend() commit 9d8a765211335cfdad464b90fb19f546af5706ae upstream. sigsuspend() is nowhere used except in signal.c itself, so we can mark it static do not pollute the global namespace. But this patch is more than a boring cleanup patch, it fixes a real issue on UserModeLinux. UML has a special console driver to display ttys using xterm, or other terminal emulators, on the host side. Vegard reported that sometimes UML is unable to spawn a xterm and he's facing the following warning: WARNING: CPU: 0 PID: 908 at include/linux/thread_info.h:128 sigsuspend+0xab/0xc0() It turned out that this warning makes absolutely no sense as the UML xterm code calls sigsuspend() on the host side, at least it tries. But as the kernel itself offers a sigsuspend() symbol the linker choose this one instead of the glibc wrapper. Interestingly this code used to work since ever but always blocked signals on the wrong side. Some recent kernel change made the WARN_ON() trigger and uncovered the bug. It is a wonderful example of how much works by chance on computers. :-) Fixes: 68f3f16d9ad0f1 ("new helper: sigsuspend()") Signed-off-by: Richard Weinberger Reported-by: Vegard Nossum Tested-by: Vegard Nossum Acked-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ceb9eea3aaf7c7ff95e6e201eaa9a00481473c95 Author: Naoya Horiguchi Date: Fri Dec 11 13:40:49 2015 -0800 mm: hugetlb: call huge_pte_alloc() only if ptep is null commit 0d777df5d8953293be090d9ab5a355db893e8357 upstream. Currently at the beginning of hugetlb_fault(), we call huge_pte_offset() and check whether the obtained *ptep is a migration/hwpoison entry or not. And if not, then we get to call huge_pte_alloc(). This is racy because the *ptep could turn into migration/hwpoison entry after the huge_pte_offset() check. This race results in BUG_ON in huge_pte_alloc(). We don't have to call huge_pte_alloc() when the huge_pte_offset() returns non-NULL, so let's fix this bug with moving the code into else block. Note that the *ptep could turn into a migration/hwpoison entry after this block, but that's not a problem because we have another !pte_present check later (we never go into hugetlb_no_page() in that case.) Fixes: 290408d4a250 ("hugetlb: hugepage migration core") Signed-off-by: Naoya Horiguchi Acked-by: Hillf Danton Acked-by: David Rientjes Cc: Hugh Dickins Cc: Dave Hansen Cc: Mel Gorman Cc: Joonsoo Kim Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f3fc333b58469ee6c4189e824fd7e15462b05cfc Author: OGAWA Hirofumi Date: Fri Nov 20 15:57:15 2015 -0800 fat: fix fake_offset handling on error path commit 928a477102c4fc6739883415b66987207e3502f4 upstream. For the root directory, . and .. are faked (using dir_emit_dots()) and ctx->pos is reset from 2 to 0. A corrupted root directory could cause fat_get_entry() to fail, but ->iterate() (fat_readdir()) reports progress to the VFS (with ctx->pos rewound to 0), so any following calls to ->iterate() continue to return the same entries again and again. The result is that userspace will never see the end of the directory, causing e.g. 'ls' to hang in a getdents() loop. [hirofumi@mail.parknet.co.jp: cleanup and make sure to correct fake_offset] Reported-by: Vegard Nossum Tested-by: Vegard Nossum Signed-off-by: Richard Weinberger Signed-off-by: OGAWA Hirofumi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 525893dd243c0f765d2476e6ce3c601da124ff23 Author: Mike Kravetz Date: Fri Nov 20 15:57:13 2015 -0800 mm/hugetlbfs: fix bugs in fallocate hole punch of areas with holes commit 1817889e3b2cc1db8abb595712095129ff9156c1 upstream. Hugh Dickins pointed out problems with the new hugetlbfs fallocate hole punch code. These problems are in the routine remove_inode_hugepages and mostly occur in the case where there are holes in the range of pages to be removed. These holes could be the result of a previous hole punch or simply sparse allocation. The current code could access pages outside the specified range. remove_inode_hugepages handles both hole punch and truncate operations. Page index handling was fixed/cleaned up so that the loop index always matches the page being processed. The code now only makes a single pass through the range of pages as it was determined page faults could not race with truncate. A cond_resched() was added after removing up to PAGEVEC_SIZE pages. Some totally unnecessary code in hugetlbfs_fallocate() that remained from early development was also removed. Tested with fallocate tests submitted here: http://librelist.com/browser//libhugetlbfs/2015/6/25/patch-tests-add-tests-for-fallocate-system-call/ And, some ftruncate tests under development Fixes: b5cec28d36f5 ("hugetlbfs: truncate_hugepages() takes a range of pages") Signed-off-by: Mike Kravetz Acked-by: Hugh Dickins Cc: Dave Hansen Cc: Naoya Horiguchi Cc: Davidlohr Bueso Cc: "Hillf Danton" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 16c61891361c8beca41cc5339689126b127ef57a Author: Michal Hocko Date: Fri Dec 11 13:40:32 2015 -0800 mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress commit 373ccbe5927034b55bdc80b0f8b54d6e13fe8d12 upstream. Tetsuo Handa has reported that the system might basically livelock in OOM condition without triggering the OOM killer. The issue is caused by internal dependency of the direct reclaim on vmstat counter updates (via zone_reclaimable) which are performed from the workqueue context. If all the current workers get assigned to an allocation request, though, they will be looping inside the allocator trying to reclaim memory but zone_reclaimable can see stalled numbers so it will consider a zone reclaimable even though it has been scanned way too much. WQ concurrency logic will not consider this situation as a congested workqueue because it relies that worker would have to sleep in such a situation. This also means that it doesn't try to spawn new workers or invoke the rescuer thread if the one is assigned to the queue. In order to fix this issue we need to do two things. First we have to let wq concurrency code know that we are in trouble so we have to do a short sleep. In order to prevent from issues handled by 0e093d99763e ("writeback: do not sleep on the congestion queue if there are no congested BDIs or if significant congestion is not being encountered in the current zone") we limit the sleep only to worker threads which are the ones of the interest anyway. The second thing to do is to create a dedicated workqueue for vmstat and mark it WQ_MEM_RECLAIM to note it participates in the reclaim and to have a spare worker thread for it. Signed-off-by: Michal Hocko Reported-by: Tetsuo Handa Cc: Tejun Heo Cc: Cristopher Lameter Cc: Joonsoo Kim Cc: Arkadiusz Miskiewicz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3f5fae4d1a3189d95b02b4b45e1218df147122bc Author: Naoya Horiguchi Date: Fri Dec 11 13:40:24 2015 -0800 mm: hugetlb: fix hugepage memory leak caused by wrong reserve count commit a88c769548047b21f76fd71e04b6a3300ff17160 upstream. When dequeue_huge_page_vma() in alloc_huge_page() fails, we fall back on alloc_buddy_huge_page() to directly create a hugepage from the buddy allocator. In that case, however, if alloc_buddy_huge_page() succeeds we don't decrement h->resv_huge_pages, which means that successful hugetlb_fault() returns without releasing the reserve count. As a result, subsequent hugetlb_fault() might fail despite that there are still free hugepages. This patch simply adds decrementing code on that code path. I reproduced this problem when testing v4.3 kernel in the following situation: - the test machine/VM is a NUMA system, - hugepage overcommiting is enabled, - most of hugepages are allocated and there's only one free hugepage which is on node 0 (for example), - another program, which calls set_mempolicy(MPOL_BIND) to bind itself to node 1, tries to allocate a hugepage, - the allocation should fail but the reserve count is still hold. Signed-off-by: Naoya Horiguchi Cc: David Rientjes Cc: Dave Hansen Cc: Mel Gorman Cc: Joonsoo Kim Cc: Hillf Danton Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 01a79daaa336a8cd69894813b59cb77e35b11b89 Author: Michal Hocko Date: Thu Nov 5 18:50:29 2015 -0800 memcg: fix thresholds for 32b architectures. commit c12176d3368b9b36ae484d323d41e94be26f9b65 upstream. Commit 424cdc141380 ("memcg: convert threshold to bytes") has fixed a regression introduced by 3e32cb2e0a12 ("mm: memcontrol: lockless page counters") where thresholds were silently converted to use page units rather than bytes when interpreting the user input. The fix is not complete, though, as properly pointed out by Ben Hutchings during stable backport review. The page count is converted to bytes but unsigned long is used to hold the value which would be obviously not sufficient for 32b systems with more than 4G thresholds. The same applies to usage as taken from mem_cgroup_usage which might overflow. Let's remove this bytes vs. pages internal tracking differences and handle thresholds in page units internally. Chage mem_cgroup_usage() to return the value in page units and revert 424cdc141380 because this should be sufficient for the consistent handling. mem_cgroup_read_u64 as the only users of mem_cgroup_usage outside of the threshold handling code is converted to give the proper in bytes result. It is doing that already for page_counter output so this is more consistent as well. The value presented to the userspace is still in bytes units. Fixes: 424cdc141380 ("memcg: convert threshold to bytes") Fixes: 3e32cb2e0a12 ("mm: memcontrol: lockless page counters") Signed-off-by: Michal Hocko Reported-by: Ben Hutchings Reviewed-by: Vladimir Davydov Acked-by: Johannes Weiner From: Michal Hocko Subject: memcg: fix thresholds for 32b architectures. Signed-off-by: Greg Kroah-Hartman Cc: Ben Hutchings Cc: Vladimir Davydov Cc: Johannes Weiner From: Andrew Morton Subject: memcg: fix thresholds for 32b architectures. don't attempt to inline mem_cgroup_usage() The compiler ignores the inline anwyay. And __always_inlining it adds 600 bytes of goop to the .o file. Cc: Ben Hutchings Cc: Johannes Weiner Cc: Michal Hocko Cc: Vladimir Davydov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds commit 56c5e58fa2f89a322a9f60e48632a6204ff1f461 Author: Greg Thelen Date: Fri Nov 6 16:32:42 2015 -0800 fs, seqfile: always allow oom killer commit 0f930902eb8806cff8dcaef9ff9faf3cfa5fd748 upstream. Since 5cec38ac866b ("fs, seq_file: fallback to vmalloc instead of oom kill processes") seq_buf_alloc() avoids calling the oom killer for PAGE_SIZE or smaller allocations; but larger allocations can use the oom killer via vmalloc(). Thus reads of small files can return ENOMEM, but larger files use the oom killer to avoid ENOMEM. The effect of this bug is that reads from /proc and other virtual filesystems can return ENOMEM instead of the preferred behavior - oom killing something (possibly the calling process). I don't know of anyone except Google who has noticed the issue. I suspect the fix is more needed in smaller systems where there isn't any reclaimable memory. But these seem like the kinds of systems which probably don't use the oom killer for production situations. Memory overcommit requires use of the oom killer to select a victim regardless of file size. Enable oom killer for small seq_buf_alloc() allocations. Fixes: 5cec38ac866b ("fs, seq_file: fallback to vmalloc instead of oom kill processes") Signed-off-by: David Rientjes Signed-off-by: Greg Thelen Acked-by: Eric Dumazet Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2343eaa317134614f5dfc25e63c8f2088fd3b5f5 Author: Andy Shevchenko Date: Fri Nov 6 16:31:31 2015 -0800 lib/hexdump.c: truncate output in case of overflow commit 9f029f540c2f7e010e4922d44ba0dfd05da79f88 upstream. There is a classical off-by-one error in case when we try to place, for example, 1+1 bytes as hex in the buffer of size 6. The expected result is to get an output truncated, but in the reality we get 6 bytes filed followed by terminating NUL. Change the logic how we fill the output in case of byte dumping into limited space. This will follow the snprintf() behaviour by truncating output even on half bytes. Fixes: 114fc1afb2de (hexdump: make it return number of bytes placed in buffer) Signed-off-by: Andy Shevchenko Reported-by: Aaro Koskinen Tested-by: Aaro Koskinen Cc: Al Viro Cc: Catalin Marinas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 83d79c0d3a568141b7792d999daf8f28e2d6c9fb Author: Tetsuo Handa Date: Thu Nov 5 18:47:44 2015 -0800 mm/oom_kill.c: reverse the order of setting TIF_MEMDIE and sending SIGKILL commit 426fb5e72d92b868912e47a1e3ca2df6eabc3872 upstream. It was confirmed that a local unprivileged user can consume all memory reserves and hang up that system using time lag between the OOM killer sets TIF_MEMDIE on an OOM victim and sends SIGKILL to that victim, for printk() inside for_each_process() loop at oom_kill_process() can consume many seconds when there are many thread groups sharing the same memory. Before starting oom-depleter process: Node 0 DMA: 3*4kB (UM) 6*8kB (U) 4*16kB (UEM) 0*32kB 0*64kB 1*128kB (M) 2*256kB (EM) 2*512kB (UE) 2*1024kB (EM) 1*2048kB (E) 1*4096kB (M) = 9980kB Node 0 DMA32: 31*4kB (UEM) 27*8kB (UE) 32*16kB (UE) 13*32kB (UE) 14*64kB (UM) 7*128kB (UM) 8*256kB (UM) 8*512kB (UM) 3*1024kB (U) 4*2048kB (UM) 362*4096kB (UM) = 1503220kB As of invoking the OOM killer: Node 0 DMA: 11*4kB (UE) 8*8kB (UEM) 6*16kB (UE) 2*32kB (EM) 0*64kB 1*128kB (U) 3*256kB (UEM) 2*512kB (UE) 3*1024kB (UEM) 1*2048kB (U) 0*4096kB = 7308kB Node 0 DMA32: 1049*4kB (UEM) 507*8kB (UE) 151*16kB (UE) 53*32kB (UEM) 83*64kB (UEM) 52*128kB (EM) 25*256kB (UEM) 11*512kB (M) 6*1024kB (UM) 1*2048kB (M) 0*4096kB = 44556kB Between the thread group leader got TIF_MEMDIE and receives SIGKILL: Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB The oom-depleter's thread group leader which got TIF_MEMDIE started memset() in user space after the OOM killer set TIF_MEMDIE, and it was free to abuse ALLOC_NO_WATERMARKS by TIF_MEMDIE for memset() in user space until SIGKILL is delivered. If SIGKILL is delivered before TIF_MEMDIE is set, the oom-depleter can terminate without touching memory reserves. Although the possibility of hitting this time lag is very small for 3.19 and earlier kernels because TIF_MEMDIE is set immediately before sending SIGKILL, preemption or long interrupts (an extreme example is SysRq-t) can step between and allow memory allocations which are not needed for terminating the OOM victim. Fixes: 83363b917a29 ("oom: make sure that TIF_MEMDIE is set under task_lock") Signed-off-by: Tetsuo Handa Acked-by: Michal Hocko Cc: David Rientjes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 64615901324372f00677e39cd16efa319f604215 Author: Catalin Marinas Date: Thu Nov 5 18:45:54 2015 -0800 mm: slab: only move management objects off-slab for sizes larger than KMALLOC_MIN_SIZE commit d4322d88f5fdf92729dd40f923013414fbb2184d upstream. On systems with a KMALLOC_MIN_SIZE of 128 (arm64, some mips and powerpc configurations defining ARCH_DMA_MINALIGN to 128), the first kmalloc_caches[] entry to be initialised after slab_early_init = 0 is "kmalloc-128" with index 7. Depending on the debug kernel configuration, sizeof(struct kmem_cache) can be larger than 128 resulting in an INDEX_NODE of 8. Commit 8fc9cf420b36 ("slab: make more slab management structure off the slab") enables off-slab management objects for sizes starting with PAGE_SIZE >> 5 (128 bytes for a 4KB page configuration) and the creation of the "kmalloc-128" cache would try to place the management objects off-slab. However, since KMALLOC_MIN_SIZE is already 128 and freelist_size == 32 in __kmem_cache_create(), kmalloc_slab(freelist_size) returns NULL (kmalloc_caches[7] not populated yet). This triggers the following bug on arm64: kernel BUG at /work/Linux/linux-2.6-aarch64/mm/slab.c:2283! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.3.0-rc4+ #540 Hardware name: Juno (DT) PC is at __kmem_cache_create+0x21c/0x280 LR is at __kmem_cache_create+0x210/0x280 [...] Call trace: __kmem_cache_create+0x21c/0x280 create_boot_cache+0x48/0x80 create_kmalloc_cache+0x50/0x88 create_kmalloc_caches+0x4c/0xf4 kmem_cache_init+0x100/0x118 start_kernel+0x214/0x33c This patch introduces an OFF_SLAB_MIN_SIZE definition to avoid off-slab management objects for sizes equal to or smaller than KMALLOC_MIN_SIZE. Fixes: 8fc9cf420b36 ("slab: make more slab management structure off the slab") Signed-off-by: Catalin Marinas Reported-by: Geert Uytterhoeven Acked-by: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 38ff7eb030aaf1dc65a4c00fb322a36fbd6bdbdc Author: Colin Ian King Date: Fri Dec 18 14:22:01 2015 -0800 proc: fix -ESRCH error when writing to /proc/$pid/coredump_filter commit 41a0c249cb8706a2efa1ab3d59466b23a27d0c8b upstream. Writing to /proc/$pid/coredump_filter always returns -ESRCH because commit 774636e19ed51 ("proc: convert to kstrto*()/kstrto*_from_user()") removed the setting of ret after the get_proc_task call and incorrectly left it as -ESRCH. Instead, return 0 when successful. Example breakage: echo 0 > /proc/self/coredump_filter bash: echo: write error: No such process Fixes: 774636e19ed51 ("proc: convert to kstrto*()/kstrto*_from_user()") Signed-off-by: Colin Ian King Acked-by: Kees Cook Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bffecd3844604aa095ed473d75f26028de5202f5 Author: Arnd Bergmann Date: Fri Nov 20 18:26:07 2015 +0100 remoteproc: avoid stack overflow in debugfs file commit 92792e48e2ae6051af30468a87994b5432da2f06 upstream. Recent gcc versions warn about reading from a negative offset of an on-stack array: drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write': drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' may be used uninitialized in this function [-Wmaybe-uninitialized] I don't see anything in sys_write() that prevents us from being called with a zero 'count' argument, so we should add an extra check in rproc_recovery_write() to prevent the access and avoid the warning. Signed-off-by: Arnd Bergmann Fixes: 2e37abb89a2e ("remoteproc: create a 'recovery' debugfs entry") Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman commit a793d2b5bc0b1d6dcac2e2ad1d5f39bd47a6a234 Author: Oleg Nesterov Date: Fri Nov 6 16:30:06 2015 -0800 proc: actually make proc_fd_permission() thread-friendly commit 54708d2858e79a2bdda10bf8a20c80eb96c20613 upstream. The commit 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly") fixed the access to /proc/self/fd from sub-threads, but introduced another problem: a sub-thread can't access /proc//fd/ or /proc/thread-self/fd if generic_permission() fails. Change proc_fd_permission() to check same_thread_group(pid_task(), current). Fixes: 96d0df79f264 ("proc: make proc_fd_permission() thread-friendly") Reported-by: "Jin, Yihua" Signed-off-by: Oleg Nesterov Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 788e6ddf4d9816185d857c34b763d26945bdcd4b Author: Takashi Iwai Date: Tue Dec 8 17:00:42 2015 +0100 ALSA: hda - Implement loopback control switch for Realtek and other codecs commit e7fdd52779a6c2b49d457f452296a77c8cffef6a upstream. Many codecs, typically found on Realtek codecs, have the analog loopback path merged to the secondary input of the middle of the output paths. Currently, we don't offer the dynamic switching in such configuration but let each loopback path mute by itself. This should work well in theory, but in reality, we often see that such a dead loopback path causes some background noises even if all the elements get muted. Such a problem has been fixed by adding the quirk accordingly to disable aamix, and it's the right fix, per se. The only problem is that it's not so trivial to achieve it; user needs to pass a hint string via patch module option or sysfs. This patch gives a bit improvement on the situation: it adds "Loopback Mixing" control element for such codecs like other codecs (e.g. IDT or VIA codecs) with the individual loopback paths. User can turn on/off the loopback path simply via a mixer app. For keeping the compatibility, the loopback is still enabled on these codecs. But user can try to turn it off if experiencing a suspicious background or click noise on the fly, then build a static fixup later once after the problem is addressed. Other than the addition of the loopback enable/disablement control, there should be no changes. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e52edae1fe3b60307d460a5ccb9a3403e14d8bc9 Author: Ioan-Adrian Ratiu Date: Fri Nov 20 22:19:02 2015 +0200 HID: usbhid: fix recursive deadlock commit e470127e9606b1fa151c4184243e61296d1e0c0f upstream. The critical section protected by usbhid->lock in hid_ctrl() is too big and because of this it causes a recursive deadlock. "Too big" means the case statement and the call to hid_input_report() do not need to be protected by the spinlock (no URB operations are done inside them). The deadlock happens because in certain rare cases drivers try to grab the lock while handling the ctrl irq which grabs the lock before them as described above. For example newer wacom tablets like 056a:033c try to reschedule proximity reads from wacom_intuos_schedule_prox_event() calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report() which tries to grab the usbhid lock already held by hid_ctrl(). There are two ways to get out of this deadlock: 1. Make the drivers work "around" the ctrl critical region, in the wacom case for ex. by delaying the scheduling of the proximity read request itself to a workqueue. 2. Shrink the critical region so the usbhid lock protects only the instructions which modify usbhid state, calling hid_input_report() with the spinlock unlocked, allowing the device driver to grab the lock first, finish and then grab the lock afterwards in hid_ctrl(). This patch implements the 2nd solution. Signed-off-by: Ioan-Adrian Ratiu Signed-off-by: Jiri Kosina Signed-off-by: Jason Gerecke Signed-off-by: Greg Kroah-Hartman commit 5b419b909db57ce8bc06e1504086067484fef90e Author: Tariq Saeed Date: Thu Jan 21 16:40:39 2016 -0800 ocfs2: NFS hangs in __ocfs2_cluster_lock due to race with ocfs2_unblock_lock commit b1b1e15ef6b80facf76d6757649dfd7295eda29f upstream. NFS on a 2 node ocfs2 cluster each node exporting dir. The lock causing the hang is the global bit map inode lock. Node 1 is master, has the lock granted in PR mode; Node 2 is in the converting list (PR -> EX). There are no holders of the lock on the master node so it should downconvert to NL and grant EX to node 2 but that does not happen. BLOCKED + QUEUED in lock res are set and it is on osb blocked list. Threads are waiting in __ocfs2_cluster_lock on BLOCKED. One thread wants EX, rest want PR. So it is as though the downconvert thread needs to be kicked to complete the conv. The hang is caused by an EX req coming into __ocfs2_cluster_lock on the heels of a PR req after it sets BUSY (drops l_lock, releasing EX thread), forcing the incoming EX to wait on BUSY without doing anything. PR has called ocfs2_dlm_lock, which sets the node 1 lock from NL -> PR, queues ast. At this time, upconvert (PR ->EX) arrives from node 2, finds conflict with node 1 lock in PR, so the lock res is put on dlm thread's dirty listt. After ret from ocf2_dlm_lock, PR thread now waits behind EX on BUSY till awoken by ast. Now it is dlm_thread that serially runs dlm_shuffle_lists, ast, bast, in that order. dlm_shuffle_lists ques a bast on behalf of node 2 (which will be run by dlm_thread right after the ast). ast does its part, sets UPCONVERT_FINISHING, clears BUSY and wakes its waiters. Next, dlm_thread runs bast. It sets BLOCKED and kicks dc thread. dc thread runs ocfs2_unblock_lock, but since UPCONVERT_FINISHING set, skips doing anything and reques. Inside of __ocfs2_cluster_lock, since EX has been waiting on BUSY ahead of PR, it wakes up first, finds BLOCKED set and skips doing anything but clearing UPCONVERT_FINISHING (which was actually "meant" for the PR thread), and this time waits on BLOCKED. Next, the PR thread comes out of wait but since UPCONVERT_FINISHING is not set, it skips updating the l_ro_holders and goes straight to wait on BLOCKED. So there, we have a hang! Threads in __ocfs2_cluster_lock wait on BLOCKED, lock res in osb blocked list. Only when dc thread is awoken, it will run ocfs2_unblock_lock and things will unhang. One way to fix this is to wake the dc thread on the flag after clearing UPCONVERT_FINISHING Orabug: 20933419 Signed-off-by: Tariq Saeed Signed-off-by: Santosh Shilimkar Reviewed-by: Wengang Wang Reviewed-by: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Reviewed-by: Joseph Qi Cc: Eric Ren Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 368f974ce05b21eae9b5bf8edaf6940079d3dc91 Author: Trond Myklebust Date: Mon Dec 28 11:27:15 2015 -0500 NFSv4.1/pnfs: Fixup an lo->plh_block_lgets imbalance in layoutreturn commit 1a093ceb053832c25b92f3cf26b957543c7baf9b upstream. Since commit 2d8ae84fbc32, nothing is bumping lo->plh_block_lgets in the layoutreturn path, so it should not be touched in nfs4_layoutreturn_release either. Fixes: 2d8ae84fbc32 ("NFSv4.1/pnfs: Remove redundant lo->plh_block_lgets...") Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit ecf177df3b63d88f6fb5e10683004f50b6dfe116 Author: Junichi Nomura Date: Tue Dec 22 10:23:44 2015 -0700 block: ensure to split after potentially bouncing a bio commit 23688bf4f830a89866fd0ed3501e342a7360fe4f upstream. blk_queue_bio() does split then bounce, which makes the segment counting based on pages before bouncing and could go wrong. Move the split to after bouncing, like we do for blk-mq, and the we fix the issue of having the bio count for segments be wrong. Fixes: 54efd50bfd87 ("block: make generic_make_request handle arbitrarily sized bios") Tested-by: Artem S. Tashkinov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c854fc16ba94297c971fc93aebdfded3f543259e Author: Seth Jennings Date: Fri Dec 11 13:40:57 2015 -0800 drivers/base/memory.c: prohibit offlining of memory blocks with missing sections commit 26bbe7ef6d5cdc7ec08cba6d433fca4060f258f3 upstream. Commit bdee237c0343 ("x86: mm: Use 2GB memory block size on large-memory x86-64 systems") and 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit") introduced large block sizes for x86. This made it possible to have multiple sections per memory block where previously, there was a only every one section per block. Since blocks consist of contiguous ranges of section, there can be holes in the blocks where sections are not present. If one attempts to offline such a block, a crash occurs since the code is not designed to deal with this. This patch is a quick fix to gaurd against the crash by not allowing blocks with non-present sections to be offlined. Addresses https://bugzilla.kernel.org/show_bug.cgi?id=107781 Signed-off-by: Seth Jennings Reported-by: Andrew Banman Cc: Daniel J Blueman Cc: Yinghai Lu Cc: Greg KH Cc: Russ Anderson Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7435c303d7e85e47738282becc3c8e15b4b02c06 Author: Mike Snitzer Date: Mon Nov 23 16:24:45 2015 -0500 dm btree: fix leak of bufio-backed block in btree_split_sibling error path commit 30ce6e1cc5a0f781d60227e9096c86e188d2c2bd upstream. The block allocated at the start of btree_split_sibling() is never released if later insert_at() fails. Fix this by releasing the previously allocated bufio block using unlock_block(). Reported-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit f6d45a66d0c5a4c5747df0b8a6eebaaa1126b56e Author: Hannes Reinecke Date: Thu Nov 26 08:46:57 2015 +0100 block: Always check queue limits for cloned requests commit bf4e6b4e757488dee1b6a581f49c7ac34cd217f8 upstream. When a cloned request is retried on other queues it always needs to be checked against the queue limits of that queue. Otherwise the calculations for nr_phys_segments might be wrong, leading to a crash in scsi_init_sgtable(). To clarify this the patch renames blk_rq_check_limits() to blk_cloned_rq_check_limits() and removes the symbol export, as the new function should only be used for cloned requests and never exported. Cc: Mike Snitzer Cc: Ewan Milne Cc: Jeff Moyer Signed-off-by: Hannes Reinecke Fixes: e2a60da74 ("block: Clean up special command handling logic") Acked-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit f7b03cd741dc1f87936b58e841a2555c6a7deb00 Author: LABBE Corentin Date: Mon Nov 16 09:35:54 2015 +0100 crypto: sun4i-ss - add missing statesize commit 4f9ea86604e3ba64edd2817795798168fbb3c1a6 upstream. sun4i-ss implementaton of md5/sha1 is via ahash algorithms. Commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero") made impossible to load them without giving statesize. This patch specifiy statesize for sha1 and md5. Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Tested-by: Chen-Yu Tsai Signed-off-by: LABBE Corentin Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit e3d57c5b7136a657d46cca666ffedf1f0d4f7880 Author: Herbert Xu Date: Fri Dec 18 19:16:57 2015 +0800 crypto: algif_skcipher - Use new skcipher interface commit 0d96e4bab2855a030077cc695a3563fd7cb0e7d8 upstream. This patch replaces uses of ablkcipher with the new skcipher interface. Signed-off-by: Herbert Xu Tested-by: Signed-off-by: Greg Kroah-Hartman commit f15e5364441e892de6b3090c357b6947513b7a7a Author: Jason A. Donenfeld Date: Sun Dec 6 02:51:37 2015 +0100 crypto: skcipher - Copy iv from desc even for 0-len walks commit 70d906bc17500edfa9bdd8c8b7e59618c7911613 upstream. Some ciphers actually support encrypting zero length plaintexts. For example, many AEAD modes support this. The resulting ciphertext for those winds up being only the authentication tag, which is a result of the key, the iv, the additional data, and the fact that the plaintext had zero length. The blkcipher constructors won't copy the IV to the right place, however, when using a zero length input, resulting in some significant problems when ciphers call their initialization routines, only to find that the ->iv parameter is uninitialized. One such example of this would be using chacha20poly1305 with a zero length input, which then calls chacha20, which calls the key setup routine, which eventually OOPSes due to the uninitialized ->iv member. Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 1f8b52002e010be989eb2e02bd0c90b65bdb3683 Author: David Gstir Date: Sun Nov 15 17:14:42 2015 +0100 crypto: talitos - Fix timing leak in ESP ICV verification commit 79960943fdc114fd4583c9ab164b5c89da7aa601 upstream. Using non-constant time memcmp() makes the verification of the authentication tag in the decrypt path vulnerable to timing attacks. Fix this by using crypto_memneq() instead. Signed-off-by: David Gstir Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 9af08bfec330b387f7432aacfa2c189e5c3e8d1d Author: David Gstir Date: Sun Nov 15 17:14:41 2015 +0100 crypto: nx - Fix timing leak in GCM and CCM decryption commit cb8affb55c7e64816f3effcd9b2fc3268c016fac upstream. Using non-constant time memcmp() makes the verification of the authentication tag in the decrypt path vulnerable to timing attacks. Fix this by using crypto_memneq() instead. Signed-off-by: David Gstir Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 08b8fa6165d4bbd4a0b2b330677974748eb8fc55 Author: Tadeusz Struk Date: Wed Oct 21 14:57:09 2015 -0700 crypto: qat - don't use userspace pointer commit 176155dac13f528e0a58c14dc322623219365d91 upstream. Bugfix - don't dereference userspace pointer. Signed-off-by: Tadeusz Struk Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d4f9756c6ad78cbb728549e1e0dd7afafd8069a6 Author: Herbert Xu Date: Sun Nov 1 17:11:19 2015 +0800 crypto: algif_hash - Only export and import on sockets with data commit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream. The hash_accept call fails to work on sockets that have not received any data. For some algorithm implementations it may cause crashes. This patch fixes this by ensuring that we only export and import on sockets that have received data. Reported-by: Harsh Jain Signed-off-by: Herbert Xu Tested-by: Stephan Mueller Signed-off-by: Greg Kroah-Hartman commit a349da65d72708d63cd8a0c1303549ac98c3a957 Author: Jaegeuk Kim Date: Thu Sep 3 13:38:23 2015 -0700 f2fs crypto: allocate buffer for decrypting filename commit 569cf1876a32e574ba8a7fb825cd91bafd003882 upstream. We got dentry pages from high_mem, and its address space directly goes into the decryption path via f2fs_fname_disk_to_usr. But, sg_init_one assumes the address is not from high_mem, so we can get this panic since it doesn't call kmap_high but kunmap_high is triggered at the end. kernel BUG at ../../../../../../kernel/mm/highmem.c:290! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM ... (kunmap_high+0xb0/0xb8) from [] (__kunmap_atomic+0xa0/0xa4) (__kunmap_atomic+0xa0/0xa4) from [] (blkcipher_walk_done+0x128/0x1ec) (blkcipher_walk_done+0x128/0x1ec) from [] (crypto_cbc_decrypt+0xc0/0x170) (crypto_cbc_decrypt+0xc0/0x170) from [] (crypto_cts_decrypt+0xc0/0x114) (crypto_cts_decrypt+0xc0/0x114) from [] (async_decrypt+0x40/0x48) (async_decrypt+0x40/0x48) from [] (f2fs_fname_disk_to_usr+0x124/0x304) (f2fs_fname_disk_to_usr+0x124/0x304) from [] (f2fs_fill_dentries+0xac/0x188) (f2fs_fill_dentries+0xac/0x188) from [] (f2fs_readdir+0x1f0/0x300) (f2fs_readdir+0x1f0/0x300) from [] (vfs_readdir+0x90/0xb4) (vfs_readdir+0x90/0xb4) from [] (SyS_getdents64+0x64/0xcc) (SyS_getdents64+0x64/0xcc) from [] (ret_fast_syscall+0x0/0x30) Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit c084696ae6b8a9f42007043b944ff0b845c797d2 Author: Russell King Date: Sun Oct 18 17:51:20 2015 +0100 crypto: caam - fix non-block aligned hash calculation commit c7556ff7e3e4f2747583bcc787f12ec9460ec3a6 upstream. caam does not properly calculate the size of the retained state when non-block aligned hashes are requested - it uses the wrong buffer sizes, which results in errors such as: caam_jr 2102000.jr1: 40000501: DECO: desc idx 5: SGT Length Error. The descriptor is trying to read more data than is contained in the SGT table. We end up here with: in_len 0x46 blocksize 0x40 last_bufsize 0x0 next_bufsize 0x6 to_hash 0x40 ctx_len 0x28 nbytes 0x20 which results in a job descriptor of: jobdesc@889: ed03d918: b0861c08 3daa0080 f1400000 3d03d938 jobdesc@889: ed03d928: 00000068 f8400000 3cde2a40 00000028 where the word at 0xed03d928 is the expected data size (0x68), and a scatterlist containing: sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000 sg@892: ed03d948: 00000000 3d03d100 00000006 00000000 sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000 0x68 comes from 0x28 (the context size) plus the "in_len" rounded down to a block size (0x40). in_len comes from 0x26 bytes of unhashed data from the previous operation, plus the 0x20 bytes from the latest operation. The fixed version would create: sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000 sg@892: ed03d948: 00000000 3d03d100 00000026 00000000 sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000 which replaces the 0x06 length with the correct 0x26 bytes of previously unhashed data. This fixes a previous commit which erroneously "fixed" this due to a DMA-API bug report; that commit indicates that the bug was caused via a test_ahash_pnum() function in the tcrypt module. No such function has ever existed in the mainline kernel. Given that the change in this commit has been tested with DMA API debug enabled and shows no issue, I can only conclude that test_ahash_pnum() was triggering that bad behaviour by CAAM. Fixes: 7d5196aba3c8 ("crypto: caam - Correct DMA unmap size in ahash_update_ctx()") Signed-off-by: Russell King Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 7333f7d64093432c7653ec8c3b226c7c34e9b2fb Author: Nicolas Iooss Date: Sun Sep 20 16:42:36 2015 +0200 crypto: crc32c-pclmul - use .rodata instead of .rotata commit 97bce7e0b58dfc7d159ded329f57961868fb060b upstream. Module crc32c-intel uses a special read-only data section named .rotata. This section is defined for K_table, and its name seems to be a spelling mistake for .rodata. Fixes: 473946e674eb ("crypto: crc32c-pclmul - Shrink K_table to 32-bit words") Signed-off-by: Nicolas Iooss Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman