commit 23c1d576322a111f34201df4c9e9f044b9648085 Author: Alexandre Frade Date: Tue Jul 3 16:35:35 2018 -0300 4.14.53-xanmod36 Signed-off-by: Alexandre Frade commit b78f8c6d8d2eecacbbecea1f4c27659c9bbc1931 Author: Alexandre Frade Date: Tue Jul 3 16:27:50 2018 -0300 Revert "sched/cfs: tunes for better desktop interactivity and smoothness" commit ae00c521549630cc38d419a2d297b02215fd5fc5 Author: Alexandre Frade Date: Tue Jul 3 16:00:13 2018 -0300 kconfig: disable pds-mq to enable cfs for tuned cpu core scheduler Signed-off-by: Alexandre Frade commit e473e02309fdfffa627c936f7a75e370db1d4953 Author: Alexandre Frade Date: Tue Jul 3 11:02:08 2018 -0300 elevator: set default scheduler to kyber for blk-mq Signed-off-by: Alexandre Frade commit 78ee13ee02bb4cd579f6ed182d1dc980dc50228b Merge: 92110c1f3a62 fa745a1bd983 Author: Alexandre Frade Date: Tue Jul 3 10:54:17 2018 -0300 Merge tag 'v4.14.53' into 4.14 This is the 4.14.53 stable release commit fa745a1bd983b601c3f9c081ebf07dad9e0e3cb9 Author: Greg Kroah-Hartman Date: Tue Jul 3 11:25:05 2018 +0200 Linux 4.14.53 commit 4798e96b7646d562f839b9a87332d86a5aa5bf10 Author: Mathias Nyman Date: Thu May 3 17:30:07 2018 +0300 xhci: Fix use-after-free in xhci_free_virt_device commit 44a182b9d17765514fa2b1cc911e4e65134eef93 upstream. KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e where xhci_free_virt_device() sets slot id to 0 if udev exists: if (dev->udev && dev->udev->slot_id) dev->udev->slot_id = 0; dev->udev will be true even if udev is freed because dev->udev is not set to NULL. set dev->udev pointer to NULL in xhci_free_dev() The original patch went to stable so this fix needs to be applied there as well. Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and freeing a xhci slot") Cc: Reported-by: Guenter Roeck Reviewed-by: Guenter Roeck Tested-by: Guenter Roeck Signed-off-by: Mathias Nyman Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 0b19825ffa2838c7a3eaa83851dc19e8d5c527b3 Author: Mike Snitzer Date: Tue Jun 26 12:04:23 2018 -0400 dm thin: handle running out of data space vs concurrent discard commit a685557fbbc3122ed11e8ad3fa63a11ebc5de8c3 upstream. Discards issued to a DM thin device can complete to userspace (via fstrim) _before_ the metadata changes associated with the discards is reflected in the thinp superblock (e.g. free blocks). As such, if a user constructs a test that loops repeatedly over these steps, block allocation can fail due to discards not having completed yet: 1) fill thin device via filesystem file 2) remove file 3) fstrim From initial report, here: https://www.redhat.com/archives/dm-devel/2018-April/msg00022.html "The root cause of this issue is that dm-thin will first remove mapping and increase corresponding blocks' reference count to prevent them from being reused before DISCARD bios get processed by the underlying layers. However. increasing blocks' reference count could also increase the nr_allocated_this_transaction in struct sm_disk which makes smd->old_ll.nr_allocated + smd->nr_allocated_this_transaction bigger than smd->old_ll.nr_blocks. In this case, alloc_data_block() will never commit metadata to reset the begin pointer of struct sm_disk, because sm_disk_get_nr_free() always return an underflow value." While there is room for improvement to the space-map accounting that thinp is making use of: the reality is this test is inherently racey and will result in the previous iteration's fstrim's discard(s) completing vs concurrent block allocation, via dd, in the next iteration of the loop. No amount of space map accounting improvements will be able to allow user's to use a block before a discard of that block has completed. So the best we can really do is allow DM thinp to gracefully handle such aggressive use of all the pool's data by degrading the pool into out-of-data-space (OODS) mode. We _should_ get that behaviour already (if space map accounting didn't falsely cause alloc_data_block() to believe free space was available).. but short of that we handle the current reality that dm_pool_alloc_data_block() can return -ENOSPC. Reported-by: Dennis Yang Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit fb4d8744a8f92626309e391f4b52138662275d0a Author: Bart Van Assche Date: Fri Jun 22 08:09:11 2018 -0700 dm zoned: avoid triggering reclaim from inside dmz_map() commit 2d0b2d64d325e22939d9db3ba784f1236459ed98 upstream. This patch avoids that lockdep reports the following: ====================================================== WARNING: possible circular locking dependency detected 4.18.0-rc1 #62 Not tainted ------------------------------------------------------ kswapd0/84 is trying to acquire lock: 00000000c313516d (&xfs_nondir_ilock_class){++++}, at: xfs_free_eofblocks+0xa2/0x1e0 but task is already holding lock: 00000000591c83ae (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x5/0x30 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (fs_reclaim){+.+.}: kmem_cache_alloc+0x2c/0x2b0 radix_tree_node_alloc.constprop.19+0x3d/0xc0 __radix_tree_create+0x161/0x1c0 __radix_tree_insert+0x45/0x210 dmz_map+0x245/0x2d0 [dm_zoned] __map_bio+0x40/0x260 __split_and_process_non_flush+0x116/0x220 __split_and_process_bio+0x81/0x180 __dm_make_request.isra.32+0x5a/0x100 generic_make_request+0x36e/0x690 submit_bio+0x6c/0x140 mpage_readpages+0x19e/0x1f0 read_pages+0x6d/0x1b0 __do_page_cache_readahead+0x21b/0x2d0 force_page_cache_readahead+0xc4/0x100 generic_file_read_iter+0x7c6/0xd20 __vfs_read+0x102/0x180 vfs_read+0x9b/0x140 ksys_read+0x55/0xc0 do_syscall_64+0x5a/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe -> #1 (&dmz->chunk_lock){+.+.}: dmz_map+0x133/0x2d0 [dm_zoned] __map_bio+0x40/0x260 __split_and_process_non_flush+0x116/0x220 __split_and_process_bio+0x81/0x180 __dm_make_request.isra.32+0x5a/0x100 generic_make_request+0x36e/0x690 submit_bio+0x6c/0x140 _xfs_buf_ioapply+0x31c/0x590 xfs_buf_submit_wait+0x73/0x520 xfs_buf_read_map+0x134/0x2f0 xfs_trans_read_buf_map+0xc3/0x580 xfs_read_agf+0xa5/0x1e0 xfs_alloc_read_agf+0x59/0x2b0 xfs_alloc_pagf_init+0x27/0x60 xfs_bmap_longest_free_extent+0x43/0xb0 xfs_bmap_btalloc_nullfb+0x7f/0xf0 xfs_bmap_btalloc+0x428/0x7c0 xfs_bmapi_write+0x598/0xcc0 xfs_iomap_write_allocate+0x15a/0x330 xfs_map_blocks+0x1cf/0x3f0 xfs_do_writepage+0x15f/0x7b0 write_cache_pages+0x1ca/0x540 xfs_vm_writepages+0x65/0xa0 do_writepages+0x48/0xf0 __writeback_single_inode+0x58/0x730 writeback_sb_inodes+0x249/0x5c0 wb_writeback+0x11e/0x550 wb_workfn+0xa3/0x670 process_one_work+0x228/0x670 worker_thread+0x3c/0x390 kthread+0x11c/0x140 ret_from_fork+0x3a/0x50 -> #0 (&xfs_nondir_ilock_class){++++}: down_read_nested+0x43/0x70 xfs_free_eofblocks+0xa2/0x1e0 xfs_fs_destroy_inode+0xac/0x270 dispose_list+0x51/0x80 prune_icache_sb+0x52/0x70 super_cache_scan+0x127/0x1a0 shrink_slab.part.47+0x1bd/0x590 shrink_node+0x3b5/0x470 balance_pgdat+0x158/0x3b0 kswapd+0x1ba/0x600 kthread+0x11c/0x140 ret_from_fork+0x3a/0x50 other info that might help us debug this: Chain exists of: &xfs_nondir_ilock_class --> &dmz->chunk_lock --> fs_reclaim Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&dmz->chunk_lock); lock(fs_reclaim); lock(&xfs_nondir_ilock_class); commit 0cfb151b93527711b7af2fea8313bd67459299e2 Author: Kirill A. Shutemov Date: Mon Jun 25 15:08:52 2018 +0300 x86/efi: Fix efi_call_phys_epilog() with CONFIG_X86_5LEVEL=y commit cfe19577047e74cdac5826adbdc2337d8437f8fb upstream. Open-coded page table entry checks don't work correctly when we fold the page table level at runtime. pgd_present() on 4-level paging machine always returns true, but open-coded version of the check may return false-negative result and we silently skip the rest of the loop body in efi_call_phys_epilog(). Replace open-coded checks with proper helpers. Signed-off-by: Kirill A. Shutemov Acked-by: Ard Biesheuvel Cc: Andrey Ryabinin Cc: Baoquan He Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: stable@vger.kernel.org # v4.12+ Fixes: 94133e46a0f5 ("x86/efi: Correct EFI identity mapping under 'efi=old_map' when KASLR is enabled") Link: http://lkml.kernel.org/r/20180625120852.18300-1-kirill.shutemov@linux.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 251141340fd8028607a20329217900ce4aac909e Author: Bart Van Assche Date: Wed Jun 27 12:55:18 2018 -0700 block: Fix cloning of requests with a special payload commit 297ba57dcdec7ea37e702bcf1a577ac32a034e21 upstream. This patch avoids that removing a path controlled by the dm-mpath driver while mkfs is running triggers the following kernel bug: kernel BUG at block/blk-core.c:3347! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 20 PID: 24369 Comm: mkfs.ext4 Not tainted 4.18.0-rc1-dbg+ #2 RIP: 0010:blk_end_request_all+0x68/0x70 Call Trace: dm_softirq_done+0x326/0x3d0 [dm_mod] blk_done_softirq+0x19b/0x1e0 __do_softirq+0x128/0x60d irq_exit+0x100/0x110 smp_call_function_single_interrupt+0x90/0x330 call_function_single_interrupt+0xf/0x20 Fixes: f9d03f96b988 ("block: improve handling of the magic discard payload") Reviewed-by: Ming Lei Reviewed-by: Christoph Hellwig Acked-by: Mike Snitzer Signed-off-by: Bart Van Assche Cc: Hannes Reinecke Cc: Johannes Thumshirn Cc: Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 29413e068b2b4b81c0423066029025244f43d32d Author: Keith Busch Date: Tue Jun 26 09:14:58 2018 -0600 block: Fix transfer when chunk sectors exceeds max commit 15bfd21fbc5d35834b9ea383dc458a1f0c9e3434 upstream. A device may have boundary restrictions where the number of sectors between boundaries exceeds its max transfer size. In this case, we need to cap the max size to the smaller of the two limits. Reported-by: Jitendra Bhivare Tested-by: Jitendra Bhivare Cc: Reviewed-by: Martin K. Petersen Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 804a0db743e01f8d613051497c9c5f6ff03b40c6 Author: Mikulas Patocka Date: Wed Jun 27 23:26:09 2018 -0700 slub: fix failure when we delete and create a slab cache commit d50d82faa0c964e31f7a946ba8aba7c715ca7ab0 upstream. In kernel 4.17 I removed some code from dm-bufio that did slab cache merging (commit 21bb13276768: "dm bufio: remove code that merges slab caches") - both slab and slub support merging caches with identical attributes, so dm-bufio now just calls kmem_cache_create and relies on implicit merging. This uncovered a bug in the slub subsystem - if we delete a cache and immediatelly create another cache with the same attributes, it fails because of duplicate filename in /sys/kernel/slab/. The slub subsystem offloads freeing the cache to a workqueue - and if we create the new cache before the workqueue runs, it complains because of duplicate filename in sysfs. This patch fixes the bug by moving the call of kobject_del from sysfs_slab_remove_workfn to shutdown_cache. kobject_del must be called while we hold slab_mutex - so that the sysfs entry is deleted before a cache with the same attributes could be created. Running device-mapper-test-suite with: dmtest run --suite thin-provisioning -n /commit_failure_causes_fallback/ triggered: Buffer I/O error on dev dm-0, logical block 1572848, async page read device-mapper: thin: 253:1: metadata operation 'dm_pool_alloc_data_block' failed: error = -5 device-mapper: thin: 253:1: aborting current metadata transaction sysfs: cannot create duplicate filename '/kernel/slab/:a-0000144' CPU: 2 PID: 1037 Comm: kworker/u48:1 Not tainted 4.17.0.snitm+ #25 Hardware name: Supermicro SYS-1029P-WTR/X11DDW-L, BIOS 2.0a 12/06/2017 Workqueue: dm-thin do_worker [dm_thin_pool] Call Trace: dump_stack+0x5a/0x73 sysfs_warn_dup+0x58/0x70 sysfs_create_dir_ns+0x77/0x80 kobject_add_internal+0xba/0x2e0 kobject_init_and_add+0x70/0xb0 sysfs_slab_add+0xb1/0x250 __kmem_cache_create+0x116/0x150 create_cache+0xd9/0x1f0 kmem_cache_create_usercopy+0x1c1/0x250 kmem_cache_create+0x18/0x20 dm_bufio_client_create+0x1ae/0x410 [dm_bufio] dm_block_manager_create+0x5e/0x90 [dm_persistent_data] __create_persistent_data_objects+0x38/0x940 [dm_thin_pool] dm_pool_abort_metadata+0x64/0x90 [dm_thin_pool] metadata_operation_failed+0x59/0x100 [dm_thin_pool] alloc_data_block.isra.53+0x86/0x180 [dm_thin_pool] process_cell+0x2a3/0x550 [dm_thin_pool] do_worker+0x28d/0x8f0 [dm_thin_pool] process_one_work+0x171/0x370 worker_thread+0x49/0x3f0 kthread+0xf8/0x130 ret_from_fork+0x35/0x40 kobject_add_internal failed for :a-0000144 with -EEXIST, don't try to register things with the same name in the same directory. kmem_cache_create(dm_bufio_buffer-16) failed with error -17 Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1806151817130.6333@file01.intranet.prod.int.rdu2.redhat.com Signed-off-by: Mikulas Patocka Reported-by: Mike Snitzer Tested-by: Mike Snitzer Cc: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit cd41a8fac35a92e3b19365181a337d4dd657bb06 Author: Hui Wang Date: Mon Jun 25 14:40:56 2018 +0800 ALSA: hda/realtek - Fix the problem of two front mics on more machines commit e41fc8c5bd41b96bfae5ce4c66bee6edabc932e8 upstream. We have 3 more Lenovo machines, they all have 2 front mics on them, so they need the fixup to change the location for one of two mics. Among these 3 Lenovo machines, one of them has the same pin cfg as the machine with subid 0x17aa3138, so use the pin cfg table to apply fixup for them. The rest machines don't share the same pin cfg, so far use the subid to apply fixup for them. Fixes: a3dafb2200bf ("ALSA: hda/realtek - adjust the location of one mic") Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c75f047560cbc39d39ee31a0088fbb8eacd36446 Author: Takashi Iwai Date: Fri Jun 22 12:17:45 2018 +0200 ALSA: hda/realtek - Add a quirk for FSC ESPRIMO U9210 commit 275ec0cb946cb75ac8977f662e608fce92f8b8a8 upstream. Fujitsu Seimens ESPRIMO Mobile U9210 requires the same fixup as H270 for the correct pin configs. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200107 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 59bcd69457c7f0d64531ca4b572e2aab0d061b3f Author: Takashi Iwai Date: Wed Jun 13 12:43:10 2018 +0200 ALSA: hda/realtek - Fix pop noise on Lenovo P50 & co commit d5a6cabf02210b896a60eee7c04c670ee9ba6dca upstream. Some Lenovo laptops, e.g. Lenovo P50, showed the pop noise at resume or runtime resume. It turned out to be reduced by applying alc_no_shutup() just like TPT440 quirk does. Since there are many Lenovo models showing the same behavior, put this workaround in ALC269_FIXUP_THINKPAD_ACPI entry so that it's applied commonly to all such Lenovo machines. Reported-by: Hans de Goede Tested-by: Benjamin Berg Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 69f96e9b570a7e09e8493a50068d08174ce3a3a2 Author: Takashi Iwai Date: Mon Jun 25 11:09:11 2018 +0200 ALSA: timer: Fix UBSAN warning at SNDRV_TIMER_IOCTL_NEXT_DEVICE ioctl commit b41f794f284966fd6ec634111e3b40d241389f96 upstream. The kernel may spew a WARNING about UBSAN undefined behavior at handling ALSA timer ioctl SNDRV_TIMER_IOCTL_NEXT_DEVICE: UBSAN: Undefined behaviour in sound/core/timer.c:1524:19 signed integer overflow: 2147483647 + 1 cannot be represented in type 'int' Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x122/0x1c8 lib/dump_stack.c:113 ubsan_epilogue+0x12/0x86 lib/ubsan.c:159 handle_overflow+0x1c2/0x21f lib/ubsan.c:190 __ubsan_handle_add_overflow+0x2a/0x31 lib/ubsan.c:198 snd_timer_user_next_device sound/core/timer.c:1524 [inline] __snd_timer_user_ioctl+0x204d/0x2520 sound/core/timer.c:1939 snd_timer_user_ioctl+0x67/0x95 sound/core/timer.c:1994 .... It happens only when a value with INT_MAX is passed, as we're incrementing it unconditionally. So the fix is trivial, check the value with INT_MAX. Although the bug itself is fairly harmless, it's better to fix it so that fuzzers won't hit this again later. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200213 Reported-and-tested-by: Team OWL337 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3d1de95138fbf54bab0049ae669299e3f1a4c4fe Author: ??? Date: Thu Jun 21 17:15:32 2018 -0700 Input: elantech - fix V4 report decoding for module with middle key commit e0ae2519ca004a628fa55aeef969c37edce522d3 upstream. Some touchpad has middle key and it will be indicated in bit 2 of packet[0]. We need to fix V4 formation's byte mask to prevent error decoding. Signed-off-by: KT Liao Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 524a0c6f2efde4262356de3d31769439abb27cb5 Author: Aaron Ma Date: Thu Jun 21 17:14:01 2018 -0700 Input: elantech - enable middle button of touchpads on ThinkPad P52 commit 24bb555e6e46d96e2a954aa0295029a81cc9bbaa upstream. PNPID is better way to identify the type of touchpads. Enable middle button support on 2 types of touchpads on Lenovo P52. Cc: stable@vger.kernel.org Signed-off-by: Aaron Ma Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit ade767642cc7abee7f14a1d7331fa64e5f475191 Author: Ben Hutchings Date: Tue Jun 19 11:17:32 2018 -0700 Input: elan_i2c_smbus - fix more potential stack buffer overflows commit 50fc7b61959af4b95fafce7fe5dd565199e0b61a upstream. Commit 40f7090bb1b4 ("Input: elan_i2c_smbus - fix corrupted stack") fixed most of the functions using i2c_smbus_read_block_data() to allocate a buffer with the maximum block size. However three functions were left unchanged: * In elan_smbus_initialize(), increase the buffer size in the same way. * In elan_smbus_calibrate_result(), the buffer is provided by the caller (calibrate_store()), so introduce a bounce buffer. Also name the result buffer size. * In elan_smbus_get_report(), the buffer is provided by the caller but happens to be the right length. Add a compile-time assertion to ensure this remains the case. Cc: # 3.19+ Signed-off-by: Ben Hutchings Reviewed-by: Benjamin Tissoires Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 8fa052853d4862988f22f1f9a030d1df44a2e8c1 Author: Enno Boland Date: Tue Jun 19 11:55:33 2018 -0700 Input: xpad - fix GPD Win 2 controller name commit dd6bee81c942c0ea01030da9356026afb88f9d18 upstream. This fixes using the controller with SDL2. SDL2 has a naive algorithm to apply the correct settings to a controller. For X-Box compatible controllers it expects that the controller name contains a variation of a 'XBOX'-string. This patch changes the identifier to contain "X-Box" as substring. Tested with Steam and C-Dogs-SDL which both detect the controller properly after adding this patch. Fixes: c1ba08390a8b ("Input: xpad - add GPD Win 2 Controller USB IDs") Cc: stable@vger.kernel.org Signed-off-by: Enno Boland Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 1b241aa840df5c7af16eb1ad0b614a372a639caa Author: Jan Kara Date: Wed Jun 13 12:09:22 2018 +0200 udf: Detect incorrect directory size commit fa65653e575fbd958bdf5fb9c4a71a324e39510d upstream. Detect when a directory entry is (possibly partially) beyond directory size and return EIO in that case since it means the filesystem is corrupted. Otherwise directory operations can further corrupt the directory and possibly also oops the kernel. CC: Anatoly Trosinenko CC: stable@vger.kernel.org Reported-and-tested-by: Anatoly Trosinenko Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit d08dfdeaf49d240674fff55189a0d8349aeb0858 Author: Boris Ostrovsky Date: Thu Jun 21 13:29:44 2018 -0400 xen: Remove unnecessary BUG_ON from __unbind_from_irq() commit eef04c7b3786ff0c9cb1019278b6c6c2ea0ad4ff upstream. Commit 910f8befdf5b ("xen/pirq: fix error path cleanup when binding MSIs") fixed a couple of errors in error cleanup path of xen_bind_pirq_msi_to_irq(). This cleanup allowed a call to __unbind_from_irq() with an unbound irq, which would result in triggering the BUG_ON there. Since there is really no reason for the BUG_ON (xen_free_irq() can operate on unbound irqs) we can remove it. Reported-by: Ben Hutchings Signed-off-by: Boris Ostrovsky Cc: stable@vger.kernel.org Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit fff76ff5e2b0b299d9c9ed0003b88c2837d9e745 Author: Dan Williams Date: Thu Jun 14 15:26:24 2018 -0700 mm: fix devmem_is_allowed() for sub-page System RAM intersections commit 2bdce74412c249ac01dfe36b6b0043ffd7a5361e upstream. Hussam reports: I was poking around and for no real reason, I did cat /dev/mem and strings /dev/mem. Then I saw the following warning in dmesg. I saved it and rebooted immediately. memremap attempted on mixed range 0x000000000009c000 size: 0x1000 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11810 at kernel/memremap.c:98 memremap+0x104/0x170 [..] Call Trace: xlate_dev_mem_ptr+0x25/0x40 read_mem+0x89/0x1a0 __vfs_read+0x36/0x170 The memremap() implementation checks for attempts to remap System RAM with MEMREMAP_WB and instead redirects those mapping attempts to the linear map. However, that only works if the physical address range being remapped is page aligned. In low memory we have situations like the following: 00000000-00000fff : Reserved 00001000-0009fbff : System RAM 0009fc00-0009ffff : Reserved ...where System RAM intersects Reserved ranges on a sub-page page granularity. Given that devmem_is_allowed() special cases any attempt to map System RAM in the first 1MB of memory, replace page_is_ram() with the more precise region_intersects() to trap attempts to map disallowed ranges. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199999 Link: http://lkml.kernel.org/r/152856436164.18127.2847888121707136898.stgit@dwillia2-desk3.amr.corp.intel.com Fixes: 92281dee825f ("arch: introduce memremap()") Signed-off-by: Dan Williams Reported-by: Hussam Al-Tayeb Tested-by: Hussam Al-Tayeb Cc: Christoph Hellwig Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6f23028480c435a58873a1bb9d4d51cba8e6c1b2 Author: Jia He Date: Thu Jun 14 15:26:14 2018 -0700 mm/ksm.c: ignore STABLE_FLAG of rmap_item->address in rmap_walk_ksm() commit 1105a2fc022f3c7482e32faf516e8bc44095f778 upstream. In our armv8a server(QDF2400), I noticed lots of WARN_ON caused by PAGE_SIZE unaligned for rmap_item->address under memory pressure tests(start 20 guests and run memhog in the host). WARNING: CPU: 4 PID: 4641 at virt/kvm/arm/mmu.c:1826 kvm_age_hva_handler+0xc0/0xc8 CPU: 4 PID: 4641 Comm: memhog Tainted: G W 4.17.0-rc3+ #8 Call trace: kvm_age_hva_handler+0xc0/0xc8 handle_hva_to_gpa+0xa8/0xe0 kvm_age_hva+0x4c/0xe8 kvm_mmu_notifier_clear_flush_young+0x54/0x98 __mmu_notifier_clear_flush_young+0x6c/0xa0 page_referenced_one+0x154/0x1d8 rmap_walk_ksm+0x12c/0x1d0 rmap_walk+0x94/0xa0 page_referenced+0x194/0x1b0 shrink_page_list+0x674/0xc28 shrink_inactive_list+0x26c/0x5b8 shrink_node_memcg+0x35c/0x620 shrink_node+0x100/0x430 do_try_to_free_pages+0xe0/0x3a8 try_to_free_pages+0xe4/0x230 __alloc_pages_nodemask+0x564/0xdc0 alloc_pages_vma+0x90/0x228 do_anonymous_page+0xc8/0x4d0 __handle_mm_fault+0x4a0/0x508 handle_mm_fault+0xf8/0x1b0 do_page_fault+0x218/0x4b8 do_translation_fault+0x90/0xa0 do_mem_abort+0x68/0xf0 el0_da+0x24/0x28 In rmap_walk_ksm, the rmap_item->address might still have the STABLE_FLAG, then the start and end in handle_hva_to_gpa might not be PAGE_SIZE aligned. Thus it will cause exceptions in handle_hva_to_gpa on arm64. This patch fixes it by ignoring (not removing) the low bits of address when doing rmap_walk_ksm. IMO, it should be backported to stable tree. the storm of WARN_ONs is very easy for me to reproduce. More than that, I watched a panic (not reproducible) as follows: page:ffff7fe003742d80 count:-4871 mapcount:-2126053375 mapping: (null) index:0x0 flags: 0x1fffc00000000000() raw: 1fffc00000000000 0000000000000000 0000000000000000 ffffecf981470000 raw: dead000000000100 dead000000000200 ffff8017c001c000 0000000000000000 page dumped because: nonzero _refcount CPU: 29 PID: 18323 Comm: qemu-kvm Tainted: G W 4.14.15-5.hxt.aarch64 #1 Hardware name: Call trace: dump_backtrace+0x0/0x22c show_stack+0x24/0x2c dump_stack+0x8c/0xb0 bad_page+0xf4/0x154 free_pages_check_bad+0x90/0x9c free_pcppages_bulk+0x464/0x518 free_hot_cold_page+0x22c/0x300 __put_page+0x54/0x60 unmap_stage2_range+0x170/0x2b4 kvm_unmap_hva_handler+0x30/0x40 handle_hva_to_gpa+0xb0/0xec kvm_unmap_hva_range+0x5c/0xd0 I even injected a fault on purpose in kvm_unmap_hva_range by seting size=size-0x200, the call trace is similar as above. So I thought the panic is similarly caused by the root cause of WARN_ON. Andrea said: : It looks a straightforward safe fix, on x86 hva_to_gfn_memslot would : zap those bits and hide the misalignment caused by the low metadata : bits being erroneously left set in the address, but the arm code : notices when that's the last page in the memslot and the hva_end is : getting aligned and the size is below one page. : : I think the problem triggers in the addr += PAGE_SIZE of : unmap_stage2_ptes that never matches end because end is aligned but : addr is not. : : } while (pte++, addr += PAGE_SIZE, addr != end); : : x86 again only works on hva_start/hva_end after converting it to : gfn_start/end and that being in pfn units the bits are zapped before : they risk to cause trouble. Jia He said: : I've tested by myself in arm64 server (QDF2400,46 cpus,96G mem) Without : this patch, the WARN_ON is very easy for reproducing. After this patch, I : have run the same benchmarch for a whole day without any WARN_ONs Link: http://lkml.kernel.org/r/1525403506-6750-1-git-send-email-hejianet@gmail.com Signed-off-by: Jia He Reviewed-by: Andrea Arcangeli Tested-by: Jia He Cc: Suzuki K Poulose Cc: Minchan Kim Cc: Claudio Imbrenda Cc: Arvind Yadav Cc: Mike Rapoport Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 76022230aa643deebdc4e4c551f3da7782bb3dee Author: Dongsheng Yang Date: Mon Jun 4 06:24:37 2018 -0400 rbd: flush rbd_dev->watch_dwork after watch is unregistered commit 23edca864951250af845a11da86bb3ea63522ed2 upstream. There is a problem if we are going to unmap a rbd device and the watch_dwork is going to queue delayed work for watch: unmap Thread watch Thread timer do_rbd_remove cancel_tasks_sync(rbd_dev) queue_delayed_work for watch destroy_workqueue(rbd_dev->task_wq) drain_workqueue(wq) destroy other resources in wq call_timer_fn __queue_work() Then the delayed work escape the cancel_tasks_sync() and destroy_workqueue() and we will get an user-after-free call trace: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Modules linked in: CPU: 7 PID: 0 Comm: swapper/7 Tainted: G OE 4.17.0-rc6+ #13 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__queue_work+0x6a/0x3b0 RSP: 0018:ffff9427df1c3e90 EFLAGS: 00010086 RAX: ffff9427deca8400 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff9427deca8400 RSI: ffff9427df1c3e50 RDI: 0000000000000000 RBP: ffff942783e39e00 R08: ffff9427deca8400 R09: ffff9427df1c3f00 R10: 0000000000000004 R11: 0000000000000005 R12: ffff9427cfb85970 R13: 0000000000002000 R14: 000000000001eca0 R15: 0000000000000007 FS: 0000000000000000(0000) GS:ffff9427df1c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000004c900a005 CR4: 00000000000206e0 Call Trace: ? __queue_work+0x3b0/0x3b0 call_timer_fn+0x2d/0x130 run_timer_softirq+0x16e/0x430 ? tick_sched_timer+0x37/0x70 __do_softirq+0xd2/0x280 irq_exit+0xd5/0xe0 smp_apic_timer_interrupt+0x6c/0x130 apic_timer_interrupt+0xf/0x20 [ Move rbd_dev->watch_dwork cancellation so that rbd_reregister_watch() either bails out early because the watch is UNREGISTERED at that point or just gets cancelled. ] Cc: stable@vger.kernel.org Fixes: 99d1694310df ("rbd: retry watch re-registration periodically") Signed-off-by: Dongsheng Yang Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 3c718460f5a3adc0e1363e37430330295477b108 Author: Hans de Goede Date: Thu Apr 26 14:10:23 2018 +0200 pwm: lpss: platform: Save/restore the ctrl register over a suspend/resume commit 1d375b58c12f08d8570b30b865def4734517f04f upstream. On some devices the contents of the ctrl register get lost over a suspend/resume and the PWM comes back up disabled after the resume. This is seen on some Bay Trail devices with the PWM in ACPI enumerated mode, so it shows up as a platform device instead of a PCI device. If we still think it is enabled and then try to change the duty-cycle after this, we end up with a "PWM_SW_UPDATE was not cleared" error and the PWM is stuck in that state from then on. This commit adds suspend and resume pm callbacks to the pwm-lpss-platform code, which save/restore the ctrl register over a suspend/resume, fixing this. Note that: 1) There is no need to do this over a runtime suspend, since we only runtime suspend when disabled and then we properly set the enable bit and reprogram the timings when we re-enable the PWM. 2) This may be happening on more systems then we realize, but has been covered up sofar by a bug in the acpi-lpss.c code which was save/restoring the regular device registers instead of the lpss private registers due to lpss_device_desc.prv_offset not being set. This is fixed by a later patch in this series. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 24ab6e6858e762ade66aebf80ba02f6c4f2311b9 Author: Alexandr Savca Date: Thu Jun 21 17:12:54 2018 -0700 Input: elan_i2c - add ELAN0618 (Lenovo v330 15IKB) ACPI ID commit 8938fc7b8fe9ccfa11751ead502a8d385b607967 upstream. Add ELAN0618 to the list of supported touchpads; this ID is used in Lenovo v330 15IKB devices. Signed-off-by: Alexandr Savca Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit a7f3c0abac1dbba0581904ef9c9643efb0415154 Author: Hans de Goede Date: Thu Apr 26 14:10:24 2018 +0200 ACPI / LPSS: Add missing prv_offset setting for byt/cht PWM devices commit fdcb613d49321b5bf5d5a1bd0fba8e7c241dcc70 upstream. The LPSS PWM device on on Bay Trail and Cherry Trail devices has a set of private registers at offset 0x800, the current lpss_device_desc for them already sets the LPSS_SAVE_CTX flag to have these saved/restored over device-suspend, but the current lpss_device_desc was not setting the prv_offset field, leading to the regular device registers getting saved/restored instead. This is causing the PWM controller to no longer work, resulting in a black screen, after a suspend/resume on systems where the firmware clears the APB clock and reset bits at offset 0x804. This commit fixes this by properly setting prv_offset to 0x800 for the PWM devices. Cc: stable@vger.kernel.org Fixes: e1c748179754 ("ACPI / LPSS: Add Intel BayTrail ACPI mode PWM") Fixes: 1bfbd8eb8a7f ("ACPI / LPSS: Add ACPI IDs for Intel Braswell") Signed-off-by: Hans de Goede Acked-by: Rafael J . Wysocki Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman commit 9aa818d42bf5f5477f66dbc941b4daddfcae290d Author: Kees Cook Date: Fri May 11 18:24:12 2018 +1000 video: uvesafb: Fix integer overflow in allocation commit 9f645bcc566a1e9f921bdae7528a01ced5bc3713 upstream. cmap->len can get close to INT_MAX/2, allowing for an integer overflow in allocation. This uses kmalloc_array() instead to catch the condition. Reported-by: Dr Silvio Cesare of InfoSect Fixes: 8bdb3a2d7df48 ("uvesafb: the driver core") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit fb7fecb4d90fd0808b45f50befa7a07917b3ff9e Author: Trond Myklebust Date: Sat Jun 9 12:50:50 2018 -0400 NFSv4: Fix a typo in nfs41_sequence_process commit 995891006ccbb73c0c9c3923cf9d25c4d07ec16b upstream. We want to compare the slot_id to the highest slot number advertised by the server. Fixes: 3be0f80b5fe9c ("NFSv4.1: Fix up replays of interrupted requests") Cc: stable@vger.kernel.org # 4.15+ Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 63715ead82c5d784798427ba5e5d21b9bc7717e2 Author: Trond Myklebust Date: Sat Jun 9 12:43:06 2018 -0400 NFSv4: Revert commit 5f83d86cf531d ("NFSv4.x: Fix wraparound issues..") commit fc40724fc6731d90cc7fb6d62d66135f85a33dd2 upstream. The correct behaviour for NFSv4 sequence IDs is to wrap around to the value 0 after 0xffffffff. See https://tools.ietf.org/html/rfc5661#section-2.10.6.1 Fixes: 5f83d86cf531d ("NFSv4.x: Fix wraparound issues when validing...") Cc: stable@vger.kernel.org # 4.6+ Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit c92d800fc9c408d09526e6651154743cd6c23c29 Author: Dave Wysochanski Date: Tue May 29 17:47:30 2018 -0400 NFSv4: Fix possible 1-byte stack overflow in nfs_idmap_read_and_verify_message commit d68894800ec5712d7ddf042356f11e36f87d7f78 upstream. In nfs_idmap_read_and_verify_message there is an incorrect sprintf '%d' that converts the __u32 'im_id' from struct idmap_msg to 'id_str', which is a stack char array variable of length NFS_UINT_MAXLEN == 11. If a uid or gid value is > 2147483647 = 0x7fffffff, the conversion overflows into a negative value, for example: crash> p (unsigned) (0x80000000) $1 = 2147483648 crash> p (signed) (0x80000000) $2 = -2147483648 The '-' sign is written to the buffer and this causes a 1 byte overflow when the NULL byte is written, which corrupts kernel stack memory. If CONFIG_CC_STACKPROTECTOR_STRONG is set we see a stack-protector panic: [11558053.616565] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffffa05b8a8c [11558053.639063] CPU: 6 PID: 9423 Comm: rpc.idmapd Tainted: G W ------------ T 3.10.0-514.el7.x86_64 #1 [11558053.641990] Hardware name: Red Hat OpenStack Compute, BIOS 1.10.2-3.el7_4.1 04/01/2014 [11558053.644462] ffffffff818c7bc0 00000000b1f3aec1 ffff880de0f9bd48 ffffffff81685eac [11558053.646430] ffff880de0f9bdc8 ffffffff8167f2b3 ffffffff00000010 ffff880de0f9bdd8 [11558053.648313] ffff880de0f9bd78 00000000b1f3aec1 ffffffff811dcb03 ffffffffa05b8a8c [11558053.650107] Call Trace: [11558053.651347] [] dump_stack+0x19/0x1b [11558053.653013] [] panic+0xe3/0x1f2 [11558053.666240] [] ? kfree+0x103/0x140 [11558053.682589] [] ? idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4] [11558053.689710] [] __stack_chk_fail+0x1b/0x30 [11558053.691619] [] idmap_pipe_downcall+0x1cc/0x1e0 [nfsv4] [11558053.693867] [] rpc_pipe_write+0x56/0x70 [sunrpc] [11558053.695763] [] vfs_write+0xbd/0x1e0 [11558053.702236] [] ? task_work_run+0xac/0xe0 [11558053.704215] [] SyS_write+0x7f/0xe0 [11558053.709674] [] system_call_fastpath+0x16/0x1b Fix this by calling the internally defined nfs_map_numeric_to_string() function which properly uses '%u' to convert this __u32. For consistency, also replace the one other place where snprintf is called. Signed-off-by: Dave Wysochanski Reported-by: Stephen Johnston Fixes: cf4ab538f1516 ("NFSv4: Fix the string length returned by the idmapper") Cc: stable@vger.kernel.org # v3.4+ Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 89864c2e7506ff0b5d62734b31872a5b6ddfb3ab Author: Scott Mayhew Date: Mon May 7 09:01:08 2018 -0400 nfsd: restrict rd_maxcount to svc_max_payload in nfsd_encode_readdir commit 9c2ece6ef67e9d376f32823086169b489c422ed0 upstream. nfsd4_readdir_rsize restricts rd_maxcount to svc_max_payload when estimating the size of the readdir reply, but nfsd_encode_readdir restricts it to INT_MAX when encoding the reply. This can result in log messages like "kernel: RPC request reserved 32896 but used 1049444". Restrict rd_dircount similarly (no reason it should be larger than svc_max_payload). Signed-off-by: Scott Mayhew Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit c508ed236c8b2dab6f19a6727704cc77ffe5dc1e Author: Mauro Carvalho Chehab Date: Thu Apr 5 05:30:52 2018 -0400 media: dvb_frontend: fix locking issues at dvb_frontend_get_event() commit 76d81243a487c09619822ef8e7201a756e58a87d upstream. As warned by smatch: drivers/media/dvb-core/dvb_frontend.c:314 dvb_frontend_get_event() warn: inconsistent returns 'sem:&fepriv->sem'. Locked on: line 288 line 295 line 306 line 314 Unlocked on: line 303 The lock implementation for get event is wrong, as, if an interrupt occurs, down_interruptible() will fail, and the routine will call up() twice when userspace calls the ioctl again. The bad code is there since when Linux migrated to git, in 2005. Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 2c40fa51428b50343e7964faea0aae2810750bc2 Author: Kai-Heng Feng Date: Mon Mar 26 02:06:16 2018 -0400 media: cx231xx: Add support for AverMedia DVD EZMaker 7 commit 29e61d6ef061b012d320327af7dbb3990e75be45 upstream. User reports AverMedia DVD EZMaker 7 can be driven by VIDEO_GRABBER. Add the device to the id_table to make it work. BugLink: https://bugs.launchpad.net/bugs/1620762 Cc: stable@vger.kernel.org Signed-off-by: Kai-Heng Feng Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 06b846486668e1de1d350f8adc86c3d36f01a4ac Author: Mauro Carvalho Chehab Date: Wed Apr 11 11:47:32 2018 -0400 media: v4l2-compat-ioctl32: prevent go past max size commit ea72fbf588ac9c017224dcdaa2019ff52ca56fee upstream. As warned by smatch: drivers/media/v4l2-core/v4l2-compat-ioctl32.c:879 put_v4l2_ext_controls32() warn: check for integer overflow 'count' The access_ok() logic should check for too big arrays too. Cc: stable@vger.kernel.org Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b28f53169c0f4947f6745a993fe655c7c7a9ff8a Author: Kieran Bingham Date: Fri May 18 16:41:54 2018 -0400 media: vsp1: Release buffers for each video node commit 83967993f2320575c0ab27a80bf1d7535909c2f4 upstream. Commit 372b2b0399fc ("media: v4l: vsp1: Release buffers in start_streaming error path") introduced a helper to clean up buffers on error paths, but inadvertently changed the code such that only the output WPF buffers were cleaned, rather than the video node being operated on. Since then vsp1_video_cleanup_pipeline() has grown to perform both video node cleanup, as well as pipeline cleanup. Split the implementation into two distinct functions that perform the required work, so that each video node can release its buffers correctly on streamoff. The pipe cleanup that was performed in the vsp1_video_stop_streaming() (releasing the pipe->dl) is moved to the function for clarity. Fixes: 372b2b0399fc ("media: v4l: vsp1: Release buffers in start_streaming error path") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Kieran Bingham Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3564366d550960865c273e8ce90130f6e1929aaa Author: Kan Liang Date: Tue Nov 14 06:06:40 2017 -0800 perf/x86/intel/uncore: Add event constraint for BDX PCU commit bb9fbe1b57503f790dbbf9f06e72cb0fb9e60740 upstream. Event select bit 7 'Use Occupancy' in PCU Box is not available for counter 0 on BDX Add a constraint to fix it. Reported-by: Stephane Eranian Signed-off-by: Kan Liang Signed-off-by: Thomas Gleixner Tested-by: Stephane Eranian Cc: peterz@infradead.org Cc: ak@linux.intel.com Link: https://lkml.kernel.org/r/1510668400-301000-1-git-send-email-kan.liang@intel.com Cc: "Jin, Yao" Signed-off-by: Greg Kroah-Hartman commit 5cb6105d2211e96250db10cda6202d7e40c3d3fc Author: Kan Liang Date: Wed Oct 18 06:05:07 2017 -0700 perf vendor events: Add Goldmont Plus V1 event file commit 65db92e0965ab56e8031d5c804f26d5be0e47047 upstream. Add a Intel event file for perf. Signed-off-by: Kan Liang Acked-by: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Sukadev Bhattiprolu Link: http://lkml.kernel.org/r/1508331907-395162-1-git-send-email-kan.liang@intel.com Signed-off-by: Arnaldo Carvalho de Melo Cc: "Jin, Yao" Signed-off-by: Greg Kroah-Hartman commit c3382e70a0435cb93eb09fd39c3419d2f8875b5d Author: Adrian Hunter Date: Thu Jun 7 14:30:02 2018 +0300 perf intel-pt: Fix packet decoding of CYC packets commit 621a5a327c1e36ffd7bb567f44a559f64f76358f upstream. Use a 64-bit type so that the cycle count is not limited to 32-bits. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1528371002-8862-1-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 4e7b3632eafa50c8d2225a4f70c7012a0ff8258b Author: Adrian Hunter Date: Thu May 31 13:23:45 2018 +0300 perf intel-pt: Fix "Unexpected indirect branch" error commit 9fb523363f6e3984457fee95bb7019395384ffa7 upstream. Some Atom CPUs can produce FUP packets that contain NLIP (next linear instruction pointer) instead of CLIP (current linear instruction pointer). That will result in "Unexpected indirect branch" errors. Fix by comparing IP to NLIP in that case. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1527762225-26024-5-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 65a163984abe6450c0f7f957581c1a8fc019e946 Author: Adrian Hunter Date: Thu May 31 13:23:44 2018 +0300 perf intel-pt: Fix MTC timing after overflow commit dd27b87ab5fcf3ea1c060b5e3ab5d31cc78e9f4c upstream. On some platforms, overflows will clear before MTC wraparound, and there is no following TSC/TMA packet. In that case the previous TMA is valid. Since there will be a valid TMA either way, stop setting 'have_tma' to false upon overflow. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1527762225-26024-4-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit e1587f178eb14ae98443494adafde35b8ac6f43c Author: Adrian Hunter Date: Thu May 31 13:23:43 2018 +0300 perf intel-pt: Fix decoding to accept CBR between FUP and corresponding TIP commit bd2e49ec48feb1855f7624198849eea4610e2286 upstream. It is possible to have a CBR packet between a FUP packet and corresponding TIP packet. Stop treating it as an error. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1527762225-26024-3-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 9e9db211cfb9e29456edc7cbf302b2b4c44b3d87 Author: Adrian Hunter Date: Thu May 31 13:23:42 2018 +0300 perf intel-pt: Fix sync_switch INTEL_PT_SS_NOT_TRACING commit dbcb82b93f3e8322891e47472c89e63058b81e99 upstream. sync_switch is a facility to synchronize decoding more closely with the point in the kernel when the context actually switched. In one case, INTEL_PT_SS_NOT_TRACING state was not correctly transitioning to INTEL_PT_SS_TRACING state due to a missing case clause. Add it. Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1527762225-26024-2-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 5009bd5b93212a206cdf09bd849779ac63847a73 Author: Adrian Hunter Date: Mon Jun 4 15:56:54 2018 +0300 perf tools: Fix symbol and object code resolution for vdso32 and vdsox32 commit aef4feace285f27c8ed35830a5d575bec7f3e90a upstream. Fix __kmod_path__parse() so that perf tools does not treat vdso32 and vdsox32 as kernel modules and fail to find the object. Signed-off-by: Adrian Hunter Cc: Jiri Olsa Cc: Wang Nan Cc: stable@vger.kernel.org Fixes: 1f121b03d058 ("perf tools: Deal with kernel module names in '[]' correctly") Link: http://lkml.kernel.org/r/1528117014-30032-3-git-send-email-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit f810961e06c6a8b2cdff26a8bac1e38921608673 Author: Sean Wang Date: Wed Apr 11 16:53:56 2018 +0800 arm: dts: mt7623: fix invalid memory node being generated commit c0b0d540db1a8bfb041166c4991dd6f624e8de45 upstream. Below two wrong nodes in existing DTS files would cause a fail boot since in fact the address 0 is not the correct place the memory device locates at. memory { device_type = "memory"; reg = <0x0 0x0 0x0 0x0>; }; memory@80000000 { reg = <0x0 0x80000000 0x0 0x40000000>; }; In order to avoid having a memory node starting at address 0, we can't include file skeleton64.dtsi and instead need to explicitly manually define a few of properties the DTS relies on such as #address-cells and #size-cells in root node and device_type in the node memory@80000000. Cc: stable@vger.kernel.org Fixes: 31ac0d69a1d4 ("ARM: dts: mediatek: add MT7623 basic support") Signed-off-by: Sean Wang Cc: Rob Herring Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit 18be8bd3aceb282c145b74144caaccb51b24bf92 Author: Jarkko Nikula Date: Fri May 18 11:38:27 2018 +0300 mfd: intel-lpss: Fix Intel Cannon Lake LPSS I2C input clock commit 4e93a658576ab115977225c9d0992b97ff19ba8c upstream. Intel Cannon Lake PCH has much higher 216 MHz input clock to LPSS I2C than Sunrisepoint which uses 120 MHz. Preliminary information was that both share the same clock rate but actual silicon implements elevated rate for better support for 3.4 MHz high-speed I2C. This incorrect input clock rate results too high I2C bus clock in case ACPI doesn't provide tuned I2C timing parameters since I2C host controller driver calculates them from input clock rate. Fix this by using the correct rate. We still share the same 230 ns SDA hold time value than Sunrisepoint. Cc: stable@vger.kernel.org Fixes: b418bbff36dd ("mfd: intel-lpss: Add Intel Cannonlake PCI IDs") Reported-by: Jian-Hong Pan Reported-by: Chris Chiu Reported-by: Daniel Drake Signed-off-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Acked-by: Mika Westerberg Tested-by: Jian-Hong Pan Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit f79c97198b5596fa8052938471bd67ae6ccb4067 Author: Andy Shevchenko Date: Tue Apr 24 18:00:10 2018 +0300 mfd: intel-lpss: Program REMAP register in PIO mode commit d28b62520830b2d0bffa2d98e81afc9f5e537e8b upstream. According to documentation REMAP register has to be programmed in either DMA or PIO mode of the slice. Move the DMA capability check below to let REMAP register be programmed in PIO mode. Cc: stable@vger.kernel.org # 4.3+ Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Signed-off-by: Andy Shevchenko Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 779d5f71c2323ef5610e7c3d9bdb73e5f92f660e Author: Johan Hovold Date: Mon Nov 20 11:45:46 2017 +0100 backlight: tps65217_bl: Fix Device Tree node lookup commit 2b12dfa124dbadf391cb9a616aaa6b056823bf75 upstream. Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. This would only cause trouble if the child node is missing while there is an unrelated node named "backlight" elsewhere in the tree. Cc: stable # 3.7 Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver") Signed-off-by: Johan Hovold Acked-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit f893fca0a4b5ac0ea6003945e791486eac32b90c Author: Johan Hovold Date: Mon Nov 20 11:45:45 2017 +0100 backlight: max8925_bl: Fix Device Tree node lookup commit d1cc0ec3da23e44c23712579515494b374f111c9 upstream. Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mfd node was also prematurely freed, while the child backlight node was leaked. Cc: stable # 3.9 Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight") Signed-off-by: Johan Hovold Acked-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit 3db7c40093f6dc58fdfaf2723980955dedadf0a3 Author: Johan Hovold Date: Mon Nov 20 11:45:44 2017 +0100 backlight: as3711_bl: Fix Device Tree node lookup commit 4a9c8bb2aca5b5a2a15744333729745dd9903562 upstream. Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mfd node was also prematurely freed. Cc: stable # 3.10 Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support") Signed-off-by: Johan Hovold Acked-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit b7261fc5f5748b3f6f1a839dbc5a744b8871dfcd Author: Silvio Cesare Date: Fri May 4 13:44:02 2018 +1000 UBIFS: Fix potential integer overflow in allocation commit 353748a359f1821ee934afc579cf04572406b420 upstream. There is potential for the size and len fields in ubifs_data_node to be too large causing either a negative value for the length fields or an integer overflow leading to an incorrect memory allocation. Likewise, when the len field is small, an integer underflow may occur. Signed-off-by: Silvio Cesare Fixes: 1e51764a3c2ac ("UBIFS: add new flash file system") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit a23cf10d9abb04652ec2daf93d494dc0e2cd835f Author: Richard Weinberger Date: Mon May 28 22:04:32 2018 +0200 ubi: fastmap: Correctly handle interrupted erasures in EBA commit 781932375ffc6411713ee0926ccae8596ed0261c upstream. Fastmap cannot track the LEB unmap operation, therefore it can happen that after an interrupted erasure the mapping still looks good from Fastmap's point of view, while reading from the PEB will cause an ECC error and confuses the upper layer. Instead of teaching users of UBI how to deal with that, we read back the VID header and check for errors. If the PEB is empty or shows ECC errors we fixup the mapping and schedule the PEB for erasure. Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Cc: Reported-by: martin bayern Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit b24d90f4d66d9e1f1313cd9bb47cdf0643894ab1 Author: Richard Weinberger Date: Wed May 16 22:17:03 2018 +0200 ubi: fastmap: Cancel work upon detach commit 6e7d80161066c99d12580d1b985cb1408bb58cf1 upstream. Ben Hutchings pointed out that 29b7a6fa1ec0 ("ubi: fastmap: Don't flush fastmap work on detach") does not really fix the problem, it just reduces the risk to hit the race window where fastmap work races against free()'ing ubi->volumes[]. The correct approach is making sure that no more fastmap work is in progress before we free ubi data structures. So we cancel fastmap work right after the ubi background thread is stopped. By setting ubi->thread_enabled to zero we make sure that no further work tries to wake the thread. Fixes: 29b7a6fa1ec0 ("ubi: fastmap: Don't flush fastmap work on detach") Fixes: 74cdaf24004a ("UBI: Fastmap: Fix memory leaks while closing the WL sub-system") Cc: stable@vger.kernel.org Cc: Ben Hutchings Cc: Martin Townsend Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit db04f92b658083a0a2842919c6d8f9013bff2d08 Author: Srinivas Kandagatla Date: Mon Jun 4 10:39:01 2018 +0100 rpmsg: smd: do not use mananged resources for endpoints and channels commit 4a2e84c6ed85434ce7843e4844b4d3263f7e233b upstream. All the managed resources would be freed by the time release function is invoked. Handling such memory in qcom_smd_edge_release() would do bad things. Found this issue while testing Audio usecase where the dsp is started up and shutdown in a loop. This patch fixes this issue by using simple kzalloc for allocating channel->name and channel which is then freed in qcom_smd_edge_release(). Without this patch restarting a remoteproc would crash the system. Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend") Cc: Signed-off-by: Srinivas Kandagatla Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit dfeb333b590c78d0dbadfa00a56635f1b2489d58 Author: NeilBrown Date: Thu Apr 26 14:46:29 2018 +1000 md: fix two problems with setting the "re-add" device state. commit 011abdc9df559ec75779bb7c53a744c69b2a94c6 upstream. If "re-add" is written to the "state" file for a device which is faulty, this has an effect similar to removing and re-adding the device. It should take up the same slot in the array that it previously had, and an accelerated (e.g. bitmap-based) rebuild should happen. The slot that "it previously had" is determined by rdev->saved_raid_disk. However this is not set when a device fails (only when a device is added), and it is cleared when resync completes. This means that "re-add" will normally work once, but may not work a second time. This patch includes two fixes. 1/ when a device fails, record the ->raid_disk value in ->saved_raid_disk before clearing ->raid_disk 2/ when "re-add" is written to a device for which ->saved_raid_disk is not set, fail. I think this is suitable for stable as it can cause re-adding a device to be forced to do a full resync which takes a lot longer and so puts data at more risk. Cc: (v4.1) Fixes: 97f6cd39da22 ("md-cluster: re-add capabilities") Signed-off-by: NeilBrown Reviewed-by: Goldwyn Rodrigues Signed-off-by: Shaohua Li Signed-off-by: Greg Kroah-Hartman commit 88896a963b4e80f5d4f6fe508ab7ce399d7bcb4c Author: Michael Trimarchi Date: Wed May 30 23:57:44 2018 +0530 rtc: sun6i: Fix bit_idx value for clk_register_gate commit 09018d4bd7994c2c9f775029bc24589bc85f76fa upstream. clk-gate core will take bit_idx through clk_register_gate and then do clk_gate_ops by using BIT(bit_idx), but rtc-sun6i is passing bit_idx as BIT(bit_idx) it becomes BIT(BIT(bit_idx) which is wrong and eventually external gate clock is not enabling. This patch fixed by passing bit index and the original change introduced from below commit. "rtc: sun6i: Add support for the external oscillator gate" (sha1: 17ecd246414b3a0fe0cb248c86977a8bda465b7b) Signed-off-by: Michael Trimarchi Fixes: 17ecd246414b ("rtc: sun6i: Add support for the external oscillator gate") Cc: stable@vger.kernel.org Signed-off-by: Jagan Teki Acked-by: Maxime Ripard Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman commit b90f3eccf8aa9eb2990e98bf8c67bd613d44aa0f Author: Marcin Ziemianowicz Date: Sun Apr 29 15:01:11 2018 -0400 clk: at91: PLL recalc_rate() now using cached MUL and DIV values commit a982e45dc150da3a08907b6dd676b735391704b4 upstream. When a USB device is connected to the USB host port on the SAM9N12 then you get "-62" error which seems to indicate USB replies from the device are timing out. Based on a logic sniffer, I saw the USB bus was running at half speed. The PLL code uses cached MUL and DIV values which get set in set_rate() and applied in prepare(), but the recalc_rate() function instead queries the hardware instead of using these cached values. Therefore, if recalc_rate() is called between a set_rate() and prepare(), the wrong frequency is calculated and later the USB clock divider for the SAM9N12 SOC will be configured for an incorrect clock. In my case, the PLL hardware was set to 96 Mhz before the OHCI driver loads, and therefore the usb clock divider was being set to /2 even though the OHCI driver set the PLL to 48 Mhz. As an alternative explanation, I noticed this was fixed in the past by 87e2ed338f1b ("clk: at91: fix recalc_rate implementation of PLL driver") but the bug was later re-introduced by 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally"). Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally) Cc: Signed-off-by: Marcin Ziemianowicz Acked-by: Boris Brezillon Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit a98f1946ea58a21ea8004e07d414ba2f99bc6434 Author: Robert Elliott Date: Thu May 31 18:36:36 2018 -0500 linvdimm, pmem: Preserve read-only setting for pmem devices commit 254a4cd50b9fe2291a12b8902e08e56dcc4e9b10 upstream. The pmem driver does not honor a forced read-only setting for very long: $ blockdev --setro /dev/pmem0 $ blockdev --getro /dev/pmem0 1 followed by various commands like these: $ blockdev --rereadpt /dev/pmem0 or $ mkfs.ext4 /dev/pmem0 results in this in the kernel serial log: nd_pmem namespace0.0: region0 read-write, marking pmem0 read-write with the read-only setting lost: $ blockdev --getro /dev/pmem0 0 That's from bus.c nvdimm_revalidate_disk(), which always applies the setting from nd_region (which is initially based on the ACPI NFIT NVDIMM state flags not_armed bit). In contrast, commit 20bd1d026aac ("scsi: sd: Keep disk read-only when re-reading partition") fixed this issue for SCSI devices to preserve the previous setting if it was set to read-only. This patch modifies bus.c to preserve any previous read-only setting. It also eliminates the kernel serial log print except for cases where read-write is changed to read-only, so it doesn't print read-only to read-only non-changes. Cc: Fixes: 581388209405 ("libnvdimm, nfit: handle unarmed dimms, mark namespaces read-only") Signed-off-by: Robert Elliott Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit a64be479ef08c945a94626e90b11ec46bcb66a5e Author: Steffen Maier Date: Thu May 17 19:14:49 2018 +0200 scsi: zfcp: fix missing REC trigger trace on enqueue without ERP thread commit 6a76550841d412330bd86aed3238d1888ba70f0e upstream. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 ZFCP_DBF_REC_TRIG Tag : ....... LUN : 0x... WWPN : 0x... D_ID : 0x... Adapter status : 0x... Port status : 0x... LUN status : 0x... Ready count : 0x... Running count : 0x... ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_... ERP need : 0xc0 ZFCP_ERP_ACTION_NONE Signed-off-by: Steffen Maier Cc: #2.6.38+ Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit beadcfcca2577f56e70f99cde38f1307aed09f03 Author: Steffen Maier Date: Thu May 17 19:14:48 2018 +0200 scsi: zfcp: fix missing REC trigger trace for all objects in ERP_FAILED commit 8c3d20aada70042a39c6a6625be037c1472ca610 upstream. That other commit introduced an inconsistency because it would trace on ERP_FAILED for all callers of port forced reopen triggers (not just terminate_rport_io), but it would not trace on ERP_FAILED for all callers of other ERP triggers such as adapter, port regular, LUN. Therefore, generalize that other commit. zfcp_erp_action_enqueue() already had two early outs which re-used the one zfcp_dbf_rec_trig() call. All ERP trigger functions finally run through zfcp_erp_action_enqueue(). So move the special handling for ZFCP_STATUS_COMMON_ERP_FAILED into zfcp_erp_action_enqueue() and add another early out with new trace marker for pseudo ERP need in this case. This removes all early returns from all ERP trigger functions so we always end up at zfcp_dbf_rec_trig(). Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 ZFCP_DBF_REC_TRIG Tag : ....... LUN : 0x... WWPN : 0x... D_ID : 0x... Adapter status : 0x... Port status : 0x... LUN status : 0x... Ready count : 0x... Running count : 0x... ERP want : 0x0. ZFCP_ERP_ACTION_REOPEN_... ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED Signed-off-by: Steffen Maier Cc: #2.6.38+ Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 60ed2673986f6c47a5fd12f328da8d92090524d9 Author: Steffen Maier Date: Thu May 17 19:14:47 2018 +0200 scsi: zfcp: fix missing REC trigger trace on terminate_rport_io for ERP_FAILED commit d70aab55924b44f213fec2b900b095430b33eec6 upstream. For problem determination we always want to see when we were invoked on the terminate_rport_io callback whether we perform something or not. Temporal event sequence of interest with a long fast_io_fail_tmo of 27 sec: loose remote port t workqueue [s] zfcp_q_ IRQ zfcperp === ================== =================== ============================ 0 recv RSCN q p.test_link_work block rport start fast_io_fail_tmo send ADISC ELS 4 recv ADISC fail block zfcp_port port forced reopen send open port 12 recv open port fail q p.gid_pn_work zfcp_erp_wakeup (zfcp_erp_wait would return) GID_PN fail Before this point, we got a SCSI trace with tag "sctrpi1" on fast_io_fail, e.g. with the typical 5 sec setting. port.status |= ERP_FAILED If fast_io_fail_tmo triggers after this point, we missed a SCSI trace. workqueue fc_dl_ ================== 27 fc_timeout_fail_rport_io fc_terminate_rport_io zfcp_scsi_terminate_rport_io zfcp_erp_port_forced_reopen _zfcp_erp_port_forced_reopen if (port.status & ERP_FAILED) return; Therefore, write a trace before above early return. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 ZFCP_DBF_REC_TRIG Tag : sctrpi1 SCSI terminate rport I/O LUN : 0xffffffffffffffff none (invalid) WWPN : 0x D_ID : 0x Adapter status : 0x... Port status : 0x... LUN status : 0x00000000 none (invalid) Ready count : 0x... Running count : 0x... ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED ERP need : 0xe0 ZFCP_ERP_ACTION_FAILED Signed-off-by: Steffen Maier Cc: #2.6.38+ Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 071f23266c301c8e07007a8f05f266f9f04c5623 Author: Steffen Maier Date: Thu May 17 19:14:46 2018 +0200 scsi: zfcp: fix missing REC trigger trace on terminate_rport_io early return commit 96d9270499471545048ed8a6d7f425a49762283d upstream. get_device() and its internally used kobject_get() only return NULL if they get passed NULL as argument. zfcp_get_port_by_wwpn() loops over adapter->port_list so the iteration variable port is always non-NULL. Struct device is embedded in struct zfcp_port so &port->dev is always non-NULL. This is the argument to get_device(). However, if we get an fc_rport in terminate_rport_io() for which we cannot find a match within zfcp_get_port_by_wwpn(), the latter can return NULL. v2.6.30 commit 70932935b61e ("[SCSI] zfcp: Fix oops when port disappears") introduced an early return without adding a trace record for this case. Even if we don't need recovery in this case, for debugging we should still see that our callback was invoked originally by scsi_transport_fc. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : REC Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : sctrpin SCSI terminate rport I/O, no zfcp port LUN : 0xffffffffffffffff none (invalid) WWPN : 0x WWPN D_ID : 0x N_Port-ID Adapter status : 0x... Port status : 0xffffffff unknown (-1) LUN status : 0x00000000 none (invalid) Ready count : 0x... Running count : 0x... ERP want : 0x03 ZFCP_ERP_ACTION_REOPEN_PORT_FORCED ERP need : 0xc0 ZFCP_ERP_ACTION_NONE Signed-off-by: Steffen Maier Fixes: 70932935b61e ("[SCSI] zfcp: Fix oops when port disappears") Cc: #2.6.38+ Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 3d0d31e512f29ad34ea078f1ad86ec074b7311b0 Author: Steffen Maier Date: Thu May 17 19:14:45 2018 +0200 scsi: zfcp: fix misleading REC trigger trace where erp_action setup failed commit 512857a795cbbda5980efa4cdb3c0b6602330408 upstream. If a SCSI device is deleted during scsi_eh host reset, we cannot get a reference to the SCSI device anymore since scsi_device_get returns !=0 by design. Assuming the recovery of adapter and port(s) was successful, zfcp_erp_strategy_followup_success() attempts to trigger a LUN reset for the half-gone SCSI device. Unfortunately, it causes the following confusing trace record which states that zfcp will do a LUN recovery as "ERP need" is ZFCP_ERP_ACTION_REOPEN_LUN == 1 and equals "ERP want". Old example trace record formatted with zfcpdbf from s390-tools: Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded LUN : 0x WWPN : 0x D_ID : 0x Adapter status : 0x5400050b Port status : 0x54000001 LUN status : 0x40000000 ZFCP_STATUS_COMMON_RUNNING but not ZFCP_STATUS_COMMON_UNBLOCKED as it was closed on close part of adapter reopen ERP want : 0x01 ERP need : 0x01 misleading However, zfcp_erp_setup_act() returns NULL as it cannot get the reference. Hence, zfcp_erp_action_enqueue() takes an early goto out and _NO_ recovery actually happens. We always do want the recovery trigger trace record even if no erp_action could be enqueued as in this case. For other cases where we did not enqueue an erp_action, 'need' has always been zero to indicate this. In order to indicate above goto out, introduce an eyecatcher "flag" to mark the "ERP need" as 'not needed' but still keep the information which erp_action type, that zfcp_erp_required_act() had decided upon, is needed. 0xc_ is chosen to be visibly different from 0x0_ in "ERP want". New example trace record formatted with zfcpdbf from s390-tools: Tag: : ersfs_3 ERP, trigger, unit reopen, port reopen succeeded LUN : 0x WWPN : 0x D_ID : 0x Adapter status : 0x5400050b Port status : 0x54000001 LUN status : 0x40000000 ERP want : 0x01 ERP need : 0xc1 would need LUN ERP, but no action set up ^ Before v2.6.38 commit ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") we could detect this case because the "erp_action" field in the trace was NULL. The rework removed erp_action as argument and field from the trace. This patch here is for tracing. A fix to allow LUN recovery in the case at hand is a topic for a separate patch. See also commit fdbd1c5e27da ("[SCSI] zfcp: Allow running unit/LUN shutdown without acquiring reference") for a similar case and background info. Signed-off-by: Steffen Maier Fixes: ae0904f60fab ("[SCSI] zfcp: Redesign of the debug tracing for recovery actions.") Cc: #2.6.38+ Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 941e8bee351e5224ab3f5d6de77da82969e723db Author: Steffen Maier Date: Thu May 17 19:14:44 2018 +0200 scsi: zfcp: fix missing SCSI trace for retry of abort / scsi_eh TMF commit 81979ae63e872ef650a7197f6ce6590059d37172 upstream. We already have a SCSI trace for the end of abort and scsi_eh TMF. Due to zfcp_erp_wait() and fc_block_scsi_eh() time can pass between the start of our eh callback and an actual send/recv of an abort / TMF request. In order to see the temporal sequence including any abort / TMF send retries, add a trace before the above two blocking functions. This supports problem determination with scsi_eh and parallel zfcp ERP. No need to explicitly trace the beginning of our eh callback, since we typically can send an abort / TMF and see its HBA response (in the worst case, it's a pseudo response on dismiss all of adapter recovery, e.g. due to an FSF request timeout [fsrth_1] of the abort / TMF). If we cannot send, we now get a trace record for the first "abrt_wt" or "[lt]r_wait" which denotes almost the beginning of the callback. No need to explicitly trace the wakeup after the above two blocking functions because the next retry loop causes another trace in any case and that is sufficient. Example trace records formatted with zfcpdbf from s390-tools: Timestamp : ... Area : SCSI Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : abrt_wt abort, before zfcp_erp_wait() Request ID : 0x0000000000000000 none (invalid) SCSI ID : 0x SCSI LUN : 0x SCSI LUN high : 0x SCSI result : 0x SCSI retries : 0x SCSI allowed : 0x SCSI scribble : 0x SCSI opcode : FCP rsp inf cod: 0x.. none (invalid) FCP rsp IU : ... none (invalid) Timestamp : ... Area : SCSI Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : lr_wait LUN reset, before zfcp_erp_wait() Request ID : 0x0000000000000000 none (invalid) SCSI ID : 0x SCSI LUN : 0x SCSI LUN high : 0x SCSI result : 0x... unrelated SCSI retries : 0x.. unrelated SCSI allowed : 0x.. unrelated SCSI scribble : 0x... unrelated SCSI opcode : ... unrelated FCP rsp inf cod: 0x.. none (invalid) FCP rsp IU : ... none (invalid) Signed-off-by: Steffen Maier Fixes: 63caf367e1c9 ("[SCSI] zfcp: Improve reliability of SCSI eh handlers in zfcp") Fixes: af4de36d911a ("[SCSI] zfcp: Block scsi_eh thread for rport state BLOCKED") Cc: #2.6.38+ Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 74da693a03ceaa21c38c604c5e0b314340a84781 Author: Steffen Maier Date: Thu May 17 19:14:43 2018 +0200 scsi: zfcp: fix missing SCSI trace for result of eh_host_reset_handler commit df30781699f53e4fd4c494c6f7dd16e3d5c21d30 upstream. For problem determination we need to see whether and why we were successful or not. This allows deduction of scsi_eh escalation. Example trace record formatted with zfcpdbf from s390-tools: Timestamp : ... Area : SCSI Subarea : 00 Level : 1 Exception : - CPU ID : .. Caller : 0x... Record ID : 1 Tag : schrh_r SCSI host reset handler result Request ID : 0x0000000000000000 none (invalid) SCSI ID : 0xffffffff none (invalid) SCSI LUN : 0xffffffff none (invalid) SCSI LUN high : 0xffffffff none (invalid) SCSI result : 0x00002002 field re-used for midlayer value: SUCCESS or in other cases: 0x2009 == FAST_IO_FAIL SCSI retries : 0xff none (invalid) SCSI allowed : 0xff none (invalid) SCSI scribble : 0xffffffffffffffff none (invalid) SCSI opcode : ffffffff ffffffff ffffffff ffffffff none (invalid) FCP rsp inf cod: 0xff none (invalid) FCP rsp IU : 00000000 00000000 00000000 00000000 none (invalid) 00000000 00000000 v2.6.35 commit a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh") introduced the first return with something other than the previously hardcoded single SUCCESS return path. Signed-off-by: Steffen Maier Fixes: a1dbfddd02d2 ("[SCSI] zfcp: Pass return code from fc_block_scsi_eh to scsi eh") Cc: #2.6.38+ Reviewed-by: Jens Remus Reviewed-by: Benjamin Block Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9db2ad79b8f03d2ddef33e860fb9cf9cd52e7cbc Author: Anil Gurumurthy Date: Wed Jun 6 08:41:42 2018 -0700 scsi: qla2xxx: Mask off Scope bits in retry delay commit 3cedc8797b9c0f2222fd45a01f849c57c088828b upstream. Some newer target uses "Status Qualifier" response in a returned "Busy Status". This new response code of 0x4001, which is "Scope" bits, translates to "Affects all units accessible by target". Due to this new value returned in the Scope bits, driver was using that value as timeout value which resulted into driver waiting for 27min timeout. This patch masks off this Scope bits so that driver does not use this value as retry delay time. Cc: Signed-off-by: Anil Gurumurthy Signed-off-by: Giridhar Malavali Signed-off-by: Himanshu Madhani Reviewed-by: Ewan D. Milne Reviewed-by: Martin Wilck Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9224583a5ee225969577ba4992322420e805fd2b Author: Himanshu Madhani Date: Sun Jun 3 22:09:53 2018 -0700 scsi: qla2xxx: Fix setting lower transfer speed if GPSC fails commit 413c2f33489b134e3cc65d9c3ff7861e8fdfe899 upstream. This patch prevents driver from setting lower default speed of 1 GB/sec, if the switch does not support Get Port Speed Capabilities (GPSC) command. Setting this default speed results into much lower write performance for large sequential WRITE. This patch modifies driver to check for gpsc_supported flags and prevents driver from issuing MBC_SET_PORT_PARAM (001Ah) to set default speed of 1 GB/sec. If driver does not send this mailbox command, firmware assumes maximum supported link speed and will operate at the max speed. Cc: stable@vger.kernel.org Signed-off-by: Himanshu Madhani Reported-by: Eda Zhou Reviewed-by: Ewan D. Milne Tested-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2829829c3e61b8ff7245345613f10344e1bf3d22 Author: Sinan Kaya Date: Sat Jun 2 00:28:53 2018 -0400 scsi: hpsa: disable device during shutdown commit 0d98ba8d70b0070ac117452ea0b663e26bbf46bf upstream. 'Commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown")' has been added to kernel to shutdown pending PCIe port service interrupts during reboot so that a newly started kexec kernel wouldn't observe pending interrupts. pcie_port_device_remove() is disabling the root port and switches by calling pci_disable_device() after all PCIe service drivers are shutdown. This has been found to cause crashes on HP DL360 Gen9 machines during reboot due to hpsa driver not clearing the bus master bit during the shutdown procedure by calling pci_disable_device(). Disable device as part of the shutdown sequence. Signed-off-by: Sinan Kaya Link: https://bugzilla.kernel.org/show_bug.cgi?id=199779 Fixes: cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown") Cc: stable@vger.kernel.org Reported-by: Ryan Finnie Tested-by: Don Brace Acked-by: Don Brace Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2d329968a883f4b64758df6a6c972a02392b3a24 Author: Dan Williams Date: Thu Apr 19 21:32:19 2018 -0700 mm: fix __gup_device_huge vs unmap commit a9b6de77b1a3ff729f7bfc54b2e17711776a416c upstream. get_user_pages_fast() for device pages is missing the typical validation that all page references have been taken while the mapping was valid. Without this validation truncate operations can not reliably coordinate against new page reference events like O_DIRECT. Cc: Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Reported-by: Jan Kara Reviewed-by: Jan Kara Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 5d6ad5a030675c6527956cf8737657b6be81b41b Author: Christophe JAILLET Date: Sun Apr 8 21:44:01 2018 +0200 iio: sca3000: Fix an error handling path in 'sca3000_probe()' commit 4a5b45383ca371e123ba103d34d4b3b87616245c upstream. Use 'devm_iio_kfifo_allocate()' instead of 'iio_kfifo_allocate()' in order to simplify code and avoid a memory leak in an error path in 'sca3000_probe()'. A call to 'sca3000_unconfigure_ring()' was missing. Sent via the next merge window as unimportant bug and there are other patches dependent on it. Signed-off-by: Christophe JAILLET Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d55209eeb1215c66d5e2b8360760c6c2ff53ae93 Author: Alexandru Ardelean Date: Mon Mar 12 14:06:53 2018 +0200 iio: adc: ad7791: remove sample freq sysfs attributes commit 7eb6b35d93c356f1afebbfb808bc296d6351e708 upstream. In the current state, these attributes are broken, because they are registered already, and the kernel throws a warning. The first registration happens via the `IIO_CHAN_INFO_SAMP_FREQ` flag from the `ad_sigma_delta` driver. In this commit these attrs are removed, and in the following the IIO_CHAN_INFO_SAMP_FREQ behavior will be implemented, which replaces these hooks. This is done to make things a bit easier to review as there is a bit of overlap in the patch if it's done all at once. Fixes: a13e831fcaa7 ("staging: iio: ad7192: implement IIO_CHAN_INFO_SAMP_FREQ") Signed-off-by: Alexandru Ardelean Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 6101eea47bf3a74345e5d722537cc9531ea85a72 Author: Filipe Manana Date: Mon Jun 11 19:24:16 2018 +0100 Btrfs: fix return value on rename exchange failure commit c5b4a50b74018b3677098151ec5f4fce07d5e6a0 upstream. If we failed during a rename exchange operation after starting/joining a transaction, we would end up replacing the return value, stored in the local 'ret' variable, with the return value from btrfs_end_transaction(). So this could end up returning 0 (success) to user space despite the operation having failed and aborted the transaction, because if there are multiple tasks having a reference on the transaction at the time btrfs_end_transaction() is called by the rename exchange, that function returns 0 (otherwise it returns -EIO and not the original error value). So fix this by not overwriting the return value on error after getting a transaction handle. Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit af20e4eccc2d5a6d8985c4ff671cabd2c1ef2016 Author: Maciej S. Szmigiero Date: Sat May 19 14:23:54 2018 +0200 X.509: unpack RSA signatureValue field from BIT STRING commit b65c32ec5a942ab3ada93a048089a938918aba7f upstream. The signatureValue field of a X.509 certificate is encoded as a BIT STRING. For RSA signatures this BIT STRING is of so-called primitive subtype, which contains a u8 prefix indicating a count of unused bits in the encoding. We have to strip this prefix from signature data, just as we already do for key data in x509_extract_key_data() function. This wasn't noticed earlier because this prefix byte is zero for RSA key sizes divisible by 8. Since BIT STRING is a big-endian encoding adding zero prefixes has no bearing on its value. The signature length, however was incorrect, which is a problem for RSA implementations that need it to be exactly correct (like AMD CCP). Signed-off-by: Maciej S. Szmigiero Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates") Cc: stable@vger.kernel.org Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 7dfc81992a3e0da45e45eab2f113658f3628f743 Author: Yang Yingliang Date: Fri Jun 22 10:52:51 2018 +0100 irqchip/gic-v3-its: Don't bind LPI to unavailable NUMA node commit c1797b11a09c8323c92b074fd48b89a936c991d0 upstream. On a NUMA system, if an ITS is local to an offline node, the ITS driver may pick an offline CPU to bind the LPI. In this case, pick an online CPU (and the first one will do). But on some systems, binding an LPI to non-local node CPU may cause deadlock (see Cavium erratum 23144). In this case, just fail the activate and return an error code. Signed-off-by: Yang Yingliang Signed-off-by: Marc Zyngier Signed-off-by: Thomas Gleixner Cc: Jason Cooper Cc: Alexandre Belloni Cc: Sumit Garg Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180622095254.5906-5-marc.zyngier@arm.com Signed-off-by: Greg Kroah-Hartman commit 88c4318d36337ddaeb21eeae34a405a6b9f93bc0 Author: Geert Uytterhoeven Date: Fri Jun 22 16:33:57 2018 +0200 time: Make sure jiffies_to_msecs() preserves non-zero time periods commit abcbcb80cd09cd40f2089d912764e315459b71f7 upstream. For the common cases where 1000 is a multiple of HZ, or HZ is a multiple of 1000, jiffies_to_msecs() never returns zero when passed a non-zero time period. However, if HZ > 1000 and not an integer multiple of 1000 (e.g. 1024 or 1200, as used on alpha and DECstation), jiffies_to_msecs() may return zero for small non-zero time periods. This may break code that relies on receiving back a non-zero value. jiffies_to_usecs() does not need such a fix: one jiffy can only be less than one µs if HZ > 1000000, and such large values of HZ are already rejected at build time, twice: - include/linux/jiffies.h does #error if HZ >= 12288, - kernel/time/time.c has BUILD_BUG_ON(HZ > USEC_PER_SEC). Broken since forever. Signed-off-by: Geert Uytterhoeven Signed-off-by: Thomas Gleixner Reviewed-by: Arnd Bergmann Cc: John Stultz Cc: Stephen Boyd Cc: linux-alpha@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180622143357.7495-1-geert@linux-m68k.org Signed-off-by: Greg Kroah-Hartman commit 0fe95015fb93d171b6cd0e315b33c26ea33e82f1 Author: Huacai Chen Date: Tue Jun 12 17:54:42 2018 +0800 MIPS: io: Add barrier after register read in inX() commit 18f3e95b90b28318ef35910d21c39908de672331 upstream. While a barrier is present in the outX() functions before the register write, a similar barrier is missing in the inX() functions after the register read. This could allow memory accesses following inX() to observe stale data. This patch is very similar to commit a1cc7034e33d12dc1 ("MIPS: io: Add barrier after register read in readX()"). Because war_io_reorder_wmb() is both used by writeX() and outX(), if readX() need a barrier then so does inX(). Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Patchwork: https://patchwork.linux-mips.org/patch/19516/ Signed-off-by: Paul Burton Cc: James Hogan Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: Huacai Chen Signed-off-by: Greg Kroah-Hartman commit 93e1297f9edce474df6839d5434a511cb130a4a2 Author: Srinivas Pandruvada Date: Mon Jun 18 12:47:45 2018 -0700 cpufreq: intel_pstate: Fix scaling max/min limits with Turbo 3.0 commit ff7c9917143b3a6cf2fa61212a32d67cf259bf9c upstream. When scaling max/min settings are changed, internally they are converted to a ratio using the max turbo 1 core turbo frequency. This works fine when 1 core max is same irrespective of the core. But under Turbo 3.0, this will not be the case. For example: Core 0: max turbo pstate: 43 (4.3GHz) Core 1: max turbo pstate: 45 (4.5GHz) In this case 1 core turbo ratio will be maximum of all, so it will be 45 (4.5GHz). Suppose scaling max is set to 4GHz (ratio 40) for all cores ,then on core one it will be = max_state * policy->max / max_freq; = 43 * (4000000/4500000) = 38 (3.8GHz) = 38 which is 200MHz less than the desired. On core2, it will be correctly set to ratio 40 (4GHz). Same holds true for scaling min frequency limit. So this requires usage of correct turbo max frequency for core one, which in this case is 4.3GHz. So we need to adjust per CPU cpu->pstate.turbo_freq using the maximum HWP ratio of that core. This change uses the HWP capability of a core to adjust max turbo frequency. But since Broadwell HWP doesn't use ratios in the HWP capabilities, we have to use legacy max 1 core turbo ratio. This is not a problem as the HWP capabilities don't differ among cores in Broadwell. We need to check for non Broadwell CPU model for applying this change, though. Signed-off-by: Srinivas Pandruvada Cc: 4.6+ # 4.6+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 55be2e6f50ac817bcb553d79ab703838b2760226 Author: Fabio Estevam Date: Thu Jun 7 13:51:33 2018 -0300 pinctrl: devicetree: Fix pctldev pointer overwrite commit bc3322bc166a2905bc91f774d7b22773dc7c063a upstream. Commit b89405b6102f ("pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs") causes the pinctrl hog pins to not get initialized on i.MX platforms leaving them with the IOMUX settings untouched. This causes several regressions on i.MX such as: - OV5640 camera driver can not be probed anymore on imx6qdl-sabresd because the camera clock pin is in a pinctrl_hog group and since its pinctrl initialization is skipped, the camera clock is kept in GPIO functionality instead of CLK_CKO function. - Audio stopped working on imx6qdl-wandboard and imx53-qsb for the same reason. Richard Fitzgerald explains the problem: "I see the bug. If the hog node isn't a 1st level child of the pinctrl parent node it will go around the for(;;) loop again but on the first pass I overwrite pctldev with the result of get_pinctrl_dev_from_of_node() so it doesn't point to the pinctrl driver any more." Fix the issue by stashing the original pctldev so it doesn't get overwritten. Fixes: b89405b6102f ("pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs") Cc: Reported-by: Mika Penttilä Reported-by: Steve Longerbeam Suggested-by: Richard Fitzgerald Signed-off-by: Fabio Estevam Reviewed-by: Dong Aisheng Reviewed-by: Richard Fitzgerald Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 7cc7ae5ce0189f5032fe42eabeb80361eede6783 Author: Paweł Chmiel Date: Mon Apr 16 17:52:45 2018 +0200 pinctrl: samsung: Correct EINTG banks order commit 5cf9a338db94cfd570aa2607bef1b30996f188e3 upstream. All banks with GPIO interrupts should be at beginning of bank array and without any other types of banks between them. This order is expected by exynos_eint_gpio_irq, when doing interrupt group to bank translation. Otherwise, kernel NULL pointer dereference would happen when trying to handle interrupt, due to wrong bank being looked up. Observed on s5pv210, when trying to handle gpj0 interrupt, where kernel was mapping it to gpi bank. Cc: stable@vger.kernel.org Fixes: 023e06dfa688 ("pinctrl: exynos: add exynos5410 SoC specific data") Fixes: 608a26a7bc04 ("pinctrl: Add s5pv210 support to pinctrl-exynos) Signed-off-by: Paweł Chmiel Reviewed-by: Tomasz Figa Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit 9e838b2e5a3c2ee04e46302f7d3d644b7dc4daf5 Author: Randy Dunlap Date: Wed Feb 28 18:33:03 2018 -0800 auxdisplay: fix broken menu commit b5b903fba96a4d1771422efd5c713ebb73f7dc82 upstream. Having the CHARLCD Kconfig symbol between "menuconfig AUXDISPLAY" and "if AUXDISPLAY" breaks the AUXDISPLAY submenus, so move the CHARLCD Kconfig symbol near the end of the file so that the menu display is continuous. Also include ARM_CHARLCD inside of the if AUXDISPLAY/endif block. Geert says that it should be there. Fixes: 39f8ea46724e ("auxdisplay: charlcd: Extract character LCD core from misc/panel") Cc: stable@vger.kernel.org # v4.12 Cc: Geert Uytterhoeven Reviewed-by: Andy Shevchenko Signed-off-by: Randy Dunlap Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman commit 226ffbf6135c0a4adf52f6f4c693c26e23d69b90 Author: Mika Westerberg Date: Wed May 23 17:14:39 2018 -0500 PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume commit 13c65840feab8109194f9490c9870587173cb29d upstream. After a suspend/resume cycle the Presence Detect or Data Link Layer Status Changed bits might be set. If we don't clear them those events will not fire anymore and nothing happens for instance when a device is now hot-unplugged. Fix this by clearing those bits in a newly introduced function pcie_reenable_notification(). This should be fine because immediately after, we check if the adapter is still present by reading directly from the status register. Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Reviewed-by: Rafael J. Wysocki Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fc0096bceae9385dbed081a7922294cfccfde827 Author: Mika Westerberg Date: Fri Apr 27 13:06:30 2018 -0500 PCI: Add ACS quirk for Intel 300 series commit f154a718e6cc0d834f5ac4dc4c3b174e65f3659e upstream. Intel 300 series chipset still has the same ACS issue as the previous generations so extend the ACS quirk to cover it as well. Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 78923ba967799cf5125651c345952e790b744940 Author: Alex Williamson Date: Wed Apr 25 14:27:37 2018 -0600 PCI: Add ACS quirk for Intel 7th & 8th Gen mobile commit e8440f4bfedc623bee40c84797ac78d9303d0db6 upstream. The specification update indicates these have the same errata for implementing non-standard ACS capabilities. Signed-off-by: Alex Williamson Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e4a424c550b61d05de509aea2eea6415bb8c185f Author: Sridhar Pitchai Date: Tue May 1 17:56:32 2018 +0000 PCI: hv: Make sure the bus domain is really unique commit 29927dfb7f69bcf2ae7fd1cda10997e646a5189c upstream. When Linux runs as a guest VM in Hyper-V and Hyper-V adds the virtual PCI bus to the guest, Hyper-V always provides unique PCI domain. commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") overrode unique domain with the serial number of the first device added to the virtual PCI bus. The reason for that patch was to have a consistent and short name for the device, but Hyper-V doesn't provide unique serial numbers. Using non-unique serial numbers as domain IDs leads to duplicate device addresses, which causes PCI bus registration to fail. commit 0c195567a8f6 ("netvsc: transparent VF management") avoids the need for commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain"). When scripts were used to configure VF devices, the name of the VF needed to be consistent and short, but with commit 0c195567a8f6 ("netvsc: transparent VF management") all the setup is done in the kernel, and we do not need to maintain consistent name. Revert commit 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") so we can reliably support multiple devices being assigned to a guest. Tag the patch for stable kernels containing commit 0c195567a8f6 ("netvsc: transparent VF management"). Fixes: 4a9b0933bdfc ("PCI: hv: Use device serial number as PCI domain") Signed-off-by: Sridhar Pitchai [lorenzo.pieralisi@arm.com: trimmed commit log] Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # v4.14+ Reviewed-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 43f6a09c8c5b181afff4956fe748b7d6d481618d Author: Tokunori Ikegami Date: Sun Jun 3 23:02:01 2018 +0900 MIPS: BCM47XX: Enable 74K Core ExternalSync for PCIe erratum commit 2a027b47dba6b77ab8c8e47b589ae9bbc5ac6175 upstream. The erratum and workaround are described by BCM5300X-ES300-RDS.pdf as below. R10: PCIe Transactions Periodically Fail Description: The BCM5300X PCIe does not maintain transaction ordering. This may cause PCIe transaction failure. Fix Comment: Add a dummy PCIe configuration read after a PCIe configuration write to ensure PCIe configuration access ordering. Set ES bit of CP0 configu7 register to enable sync function so that the sync instruction is functional. Resolution: hndpci.c: extpci_write_config() hndmips.c: si_mips_init() mipsinc.h CONF7_ES This is fixed by the CFE MIPS bcmsi chipset driver also for BCM47XX. Also the dummy PCIe configuration read is already implemented in the Linux BCMA driver. Enable ExternalSync in Config7 when CONFIG_BCMA_DRIVER_PCI_HOSTMODE=y too so that the sync instruction is externalised. Signed-off-by: Tokunori Ikegami Reviewed-by: Paul Burton Acked-by: Hauke Mehrtens Cc: Chris Packham Cc: Rafał Miłecki Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/19461/ Signed-off-by: James Hogan Signed-off-by: Greg Kroah-Hartman commit c375d0bd66840b9932353332e0e0a304581d0575 Author: Joakim Tjernlund Date: Wed Jun 6 12:13:30 2018 +0200 mtd: cfi_cmdset_0002: Avoid walking all chips when unlocking. commit f1ce87f6080b1dda7e7b1eda3da332add19d87b9 upstream. cfi_ppb_unlock() walks all flash chips when unlocking sectors, avoid walking chips unaffected by the unlock operation. Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit fbbde9343c3e2452f304cc7715d77d4c9481ac3a Author: Joakim Tjernlund Date: Wed Jun 6 12:13:29 2018 +0200 mtd: cfi_cmdset_0002: Fix unlocking requests crossing a chip boudary commit 0cd8116f172eed018907303dbff5c112690eeb91 upstream. The "sector is in requested range" test used to determine whether sectors should be re-locked or not is done on a variable that is reset everytime we cross a chip boundary, which can lead to some blocks being re-locked while the caller expect them to be unlocked. Fix the check to make sure this cannot happen. Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 2f11a0c8c23ab092feef59a941c373b0f93c51d7 Author: Joakim Tjernlund Date: Wed Jun 6 12:13:28 2018 +0200 mtd: cfi_cmdset_0002: fix SEGV unlocking multiple chips commit 5fdfc3dbad099281bf027a353d5786c09408a8e5 upstream. cfi_ppb_unlock() tries to relock all sectors that were locked before unlocking the whole chip. This locking used the chip start address + the FULL offset from the first flash chip, thereby forming an illegal address. Fix that by using the chip offset(adr). Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 80349943d56c1fdf361e6cf2f1f44ca7d210675c Author: Joakim Tjernlund Date: Wed Jun 6 12:13:27 2018 +0200 mtd: cfi_cmdset_0002: Use right chip in do_ppb_xxlock() commit f93aa8c4de307069c270b2d81741961162bead6c upstream. do_ppb_xxlock() fails to add chip->start when querying for lock status (and chip_ready test), which caused false status reports. Fix that by adding adr += chip->start and adjust call sites accordingly. Fixes: 1648eaaa1575 ("mtd: cfi_cmdset_0002: Support Persistent Protection Bits (PPB) locking") Cc: stable@vger.kernel.org Signed-off-by: Joakim Tjernlund Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit 746c1362c434d4c4d48eb53fa0ef757bc191e55f Author: Tokunori Ikegami Date: Wed May 30 18:32:26 2018 +0900 mtd: cfi_cmdset_0002: Change write buffer to check correct value commit dfeae1073583dc35c33b32150e18b7048bbb37e6 upstream. For the word write it is checked if the chip has the correct value. But it is not checked for the write buffer as only checked if ready. To make sure for the write buffer change to check the value. It is enough as this patch is only checking the last written word. Since it is described by data sheets to check the operation status. Signed-off-by: Tokunori Ikegami Reviewed-by: Joakim Tjernlund Cc: Chris Packham Cc: Brian Norris Cc: David Woodhouse Cc: Boris Brezillon Cc: Marek Vasut Cc: Richard Weinberger Cc: Cyrille Pitchen Cc: linux-mtd@lists.infradead.org Cc: stable@vger.kernel.org Signed-off-by: Boris Brezillon Signed-off-by: Greg Kroah-Hartman commit d097e5b5a1bc3cc601f11b61455210414c4f8b59 Author: Chuck Lever Date: Fri May 4 15:35:46 2018 -0400 xprtrdma: Return -ENOBUFS when no pages are available commit a8f688ec437dc2045cc8f0c89fe877d5803850da upstream. The use of -EAGAIN in rpcrdma_convert_iovs() is a latent bug: the transport never calls xprt_write_space() when more pages become available. -ENOBUFS will trigger the correct "delay briefly and call again" logic. Fixes: 7a89f9c626e3 ("xprtrdma: Honor ->send_request API contract") Signed-off-by: Chuck Lever Cc: stable@vger.kernel.org # 4.8+ Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 786c8d79f34f0c54d3f9028e994e397207ae769c Author: Leon Romanovsky Date: Tue May 29 14:56:14 2018 +0300 RDMA/mlx4: Discard unknown SQP work requests commit 6b1ca7ece15e94251d1d0d919f813943e4a58059 upstream. There is no need to crash the machine if unknown work request was received in SQP MAD. Cc: # 3.6 Fixes: 37bfc7c1e83f ("IB/mlx4: SR-IOV multiplex and demultiplex MADs") Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit a336999251226e5451afce56173c322cdc9d873a Author: Mike Marciniszyn Date: Thu May 31 11:30:09 2018 -0700 IB/hfi1: Fix user context tail allocation for DMA_RTAIL commit 1bc0299d976e000ececc6acd76e33b4582646cb7 upstream. The following code fails to allocate a buffer for the tail address that the hardware DMAs into when the user context DMA_RTAIL is set. if (HFI1_CAP_KGET_MASK(rcd->flags, DMA_RTAIL)) { rcd->rcvhdrtail_kvaddr = dma_zalloc_coherent( &dd->pcidev->dev, PAGE_SIZE, &dma_hdrqtail, gfp_flags); if (!rcd->rcvhdrtail_kvaddr) goto bail_free; rcd->rcvhdrqtailaddr_dma = dma_hdrqtail; } So the rcvhdrtail_kvaddr would then be NULL. The mmap logic fails to check for a NULL rcvhdrtail_kvaddr. The fix is to test for both user and kernel DMA_TAIL options during the allocation as well as testing for a NULL rcvhdrtail_kvaddr during the mmap processing. Additionally, all downstream testing of the capmask for DMA_RTAIL have been eliminated in favor of testing rcvhdrtail_kvaddr. Cc: # 4.9.x Reviewed-by: Michael J. Ruhl Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 964705c4a69183182362977c28786e789a384700 Author: Sebastian Sanchez Date: Wed May 2 06:43:39 2018 -0700 IB/hfi1: Optimize kthread pointer locking when queuing CQ entries commit af8aab71370a692eaf7e7969ba5b1a455ac20113 upstream. All threads queuing CQ entries on different CQs are unnecessarily synchronized by a spin lock to check if the CQ kthread worker hasn't been destroyed before queuing an CQ entry. The lock used in 6efaf10f163d ("IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker") is a device global lock and will have poor performance at scale as completions are entered from a large number of CPUs. Convert to use RCU where the read side of RCU is rvt_cq_enter() to determine that the worker is alive prior to triggering the completion event. Apply write side RCU semantics in rvt_driver_cq_init() and rvt_cq_exit(). Fixes: 6efaf10f163d ("IB/rdmavt: Avoid queuing work into a destroyed cq kthread worker") Cc: # 4.14.x Reviewed-by: Mike Marciniszyn Signed-off-by: Sebastian Sanchez Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 2bd28cba43bd24ad3c8b485c3ab4bb4a65564b0c Author: Michael J. Ruhl Date: Wed May 2 06:43:07 2018 -0700 IB/hfi1: Reorder incorrect send context disable commit a93a0a31111231bb1949f4a83b17238f0fa32d6a upstream. User send context integrity bits are cleared before the context is disabled. If the send context is still processing data, any packets that need those integrity bits will cause an error and halt the send context. During the disable handling, the driver waits for the context to drain. If the context is halted, the driver will eventually timeout because the context won't drain and then incorrectly bounce the link. Reorder the bit clearing and the context disable. Examine the software state and send context status as well as the egress status to determine if a send context is in the halted state. Promote the check macros to static functions for consistency with the new check and to follow kernel style. Remove an unused define that refers to the egress timeout. Cc: # 4.9.x Reviewed-by: Mitko Haralanov Reviewed-by: Mike Marciniszyn Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit 9e81f9a2cef15c7563181a00d103c2b2fb4184eb Author: Mike Marciniszyn Date: Wed May 2 06:42:44 2018 -0700 IB/hfi1: Fix fault injection init/exit issues commit 8c79d8223bb11b2f005695a32ddd3985de97727c upstream. There are config dependent code paths that expose panics in unload paths both in this file and in debugfs_remove_recursive() because CONFIG_FAULT_INJECTION and CONFIG_FAULT_INJECTION_DEBUG_FS can be set independently. Having CONFIG_FAULT_INJECTION set and CONFIG_FAULT_INJECTION_DEBUG_FS reset causes fault_create_debugfs_attr() to return an error. The debugfs.c routines tolerate failures, but the module unload panics dereferencing a NULL in the two exit routines. If that is fixed, the dir passed to debugfs_remove_recursive comes from a memory location that was freed and potentially reused causing a segfault or corrupting memory. Here is an example of the NULL deref panic: [66866.286829] BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 [66866.295602] IP: hfi1_dbg_ibdev_exit+0x2a/0x80 [hfi1] [66866.301138] PGD 858496067 P4D 858496067 PUD 8433a7067 PMD 0 [66866.307452] Oops: 0000 [#1] SMP [66866.310953] Modules linked in: hfi1(-) rdmavt rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm iw_cm ib_cm ib_core rpcsec_gss_krb5 nfsv4 dns_resolver nfsv3 nfs fscache sb_edac x86_pkg_temp_thermal intel_powerclamp vfat fat coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel iTCO_wdt iTCO_vendor_support crypto_simd mei_me glue_helper cryptd mxm_wmi ipmi_si pcspkr lpc_ich sg mei ioatdma ipmi_devintf i2c_i801 mfd_core shpchp ipmi_msghandler wmi acpi_power_meter acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2 sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt igb fb_sys_fops ttm ahci ptp crc32c_intel libahci pps_core drm dca libata i2c_algo_bit i2c_core [last unloaded: opa_vnic] [66866.385551] CPU: 8 PID: 7470 Comm: rmmod Not tainted 4.14.0-mam-tid-rdma #2 [66866.393317] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0018.C4.072020161249 07/20/2016 [66866.405252] task: ffff88084f28c380 task.stack: ffffc90008454000 [66866.411866] RIP: 0010:hfi1_dbg_ibdev_exit+0x2a/0x80 [hfi1] [66866.417984] RSP: 0018:ffffc90008457da0 EFLAGS: 00010202 [66866.423812] RAX: 0000000000000000 RBX: ffff880857de0000 RCX: 0000000180040001 [66866.431773] RDX: 0000000180040002 RSI: ffffea0021088200 RDI: 0000000040000000 [66866.439734] RBP: ffffc90008457da8 R08: ffff88084220e000 R09: 0000000180040001 [66866.447696] R10: 000000004220e001 R11: ffff88084220e000 R12: ffff88085a31c000 [66866.455657] R13: ffffffffa07c9820 R14: ffffffffa07c9890 R15: ffff881059d78100 [66866.463618] FS: 00007f6876047740(0000) GS:ffff88085f800000(0000) knlGS:0000000000000000 [66866.472644] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [66866.479053] CR2: 0000000000000088 CR3: 0000000856357006 CR4: 00000000001606e0 [66866.487013] Call Trace: [66866.489747] remove_one+0x1f/0x220 [hfi1] [66866.494221] pci_device_remove+0x39/0xc0 [66866.498596] device_release_driver_internal+0x141/0x210 [66866.504424] driver_detach+0x3f/0x80 [66866.508409] bus_remove_driver+0x55/0xd0 [66866.512784] driver_unregister+0x2c/0x50 [66866.517164] pci_unregister_driver+0x2a/0xa0 [66866.521934] hfi1_mod_cleanup+0x10/0xaa2 [hfi1] [66866.526988] SyS_delete_module+0x171/0x250 [66866.531558] do_syscall_64+0x67/0x1b0 [66866.535644] entry_SYSCALL64_slow_path+0x25/0x25 [66866.540792] RIP: 0033:0x7f6875525c27 [66866.544777] RSP: 002b:00007ffd48528e78 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [66866.553224] RAX: ffffffffffffffda RBX: 0000000001cc01d0 RCX: 00007f6875525c27 [66866.561185] RDX: 00007f6875596000 RSI: 0000000000000800 RDI: 0000000001cc0238 [66866.569146] RBP: 0000000000000000 R08: 00007f68757e9060 R09: 00007f6875596000 [66866.577120] R10: 00007ffd48528c00 R11: 0000000000000206 R12: 00007ffd48529db4 [66866.585080] R13: 0000000000000000 R14: 0000000001cc01d0 R15: 0000000001cc0010 [66866.593040] Code: 90 0f 1f 44 00 00 48 83 3d a3 8b 03 00 00 55 48 89 e5 53 48 89 fb 74 4e 48 8d bf 18 0c 00 00 e8 9d f2 ff ff 48 8b 83 20 0c 00 00 <48> 8b b8 88 00 00 00 e8 2a 21 b3 e0 48 8b bb 20 0c 00 00 e8 0e [66866.614127] RIP: hfi1_dbg_ibdev_exit+0x2a/0x80 [hfi1] RSP: ffffc90008457da0 [66866.621885] CR2: 0000000000000088 [66866.625618] ---[ end trace c4817425783fb092 ]--- Fix by insuring that upon failure from fault_create_debugfs_attr() the parent pointer for the routines is always set to NULL and guards added in the exit routines to insure that debugfs_remove_recursive() is not called when when the parent pointer is NULL. Fixes: 0181ce31b260 ("IB/hfi1: Add receive fault injection feature") Cc: # 4.14.x Reviewed-by: Michael J. Ruhl Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit c32951862c1a32c978643fc3cc5d47cc70c33da4 Author: Max Gurtovoy Date: Thu May 31 11:05:23 2018 +0300 IB/isert: fix T10-pi check mask setting commit 0e12af84cdd3056460f928adc164f9e87f4b303b upstream. A copy/paste bug (probably) caused setting of an app_tag check mask in case where a ref_tag check was needed. Fixes: 38a2d0d429f1 ("IB/isert: convert to the generic RDMA READ/WRITE API") Fixes: 9e961ae73c2c ("IB/isert: Support T10-PI protected transactions") Cc: stable@vger.kernel.org Reviewed-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Reviewed-by: Martin K. Petersen Signed-off-by: Max Gurtovoy Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 7d4aaca8d0937ea5ff434f5a7039f27e163f476a Author: Alex Estrin Date: Tue May 15 18:31:39 2018 -0700 IB/isert: Fix for lib/dma_debug check_sync warning commit 763b69654bfb88ea3230d015e7d755ee8339f8ee upstream. The following error message occurs on a target host in a debug build during session login: [ 3524.411874] WARNING: CPU: 5 PID: 12063 at lib/dma-debug.c:1207 check_sync+0x4ec/0x5b0 [ 3524.421057] infiniband hfi1_0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x0000000000000000] [size=76 bytes] ......snip ..... [ 3524.535846] CPU: 5 PID: 12063 Comm: iscsi_np Kdump: loaded Not tainted 3.10.0-862.el7.x86_64.debug #1 [ 3524.546764] Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.2.6 06/08/2015 [ 3524.555740] Call Trace: [ 3524.559102] [] dump_stack+0x19/0x1b [ 3524.565477] [] __warn+0xd8/0x100 [ 3524.571557] [] warn_slowpath_fmt+0x5f/0x80 [ 3524.578610] [] check_sync+0x4ec/0x5b0 [ 3524.585177] [] ? set_cpus_allowed_ptr+0x5f/0x1c0 [ 3524.592812] [] debug_dma_sync_single_for_cpu+0x80/0x90 [ 3524.601029] [] ? x2apic_send_IPI_mask+0x13/0x20 [ 3524.608574] [] ? native_smp_send_reschedule+0x5b/0x80 [ 3524.616699] [] ? resched_curr+0xf6/0x140 [ 3524.623567] [] isert_create_send_desc.isra.26+0xe0/0x110 [ib_isert] [ 3524.633060] [] isert_put_login_tx+0x55/0x8b0 [ib_isert] [ 3524.641383] [] ? try_to_wake_up+0x1a4/0x430 [ 3524.648561] [] iscsi_target_do_tx_login_io+0xdd/0x230 [iscsi_target_mod] [ 3524.658557] [] iscsi_target_do_login+0x1a7/0x600 [iscsi_target_mod] [ 3524.668084] [] ? kstrdup+0x49/0x60 [ 3524.674420] [] iscsi_target_start_negotiation+0x56/0xc0 [iscsi_target_mod] [ 3524.684656] [] __iscsi_target_login_thread+0x90e/0x1070 [iscsi_target_mod] [ 3524.694901] [] ? __iscsi_target_login_thread+0x1070/0x1070 [iscsi_target_mod] [ 3524.705446] [] ? __iscsi_target_login_thread+0x1070/0x1070 [iscsi_target_mod] [ 3524.715976] [] iscsi_target_login_thread+0x28/0x60 [iscsi_target_mod] [ 3524.725739] [] kthread+0xef/0x100 [ 3524.732007] [] ? insert_kthread_work+0x80/0x80 [ 3524.739540] [] ret_from_fork_nospec_begin+0x21/0x21 [ 3524.747558] [] ? insert_kthread_work+0x80/0x80 [ 3524.755088] ---[ end trace 23f8bf9238bd1ed8 ]--- [ 3595.510822] iSCSI/iqn.1994-05.com.redhat:537fa56299: Unsupported SCSI Opcode 0xa3, sending CHECK_CONDITION. The code calls dma_sync on login_tx_desc->dma_addr prior to initializing it with dma-mapped address. login_tx_desc is a part of iser_conn structure and is used only once during login negotiation, so the issue is fixed by eliminating dma_sync call for this buffer using a special case routine. Cc: Reviewed-by: Mike Marciniszyn Reviewed-by: Don Dutile Signed-off-by: Alex Estrin Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit c06f8c2173b2c848b28c4cf2ee2e82c4f791c638 Author: Erez Shitrit Date: Mon May 21 11:41:01 2018 +0300 IB/mlx5: Fetch soft WQE's on fatal error state commit 7b74a83cf54a3747e22c57e25712bd70eef8acee upstream. On fatal error the driver simulates CQE's for ULPs that rely on completion of all their posted work-request. For the GSI traffic, the mlx5 has its own mechanism that sends the completions via software CQE's directly to the relevant CQ. This should be kept in fatal error too, so the driver should simulate such CQE's with the specified error state in order to complete GSI QP work requests. Without the fix the next deadlock might appears: schedule_timeout+0x274/0x350 wait_for_common+0xec/0x240 mcast_remove_one+0xd0/0x120 [ib_core] ib_unregister_device+0x12c/0x230 [ib_core] mlx5_ib_remove+0xc4/0x270 [mlx5_ib] mlx5_detach_device+0x184/0x1a0 [mlx5_core] mlx5_unload_one+0x308/0x340 [mlx5_core] mlx5_pci_err_detected+0x74/0xe0 [mlx5_core] Cc: # 4.7 Fixes: 89ea94a7b6c4 ("IB/mlx5: Reset flow support for IB kernel ULPs") Signed-off-by: Erez Shitrit Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 96fb9b88385f9b8b308cf2c8b050cd38ed038a59 Author: Jack Morgenstein Date: Wed May 23 15:30:30 2018 +0300 IB/core: Make testing MR flags for writability a static inline function commit 08bb558ac11ab944e0539e78619d7b4c356278bd upstream. Make the MR writability flags check, which is performed in umem.c, a static inline function in file ib_verbs.h This allows the function to be used by low-level infiniband drivers. Cc: Signed-off-by: Jason Gunthorpe Signed-off-by: Jack Morgenstein Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 1c82abc1b26ae3ce8c81f939e579b9e44452b81b Author: Jack Morgenstein Date: Wed May 23 15:30:31 2018 +0300 IB/mlx4: Mark user MR as writable if actual virtual memory is writable commit d8f9cc328c8888369880e2527e9186d745f2bbf6 upstream. To allow rereg_user_mr to modify the MR from read-only to writable without using get_user_pages again, we needed to define the initial MR as writable. However, this was originally done unconditionally, without taking into account the writability of the underlying virtual memory. As a result, any attempt to register a read-only MR over read-only virtual memory failed. To fix this, do not add the writable flag bit when the user virtual memory is not writable (e.g. const memory). However, when the underlying memory is NOT writable (and we therefore do not define the initial MR as writable), the IB core adds a "force writable" flag to its user-pages request. If this succeeds, the reg_user_mr caller gets a writable copy of the original pages. If the user-space caller then does a rereg_user_mr operation to enable writability, this will succeed. This should not be allowed, since the original virtual memory was not writable. Cc: Fixes: 9376932d0c26 ("IB/mlx4_ib: Add support for user MR re-registration") Signed-off-by: Jason Gunthorpe Signed-off-by: Jack Morgenstein Signed-off-by: Leon Romanovsky Signed-off-by: Greg Kroah-Hartman commit 49e1083214c68a151b9395388791061a8d0de710 Author: Alex Estrin Date: Wed May 2 06:43:15 2018 -0700 IB/{hfi1, qib}: Add handling of kernel restart commit 8d3e71136a080d007620472f50c7b3e63ba0f5cf upstream. A warm restart will fail to unload the driver, leaving link state potentially flapping up to the point the BIOS resets the adapter. Correct the issue by hooking the shutdown pci method, which will bring port down. Cc: # 4.9.x Reviewed-by: Mike Marciniszyn Signed-off-by: Alex Estrin Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit e884ed82995ad9d31b6fa93bbaa7870a584700dd Author: Mike Marciniszyn Date: Fri May 18 17:07:01 2018 -0700 IB/qib: Fix DMA api warning with debug kernel commit 0252f73334f9ef68868e4684200bea3565a4fcee upstream. The following error occurs in a debug build when running MPI PSM: [ 307.415911] WARNING: CPU: 4 PID: 23867 at lib/dma-debug.c:1158 check_unmap+0x4ee/0xa20 [ 307.455661] ib_qib 0000:05:00.0: DMA-API: device driver failed to check map error[device address=0x00000000df82b000] [size=4096 bytes] [mapped as page] [ 307.517494] Modules linked in: [ 307.531584] ib_isert iscsi_target_mod ib_srpt target_core_mod rpcrdma sunrpc ib_srp scsi_transport_srp scsi_tgt ib_iser libiscsi ib_ipoib scsi_transport_iscsi rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_qib intel_powerclamp coretemp rdmavt intel_rapl iosf_mbi kvm_intel kvm irqbypass crc32_pclmul ghash_clmulni_intel ipmi_ssif ib_core aesni_intel sg ipmi_si lrw gf128mul dca glue_helper ipmi_devintf iTCO_wdt gpio_ich hpwdt iTCO_vendor_support ablk_helper hpilo acpi_power_meter cryptd ipmi_msghandler ie31200_edac shpchp pcc_cpufreq lpc_ich pcspkr ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ahci crct10dif_pclmul crct10dif_common drm crc32c_intel libahci tg3 libata serio_raw ptp i2c_core [ 307.846113] pps_core dm_mirror dm_region_hash dm_log dm_mod [ 307.866505] CPU: 4 PID: 23867 Comm: mpitests-IMB-MP Kdump: loaded Not tainted 3.10.0-862.el7.x86_64.debug #1 [ 307.911178] Hardware name: HP ProLiant DL320e Gen8, BIOS J05 11/09/2013 [ 307.944206] Call Trace: [ 307.956973] [] dump_stack+0x19/0x1b [ 307.982201] [] __warn+0xd8/0x100 [ 308.005999] [] warn_slowpath_fmt+0x5f/0x80 [ 308.034260] [] check_unmap+0x4ee/0xa20 [ 308.060801] [] ? page_add_file_rmap+0x2a/0x1d0 [ 308.090689] [] debug_dma_unmap_page+0x9d/0xb0 [ 308.120155] [] ? might_fault+0xa0/0xb0 [ 308.146656] [] qib_tid_free.isra.14+0x215/0x2a0 [ib_qib] [ 308.180739] [] qib_write+0x894/0x1280 [ib_qib] [ 308.210733] [] ? __inode_security_revalidate+0x70/0x80 [ 308.244837] [] ? security_file_permission+0x27/0xb0 [ 308.266025] qib_ib0.8006: multicast join failed for ff12:401b:8006:0000:0000:0000:ffff:ffff, status -22 [ 308.323421] [] vfs_write+0xc3/0x1f0 [ 308.347077] [] ? fget_light+0xfc/0x510 [ 308.372533] [] SyS_write+0x8a/0x100 [ 308.396456] [] system_call_fastpath+0x1c/0x21 The code calls a qib_map_page() which has never correctly tested for a mapping error. Fix by testing for pci_dma_mapping_error() in all cases and properly handling the failure in the caller. Additionally, streamline qib_map_page() arguments to satisfy just the single caller. Cc: Reviewed-by: Alex Estrin Tested-by: Don Dutile Reviewed-by: Don Dutile Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Greg Kroah-Hartman commit c41cb9cb5611747d64c3d569c1e9937f3d90e965 Author: Tadeusz Struk Date: Tue May 22 14:37:18 2018 -0700 tpm: fix race condition in tpm_common_write() commit 3ab2011ea368ec3433ad49e1b9e1c7b70d2e65df upstream. There is a race condition in tpm_common_write function allowing two threads on the same /dev/tpm, or two different applications on the same /dev/tpmrm to overwrite each other commands/responses. Fixed this by taking the priv->buffer_mutex early in the function. Also converted the priv->data_pending from atomic to a regular size_t type. There is no need for it to be atomic since it is only touched under the protection of the priv->buffer_mutex. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Tadeusz Struk Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 1bf1a5e21798518fd6a025c6e0c0168955f5e8e6 Author: Tadeusz Struk Date: Wed May 9 11:55:35 2018 -0700 tpm: fix use after free in tpm2_load_context() commit 8c81c24758ffbf17cf06c6835d361ffa57be2f0e upstream. If load context command returns with TPM2_RC_HANDLE or TPM2_RC_REFERENCE_H0 then we have use after free in line 114 and double free in 117. Fixes: 4d57856a21ed2 ("tpm2: add session handle context saving and restoring to the space code") Cc: stable@vger.kernel.org Signed-off-by: Tadeusz Struk Reviewed-by: Jarkko Sakkinen Signed-off--by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 1ed6871464b813c9fbdfac6878ce96af7725f614 Author: Srinivas Kandagatla Date: Mon Jun 4 15:14:08 2018 +0100 of: platform: stop accessing invalid dev in of_platform_device_destroy commit 522811e944ed9b36806faa019faec10f9d259cca upstream. Immediately after the platform_device_unregister() the device will be cleaned up. Accessing the freed pointer immediately after that will crash the system. Found this bug when kernel is built with CONFIG_PAGE_POISONING and testing loading/unloading audio drivers in a loop on Qcom platforms. Fix this by moving of_node_clear_flag() just before the unregister calls. Below is the crash trace: Unable to handle kernel paging request at virtual address 6b6b6b6b6b6c03 Mem abort info: ESR = 0x96000021 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000021 CM = 0, WnR = 0 [006b6b6b6b6b6c03] address between user and kernel address ranges Internal error: Oops: 96000021 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 1784 Comm: sh Tainted: G W 4.17.0-rc7-02230-ge3a63a7ef641-dirty #204 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) pstate: 80000005 (Nzcv daif -PAN -UAO) pc : clear_bit+0x18/0x2c lr : of_platform_device_destroy+0x64/0xb8 sp : ffff00000c9c3930 x29: ffff00000c9c3930 x28: ffff80003d39b200 x27: ffff000008bb1000 x26: 0000000000000040 x25: 0000000000000124 x24: ffff80003a9a3080 x23: 0000000000000060 x22: ffff00000939f518 x21: ffff80003aa79e98 x20: ffff80003aa3dae0 x19: ffff80003aa3c890 x18: ffff800009feb794 x17: 0000000000000000 x16: 0000000000000000 x15: ffff800009feb790 x14: 0000000000000000 x13: ffff80003a058778 x12: ffff80003a058728 x11: ffff80003a058750 x10: 0000000000000000 x9 : 0000000000000006 x8 : ffff80003a825988 x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000008 x2 : 0000000000000001 x1 : 6b6b6b6b6b6b6c03 x0 : 0000000000000000 Process sh (pid: 1784, stack limit = 0x (ptrval)) Call trace: clear_bit+0x18/0x2c q6afe_remove+0x20/0x38 apr_device_remove+0x30/0x70 device_release_driver_internal+0x170/0x208 device_release_driver+0x14/0x20 bus_remove_device+0xcc/0x150 device_del+0x10c/0x310 device_unregister+0x1c/0x70 apr_remove_device+0xc/0x18 device_for_each_child+0x50/0x80 apr_remove+0x18/0x20 rpmsg_dev_remove+0x38/0x68 device_release_driver_internal+0x170/0x208 device_release_driver+0x14/0x20 bus_remove_device+0xcc/0x150 device_del+0x10c/0x310 device_unregister+0x1c/0x70 qcom_smd_remove_device+0xc/0x18 device_for_each_child+0x50/0x80 qcom_smd_unregister_edge+0x3c/0x70 smd_subdev_remove+0x18/0x28 rproc_stop+0x48/0xd8 rproc_shutdown+0x60/0xe8 state_store+0xbc/0xf8 dev_attr_store+0x18/0x28 sysfs_kf_write+0x3c/0x50 kernfs_fop_write+0x118/0x1e0 __vfs_write+0x18/0x110 vfs_write+0xa4/0x1a8 ksys_write+0x48/0xb0 sys_write+0xc/0x18 el0_svc_naked+0x30/0x34 Code: d2800022 8b400c21 f9800031 9ac32043 (c85f7c22) ---[ end trace 32020935775616a2 ]--- Signed-off-by: Srinivas Kandagatla Cc: stable@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 6ba51909693c7bf8c463b9c90f7f8726b710fe42 Author: Stefan M Schaeckeler Date: Mon May 21 16:26:14 2018 -0700 of: unittest: for strings, account for trailing \0 in property length field commit 3b9cf7905fe3ab35ab437b5072c883e609d3498d upstream. For strings, account for trailing \0 in property length field: This is consistent with how dtc builds string properties. Function __of_prop_dup() would misbehave on such properties as it duplicates properties based on the property length field creating new string values without trailing \0s. Signed-off-by: Stefan M Schaeckeler Reviewed-by: Frank Rowand Tested-by: Frank Rowand Cc: Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 4910cc250b4dab82b42a743377d359abaee07b73 Author: Frank Rowand Date: Wed May 16 21:19:51 2018 -0700 of: overlay: validate offset from property fixups commit 482137bf2aecd887ebfa8756456764a2f6a0e545 upstream. The smatch static checker marks the data in offset as untrusted, leading it to warn: drivers/of/resolver.c:125 update_usages_of_a_phandle_reference() error: buffer underflow 'prop->value' 's32min-s32max' Add check to verify that offset is within the property data. Reported-by: Dan Carpenter Signed-off-by: Frank Rowand Cc: Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman commit 728ea2302acc19cd83164b38408fd5f84e5153b2 Author: Jerome Brunet Date: Thu Apr 26 12:50:46 2018 +0200 ARM64: dts: meson: disable sd-uhs modes on the libretech-cc commit d5b4885b1dff72ac670b518cfeaac719d768bd4d upstream. There is a problem with the sd-uhs mode when doing a soft reboot. Switching back from 1.8v to 3.3v messes with the card, which no longer respond (timeout errors). According to the specification, we should perform a card reset (power cycling the card) but this is something we cannot control on this design. Then the only solution to restore the communication with the card is an "unplug-plug" which is not acceptable Until we find a solution, if any, disable the sd-uhs modes on this design. For the people using uhs at the moment, there will a performance drop as a result. Fixes: 3cde63ebc85c ("ARM64: dts: meson-gxl: libretech-cc: enable high speed modes") Signed-off-by: Jerome Brunet Cc: stable@vger.kernel.org Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit 64df84dcf1e4dd3b63c60dd6f36473d19060af48 Author: Will Deacon Date: Fri Jun 22 16:23:45 2018 +0100 arm64: mm: Ensure writes to swapper are ordered wrt subsequent cache maintenance commit 71c8fc0c96abf8e53e74ed4d891d671e585f9076 upstream. When rewriting swapper using nG mappings, we must performance cache maintenance around each page table access in order to avoid coherency problems with the host's cacheable alias under KVM. To ensure correct ordering of the maintenance with respect to Device memory accesses made with the Stage-1 MMU disabled, DMBs need to be added between the maintenance and the corresponding memory access. This patch adds a missing DMB between writing a new page table entry and performing a clean+invalidate on the same line. Fixes: f992b4dfd58b ("arm64: kpti: Add ->enable callback to remap swapper using nG mappings") Cc: # 4.16.x- Acked-by: Mark Rutland Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit ee6ae5ac75abf889e89c7ad3cdb75bb15d0a6308 Author: Will Deacon Date: Fri Jun 22 10:25:25 2018 +0100 arm64: kpti: Use early_param for kpti= command-line option commit b5b7dd647f2d21b93f734ce890671cd908e69b0a upstream. We inspect __kpti_forced early on as part of the cpufeature enable callback which remaps the swapper page table using non-global entries. Ensure that __kpti_forced has been updated to reflect the kpti= command-line option before we start using it. Fixes: ea1e3de85e94 ("arm64: entry: Add fake CPU feature for unmapping the kernel at EL0") Cc: # 4.16.x- Reported-by: Wei Xu Tested-by: Sudeep Holla Tested-by: Wei Xu Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit cdfa28c29ad4b5933c84ac13293739040fa1a3e9 Author: Dave Martin Date: Thu Jun 7 12:32:05 2018 +0100 arm64: Fix syscall restarting around signal suppressed by tracer commit 0fe42512b2f03f9e5a20b9f55ef1013a68b4cd48 upstream. Commit 17c2895 ("arm64: Abstract syscallno manipulation") abstracts out the pt_regs.syscallno value for a syscall cancelled by a tracer as NO_SYSCALL, and provides helpers to set and check for this condition. However, the way this was implemented has the unintended side-effect of disabling part of the syscall restart logic. This comes about because the second in_syscall() check in do_signal() re-evaluates the "in a syscall" condition based on the updated pt_regs instead of the original pt_regs. forget_syscall() is explicitly called prior to the second check in order to prevent restart logic in the ret_to_user path being spuriously triggered, which means that the second in_syscall() check always yields false. This triggers a failure in tools/testing/selftests/seccomp/seccomp_bpf.c, when using ptrace to suppress a signal that interrups a nanosleep() syscall. Misbehaviour of this type is only expected in the case where a tracer suppresses a signal and the target process is either being single-stepped or the interrupted syscall attempts to restart via -ERESTARTBLOCK. This patch restores the old behaviour by performing the in_syscall() check only once at the start of the function. Fixes: 17c289586009 ("arm64: Abstract syscallno manipulation") Signed-off-by: Dave Martin Reported-by: Sumit Semwal Cc: Will Deacon Cc: # 4.14.x- Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 14ca7d344e271c89858858abb3757642bc4c7a76 Author: Dinh Nguyen Date: Mon May 14 10:15:19 2018 -0500 ARM: dts: socfpga: Fix NAND controller node compatible for Arria10 commit 3877ef7a1ccecaae378c497e1dcddbc2dccb664c upstream. The NAND compatible "denali,denal-nand-dt" property has never been used and is obsolete. Remove it. Cc: stable@vger.kernel.org Fixes: f549af06e9b6("ARM: dts: socfpga: Add NAND device tree for Arria10") Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit ae6647c78ff831380851869344161f460896892a Author: Marek Vasut Date: Thu May 10 16:37:26 2018 +0200 ARM: dts: socfpga: Fix NAND controller clock supply commit 4eda9b766b042ea38d84df91581b03f6145a2ab0 upstream. The Denali NAND x-clock should be supplied by nand_x_clk, not by nand_clk. Fix this, otherwise the Denali driver gets incorrect clock frequency information and incorrectly configures the NAND timing. Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Fixes: d837a80d19 ("ARM: dts: socfpga: add nand controller nodes") Cc: Steffen Trumtrar Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 3482130d8d1e60b5b08ed09874dbfafa9908df98 Author: Marek Vasut Date: Thu May 10 14:52:23 2018 +0200 ARM: dts: socfpga: Fix NAND controller node compatible commit d9a695f3c8098ac9684689774a151cff30d8aa25 upstream. The compatible string for the Denali NAND controller is incorrect, fix it by replacing it with one matching the DT bindings and the driver. Cc: stable@vger.kernel.org Signed-off-by: Marek Vasut Fixes: d837a80d19 ("ARM: dts: socfpga: add nand controller nodes") Cc: Steffen Trumtrar Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit 3db24d2e192f1ccf1723550184e38f94d173e8ab Author: Thor Thayer Date: Fri Jun 22 13:37:34 2018 -0500 ARM: dts: Fix SPI node for Arria10 commit 975ba94c2c3aca4d9f1ae26f3916d7787495ce86 upstream. Remove the unused bus-num node and change num-chipselect to num-cs to match SPI bindings. Cc: stable@vger.kernel.org Fixes: f2d6f8f817814 ("ARM: dts: socfpga: Add SPI Master1 for Arria10 SR chip") Signed-off-by: Thor Thayer Signed-off-by: Dinh Nguyen Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit eda170a9fe51284303f4999957e57e1c4b3c9ff3 Author: David Rivshin Date: Wed Apr 25 21:15:01 2018 +0100 ARM: 8764/1: kgdb: fix NUMREGBYTES so that gdb_regs[] is the correct size commit 76ed0b803a2ab793a1b27d1dfe0de7955282cd34 upstream. NUMREGBYTES (which is used as the size for gdb_regs[]) is incorrectly based on DBG_MAX_REG_NUM instead of GDB_MAX_REGS. DBG_MAX_REG_NUM is the number of total registers, while GDB_MAX_REGS is the number of 'unsigned longs' it takes to serialize those registers. Since FP registers require 3 'unsigned longs' each, DBG_MAX_REG_NUM is smaller than GDB_MAX_REGS. This causes GDB 8.0 give the following error on connect: "Truncated register 19 in remote 'g' packet" This also causes the register serialization/deserialization logic to overflow gdb_regs[], overwriting whatever follows. Fixes: 834b2964b7ab ("kgdb,arm: fix register dump") Cc: # 2.6.37+ Signed-off-by: David Rivshin Acked-by: Rabin Vincent Tested-by: Daniel Thompson Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit c9debbd1a5b84014d8651da82ca30651d83ca322 Author: Vaibhav Jain Date: Fri May 18 15:12:23 2018 +0530 cxl: Disable prefault_mode in Radix mode commit b6c84ba22ff3a198eb8d5552cf9b8fda1d792e54 upstream. Currently we see a kernel-oops reported on Power-9 while attaching a context to an AFU, with radix-mode and sysfs attr 'prefault_mode' set to anything other than 'none'. The backtrace of the oops is of this form: Unable to handle kernel paging request for data at address 0x00000080 Faulting instruction address: 0xc00800000bcf3b20 cpu 0x1: Vector: 300 (Data Access) at [c00000037f003800] pc: c00800000bcf3b20: cxl_load_segment+0x178/0x290 [cxl] lr: c00800000bcf39f0: cxl_load_segment+0x48/0x290 [cxl] sp: c00000037f003a80 msr: 9000000000009033 dar: 80 dsisr: 40000000 current = 0xc00000037f280000 paca = 0xc0000003ffffe600 softe: 3 irq_happened: 0x01 pid = 3529, comm = afp_no_int cxl_prefault+0xfc/0x248 [cxl] process_element_entry_psl9+0xd8/0x1a0 [cxl] cxl_attach_dedicated_process_psl9+0x44/0x130 [cxl] native_attach_process+0xc0/0x130 [cxl] afu_ioctl+0x3f4/0x5e0 [cxl] do_vfs_ioctl+0xdc/0x890 ksys_ioctl+0x68/0xf0 sys_ioctl+0x40/0xa0 system_call+0x58/0x6c The issue is caused as on Power-8 the AFU attr 'prefault_mode' was used to improve initial storage fault performance by prefaulting process segments. However on Power-9 with radix mode we don't have Storage-Segments that we can prefault. Also prefaulting process Pages will be too costly and fine-grained. Hence, since the prefaulting mechanism doesn't makes sense of radix-mode, this patch updates prefault_mode_store() to not allow any other value apart from CXL_PREFAULT_NONE when radix mode is enabled. Fixes: f24be42aab37 ("cxl: Add psl9 specific code") Cc: stable@vger.kernel.org # v4.12+ Signed-off-by: Vaibhav Jain Acked-by: Frederic Barrat Acked-by: Andrew Donnellan Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 971a55574b4789c64d43c6d34f5549c337567731 Author: Finley Xiao Date: Mon May 14 11:29:38 2018 +0800 soc: rockchip: power-domain: Fix wrong value when power up pd with writemask commit 9e59c5f66c624b43c766a9fe3b2430e0e976bf0e upstream. Solve the pd could only ever turn off but never turn them on again, if the pd registers have the writemask bits. So far this affects the rk3328 only. Fixes: 79bb17ce8edb ("soc: rockchip: power-domain: Support domain control in hiword-registers") Cc: stable@vger.kernel.org Signed-off-by: Finley Xiao Signed-off-by: Elaine Zhang Reviewed-by: Ulf Hansson Signed-off-by: Heiko Stuebner Signed-off-by: Greg Kroah-Hartman commit 56fbab60aa47c64898c3d18540322c317ada32ef Author: Mahesh Salgaonkar Date: Fri Apr 27 11:53:18 2018 +0530 powerpc/fadump: Unregister fadump on kexec down path. commit 722cde76d68e8cc4f3de42e71c82fd40dea4f7b9 upstream. Unregister fadump on kexec down path otherwise the fadump registration in new kexec-ed kernel complains that fadump is already registered. This makes new kernel to continue using fadump registered by previous kernel which may lead to invalid vmcore generation. Hence this patch fixes this issue by un-registering fadump in fadump_cleanup() which is called during kexec path so that new kernel can register fadump with new valid values. Fixes: b500afff11f6 ("fadump: Invalidate registration and release reserved memory for general use.") Cc: stable@vger.kernel.org # v3.4+ Signed-off-by: Mahesh Salgaonkar Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 3b185e667b5222f170a337d57ca338fd2f66f828 Author: Gautham R. Shenoy Date: Thu May 31 17:45:09 2018 +0530 cpuidle: powernv: Fix promotion from snooze if next state disabled commit 0a4ec6aa035a52c422eceb2ed51ed88392a3d6c2 upstream. The commit 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state") introduced a timeout for the snooze idle state so that it could be eventually be promoted to a deeper idle state. The snooze timeout value is static and set to the target residency of the next idle state, which would train the cpuidle governor to pick the next idle state eventually. The unfortunate side-effect of this is that if the next idle state(s) is disabled, the CPU will forever remain in snooze, despite the fact that the system is completely idle, and other deeper idle states are available. This patch fixes the issue by dynamically setting the snooze timeout to the target residency of the next enabled state on the device. Before Patch: POWER8 : Only nap disabled. $ cpupower monitor sleep 30 sleep took 30.01297 seconds and exited with status 0 |Idle_Stats PKG |CORE|CPU | snoo | Nap | Fast 0| 8| 0| 96.41| 0.00| 0.00 0| 8| 1| 96.43| 0.00| 0.00 0| 8| 2| 96.47| 0.00| 0.00 0| 8| 3| 96.35| 0.00| 0.00 0| 8| 4| 96.37| 0.00| 0.00 0| 8| 5| 96.37| 0.00| 0.00 0| 8| 6| 96.47| 0.00| 0.00 0| 8| 7| 96.47| 0.00| 0.00 POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1, stop2) disabled: $ cpupower monitor sleep 30 sleep took 30.05033 seconds and exited with status 0 |Idle_Stats PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop 0| 16| 0| 89.79| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00 0| 16| 1| 90.12| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00 0| 16| 2| 90.21| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00 0| 16| 3| 90.29| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00 After Patch: POWER8 : Only nap disabled. $ cpupower monitor sleep 30 sleep took 30.01200 seconds and exited with status 0 |Idle_Stats PKG |CORE|CPU | snoo | Nap | Fast 0| 8| 0| 16.58| 0.00| 77.21 0| 8| 1| 18.42| 0.00| 75.38 0| 8| 2| 4.70| 0.00| 94.09 0| 8| 3| 17.06| 0.00| 81.73 0| 8| 4| 3.06| 0.00| 95.73 0| 8| 5| 7.00| 0.00| 96.80 0| 8| 6| 1.00| 0.00| 98.79 0| 8| 7| 5.62| 0.00| 94.17 POWER9: Shallow states (stop0lite, stop1lite, stop2lite, stop0, stop1, stop2) disabled: $ cpupower monitor sleep 30 sleep took 30.02110 seconds and exited with status 0 |Idle_Stats PKG |CORE|CPU | snoo | stop | stop | stop | stop | stop | stop | stop | stop 0| 0| 0| 0.69| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 9.39| 89.70 0| 0| 1| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.05| 93.21 0| 0| 2| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 89.93 0| 0| 3| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 0.00| 93.26 Fixes: 78eaa10f027c ("cpuidle: powernv/pseries: Auto-promotion of snooze to deeper idle state") Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: Gautham R. Shenoy Reviewed-by: Balbir Singh Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit a5d49dfb20c943d6b9b49bdca3142795db2c55ef Author: Akshay Adiga Date: Wed May 16 17:32:14 2018 +0530 powerpc/powernv/cpuidle: Init all present cpus for deep states commit ac9816dcbab53c57bcf1d7b15370b08f1e284318 upstream. Init all present cpus for deep states instead of "all possible" cpus. Init fails if a possible cpu is guarded. Resulting in making only non-deep states available for cpuidle/hotplug. Stewart says, this means that for single threaded workloads, if you guard out a CPU core you'll not get WoF (Workload Optimised Frequency), which means that performance goes down when you wouldn't expect it to. Fixes: 77b54e9f213f ("powernv/powerpc: Add winkle support for offline cpus") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: Akshay Adiga Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 134e70c22eb0a47dcb30f20859f331344b5018db Author: Haren Myneni Date: Mon Jun 4 18:33:38 2018 +1000 powerpc/powernv: copy/paste - Mask SO bit in CR commit 75743649064ec0cf5ddd69f240ef23af66dde16e upstream. NX can set the 3rd bit in CR register for XER[SO] (Summary overflow) which is not related to paste request. The current paste function returns failure for a successful request when this bit is set. So mask this bit and check the proper return status. Fixes: 2392c8c8c045 ("powerpc/powernv/vas: Define copy/paste interfaces") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Haren Myneni Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 0e8bb91c6dd6a77c60279c4fd83975ef257ed3c2 Author: Alexey Kardashevskiy Date: Wed May 30 19:22:50 2018 +1000 powerpc/powernv/ioda2: Remove redundant free of TCE pages commit 98fd72fe82527fd26618062b60cfd329451f2329 upstream. When IODA2 creates a PE, it creates an IOMMU table with it_ops::free set to pnv_ioda2_table_free() which calls pnv_pci_ioda2_table_free_pages(). Since iommu_tce_table_put() calls it_ops::free when the last reference to the table is released, explicit call to pnv_pci_ioda2_table_free_pages() is not needed so let's remove it. This should fix double free in the case of PCI hotuplug as pnv_pci_ioda2_table_free_pages() does not reset neither iommu_table::it_base nor ::it_size. This was not exposed by SRIOV as it uses different code path via pnv_pcibios_sriov_disable(). IODA1 does not inialize it_ops::free so it does not have this issue. Fixes: c5f7700bbd2e ("powerpc/powernv: Dynamically release PE") Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 919c9b8187bc8aa66388e50248c7f6c5b0c87e97 Author: Michael Neuling Date: Thu May 17 15:37:14 2018 +1000 powerpc/ptrace: Fix enforcement of DAWR constraints commit cd6ef7eebf171bfcba7dc2df719c2a4958775040 upstream. Back when we first introduced the DAWR, in commit 4ae7ebe9522a ("powerpc: Change hardware breakpoint to allow longer ranges"), we screwed up the constraint making it a 1024 byte boundary rather than a 512. This makes the check overly permissive. Fortunately GDB is the only real user and it always did they right thing, so we never noticed. This fixes the constraint to 512 bytes. Fixes: 4ae7ebe9522a ("powerpc: Change hardware breakpoint to allow longer ranges") Cc: stable@vger.kernel.org # v3.9+ Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 1ab9092356a13ab26cf28f35943571bb35d5d875 Author: Anju T Sudhakar Date: Wed May 16 12:05:18 2018 +0530 powerpc/perf: Fix memory allocation for core-imc based on num_possible_cpus() commit d2032678e57fc508d7878307badde8f89b632ba3 upstream. Currently memory is allocated for core-imc based on cpu_present_mask, which has bit 'cpu' set iff cpu is populated. We use (cpu number / threads per core) as the array index to access the memory. Under some circumstances firmware marks a CPU as GUARDed CPU and boot the system, until cleared of errors, these CPU's are unavailable for all subsequent boots. GUARDed CPUs are possible but not present from linux view, so it blows a hole when we assume the max length of our allocation is driven by our max present cpus, where as one of the cpus might be online and be beyond the max present cpus, due to the hole. So (cpu number / threads per core) value bounds the array index and leads to memory overflow. Call trace observed during a guard test: Faulting instruction address: 0xc000000000149f1c cpu 0x69: Vector: 380 (Data Access Out of Range) at [c000003fea303420] pc:c000000000149f1c: prefetch_freepointer+0x14/0x30 lr:c00000000014e0f8: __kmalloc+0x1a8/0x1ac sp:c000003fea3036a0 msr:9000000000009033 dar:c9c54b2c91dbf6b7 current = 0xc000003fea2c0000 paca = 0xc00000000fddd880 softe: 3 irq_happened: 0x01 pid = 1, comm = swapper/104 Linux version 4.16.7-openpower1 (smc@smc-desktop) (gcc version 6.4.0 (Buildroot 2018.02.1-00006-ga8d1126)) #2 SMP Fri May 4 16:44:54 PDT 2018 enter ? for help call trace: __kmalloc+0x1a8/0x1ac (unreliable) init_imc_pmu+0x7f4/0xbf0 opal_imc_counters_probe+0x3fc/0x43c platform_drv_probe+0x48/0x80 driver_probe_device+0x22c/0x308 __driver_attach+0xa0/0xd8 bus_for_each_dev+0x88/0xb4 driver_attach+0x2c/0x40 bus_add_driver+0x1e8/0x228 driver_register+0xd0/0x114 __platform_driver_register+0x50/0x64 opal_imc_driver_init+0x24/0x38 do_one_initcall+0x150/0x15c kernel_init_freeable+0x250/0x254 kernel_init+0x1c/0x150 ret_from_kernel_thread+0x5c/0xc8 Allocating memory for core-imc based on cpu_possible_mask, which has bit 'cpu' set iff cpu is populatable, will fix this issue. Reported-by: Pridhiviraj Paidipeddi Signed-off-by: Anju T Sudhakar Reviewed-by: Balbir Singh Tested-by: Pridhiviraj Paidipeddi Fixes: 39a846db1d57 ("powerpc/perf: Add core IMC PMU support") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit c12d24161611e6038631778e614581edc4647eb6 Author: Michael Neuling Date: Thu May 17 15:37:15 2018 +1000 powerpc/ptrace: Fix setting 512B aligned breakpoints with PTRACE_SET_DEBUGREG commit 4f7c06e26ec9cf7fe9f0c54dc90079b6a4f4b2c3 upstream. In commit e2a800beaca1 ("powerpc/hw_brk: Fix off by one error when validating DAWR region end") we fixed setting the DAWR end point to its max value via PPC_PTRACE_SETHWDEBUG. Unfortunately we broke PTRACE_SET_DEBUGREG when setting a 512 byte aligned breakpoint. PTRACE_SET_DEBUGREG currently sets the length of the breakpoint to zero (memset() in hw_breakpoint_init()). This worked with arch_validate_hwbkpt_settings() before the above patch was applied but is now broken if the breakpoint is 512byte aligned. This sets the length of the breakpoint to 8 bytes when using PTRACE_SET_DEBUGREG. Fixes: e2a800beaca1 ("powerpc/hw_brk: Fix off by one error when validating DAWR region end") Cc: stable@vger.kernel.org # v3.11+ Signed-off-by: Michael Neuling Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 5fefd9a5d97a45bc2927acc0aa53a098e80a4d41 Author: Aneesh Kumar K.V Date: Wed May 30 18:48:04 2018 +0530 powerpc/mm/hash: Add missing isync prior to kernel stack SLB switch commit 91d06971881f71d945910de128658038513d1b24 upstream. Currently we do not have an isync, or any other context synchronizing instruction prior to the slbie/slbmte in _switch() that updates the SLB entry for the kernel stack. However that is not correct as outlined in the ISA. From Power ISA Version 3.0B, Book III, Chapter 11, page 1133: "Changing the contents of ... the contents of SLB entries ... can have the side effect of altering the context in which data addresses and instruction addresses are interpreted, and in which instructions are executed and data accesses are performed. ... These side effects need not occur in program order, and therefore may require explicit synchronization by software. ... The synchronizing instruction before the context-altering instruction ensures that all instructions up to and including that synchronizing instruction are fetched and executed in the context that existed before the alteration." And page 1136: "For data accesses, the context synchronizing instruction before the slbie, slbieg, slbia, slbmte, tlbie, or tlbiel instruction ensures that all preceding instructions that access data storage have completed to a point at which they have reported all exceptions they will cause." We're not aware of any bugs caused by this, but it should be fixed regardless. Add the missing isync when updating kernel stack SLB entry. Cc: stable@vger.kernel.org Signed-off-by: Aneesh Kumar K.V [mpe: Flesh out change log with more ISA text & explanation] Signed-off-by: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 69829f749a432eeb1c208b113bfec598a23ee823 Author: Miklos Szeredi Date: Thu May 31 12:26:10 2018 +0200 fuse: fix control dir setup and teardown commit 6becdb601bae2a043d7fb9762c4d48699528ea6e upstream. syzbot is reporting NULL pointer dereference at fuse_ctl_remove_conn() [1]. Since fc->ctl_ndents is incremented by fuse_ctl_add_conn() when new_inode() failed, fuse_ctl_remove_conn() reaches an inode-less dentry and tries to clear d_inode(dentry)->i_private field. Fix by only adding the dentry to the array after being fully set up. When tearing down the control directory, do d_invalidate() on it to get rid of any mounts that might have been added. [1] https://syzkaller.appspot.com/bug?id=f396d863067238959c91c0b7cfc10b163638cac6 Reported-by: syzbot Fixes: bafa96541b25 ("[PATCH] fuse: add control filesystem") Cc: # v2.6.18 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 3a37d85a90dafb4986dbfc356c6d662f0db665a8 Author: Tetsuo Handa Date: Tue May 1 13:12:14 2018 +0900 fuse: don't keep dead fuse_conn at fuse_fill_super(). commit 543b8f8662fe6d21f19958b666ab0051af9db21a upstream. syzbot is reporting use-after-free at fuse_kill_sb_blk() [1]. Since sb->s_fs_info field is not cleared after fc was released by fuse_conn_put() when initialization failed, fuse_kill_sb_blk() finds already released fc and tries to hold the lock. Fix this by clearing sb->s_fs_info field after calling fuse_conn_put(). [1] https://syzkaller.appspot.com/bug?id=a07a680ed0a9290585ca424546860464dd9658db Signed-off-by: Tetsuo Handa Reported-by: syzbot Fixes: 3b463ae0c626 ("fuse: invalidation reverse calls") Cc: John Muir Cc: Csaba Henk Cc: Anand Avati Cc: # v2.6.31 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 2f7bf369b5f8699231398aef585cb680828f3ac9 Author: Miklos Szeredi Date: Thu Feb 8 15:17:38 2018 +0100 fuse: atomic_o_trunc should truncate pagecache commit df0e91d488276086bc07da2e389986cae0048c37 upstream. Fuse has an "atomic_o_trunc" mode, where userspace filesystem uses the O_TRUNC flag in the OPEN request to truncate the file atomically with the open. In this mode there's no need to send a SETATTR request to userspace after the open, so fuse_do_setattr() checks this mode and returns. But this misses the important step of truncating the pagecache. Add the missing parts of truncation to the ATTR_OPEN branch. Reported-by: Chad Austin Fixes: 6ff958edbf39 ("fuse: add atomic open+truncate support") Signed-off-by: Miklos Szeredi Cc: Signed-off-by: Greg Kroah-Hartman commit 02832578eb9d4572a3194e50e5d2268ff049f9f4 Author: Tejun Heo Date: Fri Feb 2 09:54:14 2018 -0800 fuse: fix congested state leak on aborted connections commit 8a301eb16d99983a4961f884690ec97b92e7dcfe upstream. If a connection gets aborted while congested, FUSE can leave nr_wb_congested[] stuck until reboot causing wait_iff_congested() to wait spuriously which can lead to severe performance degradation. The leak is caused by gating congestion state clearing with fc->connected test in request_end(). This was added way back in 2009 by 26c3679101db ("fuse: destroy bdi on umount"). While the commit description doesn't explain why the test was added, it most likely was to avoid dereferencing bdi after it got destroyed. Since then, bdi lifetime rules have changed many times and now we're always guaranteed to have access to the bdi while the superblock is alive (fc->sb). Drop fc->connected conditional to avoid leaking congestion states. Signed-off-by: Tejun Heo Reported-by: Joshua Miller Cc: Johannes Weiner Cc: stable@vger.kernel.org # v2.6.29+ Acked-by: Jan Kara Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit a47c3c48769ab1e41f1dd53aa116a89f1f208aa1 Author: Tetsuo Handa Date: Fri May 11 19:54:19 2018 +0900 printk: fix possible reuse of va_list variable commit 988a35f8da1dec5a8cd2788054d1e717be61bf25 upstream. I noticed that there is a possibility that printk_safe_log_store() causes kernel oops because "args" parameter is passed to vsnprintf() again when atomic_cmpxchg() detected that we raced. Fix this by using va_copy(). Link: http://lkml.kernel.org/r/201805112002.GIF21216.OFVHFOMLJtQFSO@I-love.SAKURA.ne.jp Cc: Peter Zijlstra Cc: Steven Rostedt Cc: dvyukov@google.com Cc: syzkaller@googlegroups.com Cc: fengguang.wu@intel.com Cc: linux-kernel@vger.kernel.org Signed-off-by: Tetsuo Handa Fixes: 42a0bb3f71383b45 ("printk/nmi: generic solution for safe printk in NMI") Cc: 4.7+ # v4.7+ Reviewed-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit affd84024cbedfc0ee091396d064fbf1366ea8fe Author: Amit Pundir Date: Mon Apr 16 12:10:24 2018 +0530 Bluetooth: hci_qca: Avoid missing rampatch failure with userspace fw loader commit 7dc5fe0814c35ec4e7d2e8fa30abab72e0e6a172 upstream. AOSP use userspace firmware loader to load firmwares, which will return -EAGAIN in case qca/rampatch_00440302.bin is not found. Since there is no rampatch for dragonboard820c QCA controller revision, just make it work as is. CC: Loic Poulain CC: Nicolas Dechesne CC: Marcel Holtmann CC: Johan Hedberg CC: Stable Signed-off-by: Amit Pundir Signed-off-by: Marcel Holtmann Signed-off-by: Greg Kroah-Hartman commit 3ffecef63d0932c3becceb1ef166e95e9a1ca33d Author: Corey Minyard Date: Tue May 22 08:14:51 2018 -0500 ipmi:bt: Set the timeout before doing a capabilities check commit fe50a7d0393a552e4539da2d31261a59d6415950 upstream. There was one place where the timeout value for an operation was not being set, if a capabilities request was done from idle. Move the timeout value setting to before where that change might be requested. IMHO the cause here is the invisible returns in the macros. Maybe that's a job for later, though. Reported-by: Nordmark Claes Signed-off-by: Corey Minyard Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 26e03f8dcd347a543f62eb58831ff417736d9d53 Author: Mikulas Patocka Date: Wed May 30 08:19:22 2018 -0400 branch-check: fix long->int truncation when profiling branches commit 2026d35741f2c3ece73c11eb7e4a15d7c2df9ebe upstream. The function __builtin_expect returns long type (see the gcc documentation), and so do macros likely and unlikely. Unfortunatelly, when CONFIG_PROFILE_ANNOTATED_BRANCHES is selected, the macros likely and unlikely expand to __branch_check__ and __branch_check__ truncates the long type to int. This unintended truncation may cause bugs in various kernel code (we found a bug in dm-writecache because of it), so it's better to fix __branch_check__ to return long. Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1805300818140.24812@file01.intranet.prod.int.rdu2.redhat.com Cc: Ingo Molnar Cc: stable@vger.kernel.org Fixes: 1f0d69a9fc815 ("tracing: profile likely and unlikely annotations") Signed-off-by: Mikulas Patocka Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 5eff5dbf3108017efe46ad3803b2122dfd1128b5 Author: Matthias Schiffer Date: Sat Mar 24 17:57:49 2018 +0100 mips: ftrace: fix static function graph tracing commit 6fb8656646f996d1eef42e6d56203c4915cb9e08 upstream. ftrace_graph_caller was never run after calling ftrace_trace_function, breaking the function graph tracer. Fix this, bringing it in line with the x86 implementation. While we're at it, also streamline the control flow of _mcount a bit to reduce the number of branches. This issue was reported before: https://www.linux-mips.org/archives/linux-mips/2014-11/msg00295.html Signed-off-by: Matthias Schiffer Tested-by: Matt Redfearn Patchwork: https://patchwork.linux-mips.org/patch/18929/ Signed-off-by: Paul Burton Cc: stable@vger.kernel.org # v3.17+ Signed-off-by: Greg Kroah-Hartman commit 5f7a15af646d8c9cf52f7d86b43a590fabf4e808 Author: Steven Rostedt (VMware) Date: Mon May 14 15:40:29 2018 -0400 ftrace/selftest: Have the reset_trigger code be a bit more careful commit 756b56a9e832e063edc83be7c3889e98c536dd2b upstream. The trigger code is picky in how it can be disabled as there may be dependencies between different events and synthetic events. Change the order on how triggers are reset. 1) Reset triggers of all synthetic events first 2) Remove triggers with actions attached to them 3) Remove all other triggers If this order isn't followed, then some triggers will not be reset, and an error may happen because a trigger is busy. Cc: stable@vger.kernel.org Fixes: cfa0963dc474f ("kselftests/ftrace : Add event trigger testcases") Reviewed-by: Namhyung Kim Acked-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit ea0ac01f68aa01cc391f18148342fc4ecc912860 Author: Geert Uytterhoeven Date: Fri Jun 1 11:28:22 2018 +0200 lib/vsprintf: Remove atomic-unsafe support for %pCr commit 666902e42fd8344b923c02dc5b0f37948ff4f225 upstream. "%pCr" formats the current rate of a clock, and calls clk_get_rate(). The latter obtains a mutex, hence it must not be called from atomic context. Remove support for this rarely-used format, as vsprintf() (and e.g. printk()) must be callable from any context. Any remaining out-of-tree users will start seeing the clock's name printed instead of its rate. Reported-by: Jia-Ju Bai Fixes: 900cca2944254edd ("lib/vsprintf: add %pC{,n,r} format specifiers for clocks") Link: http://lkml.kernel.org/r/1527845302-12159-5-git-send-email-geert+renesas@glider.be To: Jia-Ju Bai To: Jonathan Corbet To: Michael Turquette To: Stephen Boyd To: Zhang Rui To: Eduardo Valentin To: Eric Anholt To: Stefan Wahren To: Greg Kroah-Hartman Cc: Sergey Senozhatsky Cc: Petr Mladek Cc: Linus Torvalds Cc: Steven Rostedt Cc: linux-doc@vger.kernel.org Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-serial@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Geert Uytterhoeven Cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Geert Uytterhoeven Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit 9fcc267de242acb5da81861334519c150c3dc445 Author: Geert Uytterhoeven Date: Fri Jun 1 11:28:19 2018 +0200 clk: renesas: cpg-mssr: Stop using printk format %pCr commit ef4b0be62641d296cf4c0ad8f75ab83ab066ed51 upstream. Printk format "%pCr" will be removed soon, as clk_get_rate() must not be called in atomic context. Replace it by open-coding the operation. This is safe here, as the code runs in task context. Link: http://lkml.kernel.org/r/1527845302-12159-2-git-send-email-geert+renesas@glider.be To: Jia-Ju Bai To: Jonathan Corbet To: Michael Turquette To: Stephen Boyd To: Zhang Rui To: Eduardo Valentin To: Eric Anholt To: Stefan Wahren To: Greg Kroah-Hartman Cc: Sergey Senozhatsky Cc: Petr Mladek Cc: Linus Torvalds Cc: Steven Rostedt Cc: linux-doc@vger.kernel.org Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-serial@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Geert Uytterhoeven Cc: stable@vger.kernel.org # 4.5+ Signed-off-by: Geert Uytterhoeven Acked-by: Stephen Boyd Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit 0cf93821e34da487c5c86d0078c70dcd47b9ae7e Author: Geert Uytterhoeven Date: Fri Jun 1 11:28:20 2018 +0200 thermal: bcm2835: Stop using printk format %pCr commit bd2a07f71a1e2e198f8a30cb551d9defe422d83d upstream. Printk format "%pCr" will be removed soon, as clk_get_rate() must not be called in atomic context. Replace it by printing the variable that already holds the clock rate. Note that calling clk_get_rate() is safe here, as the code runs in task context. Link: http://lkml.kernel.org/r/1527845302-12159-3-git-send-email-geert+renesas@glider.be To: Jia-Ju Bai To: Jonathan Corbet To: Michael Turquette To: Stephen Boyd To: Zhang Rui To: Eduardo Valentin To: Eric Anholt To: Stefan Wahren To: Greg Kroah-Hartman Cc: Sergey Senozhatsky Cc: Petr Mladek Cc: Linus Torvalds Cc: Steven Rostedt Cc: linux-doc@vger.kernel.org Cc: linux-clk@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-serial@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 4.12+ Signed-off-by: Geert Uytterhoeven Acked-by: Stefan Wahren Signed-off-by: Petr Mladek Signed-off-by: Greg Kroah-Hartman commit b2291a435c292743cc6f9ec528e9e2d72cabfa9a Author: Alexander Sverdlin Date: Sat Apr 28 22:51:39 2018 +0200 ASoC: cirrus: i2s: Fix {TX|RX}LinCtrlData setup commit 5d302ed3cc80564fb835bed5fdba1e1250ecc9e5 upstream. According to "EP93xx User’s Guide", I2STXLinCtrlData and I2SRXLinCtrlData registers actually have different format. The only currently used bit (Left_Right_Justify) has different position. Fix this and simplify the whole setup taking into account the fact that both registers have zero default value. The practical effect of the above is repaired SND_SOC_DAIFMT_RIGHT_J support (currently unused). Signed-off-by: Alexander Sverdlin Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b5e8118779e54b6e31a00e7e96fb4be94b62a18f Author: Alexander Sverdlin Date: Sat Apr 28 22:51:38 2018 +0200 ASoC: cirrus: i2s: Fix LRCLK configuration commit 2d534113be9a2aa532a1ae127a57e83558aed358 upstream. The bit responsible for LRCLK polarity is i2s_tlrs (0), not i2s_trel (2) (refer to "EP93xx User's Guide"). Previously card drivers which specified SND_SOC_DAIFMT_NB_IF actually got SND_SOC_DAIFMT_NB_NF, an adaptation is necessary to retain the old behavior. Signed-off-by: Alexander Sverdlin Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7a1d79de77f531a4d227f93554215678f8c7ad31 Author: Paul Handrigan Date: Fri May 4 16:37:41 2018 -0500 ASoC: cs35l35: Add use_single_rw to regmap config commit 6a6ad7face95af0b9e6aaf1eb2261eb70240b89b upstream. Add the use_single_rw flag to regmap config since the device does not support bulk transactions over i2c. Signed-off-by: Paul Handrigan Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 040fecfd714a67decf3334727da4d6ea99a2f576 Author: Srinivas Kandagatla Date: Mon Jun 4 12:13:26 2018 +0100 ASoC: dapm: delete dapm_kcontrol_data paths list before freeing it commit ff2faf1289c1f81b5b26b9451dd1c2006aac8db8 upstream. dapm_kcontrol_data is freed as part of dapm_kcontrol_free(), leaving the paths pointer dangling in the list. This leads to system crash when we try to unload and reload sound card. I hit this bug during ADSP crash/reboot test case on Dragon board DB410c. Without this patch, on SLAB Poisoning enabled build, kernel crashes with "BUG kmalloc-128 (Tainted: G W ): Poison overwritten" Signed-off-by: Srinivas Kandagatla Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 4e0ce7053a12dcc0fc19628fccea7f0bed77eaf5 Author: Ingo Flaschberger Date: Tue May 1 16:10:33 2018 +0200 1wire: family module autoload fails because of upper/lower case mismatch. commit 065c09563c872e52813a17218c52cd642be1dca6 upstream. 1wire family module autoload fails because of upper/lower  case mismatch. Signed-off-by: Ingo Flaschberger Acked-by: Evgeniy Polyakov Cc: stable Signed-off-by: Greg Kroah-Hartman commit 3c22218ed86921ac18b4554093a1034feb3ebb5b Author: Maxim Moseychuk Date: Thu Jan 4 21:43:03 2018 +0300 usb: do not reset if a low-speed or full-speed device timed out commit 6e01827ed93947895680fbdad68c072a0f4e2450 upstream. Some low-speed and full-speed devices (for example, bluetooth) do not have time to initialize. For them, ETIMEDOUT is a valid error. We need to give them another try. Otherwise, they will never be initialized correctly and in dmesg will be messages "Bluetooth: hci0 command 0x1002 tx timeout" or similars. Fixes: 264904ccc33c ("usb: retry reset if a device times out") Cc: stable Signed-off-by: Maxim Moseychuk Signed-off-by: Greg Kroah-Hartman commit 8b03376580c9c2b4d239bc43527bb9a35dc2078e Author: Waldemar Rymarkiewicz Date: Thu Jun 14 15:56:08 2018 +0200 PM / OPP: Update voltage in case freq == old_freq commit c5c2a97b3ac7d1ec19e7cff9e38caca6afefc3de upstream. This commit fixes a rare but possible case when the clk rate is updated without update of the regulator voltage. At boot up, CPUfreq checks if the system is running at the right freq. This is a sanity check in case a bootloader set clk rate that is outside of freq table present with cpufreq core. In such cases system can be unstable so better to change it to a freq that is preset in freq-table. The CPUfreq takes next freq that is >= policy->cur and this is our target_freq that needs to be set now. dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the old_freq (a current rate). If these are equal it returns early. If not, it searches for OPP (old_opp) that fits best to old_freq (not listed in the table) and updates old_freq (!). Here, we can end up with old_freq = old_opp.rate = target_freq, which is not handled in _generic_set_opp_regulator(). It's supposed to update voltage only when freq > old_freq || freq > old_freq. if (freq > old_freq) { ret = _set_opp_voltage(dev, reg, new_supply); [...] if (freq < old_freq) { ret = _set_opp_voltage(dev, reg, new_supply); if (ret) It results in, no voltage update while clk rate is updated. Example: freq-table = { 1000MHz 1.15V 666MHZ 1.10V 333MHz 1.05V } boot-up-freq = 800MHz # not listed in freq-table freq = target_freq = 1GHz old_freq = 800Mhz old_opp = _find_freq_ceil(opp_table, &old_freq); #(old_freq is modified!) old_freq = 1GHz Fixes: 6a0712f6f199 ("PM / OPP: Add dev_pm_opp_set_rate()") Cc: 4.6+ # v4.6+ Signed-off-by: Waldemar Rymarkiewicz Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit ba0be5973f9e5eef705409a021159a6cc0571135 Author: Rafael J. Wysocki Date: Thu Jun 14 10:01:52 2018 +0200 PM / core: Fix supplier device runtime PM usage counter imbalance commit 47e5abfb546a3ace23a77453dc2e9db92704c5ac upstream. If a device link is added via device_link_add() by the driver of the link's consumer device, the supplier's runtime PM usage counter is going to be dropped by the pm_runtime_put_suppliers() call in driver_probe_device(). However, in that case it is not incremented unless the supplier driver is already present and the link is not stateless. That leads to a runtime PM usage counter imbalance for the supplier device in a few cases. To prevent that from happening, bump up the supplier runtime PM usage counter in device_link_add() for all links with the DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe time. Use pm_runtime_get_noresume() for that as the callers of device_link_add() who want the supplier to be resumed by it are expected to pass DL_FLAG_RPM_ACTIVE in flags to it anyway, but additionally resume the supplier if the link is added during consumer driver probe to retain the existing behavior for the callers depending on it. Fixes: 21d5c57b3726 (PM / runtime: Use device links) Reported-by: Ulf Hansson Reviewed-by: Ulf Hansson Tested-by: Marek Szyprowski Cc: 4.10+ # 4.10+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit b7ac0389770aacc2dc91d17dc44fd4dcc1438faf Author: Ulf Hansson Date: Thu Apr 26 10:53:00 2018 +0200 PM / Domains: Fix error path during attach in genpd commit 72038df3c580c4c326b83c86149d7ac34007532a upstream. In case the PM domain fails to be powered on in genpd_dev_pm_attach(), it returns -EPROBE_DEFER, but keeping the device attached to its PM domain. This leads to problems when the next attempt to attach is re-tried. More precisely, in that situation an -EEXIST error code is returned, because the device already has its PM domain pointer assigned, from the first attempt. Now, because of the sloppy error handling by the existing callers of dev_pm_domain_attach(), probing is allowed to continue when -EEXIST is returned. However, in such case there are no guarantees that the PM domain is powered on by genpd, which may lead to hangs when buses/drivers tried to access their devices. Let's fix this behaviour, simply by detaching the device when powering on fails in genpd_dev_pm_attach(). Cc: v4.11+ # v4.11+ Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8ae5d476a3b7bd7938abcd0f926925c7c81fd79b Author: Eric W. Biederman Date: Fri Apr 20 09:14:56 2018 -0500 signal/xtensa: Consistenly use SIGBUS in do_unaligned_user commit 7de712ccc096b81d23cc0a941cd9b8cb3956605d upstream. While working on changing this code to use force_sig_fault I discovered that do_unaliged_user is sets si_signo to SIGBUS and passes SIGSEGV to force_sig_info. Which is just b0rked. The code is reporting a SIGBUS error so replace the SIGSEGV with SIGBUS. Cc: Chris Zankel Cc: Max Filippov Cc: linux-xtensa@linux-xtensa.org Cc: stable@vger.kernel.org Acked-by: Max Filippov Fixes: 5a0015d62668 ("[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 3") Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 980899da5dc9249aef2329ae662f16a97062e8b1 Author: Daniel Wagner Date: Tue May 8 10:55:09 2018 +0200 serial: sh-sci: Use spin_{try}lock_irqsave instead of open coding version commit 8afb1d2c12163f77777f84616a8e9444d0050ebe upstream. Commit 40f70c03e33a ("serial: sh-sci: add locking to console write function to avoid SMP lockup") copied the strategy to avoid locking problems in conjuncture with the console from the UART8250 driver. Instead using directly spin_{try}lock_irqsave(), local_irq_save() followed by spin_{try}lock() was used. While this is correct on mainline, for -rt it is a problem. spin_{try}lock() will check if it is running in a valid context. Since the local_irq_save() has already been executed, the context has changed and spin_{try}lock() will complain. The reason why spin_{try}lock() complains is that on -rt the spin locks are turned into mutexes and therefore can sleep. Sleeping with interrupts disabled is not valid. BUG: sleeping function called from invalid context at /home/wagi/work/rt/v4.4-cip-rt/kernel/locking/rtmutex.c:995 in_atomic(): 0, irqs_disabled(): 128, pid: 778, name: irq/76-eth0 CPU: 0 PID: 778 Comm: irq/76-eth0 Not tainted 4.4.126-test-cip22-rt14-00403-gcd03665c8318 #12 Hardware name: Generic RZ/G1 (Flattened Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r7:c06b01f0 r6:60010193 r5:00000000 r4:c06b01f0 [] (show_stack) from [] (dump_stack+0x78/0x94) [] (dump_stack) from [] (___might_sleep+0x134/0x194) r7:60010113 r6:c06d3559 r5:00000000 r4:ffffe000 [] (___might_sleep) from [] (rt_spin_lock+0x20/0x74) r5:c06f4d60 r4:c06f4d60 [] (rt_spin_lock) from [] (serial_console_write+0x100/0x118) r5:c06f4d60 r4:c06f4d60 [] (serial_console_write) from [] (call_console_drivers.constprop.15+0x10c/0x124) r10:c06d2894 r9:c04e18b0 r8:00000028 r7:00000000 r6:c06d3559 r5:c06d2798 r4:c06b9914 r3:c02576e4 [] (call_console_drivers.constprop.15) from [] (console_unlock+0x32c/0x430) r10:c06d30d8 r9:00000028 r8:c06dd518 r7:00000005 r6:00000000 r5:c06d2798 r4:c06d2798 r3:00000028 [] (console_unlock) from [] (vprintk_emit+0x394/0x4f0) r10:c06d2798 r9:c06d30ee r8:00000006 r7:00000005 r6:c06a78fc r5:00000027 r4:00000003 [] (vprintk_emit) from [] (vprintk+0x28/0x30) r10:c060bd46 r9:00001000 r8:c06b9a90 r7:c06b9a90 r6:c06b994c r5:c06b9a3c r4:c0062fa8 [] (vprintk) from [] (vprintk_default+0x10/0x14) [] (vprintk_default) from [] (printk+0x78/0x84) [] (printk) from [] (credit_entropy_bits+0x17c/0x2cc) r3:00000001 r2:decade60 r1:c061a5ee r0:c061a523 r4:00000006 [] (credit_entropy_bits) from [] (add_interrupt_randomness+0x160/0x178) r10:466e7196 r9:1f536000 r8:fffeef74 r7:00000000 r6:c06b9a60 r5:c06b9a3c r4:dfbcf680 [] (add_interrupt_randomness) from [] (irq_thread+0x1e8/0x248) r10:c006537c r9:c06cdf21 r8:c0064fcc r7:df791c24 r6:df791c00 r5:ffffe000 r4:df525180 [] (irq_thread) from [] (kthread+0x108/0x11c) r10:00000000 r9:00000000 r8:c0065184 r7:df791c00 r6:00000000 r5:df791d00 r4:decac000 [] (kthread) from [] (ret_from_fork+0x14/0x3c) r8:00000000 r7:00000000 r6:00000000 r5:c003fa9c r4:df791d00 Cc: Sebastian Andrzej Siewior Signed-off-by: Daniel Wagner Reviewed-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 60711b27c5f5d1dda01078df21520cfb63d06419 Author: Finn Thain Date: Wed Apr 11 20:50:14 2018 -0400 m68k/mac: Fix SWIM memory resource end address commit 3e2816c1078eb2b5a3276eb83d4da156b3e2d04f upstream. The resource size is 0x2000 == end - start + 1. Therefore end == start + 0x2000 - 1. Cc: Laurent Vivier Cc: stable@vger.kernel.org # v4.14+ Tested-by: Stan Johnson Signed-off-by: Finn Thain Acked-by: Laurent Vivier Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit da9ad89c72d58df3534fed2963972e932c70fdd7 Author: Michael Schmitz Date: Mon May 14 23:10:53 2018 +1200 m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap() commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55 upstream. If 020/030 support is enabled, get_io_area() leaves an IO_SIZE gap between mappings which is added to the vm_struct representing the mapping. __ioremap() uses the actual requested size (after alignment), while __iounmap() is passed the size from the vm_struct. On 020/030, early termination descriptors are used to set up mappings of extent 'size', which are validated on unmapping. The unmapped gap of size IO_SIZE defeats the sanity check of the pmd tables, causing __iounmap() to loop forever on 030. On 040/060, unmapping of page table entries does not check for a valid mapping, so the umapping loop always completes there. Adjust size to be unmapped by the gap that had been added in the vm_struct prior. This fixes the hang in atari_platform_init() reported a long time ago, and a similar one reported by Finn recently (addressed by removing ioremap() use from the SWIM driver. Tested on my Falcon in 030 mode - untested but should work the same on 040/060 (the extra page tables cleared there would never have been set up anyway). Signed-off-by: Michael Schmitz [geert: Minor commit description improvements] [geert: This was fixed in 2.4.23, but not in 2.5.x] Signed-off-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ab693cc665ca539d3d79783fd1699fc52697469a Author: Siarhei Liakh Date: Thu Jun 14 19:36:07 2018 +0000 x86: Call fixup_exception() before notify_die() in math_error() commit 3ae6295ccb7cf6d344908209701badbbbb503e40 upstream. fpu__drop() has an explicit fwait which under some conditions can trigger a fixable FPU exception while in kernel. Thus, we should attempt to fixup the exception first, and only call notify_die() if the fixup failed just like in do_general_protection(). The original call sequence incorrectly triggers KDB entry on debug kernels under particular FPU-intensive workloads. Andy noted, that this makes the whole conditional irq enable thing even more inconsistent, but fixing that it outside the scope of this. Signed-off-by: Siarhei Liakh Signed-off-by: Thomas Gleixner Reviewed-by: Andy Lutomirski Cc: "H. Peter Anvin" Cc: "Borislav Petkov" Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/DM5PR11MB201156F1CAB2592B07C79A03B17D0@DM5PR11MB2011.namprd11.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 64d44661e2207a408783360f3029b9a2c48a6daf Author: Borislav Petkov Date: Fri Jun 22 11:54:28 2018 +0200 x86/mce: Do not overwrite MCi_STATUS in mce_no_way_out() commit 1f74c8a64798e2c488f86efc97e308b85fb7d7aa upstream. mce_no_way_out() does a quick check during #MC to see whether some of the MCEs logged would require the kernel to panic immediately. And it passes a struct mce where MCi_STATUS gets written. However, after having saved a valid status value, the next iteration of the loop which goes over the MCA banks on the CPU, overwrites the valid status value because we're using struct mce as storage instead of a temporary variable. Which leads to MCE records with an empty status value: mce: [Hardware Error]: CPU 0: Machine Check Exception: 6 Bank 0: 0000000000000000 mce: [Hardware Error]: RIP 10: {trigger_mce+0x7/0x10} In order to prevent the loss of the status register value, return immediately when severity is a panic one so that we can panic immediately with the first fatal MCE logged. This is also the intention of this function and not to noodle over the banks while a fatal MCE is already logged. Tony: read the rest of the MCA bank to populate the struct mce fully. Suggested-by: Tony Luck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Link: https://lkml.kernel.org/r/20180622095428.626-8-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 5b8e086891b038adc667f3ae2f6839f76b54b264 Author: Tony Luck Date: Fri Jun 22 11:54:23 2018 +0200 x86/mce: Fix incorrect "Machine check from unknown source" message commit 40c36e2741d7fe1e66d6ec55477ba5fd19c9c5d2 upstream. Some injection testing resulted in the following console log: mce: [Hardware Error]: CPU 22: Machine Check Exception: f Bank 1: bd80000000100134 mce: [Hardware Error]: RIP 10: {pmem_do_bvec+0x11d/0x330 [nd_pmem]} mce: [Hardware Error]: TSC c51a63035d52 ADDR 3234bc4000 MISC 88 mce: [Hardware Error]: PROCESSOR 0:50654 TIME 1526502199 SOCKET 0 APIC 38 microcode 2000043 mce: [Hardware Error]: Run the above through 'mcelog --ascii' Kernel panic - not syncing: Machine check from unknown source This confused everybody because the first line quite clearly shows that we found a logged error in "Bank 1", while the last line says "unknown source". The problem is that the Linux code doesn't do the right thing for a local machine check that results in a fatal error. It turns out that we know very early in the handler whether the machine check is fatal. The call to mce_no_way_out() has checked all the banks for the CPU that took the local machine check. If it says we must crash, we can do so right away with the right messages. We do scan all the banks again. This means that we might initially not see a problem, but during the second scan find something fatal. If this happens we print a slightly different message (so I can see if it actually every happens). [ bp: Remove unneeded severity assignment. ] Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Ashok Raj Cc: Dan Williams Cc: Qiuxu Zhuo Cc: linux-edac Cc: stable@vger.kernel.org # 4.2 Link: http://lkml.kernel.org/r/52e049a497e86fd0b71c529651def8871c804df0.1527283897.git.tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman commit d292f33b74942e1419311887b0054794d779ce3f Author: Tony Luck Date: Fri May 25 14:42:09 2018 -0700 x86/mce: Check for alternate indication of machine check recovery on Skylake commit 4c5717da1d021cf368eabb3cb1adcaead56c0d1e upstream. Currently we just check the "CAPID0" register to see whether the CPU can recover from machine checks. But there are also some special SKUs which do not have all advanced RAS features, but do enable machine check recovery for use with NVDIMMs. Add a check for any of bits {8:5} in the "CAPID5" register (each reports some NVDIMM mode available, if any of them are set, then the system supports memory machine check recovery). Signed-off-by: Tony Luck Signed-off-by: Thomas Gleixner Cc: Qiuxu Zhuo Cc: Ashok Raj Cc: stable@vger.kernel.org # 4.9 Cc: Dan Williams Cc: Borislav Petkov Link: https://lkml.kernel.org/r/03cbed6e99ddafb51c2eadf9a3b7c8d7a0cc204e.1527283897.git.tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman commit 1d1dd2011adca8fa1e0715a83fc751eae31acf1d Author: Tony Luck Date: Fri May 25 14:41:39 2018 -0700 x86/mce: Improve error message when kernel cannot recover commit c7d606f560e4c698884697fef503e4abacdd8c25 upstream. Since we added support to add recovery from some errors inside the kernel in: commit b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries") we have done a less than stellar job at reporting the cause of recoverable machine checks that occur in other parts of the kernel. The user just gets the unhelpful message: mce: [Hardware Error]: Machine check: Action required: unknown MCACOD doubly unhelpful when they check the manual for the reported IA32_MSR_STATUS.MCACOD and see that it is listed as one of the standard recoverable values. Add an extra rule to the MCE severity table to catch this case and report it as: mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel Fixes: b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries") Signed-off-by: Tony Luck Signed-off-by: Thomas Gleixner Cc: Qiuxu Zhuo Cc: Ashok Raj Cc: stable@vger.kernel.org # 4.6+ Cc: Dan Williams Cc: Borislav Petkov Link: https://lkml.kernel.org/r/4cc7c465150a9a48b8b9f45d0b840278e77eb9b5.1527283897.git.tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman commit dbb37d98b93d239269420cd9848bd730cb33530b Author: Juergen Gross Date: Thu Jun 21 10:43:31 2018 +0200 x86/xen: Add call of speculative_store_bypass_ht_init() to PV paths commit 74899d92e66663dc7671a8017b3146dcd4735f3b upstream. Commit: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD") ... added speculative_store_bypass_ht_init() to the per-CPU initialization sequence. speculative_store_bypass_ht_init() needs to be called on each CPU for PV guests, too. Reported-by: Brian Woods Tested-by: Brian Woods Signed-off-by: Juergen Gross Cc: Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: boris.ostrovsky@oracle.com Cc: xen-devel@lists.xenproject.org Fixes: 1f50ddb4f4189243c05926b842dc1a0332195f31 ("x86/speculation: Handle HT correctly on AMD") Link: https://lore.kernel.org/lkml/20180621084331.21228-1-jgross@suse.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 3ce79716a9ff97cfe2283606aed360ff7a8e3955 Author: Dan Williams Date: Thu Jun 7 09:13:48 2018 -0700 x86/spectre_v1: Disable compiler optimizations over array_index_mask_nospec() commit eab6870fee877258122a042bfd99ee7908c40280 upstream. Mark Rutland noticed that GCC optimization passes have the potential to elide necessary invocations of the array_index_mask_nospec() instruction sequence, so mark the asm() volatile. Mark explains: "The volatile will inhibit *some* cases where the compiler could lift the array_index_nospec() call out of a branch, e.g. where there are multiple invocations of array_index_nospec() with the same arguments: if (idx < foo) { idx1 = array_idx_nospec(idx, foo) do_something(idx1); } < some other code > if (idx < foo) { idx2 = array_idx_nospec(idx, foo); do_something_else(idx2); } ... since the compiler can determine that the two invocations yield the same result, and reuse the first result (likely the same register as idx was in originally) for the second branch, effectively re-writing the above as: if (idx < foo) { idx = array_idx_nospec(idx, foo); do_something(idx); } < some other code > if (idx < foo) { do_something_else(idx); } ... if we don't take the first branch, then speculatively take the second, we lose the nospec protection. There's more info on volatile asm in the GCC docs: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile " Reported-by: Mark Rutland Signed-off-by: Dan Williams Acked-by: Mark Rutland Acked-by: Thomas Gleixner Acked-by: Linus Torvalds Cc: Cc: Peter Zijlstra Fixes: babdde2698d4 ("x86: Implement array_index_mask_nospec") Link: https://lkml.kernel.org/lkml/152838798950.14521.4893346294059739135.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit a26899e0baa4de07caf97f5e4d7298240e98fd0e Author: Greg Kroah-Hartman Date: Tue Jun 26 08:06:33 2018 +0800 Linux 4.14.52 commit 1d26c112959f91e28dadee942877e32b91596d76 Author: Vlastimil Babka Date: Thu Jun 7 17:09:29 2018 -0700 mm, page_alloc: do not break __GFP_THISNODE by zonelist reset commit 7810e6781e0fcbca78b91cf65053f895bf59e85f upstream. In __alloc_pages_slowpath() we reset zonelist and preferred_zoneref for allocations that can ignore memory policies. The zonelist is obtained from current CPU's node. This is a problem for __GFP_THISNODE allocations that want to allocate on a different node, e.g. because the allocating thread has been migrated to a different CPU. This has been observed to break SLAB in our 4.4-based kernel, because there it relies on __GFP_THISNODE working as intended. If a slab page is put on wrong node's list, then further list manipulations may corrupt the list because page_to_nid() is used to determine which node's list_lock should be locked and thus we may take a wrong lock and race. Current SLAB implementation seems to be immune by luck thanks to commit 511e3a058812 ("mm/slab: make cache_grow() handle the page allocated on arbitrary node") but there may be others assuming that __GFP_THISNODE works as promised. We can fix it by simply removing the zonelist reset completely. There is actually no reason to reset it, because memory policies and cpusets don't affect the zonelist choice in the first place. This was different when commit 183f6371aac2 ("mm: ignore mempolicies when using ALLOC_NO_WATERMARK") introduced the code, as mempolicies provided their own restricted zonelists. We might consider this for 4.17 although I don't know if there's anything currently broken. SLAB is currently not affected, but in kernels older than 4.7 that don't yet have 511e3a058812 ("mm/slab: make cache_grow() handle the page allocated on arbitrary node") it is. That's at least 4.4 LTS. Older ones I'll have to check. So stable backports should be more important, but will have to be reviewed carefully, as the code went through many changes. BTW I think that also the ac->preferred_zoneref reset is currently useless if we don't also reset ac->nodemask from a mempolicy to NULL first (which we probably should for the OOM victims etc?), but I would leave that for a separate patch. Link: http://lkml.kernel.org/r/20180525130853.13915-1-vbabka@suse.cz Signed-off-by: Vlastimil Babka Fixes: 183f6371aac2 ("mm: ignore mempolicies when using ALLOC_NO_WATERMARK") Acked-by: Mel Gorman Cc: Michal Hocko Cc: David Rientjes Cc: Joonsoo Kim Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 250edf9580f7cba70efdcca4137089bd060f5090 Author: Thadeu Lima de Souza Cascardo Date: Thu Jun 7 17:11:01 2018 -0700 fs/binfmt_misc.c: do not allow offset overflow commit 5cc41e099504b77014358b58567c5ea6293dd220 upstream. WHen registering a new binfmt_misc handler, it is possible to overflow the offset to get a negative value, which might crash the system, or possibly leak kernel data. Here is a crash log when 2500000000 was used as an offset: BUG: unable to handle kernel paging request at ffff989cfd6edca0 IP: load_misc_binary+0x22b/0x470 [binfmt_misc] PGD 1ef3e067 P4D 1ef3e067 PUD 0 Oops: 0000 [#1] SMP NOPTI Modules linked in: binfmt_misc kvm_intel ppdev kvm irqbypass joydev input_leds serio_raw mac_hid parport_pc qemu_fw_cfg parpy CPU: 0 PID: 2499 Comm: bash Not tainted 4.15.0-22-generic #24-Ubuntu Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014 RIP: 0010:load_misc_binary+0x22b/0x470 [binfmt_misc] Call Trace: search_binary_handler+0x97/0x1d0 do_execveat_common.isra.34+0x667/0x810 SyS_execve+0x31/0x40 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Use kstrtoint instead of simple_strtoul. It will work as the code already set the delimiter byte to '\0' and we only do it when the field is not empty. Tested with offsets -1, 2500000000, UINT_MAX and INT_MAX. Also tested with examples documented at Documentation/admin-guide/binfmt-misc.rst and other registrations from packages on Ubuntu. Link: http://lkml.kernel.org/r/20180529135648.14254-1-cascardo@canonical.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Thadeu Lima de Souza Cascardo Reviewed-by: Andrew Morton Cc: Alexander Viro Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 7446344baafba2f23da58ac837b86770ec977b90 Author: Michael S. Tsirkin Date: Sat May 12 00:33:10 2018 +0300 vhost: fix info leak due to uninitialized memory commit 670ae9caaca467ea1bfd325cb2a5c98ba87f94ad upstream. struct vhost_msg within struct vhost_msg_node is copied to userspace. Unfortunately it turns out on 64 bit systems vhost_msg has padding after type which gcc doesn't initialize, leaking 4 uninitialized bytes to userspace. This padding also unfortunately means 32 bit users of this interface are broken on a 64 bit kernel which will need to be fixed separately. Fixes: CVE-2018-1118 Cc: stable@vger.kernel.org Reported-by: Kevin Easton Signed-off-by: Michael S. Tsirkin Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit d37c95f529115230421ee91a9553558321cca4e8 Author: Jason Gerecke Date: Tue Jun 12 13:42:46 2018 -0700 HID: wacom: Correct logical maximum Y for 2nd-gen Intuos Pro large commit d471b6b22d37bf9928c6d0202bdaaf76583b8b61 upstream. The HID descriptor for the 2nd-gen Intuos Pro large (PTH-860) contains a typo which defines an incorrect logical maximum Y value. This causes a small portion of the bottom of the tablet to become unusable (both because the area is below the "bottom" of the tablet and because 'wacom_wac_event' ignores out-of-range values). It also results in a skewed aspect ratio. To fix this, we add a quirk to 'wacom_usage_mapping' which overwrites the data with the correct value. Signed-off-by: Jason Gerecke CC: stable@vger.kernel.org # v4.10+ Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ab17de60ceaa10ef48f39afe9753f63f0fc80037 Author: Even Xu Date: Fri Feb 12 04:11:34 2016 +0800 HID: intel_ish-hid: ipc: register more pm callbacks to support hibernation commit ebeaa367548e9e92dd9374b9464ff6e7d157117b upstream. Current ISH driver only registers suspend/resume PM callbacks which don't support hibernation (suspend to disk). Basically after hiberation, the ISH can't resume properly and user may not see sensor events (for example: screen rotation may not work). User will not see a crash or panic or anything except the following message in log: hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from ISHTP device So this patch adds support for S4/hiberbation to ISH by using the SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly. The suspend and resume functions will now be used for both suspend to RAM and hibernation. If power management is disabled, SIMPLE_DEV_PM_OPS will do nothing, the suspend and resume related functions won't be used, so mark them as __maybe_unused to clarify that this is the intended behavior, and remove #ifdefs for power management. Cc: stable@vger.kernel.org Signed-off-by: Even Xu Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit e3e6bd6a14761942a93ffef884f954764ddca39e Author: Martin Brandenburg Date: Thu May 31 16:37:00 2018 +0000 orangefs: report attributes_mask and attributes for statx commit 7f54910fa8dfe504f2e1563f4f6ddc3294dfbf3a upstream. OrangeFS formerly failed to set attributes_mask with the result that software could not see immutable and append flags present in the filesystem. Reported-by: Becky Ligon Signed-off-by: Martin Brandenburg Fixes: 68a24a6cc4a6 ("orangefs: implement statx") Cc: stable@vger.kernel.org Cc: hubcap@omnibond.com Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit f7e4328c37007c43e005af1b3ed268149f8abb32 Author: Martin Brandenburg Date: Thu May 31 16:36:58 2018 +0000 orangefs: set i_size on new symlink commit f6a4b4c9d07dda90c7c29dae96d6119ac6425dca upstream. As long as a symlink inode remains in-core, the destination (and therefore size) will not be re-fetched from the server, as it cannot change. The original implementation of the attribute cache assumed that setting the expiry time in the past was sufficient to cause a re-fetch of all attributes on the next getattr. That does not work in this case. The bug manifested itself as follows. When the command sequence touch foo; ln -s foo bar; ls -l bar is run, the output was lrwxrwxrwx. 1 fedora fedora 4906 Apr 24 19:10 bar -> foo However, after a re-mount, ls -l bar produces lrwxrwxrwx. 1 fedora fedora 3 Apr 24 19:10 bar -> foo After this commit, even before a re-mount, the output is lrwxrwxrwx. 1 fedora fedora 3 Apr 24 19:10 bar -> foo Reported-by: Becky Ligon Signed-off-by: Martin Brandenburg Fixes: 71680c18c8f2 ("orangefs: Cache getattr results.") Cc: stable@vger.kernel.org Cc: hubcap@omnibond.com Signed-off-by: Mike Marshall Signed-off-by: Greg Kroah-Hartman commit b8511dbff2639db94baad73ab912bd6f22afea14 Author: Luca Coelho Date: Tue Feb 13 11:09:40 2018 +0200 iwlwifi: fw: harden page loading code commit 9039d985811d5b109b58b202b7594fd24e433fed upstream. The page loading code trusts the data provided in the firmware images a bit too much and may cause a buffer overflow or copy unknown data if the block sizes don't match what we expect. To prevent potential problems, harden the code by checking if the sizes we are copying are what we expect. Cc: stable@vger.kernel.org Signed-off-by: Luca Coelho Signed-off-by: Greg Kroah-Hartman commit 2d58a9ac892a2c08480a113f1fb0f55dbf85e2bb Author: Tony Luck Date: Fri Jun 8 09:07:32 2018 -0700 x86/intel_rdt: Enable CMT and MBM on new Skylake stepping commit 1d9f3e20a56d33e55748552aeec597f58542f92d upstream. New stepping of Skylake has fixes for cache occupancy and memory bandwidth monitoring. Update the code to enable these by default on newer steppings. Signed-off-by: Tony Luck Signed-off-by: Thomas Gleixner Cc: Fenghua Yu Cc: stable@vger.kernel.org # v4.14 Cc: Vikas Shivappa Link: https://lkml.kernel.org/r/20180608160732.9842-1-tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman commit e6ef46cb8f01b67266a1adc1c323b5b67086b8e8 Author: Stefan Potyra Date: Wed May 2 10:55:31 2018 +0200 w1: mxc_w1: Enable clock before calling clk_get_rate() on it commit 955bc61328dc0a297fb3baccd84e9d3aee501ed8 upstream. According to the API, you may only call clk_get_rate() after actually enabling it. Found by Linux Driver Verification project (linuxtesting.org). Fixes: a5fd9139f74c ("w1: add 1-wire master driver for i.MX27 / i.MX31") Signed-off-by: Stefan Potyra Acked-by: Evgeniy Polyakov Cc: stable Signed-off-by: Greg Kroah-Hartman commit 0667483adeeefdedd21cc636cd224632d5570980 Author: Hans de Goede Date: Thu May 31 13:21:07 2018 +0200 libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk commit 2cfce3a86b64b53f0a70e92a6a659c720c319b45 upstream. Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs. This has lead to several reports of users of that SSD where LPM was working fine and who know have a significantly increased idle power consumption on their laptops. Likely there is another problem on the T450s from the original reporter which gets exposed by the uncore reaching deeper sleep states (higher PC-states) due to LPM being enabled. The problem as reported, a hardfreeze about once a day, already did not sound like it would be caused by LPM and the reports of the SSD working fine confirm this. The original reporter is ok with dropping the quirk. A X250 user has reported the same hard freeze problem and for him the problem went away after unrelated updates, I suspect some GPU driver stack changes fixed things. TL;DR: The original reporters problem were triggered by LPM but not an LPM issue, so drop the quirk for the SSD in question. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207 Cc: stable@vger.kernel.org Cc: Richard W.M. Jones Cc: Lorenzo Dalrio Reported-by: Lorenzo Dalrio Signed-off-by: Hans de Goede Signed-off-by: Tejun Heo Acked-by: "Richard W.M. Jones" Signed-off-by: Greg Kroah-Hartman commit 27c0f1e5d94d90ef07a3c33fe20996c403fbbf9e Author: Dan Carpenter Date: Tue May 29 12:13:24 2018 +0300 libata: zpodd: small read overflow in eject_tray() commit 18c9a99bce2a57dfd7e881658703b5d7469cc7b9 upstream. We read from the cdb[] buffer in ata_exec_internal_sg(). It has to be ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes. Fixes: 213342053db5 ("libata: handle power transition of ODD") Signed-off-by: Dan Carpenter Signed-off-by: Tejun Heo Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1404d2e5dd3647d9bec8960c7dc90aea7cbd8b63 Author: Chen Yu Date: Fri Jun 8 09:07:33 2018 +0800 cpufreq: governors: Fix long idle detection logic in load calculation commit 7592019634f8473f0b0973ce79297183077bdbc2 upstream. According to current code implementation, detecting the long idle period is done by checking if the interval between two adjacent utilization update handlers is long enough. Although this mechanism can detect if the idle period is long enough (no utilization hooks invoked during idle period), it might not cover a corner case: if the task has occupied the CPU for too long which causes no context switches during that period, then no utilization handler will be launched until this high prio task is scheduled out. As a result, the idle_periods field might be calculated incorrectly because it regards the 100% load as 0% and makes the conservative governor who uses this field confusing. Change the detection to compare the idle_time with sampling_rate directly. Reported-by: Artem S. Tashkinov Signed-off-by: Chen Yu Acked-by: Viresh Kumar Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c3c77b5db39350c8d64c85102138ab9ba6066815 Author: Tao Wang Date: Sat May 26 15:16:48 2018 +0800 cpufreq: Fix new policy initialization during limits updates via sysfs commit c7d1f119c48f64bebf0fa1e326af577c6152fe30 upstream. If the policy limits are updated via cpufreq_update_policy() and subsequently via sysfs, the limits stored in user_policy may be set incorrectly. For example, if both min and max are set via sysfs to the maximum available frequency, user_policy.min and user_policy.max will also be the maximum. If a policy notifier triggered by cpufreq_update_policy() lowers both the min and the max at this point, that change is not reflected by the user_policy limits, so if the max is updated again via sysfs to the same lower value, then user_policy.max will be lower than user_policy.min which shouldn't happen. In particular, if one of the policy CPUs is then taken offline and back online, cpufreq_set_policy() will fail for it due to a failing limits check. To prevent that from happening, initialize the min and max fields of the new_policy object to the ones stored in user_policy that were previously set via sysfs. Signed-off-by: Kevin Wangtao Acked-by: Viresh Kumar [ rjw: Subject & changelog ] Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 67b46304b92b6bbb165817abe8700a2ec1aa8305 Author: Tejun Heo Date: Wed May 23 10:56:32 2018 -0700 bdi: Move cgroup bdi_writeback to a dedicated low concurrency workqueue commit f183464684190bacbfb14623bd3e4e51b7575b4c upstream. From 0aa2e9b921d6db71150633ff290199554f0842a8 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Wed, 23 May 2018 10:29:00 -0700 cgwb_release() punts the actual release to cgwb_release_workfn() on system_wq. Depending on the number of cgroups or block devices, there can be a lot of cgwb_release_workfn() in flight at the same time. We're periodically seeing close to 256 kworkers getting stuck with the following stack trace and overtime the entire system gets stuck. [] _synchronize_rcu_expedited.constprop.72+0x2fc/0x330 [] synchronize_rcu_expedited+0x24/0x30 [] bdi_unregister+0x53/0x290 [] release_bdi+0x89/0xc0 [] wb_exit+0x85/0xa0 [] cgwb_release_workfn+0x54/0xb0 [] process_one_work+0x150/0x410 [] worker_thread+0x6d/0x520 [] kthread+0x12c/0x160 [] ret_from_fork+0x29/0x40 [] 0xffffffffffffffff The events leading to the lockup are... 1. A lot of cgwb_release_workfn() is queued at the same time and all system_wq kworkers are assigned to execute them. 2. They all end up calling synchronize_rcu_expedited(). One of them wins and tries to perform the expedited synchronization. 3. However, that invovles queueing rcu_exp_work to system_wq and waiting for it. Because #1 is holding all available kworkers on system_wq, rcu_exp_work can't be executed. cgwb_release_workfn() is waiting for synchronize_rcu_expedited() which in turn is waiting for cgwb_release_workfn() to free up some of the kworkers. We shouldn't be scheduling hundreds of cgwb_release_workfn() at the same time. There's nothing to be gained from that. This patch updates cgwb release path to use a dedicated percpu workqueue with @max_active of 1. While this resolves the problem at hand, it might be a good idea to isolate rcu_exp_work to its own workqueue too as it can be used from various paths and is prone to this sort of indirect A-A deadlocks. Signed-off-by: Tejun Heo Cc: "Paul E. McKenney" Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ba502bf2be45f37f38581353af8897a91493f33a Author: Roman Pen Date: Sun Jun 10 22:38:24 2018 +0200 blk-mq: reinit q->tag_set_list entry only after grace period commit a347c7ad8edf4c5685154f3fdc3c12fc1db800ba upstream. It is not allowed to reinit q->tag_set_list list entry while RCU grace period has not completed yet, otherwise the following soft lockup in blk_mq_sched_restart() happens: [ 1064.252652] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [fio:9270] [ 1064.254445] task: ffff99b912e8b900 task.stack: ffffa6d54c758000 [ 1064.254613] RIP: 0010:blk_mq_sched_restart+0x96/0x150 [ 1064.256510] Call Trace: [ 1064.256664] [ 1064.256824] blk_mq_free_request+0xea/0x100 [ 1064.256987] msg_io_conf+0x59/0xd0 [ibnbd_client] [ 1064.257175] complete_rdma_req+0xf2/0x230 [ibtrs_client] [ 1064.257340] ? ibtrs_post_recv_empty+0x4d/0x70 [ibtrs_core] [ 1064.257502] ibtrs_clt_rdma_done+0xd1/0x1e0 [ibtrs_client] [ 1064.257669] ib_create_qp+0x321/0x380 [ib_core] [ 1064.257841] ib_process_cq_direct+0xbd/0x120 [ib_core] [ 1064.258007] irq_poll_softirq+0xb7/0xe0 [ 1064.258165] __do_softirq+0x106/0x2a2 [ 1064.258328] irq_exit+0x92/0xa0 [ 1064.258509] do_IRQ+0x4a/0xd0 [ 1064.258660] common_interrupt+0x7a/0x7a [ 1064.258818] Meanwhile another context frees other queue but with the same set of shared tags: [ 1288.201183] INFO: task bash:5910 blocked for more than 180 seconds. [ 1288.201833] bash D 0 5910 5820 0x00000000 [ 1288.202016] Call Trace: [ 1288.202315] schedule+0x32/0x80 [ 1288.202462] schedule_timeout+0x1e5/0x380 [ 1288.203838] wait_for_completion+0xb0/0x120 [ 1288.204137] __wait_rcu_gp+0x125/0x160 [ 1288.204287] synchronize_sched+0x6e/0x80 [ 1288.204770] blk_mq_free_queue+0x74/0xe0 [ 1288.204922] blk_cleanup_queue+0xc7/0x110 [ 1288.205073] ibnbd_clt_unmap_device+0x1bc/0x280 [ibnbd_client] [ 1288.205389] ibnbd_clt_unmap_dev_store+0x169/0x1f0 [ibnbd_client] [ 1288.205548] kernfs_fop_write+0x109/0x180 [ 1288.206328] vfs_write+0xb3/0x1a0 [ 1288.206476] SyS_write+0x52/0xc0 [ 1288.206624] do_syscall_64+0x68/0x1d0 [ 1288.206774] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 What happened is the following: 1. There are several MQ queues with shared tags. 2. One queue is about to be freed and now task is in blk_mq_del_queue_tag_set(). 3. Other CPU is in blk_mq_sched_restart() and loops over all queues in tag list in order to find hctx to restart. Because linked list entry was modified in blk_mq_del_queue_tag_set() without proper waiting for a grace period, blk_mq_sched_restart() never ends, spining in list_for_each_entry_rcu_rr(), thus soft lockup. Fix is simple: reinit list entry after an RCU grace period elapsed. Fixes: Fixes: 705cda97ee3a ("blk-mq: Make it safe to use RCU to iterate over blk_mq_tag_set.tag_list") Cc: stable@vger.kernel.org Cc: Sagi Grimberg Cc: linux-block@vger.kernel.org Reviewed-by: Christoph Hellwig Reviewed-by: Ming Lei Reviewed-by: Bart Van Assche Signed-off-by: Roman Pen Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 00946218ffe376ff3234ff3c81cd4193e3ca95e2 Author: Josef Bacik Date: Wed May 16 14:51:19 2018 -0400 nbd: use bd_set_size when updating disk size commit 9e2b19675d1338d2a38e99194756f2db44a081df upstream. When we stopped relying on the bdev everywhere I broke updating the block device size on the fly, which ceph relies on. We can't just do set_capacity, we also have to do bd_set_size so things like parted will notice the device size change. Fixes: 29eaadc ("nbd: stop using the bdev everywhere") cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a477d00557f59a20de6398a20808998ce97dce08 Author: Josef Bacik Date: Wed May 16 14:51:18 2018 -0400 nbd: update size when connected commit c3f7c9397609705ef848cc98a5fb429b3e90c3c4 upstream. I messed up changing the size of an NBD device while it was connected by not actually updating the device or doing the uevent. Fix this by updating everything if we're connected and we change the size. cc: stable@vger.kernel.org Fixes: 639812a ("nbd: don't set the device size until we're connected") Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit edee2e826640c1ba54d51914b1699bc24a1f32c9 Author: Josef Bacik Date: Wed May 16 14:51:17 2018 -0400 nbd: fix nbd device deletion commit 8364da4751cf22201d74933d5e634176f44ed407 upstream. This fixes a use after free bug, we shouldn't be doing disk->queue right after we do del_gendisk(disk). Save the queue and do the cleanup after the del_gendisk. Fixes: c6a4759ea0c9 ("nbd: add device refcounting") cc: stable@vger.kernel.org Signed-off-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ffb179cfbcf66da752524983a702e8adbaf462b7 Author: Shirish Pargaonkar Date: Mon Jun 4 06:46:22 2018 -0500 cifs: For SMB2 security informaion query, check for minimum sized security descriptor instead of sizeof FileAllInformation class commit ee25c6dd7b05113783ce1f4fab6b30fc00d29b8d upstream. Validate_buf () function checks for an expected minimum sized response passed to query_info() function. For security information, the size of a security descriptor can be smaller (one subauthority, no ACEs) than the size of the structure that defines FileInfoClass of FileAllInformation. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199725 Cc: Signed-off-by: Shirish Pargaonkar Reviewed-by: Noah Morrison Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 2a8737336dbd3906ec33c391a7b0f57d2f760d55 Author: Mark Syms Date: Thu May 24 09:47:31 2018 +0100 CIFS: 511c54a2f69195b28afb9dd119f03787b1625bb4 adds a check for session expiry commit d81243c697ffc71f983736e7da2db31a8be0001f upstream. Handle this additional status in the same way as SESSION_EXPIRED. Signed-off-by: Mark Syms Signed-off-by: Steve French CC: Stable Signed-off-by: Greg Kroah-Hartman commit ae62f35def75922782c7d2bdc9f7ca2097c3adce Author: Steve French Date: Thu May 31 15:19:25 2018 -0500 smb3: on reconnect set PreviousSessionId field commit b2adf22fdfba85a6701c481faccdbbb3a418ccfc upstream. The server detects reconnect by the (non-zero) value in PreviousSessionId of SMB2/SMB3 SessionSetup request, but this behavior regressed due to commit 166cea4dc3a4f66f020cfb9286225ecd228ab61d ("SMB2: Separate RawNTLMSSP authentication from SMB2_sess_setup") CC: Stable CC: Sachin Prabhu Signed-off-by: Steve French Reviewed-by: Ronnie Sahlberg Signed-off-by: Greg Kroah-Hartman commit dcde75924f25c21f6eb6e394782e930ed439dda5 Author: Steve French Date: Sat May 19 02:04:55 2018 -0500 smb3: fix various xid leaks commit cfe89091644c441a1ade6dae6d2e47b715648615 upstream. Fix a few cases where we were not freeing the xid which led to active requests being non-zero at unmount time. Signed-off-by: Steve French CC: Stable Reviewed-by: Ronnie Sahlberg Signed-off-by: Greg Kroah-Hartman commit e0b510a4170e220d978a6cfbe25e634193fffbfa Author: Tony Luck Date: Fri Apr 27 09:37:08 2018 -0700 x86/MCE: Fix stack out-of-bounds write in mce-inject.c: Flags_read() commit 985c78d3ff8e9c74450fa2bb08eb55e680d999ca upstream. Each of the strings that we want to put into the buf[MAX_FLAG_OPT_SIZE] in flags_read() is two characters long. But the sprintf() adds a trailing newline and will add a terminating NUL byte. So MAX_FLAG_OPT_SIZE needs to be 4. sprintf() calls vsnprintf() and *that* does return: " * The return value is the number of characters which would * be generated for the given input, excluding the trailing * '\0', as per ISO C99." Note the "excluding". Reported-by: Dmitry Vyukov Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Cc: linux-edac Link: http://lkml.kernel.org/r/20180427163707.ktaiysvbk3yhk4wm@agluck-desk Signed-off-by: Greg Kroah-Hartman commit c5c00990f75daa8cb50d6d26f2c5db8b9f3a50dc Author: Dennis Wassenberg Date: Tue Jun 12 07:11:11 2018 +0200 ALSA: hda: add dock and led support for HP ProBook 640 G4 commit 7eef32c1ef895a3a96463f9cbd04203007cd5555 upstream. This patch adds missing initialisation for HP 2013 UltraSlim Dock Line-In/Out PINs and activates keyboard mute/micmute leds for HP ProBook 640 G4 Signed-off-by: Dennis Wassenberg Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e6c9fd8cf7d05e8be07cfc741108440477deb5b6 Author: Dennis Wassenberg Date: Tue Jun 12 07:10:59 2018 +0200 ALSA: hda: add dock and led support for HP EliteBook 830 G5 commit 2861751f67b91e1d24e68010ced96614fb3140f4 upstream. This patch adds missing initialisation for HP 2013 UltraSlim Dock Line-In/Out PINs and activates keyboard mute/micmute leds for HP EliteBook 830 G5 Signed-off-by: Dennis Wassenberg Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a3eb20df0e23e23c6604fbff4d6c5a6c610f7dbc Author: Bo Chen Date: Thu May 31 15:35:18 2018 -0700 ALSA: hda - Handle kzalloc() failure in snd_hda_attach_pcm_stream() commit a3aa60d511746bd6c0d0366d4eb90a7998bcde8b upstream. When 'kzalloc()' fails in 'snd_hda_attach_pcm_stream()', a new pcm instance is created without setting its operators via 'snd_pcm_set_ops()'. Following operations on the new pcm instance can trigger kernel null pointer dereferences and cause kernel oops. This bug was found with my work on building a gray-box fault-injection tool for linux-kernel-module binaries. A kernel null pointer dereference was confirmed from line 'substream->ops->open()' in function 'snd_pcm_open_substream()' in file 'sound/core/pcm_native.c'. This patch fixes the bug by calling 'snd_device_free()' in the error handling path of 'kzalloc()', which removes the new pcm instance from the snd card before returns with an error code. Signed-off-by: Bo Chen Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 03701e42cc19323b9624fb7d12b855a8c5ef440e Author: Takashi Iwai Date: Fri May 18 12:14:32 2018 +0200 ALSA: hda/conexant - Add fixup for HP Z2 G4 workstation commit f16041df4c360eccacfe90f96673b37829e4c959 upstream. HP Z2 G4 requires the same workaround as other HP machines that have no mic-pin detection. Cc: Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ff7eb857eeca10368f43343ac8c5e6f39250adeb Author: Hui Wang Date: Wed May 30 12:33:07 2018 +0800 ALSA: hda/realtek - Enable mic-mute hotkey for several Lenovo AIOs commit 986376b68dcc95bb7df60ad30c2353c1f7578fa5 upstream. We have several Lenovo AIOs like M810z, M820z and M920z, they have the same design for mic-mute hotkey and led and they use the same codec with the same pin configuration, so use the pin conf table to apply fix to all of them. Fixes: 29693efcea0f ("ALSA: hda - Fix micmute hotkey problem for a lenovo AIO machine") Cc: Signed-off-by: Hui Wang Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b1cf23c2c8db7c73d3ae684fa13d0a28631d1768 Author: Qu Wenruo Date: Tue Jun 5 12:36:56 2018 +0800 btrfs: scrub: Don't use inode pages for device replace commit ac0b4145d662a3b9e34085dea460fb06ede9b69b upstream. [BUG] Btrfs can create compressed extent without checksum (even though it shouldn't), and if we then try to replace device containing such extent, the result device will contain all the uncompressed data instead of the compressed one. Test case already submitted to fstests: https://patchwork.kernel.org/patch/10442353/ [CAUSE] When handling compressed extent without checksum, device replace will goe into copy_nocow_pages() function. In that function, btrfs will get all inodes referring to this data extents and then use find_or_create_page() to get pages direct from that inode. The problem here is, pages directly from inode are always uncompressed. And for compressed data extent, they mismatch with on-disk data. Thus this leads to corrupted compressed data extent written to replace device. [FIX] In this attempt, we could just remove the "optimization" branch, and let unified scrub_pages() to handle it. Although scrub_pages() won't bother reusing page cache, it will be a little slower, but it does the correct csum checking and won't cause such data corruption caused by "optimization". Note about the fix: this is the minimal fix that can be backported to older stable trees without conflicts. The whole callchain from copy_nocow_pages() can be deleted, and will be in followup patches. Fixes: ff023aac3119 ("Btrfs: add code to scrub to copy read data to another disk") CC: stable@vger.kernel.org # 4.4+ Reported-by: James Harvey Reviewed-by: James Harvey Signed-off-by: Qu Wenruo [ remove code removal, add note why ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 4cb8942042bde6b58cac0c76d12a24b62ab0c76c Author: Su Yue Date: Wed May 30 16:48:56 2018 +0800 btrfs: return error value if create_io_em failed in cow_file_range commit 090a127afa8f73e9618d4058d6755f7ec7453dd6 upstream. In cow_file_range(), create_io_em() may fail, but its return value is not recorded. Then return value may be 0 even it failed which is a wrong behavior. Let cow_file_range() return PTR_ERR(em) if create_io_em() failed. Fixes: 6f9994dbabe5 ("Btrfs: create a helper to create em for IO") CC: stable@vger.kernel.org # 4.11+ Signed-off-by: Su Yue Reviewed-by: Nikolay Borisov Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5f7e3b5b96f8b787e95bfd91636261fd32d80dc2 Author: Omar Sandoval Date: Tue May 22 15:44:01 2018 -0700 Btrfs: fix memory and mount leak in btrfs_ioctl_rm_dev_v2() commit fd4e994bd1f9dc9628e168a7f619bf69f6984635 upstream. If we have invalid flags set, when we error out we must drop our writer counter and free the buffer we allocated for the arguments. This bug is trivially reproduced with the following program on 4.7+: #include #include #include #include #include #include #include #include #include #include int main(int argc, char **argv) { struct btrfs_ioctl_vol_args_v2 vol_args = { .flags = UINT64_MAX, }; int ret; int fd; if (argc != 2) { fprintf(stderr, "usage: %s PATH\n", argv[0]); return EXIT_FAILURE; } fd = open(argv[1], O_WRONLY); if (fd == -1) { perror("open"); return EXIT_FAILURE; } ret = ioctl(fd, BTRFS_IOC_RM_DEV_V2, &vol_args); if (ret == -1) perror("ioctl"); close(fd); return EXIT_SUCCESS; } When unmounting the filesystem, we'll hit the WARN_ON(mnt_get_writers(mnt)) in cleanup_mnt() and also may prevent the filesystem to be remounted read-only as the writer count will stay lifted. Fixes: 6b526ed70cf1 ("btrfs: introduce device delete by devid") CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Omar Sandoval Reviewed-by: Su Yue Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 55d29ff48222c89a7ca03b8eacb7d4f62fd651be Author: Omar Sandoval Date: Tue May 22 15:02:12 2018 -0700 Btrfs: fix clone vs chattr NODATASUM race commit b5c40d598f5408bd0ca22dfffa82f03cd9433f23 upstream. In btrfs_clone_files(), we must check the NODATASUM flag while the inodes are locked. Otherwise, it's possible that btrfs_ioctl_setflags() will change the flags after we check and we can end up with a party checksummed file. The race window is only a few instructions in size, between the if and the locks which is: 3834 if (S_ISDIR(src->i_mode) || S_ISDIR(inode->i_mode)) 3835 return -EISDIR; where the setflags must be run and toggle the NODATASUM flag (provided the file size is 0). The clone will block on the inode lock, segflags takes the inode lock, changes flags, releases log and clone continues. Not impossible but still needs a lot of bad luck to hit unintentionally. Fixes: 0e7b824c4ef9 ("Btrfs: don't make a file partly checksummed through file clone") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Omar Sandoval Reviewed-by: Nikolay Borisov Reviewed-by: David Sterba [ update changelog ] Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c81a6be9da6d9fd9264cf759f2676b07d0727b41 Author: Tetsuo Handa Date: Mon May 7 19:10:31 2018 +0900 driver core: Don't ignore class_dir_create_and_add() failure. commit 84d0c27d6233a9ba0578b20f5a09701eb66cee42 upstream. syzbot is hitting WARN() at kernfs_add_one() [1]. This is because kernfs_create_link() is confused by previous device_add() call which continued without setting dev->kobj.parent field when get_device_parent() failed by memory allocation fault injection. Fix this by propagating the error from class_dir_create_and_add() to the calllers of get_device_parent(). [1] https://syzkaller.appspot.com/bug?id=fae0fb607989ea744526d1c082a5b8de6529116f Signed-off-by: Tetsuo Handa Reported-by: syzbot Cc: Greg Kroah-Hartman Cc: stable Signed-off-by: Greg Kroah-Hartman commit f3233cb2485ce482cc2285354dcfca90094442ac Author: Jan Kara Date: Fri May 25 12:51:25 2018 -0400 ext4: fix fencepost error in check for inode count overflow during resize commit 4f2f76f751433908364ccff82f437a57d0e6e9b7 upstream. ext4_resize_fs() has an off-by-one bug when checking whether growing of a filesystem will not overflow inode count. As a result it allows a filesystem with 8192 inodes per group to grow to 64TB which overflows inode count to 0 and makes filesystem unusable. Fix it. Cc: stable@vger.kernel.org Fixes: 3f8a6411fbada1fa482276591e037f3b1adcf55b Reported-by: Jaco Kroon Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Signed-off-by: Greg Kroah-Hartman commit 21542545990c5aba4b919ac0f8c8ae6a408b49d4 Author: Theodore Ts'o Date: Wed May 23 11:31:03 2018 -0400 ext4: correctly handle a zero-length xattr with a non-zero e_value_offs commit 8a2b307c21d4b290e3cbe33f768f194286d07c23 upstream. Ext4 will always create ext4 extended attributes which do not have a value (where e_value_size is zero) with e_value_offs set to zero. In most places e_value_offs will not be used in a substantive way if e_value_size is zero. There was one exception to this, which is in ext4_xattr_set_entry(), where if there is a maliciously crafted file system where there is an extended attribute with e_value_offs is non-zero and e_value_size is 0, the attempt to remove this xattr will result in a negative value getting passed to memmove, leading to the following sadness: [ 41.225365] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null) [ 44.538641] BUG: unable to handle kernel paging request at ffff9ec9a3000000 [ 44.538733] IP: __memmove+0x81/0x1a0 [ 44.538755] PGD 1249bd067 P4D 1249bd067 PUD 1249c1067 PMD 80000001230000e1 [ 44.538793] Oops: 0003 [#1] SMP PTI [ 44.539074] CPU: 0 PID: 1470 Comm: poc Not tainted 4.16.0-rc1+ #1 ... [ 44.539475] Call Trace: [ 44.539832] ext4_xattr_set_entry+0x9e7/0xf80 ... [ 44.539972] ext4_xattr_block_set+0x212/0xea0 ... [ 44.540041] ext4_xattr_set_handle+0x514/0x610 [ 44.540065] ext4_xattr_set+0x7f/0x120 [ 44.540090] __vfs_removexattr+0x4d/0x60 [ 44.540112] vfs_removexattr+0x75/0xe0 [ 44.540132] removexattr+0x4d/0x80 ... [ 44.540279] path_removexattr+0x91/0xb0 [ 44.540300] SyS_removexattr+0xf/0x20 [ 44.540322] do_syscall_64+0x71/0x120 [ 44.540344] entry_SYSCALL_64_after_hwframe+0x21/0x86 https://bugzilla.kernel.org/show_bug.cgi?id=199347 This addresses CVE-2018-10840. Reported-by: "Xu, Wen" Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Cc: stable@kernel.org Fixes: dec214d00e0d7 ("ext4: xattr inode deduplication") Signed-off-by: Greg Kroah-Hartman commit 02d45ec6e770dcad4a48ad185feff588e3dcedc2 Author: Theodore Ts'o Date: Tue May 22 17:14:07 2018 -0400 ext4: bubble errors from ext4_find_inline_data_nolock() up to ext4_iget() commit eb9b5f01c33adebc31cbc236c02695f605b0e417 upstream. If ext4_find_inline_data_nolock() returns an error it needs to get reflected up to ext4_iget(). In order to fix this, ext4_iget_extra_inode() needs to return an error (and not return void). This is related to "ext4: do not allow external inodes for inline data" (which fixes CVE-2018-11412) in that in the errors=continue case, it would be useful to for userspace to receive an error indicating that file system is corrupted. Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit e81d371dac30019816a1c5a3a2c4c44bb3c68558 Author: Theodore Ts'o Date: Tue May 22 16:15:24 2018 -0400 ext4: do not allow external inodes for inline data commit 117166efb1ee8f13c38f9e96b258f16d4923f888 upstream. The inline data feature was implemented before we added support for external inodes for xattrs. It makes no sense to support that combination, but the problem is that there are a number of extended attribute checks that are skipped if e_value_inum is non-zero. Unfortunately, the inline data code is completely e_value_inum unaware, and attempts to interpret the xattr fields as if it were an inline xattr --- at which point, Hilarty Ensues. This addresses CVE-2018-11412. https://bugzilla.kernel.org/show_bug.cgi?id=199803 Reported-by: Jann Horn Reviewed-by: Andreas Dilger Signed-off-by: Theodore Ts'o Fixes: e50e5129f384 ("ext4: xattr-in-inode support") Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit bd713edfc85d20ba6a8ea970c0f542774084a4d2 Author: Lukas Czerner Date: Sun May 13 19:28:35 2018 -0400 ext4: update mtime in ext4_punch_hole even if no blocks are released commit eee597ac931305eff3d3fd1d61d6aae553bc0984 upstream. Currently in ext4_punch_hole we're going to skip the mtime update if there are no actual blocks to release. However we've actually modified the file by zeroing the partial block so the mtime should be updated. Moreover the sync and datasync handling is skipped as well, which is also wrong. Fix it. Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Reported-by: Joe Habermann Cc: Signed-off-by: Greg Kroah-Hartman commit f70af46a52b3c354643c92e8a59b34a86472559d Author: Jan Kara Date: Sat May 12 19:55:00 2018 -0400 ext4: fix hole length detection in ext4_ind_map_blocks() commit 2ee3ee06a8fd792765fa3267ddf928997797eec5 upstream. When ext4_ind_map_blocks() computes a length of a hole, it doesn't count with the fact that mapped offset may be somewhere in the middle of the completely empty subtree. In such case it will return too large length of the hole which then results in lseek(SEEK_DATA) to end up returning an incorrect offset beyond the end of the hole. Fix the problem by correctly taking offset within a subtree into account when computing a length of a hole. Fixes: facab4d9711e7aa3532cb82643803e8f1b9518e8 CC: stable@vger.kernel.org Reported-by: Jeff Mahoney Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 84f4d2c6dabef6622f4d22a592cf4d1dca9e7dae Author: Trond Myklebust Date: Thu Oct 19 15:46:45 2017 -0400 NFSv4.1: Fix up replays of interrupted requests commit 3be0f80b5fe9c16eca2d538f799b94ca8aa59433 upstream. If the previous request on a slot was interrupted before it was processed by the server, then our slot sequence number may be out of whack, and so we try the next operation using the old sequence number. The problem with this, is that not all servers check to see that the client is replaying the same operations as previously when they decide to go to the replay cache, and so instead of the expected error of NFS4ERR_SEQ_FALSE_RETRY, we get a replay of the old reply, which could (if the operations match up) be mistaken by the client for a new reply. To fix this, we attempt to send a COMPOUND containing only the SEQUENCE op in order to resync our slot sequence number. Cc: Olga Kornievskaia [olga.kornievskaia@gmail.com: fix an Oops] Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 5e8a5c30546f731b20591eb8cffc7db299286d05 Author: Daniel Borkmann Date: Fri Jun 15 03:07:45 2018 +0200 tls: fix use-after-free in tls_push_record [ Upstream commit a447da7d00410278c90d3576782a43f8b675d7be ] syzkaller managed to trigger a use-after-free in tls like the following: BUG: KASAN: use-after-free in tls_push_record.constprop.15+0x6a2/0x810 [tls] Write of size 1 at addr ffff88037aa08000 by task a.out/2317 CPU: 3 PID: 2317 Comm: a.out Not tainted 4.17.0+ #144 Hardware name: LENOVO 20FBCTO1WW/20FBCTO1WW, BIOS N1FET47W (1.21 ) 11/28/2016 Call Trace: dump_stack+0x71/0xab print_address_description+0x6a/0x280 kasan_report+0x258/0x380 ? tls_push_record.constprop.15+0x6a2/0x810 [tls] tls_push_record.constprop.15+0x6a2/0x810 [tls] tls_sw_push_pending_record+0x2e/0x40 [tls] tls_sk_proto_close+0x3fe/0x710 [tls] ? tcp_check_oom+0x4c0/0x4c0 ? tls_write_space+0x260/0x260 [tls] ? kmem_cache_free+0x88/0x1f0 inet_release+0xd6/0x1b0 __sock_release+0xc0/0x240 sock_close+0x11/0x20 __fput+0x22d/0x660 task_work_run+0x114/0x1a0 do_exit+0x71a/0x2780 ? mm_update_next_owner+0x650/0x650 ? handle_mm_fault+0x2f5/0x5f0 ? __do_page_fault+0x44f/0xa50 ? mm_fault_error+0x2d0/0x2d0 do_group_exit+0xde/0x300 __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x9a/0x300 ? page_fault+0x8/0x30 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This happened through fault injection where aead_req allocation in tls_do_encryption() eventually failed and we returned -ENOMEM from the function. Turns out that the use-after-free is triggered from tls_sw_sendmsg() in the second tls_push_record(). The error then triggers a jump to waiting for memory in sk_stream_wait_memory() resp. returning immediately in case of MSG_DONTWAIT. What follows is the trim_both_sgl(sk, orig_size), which drops elements from the sg list added via tls_sw_sendmsg(). Now the use-after-free gets triggered when the socket is being closed, where tls_sk_proto_close() callback is invoked. The tls_complete_pending_work() will figure that there's a pending closed tls record to be flushed and thus calls into the tls_push_pending_closed_record() from there. ctx->push_pending_record() is called from the latter, which is the tls_sw_push_pending_record() from sw path. This again calls into tls_push_record(). And here the tls_fill_prepend() will panic since the buffer address has been freed earlier via trim_both_sgl(). One way to fix it is to move the aead request allocation out of tls_do_encryption() early into tls_push_record(). This means we don't prep the tls header and advance state to the TLS_PENDING_CLOSED_RECORD before allocation which could potentially fail happened. That fixes the issue on my side. Fixes: 3c4d7559159b ("tls: kernel TLS support") Reported-by: syzbot+5c74af81c547738e1684@syzkaller.appspotmail.com Reported-by: syzbot+709f2810a6a05f11d4d3@syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann Acked-by: Dave Watson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 244c10f9bfa35b59e4acf61a0fb15a94f6110991 Author: Dexuan Cui Date: Wed Jun 6 21:32:51 2018 +0000 hv_netvsc: Fix a network regression after ifdown/ifup [ Upstream commit 52acf73b6e9a6962045feb2ba5a8921da2201915 ] Recently people reported the NIC stops working after "ifdown eth0; ifup eth0". It turns out in this case the TX queues are not enabled, after the refactoring of the common detach logic: when the NIC has sub-channels, usually we enable all the TX queues after all sub-channels are set up: see rndis_set_subchannel() -> netif_device_attach(), but in the case of "ifdown eth0; ifup eth0" where the number of channels doesn't change, we also must make sure the TX queues are enabled. The patch fixes the regression. Fixes: 7b2ee50c0cd5 ("hv_netvsc: common detach logic") Signed-off-by: Dexuan Cui Cc: Stephen Hemminger Cc: K. Y. Srinivasan Cc: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5320e035d7bbdade3755f90dc9b55ee542edc4d3 Author: Willem de Bruijn Date: Wed Jun 6 11:23:01 2018 -0400 net: in virtio_net_hdr only add VLAN_HLEN to csum_start if payload holds vlan [ Upstream commit fd3a88625844907151737fc3b4201676effa6d27 ] Tun, tap, virtio, packet and uml vector all use struct virtio_net_hdr to communicate packet metadata to userspace. For skbuffs with vlan, the first two return the packet as it may have existed on the wire, inserting the VLAN tag in the user buffer. Then virtio_net_hdr.csum_start needs to be adjusted by VLAN_HLEN bytes. Commit f09e2249c4f5 ("macvtap: restore vlan header on user read") added this feature to macvtap. Commit 3ce9b20f1971 ("macvtap: Fix csum_start when VLAN tags are present") then fixed up csum_start. Virtio, packet and uml do not insert the vlan header in the user buffer. When introducing virtio_net_hdr_from_skb to deduplicate filling in the virtio_net_hdr, the variant from macvtap which adds VLAN_HLEN was applied uniformly, breaking csum offset for packets with vlan on virtio and packet. Make insertion of VLAN_HLEN optional. Convert the callers to pass it when needed. Fixes: e858fae2b0b8f4 ("virtio_net: use common code for virtio_net_hdr and skb GSO conversion") Fixes: 1276f24eeef2 ("packet: use common code for virtio_net_hdr and skb GSO conversion") Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2e5d3168821d2ae523ebab5dd5df6a38f728b0d7 Author: Paolo Abeni Date: Fri Jun 8 11:35:40 2018 +0200 udp: fix rx queue len reported by diag and proc interface [ Upstream commit 6c206b20092a3623184cff9470dba75d21507874 ] After commit 6b229cf77d68 ("udp: add batching to udp_rmem_release()") the sk_rmem_alloc field does not measure exactly anymore the receive queue length, because we batch the rmem release. The issue is really apparent only after commit 0d4a6608f68c ("udp: do rmem bulk free even if the rx sk queue is empty"): the user space can easily check for an empty socket with not-0 queue length reported by the 'ss' tool or the procfs interface. We need to use a custom UDP helper to report the correct queue length, taking into account the forward allocation deficit. Reported-by: trevor.francis@46labs.com Fixes: 6b229cf77d68 ("UDP: add batching to udp_rmem_release()") Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 91717ffc9057f38a0203a40ef36ae2e482fd7cbe Author: Cong Wang Date: Thu Jun 7 13:39:49 2018 -0700 socket: close race condition between sock_close() and sockfs_setattr() [ Upstream commit 6d8c50dcb029872b298eea68cc6209c866fd3e14 ] fchownat() doesn't even hold refcnt of fd until it figures out fd is really needed (otherwise is ignored) and releases it after it resolves the path. This means sock_close() could race with sockfs_setattr(), which leads to a NULL pointer dereference since typically we set sock->sk to NULL in ->release(). As pointed out by Al, this is unique to sockfs. So we can fix this in socket layer by acquiring inode_lock in sock_close() and checking against NULL in sockfs_setattr(). sock_release() is called in many places, only the sock_close() path matters here. And fortunately, this should not affect normal sock_close() as it is only called when the last fd refcnt is gone. It only affects sock_close() with a parallel sockfs_setattr() in progress, which is not common. Fixes: 86741ec25462 ("net: core: Add a UID field to struct sock.") Reported-by: shankarapailoor Cc: Tetsuo Handa Cc: Lorenzo Colitti Cc: Al Viro Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 39f4ae01c1d6c6891b46d6cb1f3f869823bac21a Author: Frank van der Linden Date: Tue Jun 12 23:09:37 2018 +0000 tcp: verify the checksum of the first data segment in a new connection [ Upstream commit 4fd44a98ffe0d048246efef67ed640fdf2098a62 ] commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") introduced an optimization for the handling of child sockets created for a new TCP connection. But this optimization passes any data associated with the last ACK of the connection handshake up the stack without verifying its checksum, because it calls tcp_child_process(), which in turn calls tcp_rcv_state_process() directly. These lower-level processing functions do not do any checksum verification. Insert a tcp_checksum_complete call in the TCP_NEW_SYN_RECEIVE path to fix this. Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table") Signed-off-by: Frank van der Linden Signed-off-by: Eric Dumazet Tested-by: Balbir Singh Reviewed-by: Balbir Singh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 81d159444da5b4dc7fee9182b5f8596b84722789 Author: Davide Caratti Date: Fri Jun 8 05:02:31 2018 +0200 net/sched: act_simple: fix parsing of TCA_DEF_DATA [ Upstream commit 8d499533e0bc02d44283dbdab03142b599b8ba16 ] use nla_strlcpy() to avoid copying data beyond the length of TCA_DEF_DATA netlink attribute, in case it is less than SIMP_MAX_DATA and it does not end with '\0' character. v2: fix errors in the commit message, thanks Hangbin Liu Fixes: fa1b1cff3d06 ("net_cls_act: Make act_simple use of netlink policy.") Signed-off-by: Davide Caratti Reviewed-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 73c0eab8d2158ef08120e979ce96f4fd80bc4488 Author: Zhouyang Jia Date: Mon Jun 11 13:26:35 2018 +0800 net: dsa: add error handling for pskb_trim_rcsum [ Upstream commit 349b71d6f427ff8211adf50839dbbff3f27c1805 ] When pskb_trim_rcsum fails, the lack of error-handling code may cause unexpected results. This patch adds error-handling code after calling pskb_trim_rcsum. Signed-off-by: Zhouyang Jia Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6bcc27abfa62161ef7dae18dfe1bce70865b2aa8 Author: Julian Anastasov Date: Mon Jun 11 02:02:54 2018 +0300 ipv6: allow PMTU exceptions to local routes [ Upstream commit 0975764684487bf3f7a47eef009e750ea41bd514 ] IPVS setups with local client and remote tunnel server need to create exception for the local virtual IP. What we do is to change PMTU from 64KB (on "lo") to 1460 in the common case. Suggested-by: Martin KaFai Lau Fixes: 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception") Fixes: 7343ff31ebf0 ("ipv6: Don't create clones of host routes.") Signed-off-by: Julian Anastasov Acked-by: David Ahern Acked-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6e48ee025dc9a20cfe3fdc5a268cb0b971d58a4e Author: Bjørn Mork Date: Fri Jun 8 09:15:24 2018 +0200 cdc_ncm: avoid padding beyond end of skb [ Upstream commit 49c2c3f246e2fc3009039e31a826333dcd0283cd ] Commit 4a0e3e989d66 ("cdc_ncm: Add support for moving NDP to end of NCM frame") added logic to reserve space for the NDP at the end of the NTB/skb. This reservation did not take the final alignment of the NDP into account, causing us to reserve too little space. Additionally the padding prior to NDP addition did not ensure there was enough space for the NDP. The NTB/skb with the NDP appended would then exceed the configured max size. This caused the final padding of the NTB to use a negative count, padding to almost INT_MAX, and resulting in: [60103.825970] BUG: unable to handle kernel paging request at ffff9641f2004000 [60103.825998] IP: __memset+0x24/0x30 [60103.826001] PGD a6a06067 P4D a6a06067 PUD 4f65a063 PMD 72003063 PTE 0 [60103.826013] Oops: 0002 [#1] SMP NOPTI [60103.826018] Modules linked in: (removed( [60103.826158] CPU: 0 PID: 5990 Comm: Chrome_DevTools Tainted: G O 4.14.0-3-amd64 #1 Debian 4.14.17-1 [60103.826162] Hardware name: LENOVO 20081 BIOS 41CN28WW(V2.04) 05/03/2012 [60103.826166] task: ffff964193484fc0 task.stack: ffffb2890137c000 [60103.826171] RIP: 0010:__memset+0x24/0x30 [60103.826174] RSP: 0000:ffff964316c03b68 EFLAGS: 00010216 [60103.826178] RAX: 0000000000000000 RBX: 00000000fffffffd RCX: 000000001ffa5000 [60103.826181] RDX: 0000000000000005 RSI: 0000000000000000 RDI: ffff9641f2003ffc [60103.826184] RBP: ffff964192f6c800 R08: 00000000304d434e R09: ffff9641f1d2c004 [60103.826187] R10: 0000000000000002 R11: 00000000000005ae R12: ffff9642e6957a80 [60103.826190] R13: ffff964282ff2ee8 R14: 000000000000000d R15: ffff9642e4843900 [60103.826194] FS: 00007f395aaf6700(0000) GS:ffff964316c00000(0000) knlGS:0000000000000000 [60103.826197] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [60103.826200] CR2: ffff9641f2004000 CR3: 0000000013b0c000 CR4: 00000000000006f0 [60103.826204] Call Trace: [60103.826212] [60103.826225] cdc_ncm_fill_tx_frame+0x5e3/0x740 [cdc_ncm] [60103.826236] cdc_ncm_tx_fixup+0x57/0x70 [cdc_ncm] [60103.826246] usbnet_start_xmit+0x5d/0x710 [usbnet] [60103.826254] ? netif_skb_features+0x119/0x250 [60103.826259] dev_hard_start_xmit+0xa1/0x200 [60103.826267] sch_direct_xmit+0xf2/0x1b0 [60103.826273] __dev_queue_xmit+0x5e3/0x7c0 [60103.826280] ? ip_finish_output2+0x263/0x3c0 [60103.826284] ip_finish_output2+0x263/0x3c0 [60103.826289] ? ip_output+0x6c/0xe0 [60103.826293] ip_output+0x6c/0xe0 [60103.826298] ? ip_forward_options+0x1a0/0x1a0 [60103.826303] tcp_transmit_skb+0x516/0x9b0 [60103.826309] tcp_write_xmit+0x1aa/0xee0 [60103.826313] ? sch_direct_xmit+0x71/0x1b0 [60103.826318] tcp_tasklet_func+0x177/0x180 [60103.826325] tasklet_action+0x5f/0x110 [60103.826332] __do_softirq+0xde/0x2b3 [60103.826337] irq_exit+0xae/0xb0 [60103.826342] do_IRQ+0x81/0xd0 [60103.826347] common_interrupt+0x98/0x98 [60103.826351] [60103.826355] RIP: 0033:0x7f397bdf2282 [60103.826358] RSP: 002b:00007f395aaf57d8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff6e [60103.826362] RAX: 0000000000000000 RBX: 00002f07bc6d0900 RCX: 00007f39752d7fe7 [60103.826365] RDX: 0000000000000022 RSI: 0000000000000147 RDI: 00002f07baea02c0 [60103.826368] RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 [60103.826371] R10: 00000000ffffffff R11: 0000000000000000 R12: 00002f07baea02c0 [60103.826373] R13: 00002f07bba227a0 R14: 00002f07bc6d090c R15: 0000000000000000 [60103.826377] Code: 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 [60103.826442] RIP: __memset+0x24/0x30 RSP: ffff964316c03b68 [60103.826444] CR2: ffff9641f2004000 Commit e1069bbfcf3b ("net: cdc_ncm: Reduce memory use when kernel memory low") made this bug much more likely to trigger by reducing the NTB size under memory pressure. Link: https://bugs.debian.org/893393 Reported-by: Горбешко Богдан Reported-and-tested-by: Dennis Wassenberg Cc: Enrico Mioso Fixes: 4a0e3e989d66 ("cdc_ncm: Add support for moving NDP to end of NCM frame") Signed-off-by: Bjørn Mork Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 584b975af0d29c461920acb4d512f70b0bbe3661 Author: Xiangning Yu Date: Thu Jun 7 13:39:59 2018 +0800 bonding: re-evaluate force_primary when the primary slave name changes [ Upstream commit eb55bbf865d9979098c6a7a17cbdb41237ece951 ] There is a timing issue under active-standy mode, when bond_enslave() is called, bond->params.primary might not be initialized yet. Any time the primary slave string changes, bond->force_primary should be set to true to make sure the primary becomes the active slave. Signed-off-by: Xiangning Yu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 33445c07cd45541410fb4cabd08b10827764c07f Author: Greg Kroah-Hartman Date: Thu Jun 21 04:03:02 2018 +0900 Linux 4.14.51 commit 40c809774c692877b1167003d9807f7aaa46ad2b Author: Eric Dumazet Date: Sun Dec 10 17:55:02 2017 -0800 tcp: do not overshoot window_clamp in tcp_rcv_space_adjust() commit 02db55718d53f9d426cee504c27fb768e9ed4ffe upstream. While rcvbuf is properly clamped by tcp_rmem[2], rcvwin is left to a potentially too big value. It has no serious effect, since : 1) tcp_grow_window() has very strict checks. 2) window_clamp can be mangled by user space to any value anyway. tcp_init_buffer_space() and companions use tcp_full_space(), we use tcp_win_from_space() to avoid reloading sk->sk_rcvbuf Signed-off-by: Eric Dumazet Acked-by: Soheil Hassas Yeganeh Acked-by: Wei Wang Acked-by: Neal Cardwell Signed-off-by: David S. Miller Cc: Benjamin Gilbert Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 7ab8fc065fff258d0b2c5e48e529fd780905db45 Author: Liu Bo Date: Fri Jun 15 02:39:04 2018 +0000 Btrfs: make raid6 rebuild retry more [ Upstream commit 8810f7517a3bc4ca2d41d022446d3f5fd6b77c09 ] There is a scenario that can end up with rebuild process failing to return good content, i.e. suppose that all disks can be read without problems and if the content that was read out doesn't match its checksum, currently for raid6 btrfs at most retries twice, - the 1st retry is to rebuild with all other stripes, it'll eventually be a raid5 xor rebuild, - if the 1st fails, the 2nd retry will deliberately fail parity p so that it will do raid6 style rebuild, however, the chances are that another non-parity stripe content also has something corrupted, so that the above retries are not able to return correct content, and users will think of this as data loss. More seriouly, if the loss happens on some important internal btree roots, it could refuse to mount. This extends btrfs to do more retries and each retry fails only one stripe. Since raid6 can tolerate 2 disk failures, if there is one more failure besides the failure on which we're recovering, this can always work. The worst case is to retry as many times as the number of raid6 disks, but given the fact that such a scenario is really rare in practice, it's still acceptable. Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6bf89b7c6b319259f7991a424187ab2647db6424 Author: Liu Bo Date: Fri Jun 15 02:39:02 2018 +0000 Btrfs: fix scrub to repair raid6 corruption [ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ] The raid6 corruption is that, suppose that all disks can be read without problems and if the content that was read out doesn't match its checksum, currently for raid6 btrfs at most retries twice, - the 1st retry is to rebuild with all other stripes, it'll eventually be a raid5 xor rebuild, - if the 1st fails, the 2nd retry will deliberately fail parity p so that it will do raid6 style rebuild, however, the chances are that another non-parity stripe content also has something corrupted, so that the above retries are not able to return correct content. We've fixed normal reads to rebuild raid6 correctly with more retries in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix scrub to do the exactly same rebuild process. [1]: https://patchwork.kernel.org/patch/10091755/ Signed-off-by: Liu Bo Signed-off-by: David Sterba Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit db5f02cc70a8251e103241cc230e01392729739c Author: Sasha Levin Date: Fri Jun 15 02:39:01 2018 +0000 Revert "Btrfs: fix scrub to repair raid6 corruption" This reverts commit d91bb7c6988bd6450284c762b33f2e1ea3fe7c97. This commit used an incorrect log message. Signed-off-by: Sasha Levin Reported-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 5e4b5b7194d3d561e8791c167eb1e671b96ca575 Author: Russell King Date: Wed Apr 11 18:24:01 2018 +0100 ARM: kexec: fix kdump register saving on panic() [ Upstream commit 2d7b3c64431245c95b05a441669c074da10db943 ] When a panic() occurs, the kexec code uses smp_send_stop() to stop the other CPUs, but this results in the CPU register state not being saved, and gdb is unable to inspect the state of other CPUs. Commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump friendly version in panic path") addressed the issue on x86, but ignored other architectures. Address the issue on ARM by splitting out the crash stop implementation to crash_smp_send_stop() and adding the necessary protection. Signed-off-by: Russell King Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb7a554ae7454ba921d3d59d9480e90c117f97d3 Author: Łukasz Stelmach Date: Wed Apr 4 08:46:58 2018 +0100 ARM: 8758/1: decompressor: restore r1 and r2 just before jumping to the kernel [ Upstream commit f2ae9de019e4e2807d812ec4fe1df7c34788a0a0 ] The hypervisor setup before __enter_kernel destroys the value sotred in r1. The value needs to be restored just before the jump. Fixes: 6b52f7bdb888 ("ARM: hyp-stub: Use r1 for the soft-restart address") Signed-off-by: Łukasz Stelmach Signed-off-by: Russell King Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c7d7e3f62dbe0908213a922a714961ec56628c21 Author: Łukasz Stelmach Date: Tue Apr 3 09:04:57 2018 +0100 ARM: 8753/1: decompressor: add a missing parameter to the addruart macro [ Upstream commit e07e3c33b9c0b5751ade624f44325c9bf2487ea6 ] In commit 639da5ee374b ("ARM: add an extra temp register to the low level debugging addruart macro") an additional temporary register was added to the addruart macro, but the decompressor code wasn't updated. Fixes: 639da5ee374b ("ARM: add an extra temp register to the low level debugging addruart macro") Signed-off-by: Łukasz Stelmach Signed-off-by: Russell King Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 823e02ea7be553c9a2dddffe72ac3bc88c6a3933 Author: Mark Rutland Date: Fri May 18 16:08:41 2018 +0200 efi/libstub/arm64: Handle randomized TEXT_OFFSET [ Upstream commit 4f74d72aa7067e75af92fbab077e6d7d0210be66 ] When CONFIG_RANDOMIZE_TEXT_OFFSET=y, TEXT_OFFSET is an arbitrary multiple of PAGE_SIZE in the interval [0, 2MB). The EFI stub does not account for the potential misalignment of TEXT_OFFSET relative to EFI_KIMG_ALIGN, and produces a randomized physical offset which is always a round multiple of EFI_KIMG_ALIGN. This may result in statically allocated objects whose alignment exceeds PAGE_SIZE to appear misaligned in memory. This has been observed to result in spurious stack overflow reports and failure to make use of the IRQ stacks, and theoretically could result in a number of other issues. We can OR in the low bits of TEXT_OFFSET to ensure that we have the necessary offset (and hence preserve the misalignment of TEXT_OFFSET relative to EFI_KIMG_ALIGN), so let's do that. Reported-by: Kim Phillips Tested-by: Kim Phillips [ardb: clarify comment and commit log, drop unneeded parens] Signed-off-by: Mark Rutland Signed-off-by: Ard Biesheuvel Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 6f26b3671184c36d ("arm64: kaslr: increase randomization granularity") Link: http://lkml.kernel.org/r/20180518140841.9731-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f5c7add0d0f568e30c7b645175ef2edd5c9bebb Author: Helge Deller Date: Fri May 18 16:12:12 2018 +0200 parisc: Move setup_profiling_timer() out of init section [ Upstream commit 01f56832cfb6fcc204e7203f46841b6185ebd574 ] No other architecture has setup_profiling_timer() in the init section, thus on parisc we face this section mismatch warning: Reference from the function devm_device_add_group() to the function .init.text:setup_profiling_timer() Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 588977742078d730aca04fb9eacdbfcae8873316 Author: Mathieu Malaterre Date: Wed May 16 22:09:02 2018 +0200 sched/deadline: Make the grub_reclaim() function static [ Upstream commit 3febfc8a219a036633b57a34c6678e21b6a0580d ] Since the grub_reclaim() function can be made static, make it so. Silences the following GCC warning (W=1): kernel/sched/deadline.c:1120:5: warning: no previous prototype for ‘grub_reclaim’ [-Wmissing-prototypes] Signed-off-by: Mathieu Malaterre Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20180516200902.959-1-malat@debian.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb49d19ed9da82f26d3e43122ddaf8bf31a122bd Author: Mathieu Malaterre Date: Wed May 16 21:53:47 2018 +0200 sched/debug: Move the print_rt_rq() and print_dl_rq() declarations to kernel/sched/sched.h [ Upstream commit f6a3463063f42d9fb2c78f386437a822e0ad1792 ] In the following commit: 6b55c9654fcc ("sched/debug: Move print_cfs_rq() declaration to kernel/sched/sched.h") the print_cfs_rq() prototype was added to , right next to the prototypes for print_cfs_stats(), print_rt_stats() and print_dl_stats(). Finish this previous commit and also move related prototypes for print_rt_rq() and print_dl_rq(). Remove existing extern declarations now that they not needed anymore. Silences the following GCC warning, triggered by W=1: kernel/sched/debug.c:573:6: warning: no previous prototype for ‘print_rt_rq’ [-Wmissing-prototypes] kernel/sched/debug.c:603:6: warning: no previous prototype for ‘print_dl_rq’ [-Wmissing-prototypes] Signed-off-by: Mathieu Malaterre Acked-by: Peter Zijlstra Cc: Linus Torvalds Cc: Srikar Dronamraju Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20180516195348.30426-1-malat@debian.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 96ef5c44149479f13b8943a556f4193d126e1222 Author: Dan Carpenter Date: Wed May 16 17:00:26 2018 +0300 drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl() [ Upstream commit 2b6207291b7b277a5df9d1aab44b56815a292dba ] There is a comment here which says that DIV_ROUND_UP() and that's where the problem comes from. Say you pick: args->bpp = UINT_MAX - 7; args->width = 4; args->height = 1; The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and because of how we picked args->width that means cpp < UINT_MAX / 4. I've fixed it by preventing the integer overflow in DIV_ROUND_UP(). I removed the check for !cpp because it's not possible after this change. I also changed all the 0xffffffffU references to U32_MAX. Signed-off-by: Dan Carpenter Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180516140026.GA19340@mwanda Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 77a60e752ec8d2b0b507d55f7a5aa36e6c8c15e7 Author: Waiman Long Date: Tue May 15 17:49:51 2018 -0400 locking/percpu-rwsem: Annotate rwsem ownership transfer by setting RWSEM_OWNER_UNKNOWN [ Upstream commit 5a817641f68a6399a5fac8b7d2da67a73698ffed ] The filesystem freezing code needs to transfer ownership of a rwsem embedded in a percpu-rwsem from the task that does the freezing to another one that does the thawing by calling percpu_rwsem_release() after freezing and percpu_rwsem_acquire() before thawing. However, the new rwsem debug code runs afoul with this scheme by warning that the task that releases the rwsem isn't the one that acquires it, as reported by Amir Goldstein: DEBUG_LOCKS_WARN_ON(sem->owner != get_current()) WARNING: CPU: 1 PID: 1401 at /home/amir/build/src/linux/kernel/locking/rwsem.c:133 up_write+0x59/0x79 Call Trace: percpu_up_write+0x1f/0x28 thaw_super_locked+0xdf/0x120 do_vfs_ioctl+0x270/0x5f1 ksys_ioctl+0x52/0x71 __x64_sys_ioctl+0x16/0x19 do_syscall_64+0x5d/0x167 entry_SYSCALL_64_after_hwframe+0x49/0xbe To work properly with the rwsem debug code, we need to annotate that the rwsem ownership is unknown during the tranfer period until a brave soul comes forward to acquire the ownership. During that period, optimistic spinning will be disabled. Reported-by: Amir Goldstein Tested-by: Amir Goldstein Signed-off-by: Waiman Long Acked-by: Peter Zijlstra Cc: Andrew Morton Cc: Davidlohr Bueso Cc: Jan Kara Cc: Linus Torvalds Cc: Matthew Wilcox Cc: Oleg Nesterov Cc: Paul E. McKenney Cc: Theodore Y. Ts'o Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-fsdevel@vger.kernel.org Link: http://lkml.kernel.org/r/1526420991-21213-3-git-send-email-longman@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b3f84e48786d5696153917f7d93a0e3a5c21b294 Author: Waiman Long Date: Tue May 15 17:49:50 2018 -0400 locking/rwsem: Add a new RWSEM_ANONYMOUSLY_OWNED flag [ Upstream commit d7d760efad70c7a030725499bf9f342f04af24dd ] There are use cases where a rwsem can be acquired by one task, but released by another task. In thess cases, optimistic spinning may need to be disabled. One example will be the filesystem freeze/thaw code where the task that freezes the filesystem will acquire a write lock on a rwsem and then un-owns it before returning to userspace. Later on, another task will come along, acquire the ownership, thaw the filesystem and release the rwsem. Bit 0 of the owner field was used to designate that it is a reader owned rwsem. It is now repurposed to mean that the owner of the rwsem is not known. If only bit 0 is set, the rwsem is reader owned. If bit 0 and other bits are set, it is writer owned with an unknown owner. One such value for the latter case is (-1L). So we can set owner to 1 for reader-owned, -1 for writer-owned. The owner is unknown in both cases. To handle transfer of rwsem ownership, the higher level code should set the owner field to -1 to indicate a write-locked rwsem with unknown owner. Optimistic spinning will be disabled in this case. Once the higher level code figures who the new owner is, it can then set the owner field accordingly. Tested-by: Amir Goldstein Signed-off-by: Waiman Long Acked-by: Peter Zijlstra Cc: Andrew Morton Cc: Davidlohr Bueso Cc: Jan Kara Cc: Linus Torvalds Cc: Matthew Wilcox Cc: Oleg Nesterov Cc: Paul E. McKenney Cc: Theodore Y. Ts'o Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-fsdevel@vger.kernel.org Link: http://lkml.kernel.org/r/1526420991-21213-2-git-send-email-longman@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5746752bdbe4e7c6512d581dce5cc4ebc45ae75 Author: Stefan Agner Date: Wed Apr 18 14:49:08 2018 +0200 clk: imx6ull: use OSC clock during AXI rate change [ Upstream commit 2e5be528ab0182ad4b42b9feea3b80f85f37179b ] On i.MX6 ULL using PLL3 seems to cause a freeze when setting the parent to IMX6UL_CLK_PLL3_USB_OTG. This only seems to appear since commit 6f9575e55632 ("clk: imx: Add CLK_IS_CRITICAL flag for busy divider and busy mux"), probably because the clock is now forced to be on. Fixes: 6f9575e55632("clk: imx: Add CLK_IS_CRITICAL flag for busy divider and busy mux") Signed-off-by: Stefan Agner Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0c5dfa51caf77461da90b3af1f1ec28490255bc0 Author: Sekhar Nori Date: Fri May 11 20:51:36 2018 +0530 ARM: davinci: board-dm646x-evm: set VPIF capture card name [ Upstream commit bb7298a7e87cf3430eb62be8746e5d7a07ca9d7c ] VPIF capture driver expects card name to be set since it uses it without checking for NULL. The commit which introduced VPIF display and capture support added card name only for display, not for capture. Set it in platform data to probe driver successfully. While at it, also fix the display card name to something more appropriate. Fixes: 85609c1ccda6 ("DaVinci: DM646x - platform changes for vpif capture and display drivers") Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit eb6b0d6987fc58c5dc79abba8a82e1fe999ef602 Author: Sekhar Nori Date: Fri May 11 20:51:35 2018 +0530 ARM: davinci: board-dm646x-evm: pass correct I2C adapter id for VPIF [ Upstream commit 7d46899d57f8b61eb28701d9a4043b71e3392c26 ] commit a16cb91ad9c4 ("[media] media: vpif: use a configurable i2c_adapter_id for vpif display") removed hardcoded I2C adaptor setting in VPIF driver, but missed updating platform data passed from DM646x board. Fix it. Fixes: a16cb91ad9c4 ("[media] media: vpif: use a configurable i2c_adapter_id for vpif display") Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ae7418dd09f9879b21fb7b8c8ddb2e3ce8d4523d Author: Sekhar Nori Date: Fri May 11 20:51:34 2018 +0530 ARM: davinci: dm646x: fix timer interrupt generation [ Upstream commit 73d4337ed9ceddef4b2f0e226634d5f985aa2d1c ] commit b38434145b34 ("ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x") inadvertently removed priority setting for timer0_12 (bottom half of timer0). This timer is used as clockevent. When INTPRIn register setting for an interrupt is left at 0, it is mapped to FIQ by the AINTC causing the timer interrupt to not get generated. Fix it by including an entry for timer0_12 in interrupt priority map array. While at it, move the clockevent comment to the right place. Fixes: b38434145b34 ("ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x") Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit daf6bdb29d55325d49bb00bacda154e91b374975 Author: Peter Rosin Date: Wed May 9 21:47:48 2018 +0200 i2c: viperboard: return message count on master_xfer success [ Upstream commit 35cd67a0caf767aba472452865dcb4471fcce2b1 ] Returning zero is wrong in this case. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 174a13aa8669 ("i2c: Add viperboard i2c master driver") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cbfe697cdba95c055830f4e04cb4d30a4fdd6be1 Author: Peter Rosin Date: Wed May 9 21:46:30 2018 +0200 i2c: pmcmsp: fix error return from master_xfer [ Upstream commit 12d9bbc5a7f347eaa65ff2a9d34995cadc05eb1b ] Returning -1 (-EPERM) is not appropriate here, go with -EIO. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 1b144df1d7d6 ("i2c: New PMC MSP71xx TWI bus driver") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0c1885743a9bdd554d20c368d775142224abdff9 Author: Peter Rosin Date: Wed May 9 21:46:29 2018 +0200 i2c: pmcmsp: return message count on master_xfer success [ Upstream commit de9a8634f1cb4560a35696d472cc7f1383d9b866 ] Returning zero is wrong in this case. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 1b144df1d7d6 ("i2c: New PMC MSP71xx TWI bus driver") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7416dd78ad9a5c1e254d293cf5e3fee8656665cc Author: Russell King Date: Thu May 10 14:24:20 2018 +0100 ARM: keystone: fix platform_domain_notifier array overrun [ Upstream commit 9954b80b8c0e8abc98e17bba0fccd9876211ceaa ] platform_domain_notifier contains a variable sized array, which the pm_clk_notify() notifier treats as a NULL terminated array: for (con_id = clknb->con_ids; *con_id; con_id++) pm_clk_add(dev, *con_id); Omitting the initialiser for con_ids means that the array is zero sized, and there is no NULL terminator. This leads to pm_clk_notify() overrunning into what ever structure follows, which may not be NULL. This leads to an oops: Unable to handle kernel NULL pointer dereference at virtual address 0000008c pgd = c0003000 [0000008c] *pgd=80000800004003c, *pmd=00000000c Internal error: Oops: 206 [#1] PREEMPT SMP ARM Modules linked in:c CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.16.0+ #9 Hardware name: Keystone PC is at strlen+0x0/0x34 LR is at kstrdup+0x18/0x54 pc : [] lr : [] psr: 20000013 sp : eec73dc0 ip : eed780c0 fp : 00000001 r10: 00000000 r9 : 00000000 r8 : eed71e10 r7 : 0000008c r6 : 0000008c r5 : 014000c0 r4 : c03a6ff4 r3 : c09445d0 r2 : 00000000 r1 : 014000c0 r0 : 0000008c Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 30c5387d Table: 00003000 DAC: fffffffd Process swapper/0 (pid: 1, stack limit = 0xeec72210) Stack: (0xeec73dc0 to 0xeec74000) ... [] (strlen) from [] (kstrdup+0x18/0x54) [] (kstrdup) from [] (__pm_clk_add+0x58/0x120) [] (__pm_clk_add) from [] (pm_clk_notify+0x64/0xa8) [] (pm_clk_notify) from [] (notifier_call_chain+0x44/0x84) [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x48/0x60) [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x18/0x20) [] (blocking_notifier_call_chain) from [] (device_add+0x36c/0x534) [] (device_add) from [] (of_platform_device_create_pdata+0x70/0xa4) [] (of_platform_device_create_pdata) from [] (of_platform_bus_create+0xf0/0x1ec) [] (of_platform_bus_create) from [] (of_platform_populate+0x5c/0xac) [] (of_platform_populate) from [] (of_platform_default_populate_init+0x8c/0xa8) [] (of_platform_default_populate_init) from [] (do_one_initcall+0x3c/0x164) [] (do_one_initcall) from [] (kernel_init_freeable+0x10c/0x1d0) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) Exception stack(0xeec73fb0 to 0xeec73ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Code: e3520000 1afffff7 e12fff1e c0801730 (e5d02000) ---[ end trace cafa8f148e262e80 ]--- Fix this by adding the necessary initialiser. Fixes: fc20ffe1213b ("ARM: keystone: add PM domain support for clock management") Signed-off-by: Russell King Acked-by: Santosh Shilimkar Signed-off-by: Olof Johansson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a187b9c72d0cc71d30abfc6e2a5e692a897177bb Author: Daniel Glöckner Date: Mon May 14 09:40:05 2018 -0500 usb: musb: fix remote wakeup racing with suspend [ Upstream commit ebc3dd688cd988754a304147753b13e58de1b5a1 ] It has been observed that writing 0xF2 to the power register while it reads as 0xF4 results in the register having the value 0xF0, i.e. clearing RESUME and setting SUSPENDM in one go does not work. It might also violate the USB spec to transition directly from resume to suspend, especially when not taking T_DRSMDN into account. But this is what happens when a remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the root hub and musb_bus_suspend being called. This commit returns -EBUSY when musb_bus_suspend is called while remote wakeup is signalled and thus avoids to reset the RESUME bit. Ignoring this error when musb_port_suspend is called from musb_hub_control is ok. Signed-off-by: Daniel Glöckner Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 634b9e0aabd92d2b6f0df7580b60fd0921b1c578 Author: David Howells Date: Thu May 10 23:10:40 2018 +0100 afs: Fix the non-encryption of calls [ Upstream commit 4776cab43fd3111618112737a257dc3ef368eddd ] Some AFS servers refuse to accept unencrypted traffic, so can't be accessed with kAFS. Set the AF_RXRPC security level to encrypt client calls to deal with this. Note that incoming service calls are set by the remote client and so aren't affected by this. This requires an AF_RXRPC patch to pass the value set by setsockopt to calls begun by the kernel. Signed-off-by: David Howells Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a92a286361572e65988e37ac7c5da91a04e26a01 Author: Ben Hutchings Date: Thu May 10 19:20:54 2018 +0100 mtd: Fix comparison in map_word_andequal() [ Upstream commit ea739a287f4f16d6250bea779a1026ead79695f2 ] Commit 9e343e87d2c4 ("mtd: cfi: convert inline functions to macros") changed map_word_andequal() into a macro, but also changed the right hand side of the comparison from val3 to val2. Change it back to use val3 on the right hand side. Thankfully this did not cause a regression because all callers currently pass the same argument for val2 and val3. Fixes: 9e343e87d2c4 ("mtd: cfi: convert inline functions to macros") Signed-off-by: Ben Hutchings Signed-off-by: Boris Brezillon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9b9ac282bad9a0463a9dbc7cd4c9de30c03ca5f9 Author: Dave Hansen Date: Wed May 9 10:13:56 2018 -0700 x86/pkeys/selftests: Add a test for pkey 0 [ Upstream commit 3488a600d90bcaf061b104dbcfbdc8d99b398312 ] Protection key 0 is the default key for all memory and will not normally come back from pkey_alloc(). But, you might still want pass it to mprotect_pkey(). This check ensures that you can use pkey 0. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171356.9E40B254@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1f192a9e0cd3591142841731e01e5d9eb1c793d Author: Dave Hansen Date: Wed May 9 10:13:54 2018 -0700 x86/pkeys/selftests: Save off 'prot' for allocations [ Upstream commit acb25d761d6f2f64e785ccefc71e54f244f1eda4 ] This makes it possible to to tell what 'prot' a given allocation is supposed to have. That way, if we want to change just the pkey, we know what 'prot' to pass to mprotect_pkey(). Also, keep a record of the most recent allocation so the tests can easily find it. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171354.AA23E228@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cdfdffcaa8f99139f4b5e49790b4465a64a85839 Author: Dave Hansen Date: Wed May 9 10:13:52 2018 -0700 x86/pkeys/selftests: Fix pointer math [ Upstream commit 3d64f4ed15c3c53dba4c514bf59c334464dee373 ] We dump out the entire area of the siginfo where the si_pkey_ptr is supposed to be. But, we do some math on the poitner, which is a u32. We intended to do byte math, not u32 math on the pointer. Cast it over to a u8* so it works. Also, move this block of code to below th si_code check. It doesn't hurt anything, but the si_pkey field is gibberish for other signal types. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171352.9BE09819@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2dd0e5d62a6b167cc3889d05da37b293bc21f2f0 Author: Dave Hansen Date: Wed May 9 10:13:50 2018 -0700 x86/pkeys/selftests: Fix pkey exhaustion test off-by-one [ Upstream commit f50b4878329ab61d8e05796f655adeb6f5fb57c6 ] In our "exhaust all pkeys" test, we make sure that there is the expected number available. Turns out that the test did not cover the execute-only key, but discussed it anyway. It did *not* discuss the test-allocated key. Now that we have a test for the mprotect(PROT_EXEC) case, this off-by-one issue showed itself. Correct the off-by- one and add the explanation for the case we missed. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171350.E1656B95@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 63bdea73bd5283ee66df1a3aa1cebd34a2dc181f Author: Dave Hansen Date: Wed May 9 10:13:48 2018 -0700 x86/pkeys/selftests: Add PROT_EXEC test [ Upstream commit 6af17cf89e99b64cf1f660bf848755442ab2f047 ] Under the covers, implement executable-only memory with protection keys when userspace calls mprotect(PROT_EXEC). But, we did not have a selftest for that. Now we do. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171348.9EEE4BEF@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 1fcd226878b3f8eb838dab7bef6d423cdec6035c Author: Dave Hansen Date: Wed May 9 10:13:47 2018 -0700 x86/pkeys/selftests: Factor out "instruction page" [ Upstream commit 3fcd2b2d928904cbf30b01e2c5e4f1dd2f9ab262 ] We currently have an execute-only test, but it is for the explicit mprotect_pkey() interface. We will soon add a test for the implicit mprotect(PROT_EXEC) enterface. We need this code in both tests. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171347.C64AB733@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 777d513aaaf620dab38bbbbb32d4191e18714c89 Author: Dave Hansen Date: Wed May 9 10:13:46 2018 -0700 x86/pkeys/selftests: Allow faults on unknown keys [ Upstream commit 7e7fd67ca39335a49619729821efb7cbdd674eb0 ] The exec-only pkey is allocated inside the kernel and userspace is not told what it is. So, allow PK faults to occur that have an unknown key. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171345.7FC7DA00@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9545530701c9031ac5431f388ad82b28acc3fc75 Author: Dave Hansen Date: Wed May 9 10:13:42 2018 -0700 x86/pkeys/selftests: Remove dead debugging code, fix dprint_in_signal [ Upstream commit a50093d60464dd51d1ae0c2267b0abe9e1de77f3 ] There is some noisy debug code at the end of the signal handler. It was disabled by an early, unconditional "return". However, that return also hid a dprint_in_signal=0, which kept dprint_in_signal=1 and effectively locked us into permanent dprint_in_signal=1 behavior. Remove the return and the dead code, fixing dprint_in_signal. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171342.846B9B2E@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8b9f3a7404d79ebcdf2a8491ea37d5b1b851ac6a Author: Dave Hansen Date: Wed May 9 10:13:40 2018 -0700 x86/pkeys/selftests: Stop using assert() [ Upstream commit 86b9eea230edf4c67d4d4a70fba9b74505867a25 ] If we use assert(), the program "crashes". That can be scary to users, so stop doing it. Just exit with a >0 exit code instead. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171340.E63EF7DA@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 477c024fb33ab5fd9bc139495fe6323191e513df Author: Dave Hansen Date: Wed May 9 10:13:38 2018 -0700 x86/pkeys/selftests: Give better unexpected fault error messages [ Upstream commit 55556b0b2016806b2e16a20b62d143383983a34a ] do_not_expect_pk_fault() is a helper that we call when we do not expect a PK fault to have occurred. But, it is a function, which means that it obscures the line numbers from pkey_assert(). It also gives no details. Replace it with an implementation that gives nice line numbers and also lets callers pass in a more descriptive message about what happened that caused the unexpected fault. Signed-off-by: Dave Hansen Cc: Andrew Morton Cc: Dave Hansen Cc: Linus Torvalds Cc: Michael Ellermen Cc: Peter Zijlstra Cc: Ram Pai Cc: Shuah Khan Cc: Thomas Gleixner Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20180509171338.55D13B64@viggo.jf.intel.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4824a6473b8553a503af02376157b099f03ef8e8 Author: Andy Lutomirski Date: Tue May 8 10:28:35 2018 -0700 x86/selftests: Add mov_to_ss test [ Upstream commit 59c2a7226fc5130032021c99f05ad5c0a56551cd ] This exercises a nasty corner case of the x86 ISA. Signed-off-by: Andy Lutomirski Cc: Borislav Petkov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/67e08b69817171da8026e0eb3af0214b06b4d74f.1525800455.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c25b160c8da6f3c20a5eed95f98f76bf2c26c55e Author: Ingo Molnar Date: Mon May 14 10:59:08 2018 +0200 x86/mpx/selftests: Adjust the self-test to fresh distros that export the MPX ABI [ Upstream commit 73bb4d6cd192b8629c5125aaada9892d9fc986b6 ] Fix this warning: mpx-mini-test.c:422:0: warning: "SEGV_BNDERR" redefined Cc: Dave Hansen Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: akpm@linux-foundation.org Cc: dave.hansen@intel.com Cc: linux-mm@kvack.org Cc: linuxram@us.ibm.com Cc: mpe@ellerman.id.au Cc: shakeelb@google.com Cc: shuah@kernel.org Link: http://lkml.kernel.org/r/20180514085908.GA12798@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2361f1f4fff26781386536379d117aa1c0218ad5 Author: Ingo Molnar Date: Mon May 14 10:56:23 2018 +0200 x86/pkeys/selftests: Adjust the self-test to fresh distros that export the pkeys ABI [ Upstream commit 0fb96620dce351608aa82eed5942e2f58b07beda ] Ubuntu 18.04 started exporting pkeys details in header files, resulting in build failures and warnings in the pkeys self-tests: protection_keys.c:232:0: warning: "SEGV_BNDERR" redefined protection_keys.c:387:5: error: conflicting types for ‘pkey_get’ protection_keys.c:409:5: error: conflicting types for ‘pkey_set’ ... Fix these namespace conflicts and double definitions, plus also clean up the ABI definitions to make it all a bit more readable ... Cc: Dave Hansen Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: akpm@linux-foundation.org Cc: dave.hansen@intel.com Cc: linux-mm@kvack.org Cc: linuxram@us.ibm.com Cc: mpe@ellerman.id.au Cc: shakeelb@google.com Cc: shuah@kernel.org Link: http://lkml.kernel.org/r/20180514085623.GB7094@gmail.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 847f0cacf21eb0f575acbf06e7314466347be841 Author: Ingo Molnar Date: Mon May 14 10:15:54 2018 +0200 objtool, kprobes/x86: Sync the latest header with tools/objtool/arch/x86/include/asm/insn.h [ Upstream commit 4fe875e4bd3cae85ae6f6eaf77f63fabe613b66e ] The following commit: ee6a7354a362: kprobes/x86: Prohibit probing on exception masking instructions Modified , adding the insn_masking_exception() function. Sync the tooling version of the header to it, to fix this warning: Warning: synced file at 'tools/objtool/arch/x86/include/asm/insn.h' differs from latest kernel version at 'arch/x86/include/asm/insn.h' Cc: Peter Zijlstra Cc: Josh Poimboeuf Cc: Masami Hiramatsu Cc: Thomas Gleixner Cc: Ricardo Neri Cc: Francis Deslauriers Cc: Oleg Nesterov Cc: Alexei Starovoitov Cc: Steven Rostedt Cc: Andy Lutomirski Cc: "H . Peter Anvin" Cc: Yonghong Song Cc: Borislav Petkov Cc: Linus Torvalds Cc: "David S . Miller" Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5aaee3e9ef32913ed77eb8fe4e9b51b5ace32a67 Author: Masami Hiramatsu Date: Wed May 9 21:58:45 2018 +0900 uprobes/x86: Prohibit probing on MOV SS instruction [ Upstream commit 13ebe18c94f5b0665c01ae7fad2717ae959f4212 ] Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by uprobes must be prohibited. uprobe already rejects probing on POP SS (0x1f), but allows probing on MOV SS (0x8e and reg == 2). This checks the target instruction and if it is MOV SS or POP SS, returns -ENOTSUPP to reject probing. Signed-off-by: Masami Hiramatsu Signed-off-by: Thomas Gleixner Acked-by: Oleg Nesterov Cc: Ricardo Neri Cc: Francis Deslauriers Cc: Alexei Starovoitov Cc: Steven Rostedt Cc: Andy Lutomirski Cc: "H . Peter Anvin" Cc: Yonghong Song Cc: Borislav Petkov Cc: Linus Torvalds Cc: "David S . Miller" Link: https://lkml.kernel.org/r/152587072544.17316.5950935243917346341.stgit@devbox Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba202cd5a1f045609c43058b2aeddd6fb341f236 Author: Masami Hiramatsu Date: Wed May 9 21:58:15 2018 +0900 kprobes/x86: Prohibit probing on exception masking instructions [ Upstream commit ee6a7354a3629f9b65bc18dbe393503e9440d6f5 ] Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by kprobes must be prohibited. However, kprobes usually executes those instructions directly on trampoline buffer (a.k.a. kprobe-booster), except for the kprobes which has post_handler. Thus if kprobe user probes MOV SS with post_handler, it will do single-stepping on the MOV SS. This means it is safe that if it is used via ftrace or perf/bpf since those don't use the post_handler. Anyway, since the stack switching is a rare case, it is safer just rejecting kprobes on such instructions. Signed-off-by: Masami Hiramatsu Signed-off-by: Thomas Gleixner Cc: Ricardo Neri Cc: Francis Deslauriers Cc: Oleg Nesterov Cc: Alexei Starovoitov Cc: Steven Rostedt Cc: Andy Lutomirski Cc: "H . Peter Anvin" Cc: Yonghong Song Cc: Borislav Petkov Cc: Linus Torvalds Cc: "David S . Miller" Link: https://lkml.kernel.org/r/152587069574.17316.3311695234863248641.stgit@devbox Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 12ddc2639e31d96f5b136a84baf7d2b312db5519 Author: Ashish Samant Date: Fri May 11 16:02:07 2018 -0700 ocfs2: take inode cluster lock before moving reflinked inode from orphan dir [ Upstream commit e4383029201470523c3ffe339bd7d57e9b4a7d65 ] While reflinking an inode, we create a new inode in orphan directory, then take EX lock on it, reflink the original inode to orphan inode and release EX lock. Once the lock is released another node could request it in EX mode from ocfs2_recover_orphans() which causes downconvert of the lock, on this node, to NL mode. Later we attempt to initialize security acl for the orphan inode and move it to the reflink destination. However, while doing this we dont take EX lock on the inode. This could potentially cause problems because we could be starting transaction, accessing journal and modifying metadata of the inode while holding NL lock and with another node holding EX lock on the inode. Fix this by taking orphan inode cluster lock in EX mode before initializing security and moving orphan inode to reflink destination. Use the __tracker variant while taking inode lock to avoid recursive locking in the ocfs2_init_security_and_acl() call chain. Link: http://lkml.kernel.org/r/1523475107-7639-1-git-send-email-ashish.samant@oracle.com Signed-off-by: Ashish Samant Reviewed-by: Joseph Qi Reviewed-by: Junxiao Bi Acked-by: Jun Piao Cc: Mark Fasheh Cc: Joel Becker Cc: Changwei Ge Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 553495752c8241ef0a4a2c2fc3a5c8298899ec81 Author: Laura Abbott Date: Fri May 11 16:01:57 2018 -0700 proc/kcore: don't bounds check against address 0 [ Upstream commit 3955333df9a50e8783d115613a397ae55d905080 ] The existing kcore code checks for bad addresses against __va(0) with the assumption that this is the lowest address on the system. This may not hold true on some systems (e.g. arm64) and produce overflows and crashes. Switch to using other functions to validate the address range. It's currently only seen on arm64 and it's not clear if anyone wants to use that particular combination on a stable release. So this is not urgent for stable. Link: http://lkml.kernel.org/r/20180501201143.15121-1-labbott@redhat.com Signed-off-by: Laura Abbott Tested-by: Dave Anderson Cc: Kees Cook Cc: Ard Biesheuvel Cc: Ingo Molnar Cc: Andi Kleen Cc: Alexey Dobriyan a Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20e557fb26cae647f13b4973c47293d691ff5666 Author: Jeffrey Hugo Date: Fri May 11 16:01:42 2018 -0700 init: fix false positives in W+X checking [ Upstream commit ae646f0b9ca135b87bc73ff606ef996c3029780a ] load_module() creates W+X mappings via __vmalloc_node_range() (from layout_and_allocate()->move_module()->module_alloc()) by using PAGE_KERNEL_EXEC. These mappings are later cleaned up via "call_rcu_sched(&freeinit->rcu, do_free_init)" from do_init_module(). This is a problem because call_rcu_sched() queues work, which can be run after debug_checkwx() is run, resulting in a race condition. If hit, the race results in a nasty splat about insecure W+X mappings, which results in a poor user experience as these are not the mappings that debug_checkwx() is intended to catch. This issue is observed on multiple arm64 platforms, and has been artificially triggered on an x86 platform. Address the race by flushing the queued work before running the arch-defined mark_rodata_ro() which then calls debug_checkwx(). Link: http://lkml.kernel.org/r/1525103946-29526-1-git-send-email-jhugo@codeaurora.org Fixes: e1a58320a38d ("x86/mm: Warn on W^X mappings") Signed-off-by: Jeffrey Hugo Reported-by: Timur Tabi Reported-by: Jan Glauber Acked-by: Kees Cook Acked-by: Ingo Molnar Acked-by: Will Deacon Acked-by: Laura Abbott Cc: Mark Rutland Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Stephen Smalley Cc: Thomas Gleixner Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 86900754306e7e4eafbd050e4405f292cf4458f3 Author: Roman Mashak Date: Fri May 11 10:55:09 2018 -0400 net sched actions: fix invalid pointer dereferencing if skbedit flags missing [ Upstream commit af5d01842fe1fbfb9f5e1c1d957ba02ab6f4569a ] When application fails to pass flags in netlink TLV for a new skbedit action, the kernel results in the following oops: [ 8.307732] BUG: unable to handle kernel paging request at 0000000000021130 [ 8.309167] PGD 80000000193d1067 P4D 80000000193d1067 PUD 180e0067 PMD 0 [ 8.310595] Oops: 0000 [#1] SMP PTI [ 8.311334] Modules linked in: kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper serio_raw [ 8.314190] CPU: 1 PID: 397 Comm: tc Not tainted 4.17.0-rc3+ #357 [ 8.315252] RIP: 0010:__tcf_idr_release+0x33/0x140 [ 8.316203] RSP: 0018:ffffa0718038f840 EFLAGS: 00010246 [ 8.317123] RAX: 0000000000000001 RBX: 0000000000021100 RCX: 0000000000000000 [ 8.319831] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000021100 [ 8.321181] RBP: 0000000000000000 R08: 000000000004adf8 R09: 0000000000000122 [ 8.322645] R10: 0000000000000000 R11: ffffffff9e5b01ed R12: 0000000000000000 [ 8.324157] R13: ffffffff9e0d3cc0 R14: 0000000000000000 R15: 0000000000000000 [ 8.325590] FS: 00007f591292e700(0000) GS:ffff8fcf5bc40000(0000) knlGS:0000000000000000 [ 8.327001] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.327987] CR2: 0000000000021130 CR3: 00000000180e6004 CR4: 00000000001606a0 [ 8.329289] Call Trace: [ 8.329735] tcf_skbedit_init+0xa7/0xb0 [ 8.330423] tcf_action_init_1+0x362/0x410 [ 8.331139] ? try_to_wake_up+0x44/0x430 [ 8.331817] tcf_action_init+0x103/0x190 [ 8.332511] tc_ctl_action+0x11a/0x220 [ 8.333174] rtnetlink_rcv_msg+0x23d/0x2e0 [ 8.333902] ? _cond_resched+0x16/0x40 [ 8.334569] ? __kmalloc_node_track_caller+0x5b/0x2c0 [ 8.335440] ? rtnl_calcit.isra.31+0xf0/0xf0 [ 8.336178] netlink_rcv_skb+0xdb/0x110 [ 8.336855] netlink_unicast+0x167/0x220 [ 8.337550] netlink_sendmsg+0x2a7/0x390 [ 8.338258] sock_sendmsg+0x30/0x40 [ 8.338865] ___sys_sendmsg+0x2c5/0x2e0 [ 8.339531] ? pagecache_get_page+0x27/0x210 [ 8.340271] ? filemap_fault+0xa2/0x630 [ 8.340943] ? page_add_file_rmap+0x108/0x200 [ 8.341732] ? alloc_set_pte+0x2aa/0x530 [ 8.342573] ? finish_fault+0x4e/0x70 [ 8.343332] ? __handle_mm_fault+0xbc1/0x10d0 [ 8.344337] ? __sys_sendmsg+0x53/0x80 [ 8.345040] __sys_sendmsg+0x53/0x80 [ 8.345678] do_syscall_64+0x4f/0x100 [ 8.346339] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 8.347206] RIP: 0033:0x7f591191da67 [ 8.347831] RSP: 002b:00007fff745abd48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 8.349179] RAX: ffffffffffffffda RBX: 00007fff745abe70 RCX: 00007f591191da67 [ 8.350431] RDX: 0000000000000000 RSI: 00007fff745abdc0 RDI: 0000000000000003 [ 8.351659] RBP: 000000005af35251 R08: 0000000000000001 R09: 0000000000000000 [ 8.352922] R10: 00000000000005f1 R11: 0000000000000246 R12: 0000000000000000 [ 8.354183] R13: 00007fff745afed0 R14: 0000000000000001 R15: 00000000006767c0 [ 8.355400] Code: 41 89 d4 53 89 f5 48 89 fb e8 aa 20 fd ff 85 c0 0f 84 ed 00 00 00 48 85 db 0f 84 cf 00 00 00 40 84 ed 0f 85 cd 00 00 00 45 84 e4 <8b> 53 30 74 0d 85 d2 b8 ff ff ff ff 0f 8f b3 00 00 00 8b 43 2c [ 8.358699] RIP: __tcf_idr_release+0x33/0x140 RSP: ffffa0718038f840 [ 8.359770] CR2: 0000000000021130 [ 8.360438] ---[ end trace 60c66be45dfc14f0 ]--- The caller calls action's ->init() and passes pointer to "struct tc_action *a", which later may be initialized to point at the existing action, otherwise "struct tc_action *a" is still invalid, and therefore dereferencing it is an error as happens in tcf_idr_release, where refcnt is decremented. So in case of missing flags tcf_idr_release must be called only for existing actions. v2: - prepare patch for net tree Fixes: 5e1567aeb7fe ("net sched: skbedit action fix late binding") Signed-off-by: Roman Mashak Acked-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 55e95f9ad712f43756393bfc1369ddade995ef26 Author: Emil Tantilov Date: Thu Apr 19 17:06:57 2018 -0700 ixgbe: return error on unsupported SFP module when resetting [ Upstream commit bbb2707623f3ccc48695da2433f06d7c38193451 ] Add check for unsupported module and return the error code. This fixes a Coverity hit due to unused return status from setup_sfp. Signed-off-by: Emil Tantilov Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 33d1c29e935ef72dbcaf0eeeb67b6cb0788fa045 Author: Marian Rotariu Date: Mon Apr 30 12:23:01 2018 +0300 x86: Delay skip of emulated hypercall instruction [ Upstream commit 6356ee0c9602004e0a3b4b2dad68ee2ee9385b17 ] The IP increment should be done after the hypercall emulation, after calling the various handlers. In this way, these handlers can accurately identify the the IP of the VMCALL if they need it. This patch keeps the same functionality for the Hyper-V handler which does not use the return code of the standard kvm_skip_emulated_instruction() call. Signed-off-by: Marian Rotariu [Hyper-V hypercalls also need kvm_skip_emulated_instruction() - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ce44a4d5db630728a5a20cf833afeafe1dce88f6 Author: Wanpeng Li Date: Thu Apr 26 17:55:03 2018 -0700 KVM: Extend MAX_IRQ_ROUTES to 4096 for all archs [ Upstream commit ddc9cfb79c1096a0855839631c091aa7e9602052 ] Our virtual machines make use of device assignment by configuring 12 NVMe disks for high I/O performance. Each NVMe device has 129 MSI-X Table entries: Capabilities: [50] MSI-X: Enable+ Count=129 Masked-Vector table: BAR=0 offset=00002000 The windows virtual machines fail to boot since they will map the number of MSI-table entries that the NVMe hardware reported to the bus to msi routing table, this will exceed the 1024. This patch extends MAX_IRQ_ROUTES to 4096 for all archs, in the future this might be extended again if needed. Reviewed-by: Cornelia Huck Cc: Paolo Bonzini Cc: Radim KrÄmář Cc: Cornelia Huck Cc: Christian Borntraeger Signed-off-by: Wanpeng Li Signed-off-by: Tonny Lu Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 29475c404b56f4ff03d99e35b9258dc6dbf8f4b1 Author: David Howells Date: Thu May 10 23:26:01 2018 +0100 rxrpc: Fix the min security level for kernel calls [ Upstream commit 93864fc3ffcc4bf70e96cfb5cc6e941630419ad0 ] Fix the kernel call initiation to set the minimum security level for kernel initiated calls (such as from kAFS) from the sockopt value. Fixes: 19ffa01c9c45 ("rxrpc: Use structs to hold connection params and protocol info") Signed-off-by: David Howells Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b2abd2b98afccb8dfa9d0e51ab8f77e574ad7756 Author: David Howells Date: Thu May 10 23:26:00 2018 +0100 rxrpc: Fix error reception on AF_INET6 sockets [ Upstream commit f2aeed3a591ff29a82495eeaa92ac4780bad7487 ] AF_RXRPC tries to turn on IP_RECVERR and IP_MTU_DISCOVER on the UDP socket it just opened for communications with the outside world, regardless of the type of socket. Unfortunately, this doesn't work with an AF_INET6 socket. Fix this by turning on IPV6_RECVERR and IPV6_MTU_DISCOVER instead if the socket is of the AF_INET6 family. Without this, kAFS server and address rotation doesn't work correctly because the algorithm doesn't detect received network errors. Fixes: 75b54cb57ca3 ("rxrpc: Add IPv6 support") Signed-off-by: David Howells Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b5b3188098b3c438534c083243777bc685bb0627 Author: Michal Kalderon Date: Tue May 8 21:29:19 2018 +0300 qede: Fix gfp flags sent to rdma event node allocation [ Upstream commit 090477e4acb31c5dd674940c7c01d4f16bd1ac41 ] A previous commit 4609adc27175 ("qede: Fix qedr link update") added a flow that could allocate rdma event objects from an interrupt path (link notification). Therefore the kzalloc call should be done with GFP_ATOMIC. fixes: 4609adc27175 ("qede: Fix qedr link update") Signed-off-by: Michal Kalderon Signed-off-by: Sudarsana Kalluru Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6618d064bacad3bef642825263eb4e8edcc55142 Author: Michal Kalderon Date: Tue May 8 21:29:18 2018 +0300 qed: Fix l2 initializations over iWARP personality [ Upstream commit af6858ee423a309d93054c361c61099b8eb12bbf ] If qede driver was loaded on a device configured for iWARP the l2 mutex wouldn't be allocated, and some l2 related resources wouldn't be freed. fixes: c851a9dc4359 ("qed: Introduce iWARP personality") Signed-off-by: Michal Kalderon Signed-off-by: Sudarsana Kalluru Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc5af7b0de98ce376fb7d34035749e71c081a7ff Author: Ying Xue Date: Tue May 8 21:44:06 2018 +0800 tipc: eliminate KMSAN uninit-value in strcmp complaint [ Upstream commit 94f6a80c0c11828cb7b3d79294459dd8d761ca89 ] When we get link properties through netlink interface with tipc_nl_node_get_link(), we don't validate TIPC_NLA_LINK_NAME attribute at all, instead we directly use it. As a consequence, KMSAN detected the TIPC_NLA_LINK_NAME attribute was an uninitialized value, and then posted the following complaint: ================================================================== BUG: KMSAN: uninit-value in strcmp+0xf7/0x160 lib/string.c:329 CPU: 1 PID: 4527 Comm: syz-executor655 Not tainted 4.16.0+ #87 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x185/0x1d0 lib/dump_stack.c:53 kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067 __msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683 strcmp+0xf7/0x160 lib/string.c:329 tipc_nl_node_get_link+0x220/0x6f0 net/tipc/node.c:1881 genl_family_rcv_msg net/netlink/genetlink.c:599 [inline] genl_rcv_msg+0x1686/0x1810 net/netlink/genetlink.c:624 netlink_rcv_skb+0x378/0x600 net/netlink/af_netlink.c:2447 genl_rcv+0x63/0x80 net/netlink/genetlink.c:635 netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline] netlink_unicast+0x166b/0x1740 net/netlink/af_netlink.c:1337 netlink_sendmsg+0x1048/0x1310 net/netlink/af_netlink.c:1900 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046 __sys_sendmsg net/socket.c:2080 [inline] SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091 SyS_sendmsg+0x54/0x80 net/socket.c:2087 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 RIP: 0033:0x445589 RSP: 002b:00007fb7ee66cdb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000006dac24 RCX: 0000000000445589 RDX: 0000000000000000 RSI: 0000000020023000 RDI: 0000000000000003 RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffa2bf3f3f R14: 00007fb7ee66d9c0 R15: 0000000000000001 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:278 [inline] kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:188 kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:314 kmsan_slab_alloc+0x11/0x20 mm/kmsan/kmsan.c:321 slab_post_alloc_hook mm/slab.h:445 [inline] slab_alloc_node mm/slub.c:2737 [inline] __kmalloc_node_track_caller+0xaed/0x11c0 mm/slub.c:4369 __kmalloc_reserve net/core/skbuff.c:138 [inline] __alloc_skb+0x2cf/0x9f0 net/core/skbuff.c:206 alloc_skb include/linux/skbuff.h:984 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1183 [inline] netlink_sendmsg+0x9a6/0x1310 net/netlink/af_netlink.c:1875 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg net/socket.c:640 [inline] ___sys_sendmsg+0xec0/0x1310 net/socket.c:2046 __sys_sendmsg net/socket.c:2080 [inline] SYSC_sendmsg+0x2a3/0x3d0 net/socket.c:2091 SyS_sendmsg+0x54/0x80 net/socket.c:2087 do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 ================================================================== To quiet the complaint, TIPC_NLA_LINK_NAME attribute has been validated in tipc_nl_node_get_link() before it's used. Reported-by: syzbot+df0257c92ffd4fcc58cd@syzkaller.appspotmail.com Signed-off-by: Ying Xue Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ca2fa569d65a7a4b0fbc1aada8fd373cd4a0790 Author: Mathieu Malaterre Date: Sat May 5 21:54:05 2018 +0200 agp: uninorth: make two functions static [ Upstream commit dec60f3a9b7251f2657d743d96ba9a83dca02351 ] Both ‘uninorth_remove_memory’ and ‘null_cache_flush’ can be made static. So make them. Silence the following gcc warning (W=1): drivers/char/agp/uninorth-agp.c:198:5: warning: no previous prototype for ‘uninorth_remove_memory’ [-Wmissing-prototypes] and drivers/char/agp/uninorth-agp.c:473:6: warning: no previous prototype for ‘null_cache_flush’ [-Wmissing-prototypes] Signed-off-by: Mathieu Malaterre Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8223298c5075c9fb0ae4b10274124c35cd6ea120 Author: Paulo Alcantara Date: Fri May 4 11:25:26 2018 -0300 cifs: smb2ops: Fix listxattr() when there are no EAs [ Upstream commit ae2cd7fb478b8da707906ee1706ae1379968a8f9 ] As per listxattr(2): On success, a nonnegative number is returned indicating the size of the extended attribute name list. On failure, -1 is returned and errno is set appropriately. In SMB1, when the server returns an empty EA list through a listxattr(), it will correctly return 0 as there are no EAs for the given file. However, in SMB2+, it returns -ENODATA in listxattr() which is wrong since the request and response were sent successfully, although there's no actual EA for the given file. This patch fixes listxattr() for SMB2+ by returning 0 in cifs_listxattr() when the server returns an empty list of EAs. Signed-off-by: Paulo Alcantara Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fcc0315abc95076062cfe59b9933d08fdcad2781 Author: David Gilhooley Date: Tue May 8 15:49:42 2018 -0700 arm64: Add MIDR encoding for NVIDIA CPUs [ Upstream commit 1b06bd8dd95f7a19ab33fdf0f477c94950822ab3 ] This patch adds the MIDR encodings for NVIDIA as well as the Denver and Carmel CPUs used in Tegra SoCs. Signed-off-by: David Gilhooley Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56068475a7f02f7fb7afdb941cc6e6b53d6f3a91 Author: Jakob Unterwurzacher Date: Wed Apr 18 16:10:03 2018 +0200 can: dev: increase bus-off message severity [ Upstream commit 71c23a821c6bcacba71a094efe49ee689605906b ] bus-off is usually caused by hardware malfunction or configuration error (baud rate mismatch) and causes a complete loss of communication. Increase the "bus-off" message's severity from netdev_dbg() to netdev_info() to make it visible to the user. A can interface going into bus-off is similar in severity to ethernet's "Link is Down" message, which is also printed at info level. It is debatable whether the the "restarted" message should also be changed to netdev_info() to make the interface state changes comprehensible from the kernel log. I have chosen to keep the "restarted" message at dbg for now as the "bus-off" message should be enough for the user to notice and investigate the problem. Signed-off-by: Jakob Unterwurzacher Cc: linux-can@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4dc2437cdd6b6c6a745500ac647dc3cd66a0e2ee Author: Igor Russkikh Date: Mon May 7 16:10:38 2018 +0300 net: aquantia: driver should correctly declare vlan_features bits [ Upstream commit 8c61ab7f111a2b29d051348b9cb9a39804ebf1f8 ] In particular, not reporting SG forced skbs to be linear for vlan interfaces over atlantic NIC. With this fix it is possible to enable SG feature on device and therefore optimize performance. Reported-by: Ma Yuying Signed-off-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a951cf4da8964e4f8797b48e9c805abac4c7b1d9 Author: van der Linden, Frank Date: Fri May 4 16:11:00 2018 -0400 x86/xen: Reset VCPU0 info pointer after shared_info remap [ Upstream commit d1ecfa9d1f402366b1776fbf84e635678a51414f ] This patch fixes crashes during boot for HVM guests on older (pre HVM vector callback) Xen versions. Without this, current kernels will always fail to boot on those Xen versions. Sample stack trace: BUG: unable to handle kernel paging request at ffffffffff200000 IP: __xen_evtchn_do_upcall+0x1e/0x80 PGD 1e0e067 P4D 1e0e067 PUD 1e10067 PMD 235c067 PTE 0 Oops: 0002 [#1] SMP PTI Modules linked in: CPU: 0 PID: 512 Comm: kworker/u2:0 Not tainted 4.14.33-52.13.amzn1.x86_64 #1 Hardware name: Xen HVM domU, BIOS 3.4.3.amazon 11/11/2016 task: ffff88002531d700 task.stack: ffffc90000480000 RIP: 0010:__xen_evtchn_do_upcall+0x1e/0x80 RSP: 0000:ffff880025403ef0 EFLAGS: 00010046 RAX: ffffffff813cc760 RBX: ffffffffff200000 RCX: ffffc90000483ef0 RDX: ffff880020540a00 RSI: ffff880023c78000 RDI: 000000000000001c RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff880025403f5c R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880025400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffff200000 CR3: 0000000001e0a000 CR4: 00000000000006f0 Call Trace: do_hvm_evtchn_intr+0xa/0x10 __handle_irq_event_percpu+0x43/0x1a0 handle_irq_event_percpu+0x20/0x50 handle_irq_event+0x39/0x60 handle_fasteoi_irq+0x80/0x140 handle_irq+0xaf/0x120 do_IRQ+0x41/0xd0 common_interrupt+0x7d/0x7d During boot, the HYPERVISOR_shared_info page gets remapped to make it work with KASLR. This means that any pointer derived from it needs to be adjusted. The only value that this applies to is the vcpu_info pointer for VCPU 0. For PV and HVM with the callback vector feature, this gets done via the smp_ops prepare_boot_cpu callback. Older Xen versions do not support the HVM callback vector, so there is no Xen-specific smp_ops set up in that scenario. So, the vcpu_info pointer for VCPU 0 never gets set to the proper value, and the first reference of it will be bad. Fix this by resetting it immediately after the remap. Signed-off-by: Frank van der Linden Reviewed-by: Eduardo Valentin Reviewed-by: Alakesh Haloi Reviewed-by: Vallish Vaidyeshwara Reviewed-by: Boris Ostrovsky Cc: Juergen Gross Cc: Boris Ostrovsky Cc: xen-devel@lists.xenproject.org Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba29f3738e86f4e69cc8470a60a62e21d492475d Author: Sara Sharon Date: Fri Apr 20 13:49:19 2018 +0300 mac80211: use timeout from the AddBA response instead of the request [ Upstream commit 914eac248d876f9c00cd1792ffec3d182c863f13 ] 2016 spec, section 10.24.2 specifies that the block ack timeout in the ADD BA request is advisory. That means we should check the value in the response and act upon it (same as buffer size). Signed-off-by: Sara Sharon Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e4bd54eb87c820b3e2da9a9701896d6ac1bae6f6 Author: Clément Péron Date: Thu May 3 17:32:07 2018 +0200 ARM: dts: cygnus: fix irq type for arm global timer [ Upstream commit 675c7215aacf54242b2e8bc64bab698abbe764db ] As per ARM documentation PPI(0) ID27 - global timer interrupt is rising-edge sensitive. set IRQ triggering type to IRQ_TYPE_EDGE_RISING for ARM Global timers. Fixes: c9ad7bc5fe3 ("ARM: dts: Enable Broadcom Cygnus SoC") Signed-off-by: Clément Péron Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 36166445a922a50343bec7f193f243390e9e0680 Author: Mathieu Malaterre Date: Sat May 5 22:00:37 2018 +0200 driver core: add __printf verification to __ata_ehi_pushv_desc [ Upstream commit 0d74d872c3f8b9cb3d096fb932a063b43b37f188 ] __printf is useful to verify format and arguments. Remove the following warning (with W=1): drivers/ata/libata-eh.c:183:10: warning: function might be possible candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format] Signed-off-by: Mathieu Malaterre Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bc707b2d950b549b6071f39fe269291ec6031d5a Author: Tomi Valkeinen Date: Wed May 2 12:11:59 2018 +0300 drm/omap: handle alloc failures in omap_connector [ Upstream commit 47aaaec818dfd1009d1358974a2931f05dd57203 ] Handle memory allocation failures in omap_connector to avoid NULL derefs. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-5-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot Reviewed-by: Peter Ujfalusi Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 771f573cc158884bae8cf22d1a5627c396aa868f Author: Tomi Valkeinen Date: Wed May 2 12:11:56 2018 +0300 drm/omap: check return value from soc_device_match [ Upstream commit 4d6cb5e2fee52af17001e92950f0894304706ee4 ] soc_device_match() can return NULL, so add a check and fail if soc_device_match() fails. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-2-tomi.valkeinen@ti.com Reviewed-by: Benoit Parrot Reviewed-by: Peter Ujfalusi Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a490d0570df2d7fe7ffe40e4049c7846677aa078 Author: Tomi Valkeinen Date: Thu Mar 29 13:40:37 2018 +0300 drm/omap: fix possible NULL ref issue in tiler_reserve_2d [ Upstream commit 6a0f0c55619f0b82a677cab72e77c3444a5eee58 ] tiler_reserve_2d allocates memory but does not check if it got the memory. Add the check and return ENOMEM on failure. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-2-tomi.valkeinen@ti.com Reviewed-by: Emil Velikov Reviewed-by: Laurent Pinchart Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9631f32b61dcdaf4f52976f3706364f470cfcca0 Author: Tomi Valkeinen Date: Thu Mar 29 13:40:36 2018 +0300 drm/omap: fix uninitialized ret variable [ Upstream commit 77eeac24b10fc84d3ffd5b11a897dff88dde244d ] audio_config function for both HDMI4 and HDMI5 return uninitialized value as the error code if the display is not currently enabled. For some reason this has not caused any issues. Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-1-tomi.valkeinen@ti.com Reviewed-by: Emil Velikov Reviewed-by: Laurent Pinchart Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ca3c09a74945bfa9db326cee60601f60237e5606 Author: Dan Carpenter Date: Wed Apr 18 17:29:37 2018 +0300 drm/omap: silence unititialized variable warning [ Upstream commit 4a9fbfcab19d3f71ad2bf0bcb653c4ee84e69c7f ] Smatch complains that "area_free" could be used without being initialized. This code is several years old and premusably works fine so this can't be a very serious bug. But it's easy enough to silence the warning. If "area_free" is false at the end of the function then we return -ENOMEM. Signed-off-by: Dan Carpenter Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20180418142937.GA13828@mwanda Signed-off-by: Sean Paul Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6ad69952d50d719ec9fbf3062e50d47b3e314231 Author: Ilan Peer Date: Fri Apr 20 13:49:20 2018 +0300 mac80211: Adjust SAE authentication timeout [ Upstream commit 407879b690ba3a6bf29be896d02dad63463bd1c0 ] The IEEE P802.11-REVmd D1.0 specification updated the SAE authentication timeout to be 2000 milliseconds (see dot11RSNASAERetransPeriod). Update the SAE timeout setting accordingly. While at it, reduce some code duplication in the timeout configuration. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 46d6ee12fa9dc094193b06be3d4db236cfa564a9 Author: Etienne Carriere Date: Sun Apr 29 14:22:29 2018 +0200 tee: check shm references are consistent in offset/size [ Upstream commit ab9d3db5b320a052452b9cd035599ee3c84bbee9 ] This change prevents userland from referencing TEE shared memory outside the area initially allocated by its owner. Prior this change an application could not reference or access memory it did not own but it could reference memory not explicitly allocated by owner but still allocated to the owner due to the memory allocation granule. Reported-by: Alexandre Jutras Signed-off-by: Etienne Carriere Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d40e177f29ab6fd3cc4ddd261d785c3e5b1a2918 Author: Rich Felker Date: Sat May 5 16:40:23 2018 -0400 sh: fix build failure for J2 cpu with SMP disabled [ Upstream commit 6cb465972c4eb6741b3094a58a65e527fc63c100 ] The sh asm/smp.h defines a fallback hard_smp_processor_id macro for the !SMP case, but linux/smp.h never includes asm/smp.h in the !SMP case. Signed-off-by: Rich Felker Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0742396317a0a0e41ab47e9de10cd6f16317f049 Author: Peter Zijlstra Date: Mon Apr 30 14:51:01 2018 +0200 sched/core: Introduce set_special_state() [ Upstream commit b5bf9a90bbebffba888c9144c5a8a10317b04064 ] Gaurav reported a perceived problem with TASK_PARKED, which turned out to be a broken wait-loop pattern in __kthread_parkme(), but the reported issue can (and does) in fact happen for states that do not do condition based sleeps. When the 'current->state = TASK_RUNNING' store of a previous (concurrent) try_to_wake_up() collides with the setting of a 'special' sleep state, we can loose the sleep state. Normal condition based wait-loops are immune to this problem, but for sleep states that are not condition based are subject to this problem. There already is a fix for TASK_DEAD. Abstract that and also apply it to TASK_STOPPED and TASK_TRACED, both of which are also without condition based wait-loop. Reported-by: Gaurav Kohli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a614eaa465f78767cfe6c5580c9741d73a228964 Author: Rob Herring Date: Thu May 3 13:09:44 2018 -0500 spi: bcm2835aux: ensure interrupts are enabled for shared handler [ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ] The BCM2835 AUX SPI has a shared interrupt line (with AUX UART). Downstream fixes this with an AUX irqchip to demux the IRQ sources and a DT change which breaks compatibility with older kernels. The AUX irqchip was already rejected for upstream[1] and the DT change would break working systems if the DTB is updated to a newer one. The latter issue was brought to my attention by Alex Graf. The root cause however is a bug in the shared handler. Shared handlers must check that interrupts are actually enabled before servicing the interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled. [1] https://patchwork.kernel.org/patch/9781221/ Cc: Alexander Graf Cc: Marc Zyngier Cc: Mark Brown Cc: Eric Anholt Cc: Stefan Wahren Cc: Florian Fainelli Cc: Ray Jui Cc: Scott Branden Cc: bcm-kernel-feedback-list@broadcom.com Cc: linux-spi@vger.kernel.org Cc: linux-rpi-kernel@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Rob Herring Reviewed-by: Eric Anholt Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 373a625cb3c49d72800ac7b2ac00f1d66ba7457f Author: Parav Pandit Date: Wed May 2 13:18:59 2018 +0300 RDMA/cma: Do not query GID during QP state transition to RTR [ Upstream commit 9aa169213d1166d30ae357a44abbeae93459339d ] When commit [1] was added, SGID was queried to derive the SMAC address. Then, later on during a refactor [2], SMAC was no longer needed. However, the now useless GID query remained. Then during additional code changes later on, the GID query was being done in such a way that it caused iWARP queries to start breaking. Remove the useless GID query and resolve the iWARP breakage at the same time. This is discussed in [3]. [1] commit dd5f03beb4f7 ("IB/core: Ethernet L2 attributes in verbs/cm structures") [2] commit 5c266b2304fb ("IB/cm: Remove the usage of smac and vid of qp_attr and cm_av") [3] https://www.spinics.net/lists/linux-rdma/msg63951.html Suggested-by: Shiraz Saleem Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3c54e919bd4f41417b601448b73fa2c0aafb47d0 Author: Sebastian Sanchez Date: Tue May 1 05:36:13 2018 -0700 IB/hfi1: Fix memory leak in exception path in get_irq_affinity() [ Upstream commit 59482a14918b282ca2a98f38c69da5ebeb1107d2 ] When IRQ affinity is set and the interrupt type is unknown, a cpu mask allocated within the function is never freed. Fix this memory leak by allocating memory within the scope where it is used. Reviewed-by: Mike Marciniszyn Reviewed-by: Michael J. Ruhl Signed-off-by: Sebastian Sanchez Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 77662d35b8c5e95ad498c253d434c37e137a2eda Author: Michael J. Ruhl Date: Tue May 1 05:35:43 2018 -0700 IB/hfi1 Use correct type for num_user_context [ Upstream commit 5da9e742be44d9b7c68b1bf6e1aaf46a1aa7a52b ] The module parameter num_user_context is defined as 'int' and defaults to -1. The module_param_named() says that it is uint. Correct module_param_named() type information and update the modinfo text to reflect the default value. Reviewed-by: Dennis Dalessandro Signed-off-by: Michael J. Ruhl Signed-off-by: Dennis Dalessandro Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 194feed06bcea86a804d2a547f34f1033faa728f Author: Stefan Raspl Date: Thu May 3 17:57:39 2018 +0200 smc: fix sendpage() call [ Upstream commit bda27ff5c4526f80a7620a94ecfe8dca153e3696 ] The sendpage() call grabs the sock lock before calling the default implementation - which tries to grab it once again. Signed-off-by: Stefan Raspl Signed-off-by: Ursula Braun < Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9c0f528f6bf0abcea8291d620117b8b49fb48ab5 Author: Janusz Krzysztofik Date: Wed May 2 20:32:03 2018 +0200 ARM: OMAP1: ams-delta: fix deferred_fiq handler [ Upstream commit baf64250b4a513bf4ac226fd938692dc1836f4f6 ] The deferred_fiq handler used to limit hardware operations to IRQ unmask only, relying on gpio-omap assigned handler performing the ACKs. Since commit 80ac93c27441 ("gpio: omap: Fix lost edge interrupts") this is no longer the case as handle_edge_irq() has been replaced with handle_simmple_irq() which doesn't touch the hardware. Add single ACK operation per each active IRQ pin to the handler. While being at it, move unmask operation out of irq_counter loop so it is also called only once for each active IRQ pin. Fixes: 80ac93c27441 ("gpio: omap: Fix lost edge interrupts") Signed-off-by: Janusz Krzysztofik Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ac5e86401fea34255dcc65f791d927bf8f84673b Author: Keith Busch Date: Tue Apr 17 14:42:44 2018 -0600 nvme: Set integrity flag for user passthrough commands [ Upstream commit f31a21103c03bb62846409fdc60cc9faf2398cfb ] If the command a separate metadata buffer attached, the request needs to have the integrity flag set so the driver knows to map it. Signed-off-by: Keith Busch Reviewed-by: Martin K. Petersen Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b19122a48f01544456f4b4efe423b9aa7c21be6d Author: Chengguang Xu Date: Sat Apr 14 20:06:19 2018 +0800 nvme: fix potential memory leak in option parsing [ Upstream commit 59a2f3f00fd744dbad22593f47552037d3154ca6 ] When specifying same string type option several times, current option parsing may cause memory leak. Hence, call kfree for previous one in this case. Signed-off-by: Chengguang Xu Reviewed-by: Christoph Hellwig Reviewed-by: Sagi Grimberg Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 665d3c7f1e506ed9310e3038ab0966520fa5749a Author: Changbin Du Date: Fri Apr 20 13:29:55 2018 +0800 iommu/vt-d: fix shift-out-of-bounds in bug checking [ Upstream commit 0dfc0c792d691f8056f38b5c30789f504be0e467 ] It allows to flush more than 4GB of device TLBs. So the mask should be 64bit wide. UBSAN captured this fault as below. [ 3.760024] ================================================================================ [ 3.768440] UBSAN: Undefined behaviour in drivers/iommu/dmar.c:1348:3 [ 3.774864] shift exponent 64 is too large for 32-bit type 'int' [ 3.780853] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G U 4.17.0-rc1+ #89 [ 3.788661] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.2.8 01/26/2016 [ 3.796034] Call Trace: [ 3.798472] [ 3.800479] dump_stack+0x90/0xfb [ 3.803787] ubsan_epilogue+0x9/0x40 [ 3.807353] __ubsan_handle_shift_out_of_bounds+0x10e/0x170 [ 3.812916] ? qi_flush_dev_iotlb+0x124/0x180 [ 3.817261] qi_flush_dev_iotlb+0x124/0x180 [ 3.821437] iommu_flush_dev_iotlb+0x94/0xf0 [ 3.825698] iommu_flush_iova+0x10b/0x1c0 [ 3.829699] ? fq_ring_free+0x1d0/0x1d0 [ 3.833527] iova_domain_flush+0x25/0x40 [ 3.837448] fq_flush_timeout+0x55/0x160 [ 3.841368] ? fq_ring_free+0x1d0/0x1d0 [ 3.845200] ? fq_ring_free+0x1d0/0x1d0 [ 3.849034] call_timer_fn+0xbe/0x310 [ 3.852696] ? fq_ring_free+0x1d0/0x1d0 [ 3.856530] run_timer_softirq+0x223/0x6e0 [ 3.860625] ? sched_clock+0x5/0x10 [ 3.864108] ? sched_clock+0x5/0x10 [ 3.867594] __do_softirq+0x1b5/0x6f5 [ 3.871250] irq_exit+0xd4/0x130 [ 3.874470] smp_apic_timer_interrupt+0xb8/0x2f0 [ 3.879075] apic_timer_interrupt+0xf/0x20 [ 3.883159] [ 3.885255] RIP: 0010:poll_idle+0x60/0xe7 [ 3.889252] RSP: 0018:ffffb1b201943e30 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 [ 3.896802] RAX: 0000000080200000 RBX: 000000000000008e RCX: 000000000000001f [ 3.903918] RDX: 0000000000000000 RSI: 000000002819aa06 RDI: 0000000000000000 [ 3.911031] RBP: ffff9e93c6b33280 R08: 00000010f717d567 R09: 000000000010d205 [ 3.918146] R10: ffffb1b201943df8 R11: 0000000000000001 R12: 00000000e01b169d [ 3.925260] R13: 0000000000000000 R14: ffffffffb12aa400 R15: 0000000000000000 [ 3.932382] cpuidle_enter_state+0xb4/0x470 [ 3.936558] do_idle+0x222/0x310 [ 3.939779] cpu_startup_entry+0x78/0x90 [ 3.943693] start_secondary+0x205/0x2e0 [ 3.947607] secondary_startup_64+0xa5/0xb0 [ 3.951783] ================================================================================ Signed-off-by: Changbin Du Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d98905c00c4c348eae88a5c195c611e2e1f23fc5 Author: Bhadram Varka Date: Wed May 2 20:44:40 2018 +0530 arm64: tegra: Make BCM89610 PHY interrupt as active low [ Upstream commit 9df50ba76ac1485b844beffa1f3f5d9659d9cdaf ] Need to configure PHY interrupt as active low for P3310 Tegra186 platform otherwise it results in spurious interrupts. This issue wasn't seen before because the generic PHY driver without interrupt support was used. Signed-off-by: Bhadram Varka Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 61ca60932d52536944d56880032fc7a9ca305557 Author: Peter Zijlstra Date: Mon Apr 30 14:50:22 2018 +0200 kthread, sched/wait: Fix kthread_parkme() wait-loop [ Upstream commit 741a76b350897604c48fb12beff1c9b77724dc96 ] Gaurav reported a problem with __kthread_parkme() where a concurrent try_to_wake_up() could result in competing stores to ->state which, when the TASK_PARKED store got lost bad things would happen. The comment near set_current_state() actually mentions this competing store, but only mentions the case against TASK_RUNNING. This same store, with different timing, can happen against a subsequent !RUNNING store. This normally is not a problem, because as per that same comment, the !RUNNING state store is inside a condition based wait-loop: for (;;) { set_current_state(TASK_UNINTERRUPTIBLE); if (!need_sleep) break; schedule(); } __set_current_state(TASK_RUNNING); If we loose the (first) TASK_UNINTERRUPTIBLE store to a previous (concurrent) wakeup, the schedule() will NO-OP and we'll go around the loop once more. The problem here is that the TASK_PARKED store is not inside the KTHREAD_SHOULD_PARK condition wait-loop. There is a genuine issue with sleeps that do not have a condition; this is addressed in a subsequent patch. Reported-by: Gaurav Kohli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Oleg Nesterov Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7a65e899d521eba676a1e652f9bf48d67722a18 Author: Peter Zijlstra Date: Fri Apr 20 11:50:05 2018 +0200 stop_machine, sched: Fix migrate_swap() vs. active_balance() deadlock [ Upstream commit 0b26351b910fb8fe6a056f8a1bbccabe50c0e19f ] Matt reported the following deadlock: CPU0 CPU1 schedule(.prev=migrate/0) pick_next_task() ... idle_balance() migrate_swap() active_balance() stop_two_cpus() spin_lock(stopper0->lock) spin_lock(stopper1->lock) ttwu(migrate/0) smp_cond_load_acquire() -- waits for schedule() stop_one_cpu(1) spin_lock(stopper1->lock) -- waits for stopper lock Fix this deadlock by taking the wakeups out from under stopper->lock. This allows the active_balance() to queue the stop work and finish the context switch, which in turn allows the wakeup from migrate_swap() to observe the context and complete the wakeup. Signed-off-by: Peter Zijlstra (Intel) Reported-by: Matt Fleming Signed-off-by: Peter Zijlstra (Intel) Acked-by: Matt Fleming Cc: Linus Torvalds Cc: Michal Hocko Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20180420095005.GH4064@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a814d1101042d117069de12ba6a0ba152ac3f79a Author: Helge Deller Date: Fri Apr 20 23:19:17 2018 +0200 parisc: drivers.c: Fix section mismatches [ Upstream commit b819439fea305a0bfd6ca23a7994fd1a8847c0d8 ] Fix two section mismatches in drivers.c: 1) Section mismatch in reference from the function alloc_tree_node() to the function .init.text:create_tree_node(). 2) Section mismatch in reference from the function walk_native_bus() to the function .init.text:alloc_pa_dev(). Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 609377d79e7578fc977ef02381febcc71a7a810a Author: Daniel Borkmann Date: Wed May 2 20:12:22 2018 +0200 bpf, x64: fix memleak when not converging after image [ Upstream commit 3aab8884c9eb99189a3569ac4e6b205371c9ac0b ] While reviewing x64 JIT code, I noticed that we leak the prior allocated JIT image in the case where proglen != oldproglen during the JIT passes. Prior to the commit e0ee9c12157d ("x86: bpf_jit: fix two bugs in eBPF JIT compiler") we would just break out of the loop, and using the image as the JITed prog since it could only shrink in size anyway. After e0ee9c12157d, we would bail out to out_addrs label where we free addrs and jit_data but not the image coming from bpf_jit_binary_alloc(). Fixes: e0ee9c12157d ("x86: bpf_jit: fix two bugs in eBPF JIT compiler") Signed-off-by: Daniel Borkmann Acked-by: Alexei Starovoitov Acked-by: David S. Miller Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 666776d5f45d478ef97b087ebc9ca0f52e55fdc5 Author: Jim Gill Date: Fri Apr 20 19:04:47 2018 -0700 scsi: vmw-pvscsi: return DID_BUS_BUSY for adapter-initated aborts [ Upstream commit f4b024271ae3e9786e5d6f1c05b01b57a74e1d6d ] The vmw_pvscsi driver returns DID_ABORT for commands aborted internally by the adapter, leading to the filesystem going read-only. Change the result to DID_BUS_BUSY, causing the kernel to retry the command. Signed-off-by: Jim Gill Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09e12b91d12c03c31fee65ab7e4052b7f14e006b Author: Arnd Bergmann Date: Fri Apr 6 16:28:23 2018 +0200 hexagon: export csum_partial_copy_nocheck [ Upstream commit 330e261c35dfb969c48f996dbbc8b334b5ee8d9d ] This is needed to link ipv6 as a loadable module, which in turn happens in allmodconfig. Signed-off-by: Arnd Bergmann Signed-off-by: Richard Kuo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8794fff6f4d9d48c6638b05f8de6bda8919b1748 Author: Arnd Bergmann Date: Fri Apr 6 16:28:22 2018 +0200 hexagon: add memset_io() helper [ Upstream commit a57ab96ef9dde231d4d46edba4d5f73720edc16a ] We already have memcpy_toio(), but not memset_io(), so let's add the obvious version to allow building an allmodconfig kernel without errors like drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_bo_move_memcpy': drivers/gpu/drm/ttm/ttm_bo_util.c:390:3: error: implicit declaration of function 'memset_io' [-Werror=implicit-function-declaration] Signed-off-by: Arnd Bergmann Signed-off-by: Richard Kuo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 960fe000b1d3228394f930a824eeb1a401c2cdd9 Author: Nick Dyer Date: Tue May 1 11:40:18 2018 -0700 Input: atmel_mxt_ts - fix the firmware update [ Upstream commit 068bdb67ef74df0ad1627b7247a163e3e252ac11 ] The automatic update mechanism will trigger an update if the info block CRCs are different between maxtouch configuration file (maxtouch.cfg) and chip. The driver compared the CRCs without retrieving the chip CRC, resulting always in a failure and firmware flashing action triggered. Fix this issue by retrieving the chip info block CRC before the check. Note that this solution has the benefit that by reading the information block and the object table into a contiguous region of memory, we can verify the checksum at probe time. This means we make sure that we are indeed talking to a chip that supports object protocol correctly. Using this patch on a kevin chromebook, the touchscreen and touchpad drivers are able to match the CRC: atmel_mxt_ts 3-004b: Family: 164 Variant: 14 Firmware V2.3.AA Objects: 40 atmel_mxt_ts 5-004a: Family: 164 Variant: 17 Firmware V2.0.AA Objects: 31 atmel_mxt_ts 3-004b: Resetting device atmel_mxt_ts 5-004a: Resetting device atmel_mxt_ts 3-004b: Config CRC 0x573E89: OK atmel_mxt_ts 3-004b: Touchscreen size X4095Y2729 input: Atmel maXTouch Touchscreen as /devices/platform/ff130000.i2c/i2c-3/3-004b/input/input5 atmel_mxt_ts 5-004a: Config CRC 0x0AF6BA: OK atmel_mxt_ts 5-004a: Touchscreen size X1920Y1080 input: Atmel maXTouch Touchpad as /devices/platform/ff140000.i2c/i2c-5/5-004a/input/input6 Signed-off-by: Nick Dyer Acked-by: Benson Leung [Ezequiel: minor patch massage] Signed-off-by: Ezequiel Garcia Tested-by: Sebastian Reichel Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f8d7147cb60ffafe2363592cca2daee75a6a8530 Author: Adam Ford Date: Tue May 1 08:58:53 2018 -0500 ARM: dts: logicpd-som-lv: Fix Audio Mute [ Upstream commit 95e59fc3c3fa3187a07a75f40b21637deb4bd12d ] The Audio has worked, but the mute pin has a weak pulldown which alows some of the audio signal to pass very quietly. This patch fixes that so the mute pin is actively driven high for mute or low for normal operation. Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by: Adam Ford Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8c4511032ac1d3087906415a770beb75ad198493 Author: Adam Ford Date: Mon Apr 30 18:24:34 2018 -0500 ARM: dts: logicpd-som-lv: Fix WL127x Startup Issues [ Upstream commit 189822cbcbf3ea37c26a15612d8f922c440bc0e0 ] The VAUX3 rail from the PMIC powers a clock driver which clocks the WL127x. This corrects a bug which did not correctly associate the vin-supply with the proper power rail. This also fixes a typo in the pinmuxing to properly configure the interrupt pin. Fixes: ab8dd3aed011 ("ARM: DTS: Add minimal Support for Logic PD DM3730 SOM-LV") Signed-off-by: Adam Ford Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 691f0a6b3b098511e98e7f4df30f8fa0d26b2868 Author: Tero Kristo Date: Fri Mar 9 11:50:20 2018 +0200 ARM: OMAP2+: powerdomain: use raw_smp_processor_id() for trace [ Upstream commit 33e9572483031a79ad0a4468064675144d9269ec ] smp_processor_id() checks preemption if CONFIG_DEBUG_PREEMPT is enabled, causing a warning dump during boot: [ 5.042377] BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 [ 5.050281] caller is pwrdm_set_next_pwrst+0x48/0x88 [ 5.055330] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.14.24-g57341df0b4 #1 Use the raw_smp_processor_id() for the trace instead, this value does not need to be perfectly correct. The alternative of disabling preempt is too heavy weight operation to be applied in PM hot path for just tracing purposes. Signed-off-by: Tero Kristo Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 061a560f3293e06c72f4c36219e5bd4153c8cc6a Author: Geert Uytterhoeven Date: Wed Apr 25 09:49:38 2018 +0200 dt-bindings: panel: lvds: Fix path to display timing bindings [ Upstream commit f130307054a59ca21d2396f386be77ebd2e8ca96 ] Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common panel properties") Signed-off-by: Geert Uytterhoeven Reviewed-by: Laurent Pinchart Signed-off-by: Rob Herring Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1ac1ca7352dc59d1710fa14468e36b73ba454e0 Author: Sekhar Nori Date: Wed Apr 25 14:53:23 2018 +0530 ARM: davinci: board-dm355-evm: fix broken networking [ Upstream commit 5c054de228dd6d97bf8e38962bd118953b66e5a0 ] Since commit 09f3756bb9a8 ("dm9000: Return an ERR_PTR() in all error conditions of dm9000_parse_dt()"), passing either non-NULL platform data or device-tree for dm9000 driver to probe is mandatory. DM335 board was using none, so networking failed to initialize. Fix it by passing non-NULL (but empty) platform data. Fixes: 09f3756bb9a8 ("dm9000: Return an ERR_PTR() in all error conditions of dm9000_parse_dt()") Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 034a9e9b235efa6ab98b67cd0bac57496d702589 Author: Sekhar Nori Date: Tue Apr 24 20:05:06 2018 +0530 ARM: davinci: board-omapl138-hawk: fix GPIO numbers for MMC/SD lookup [ Upstream commit d45622c0eaa5992a1a2248cbe93e1ff7a2da7be4 ] commit c4dc56be7e26 ("ARM: davinci: fix the GPIO lookup for omapl138-hawk") fixed the GPIO chip name for look-up of MMC/SD CD and WP pins, but forgot to change the GPIO numbers passed. The GPIO numbers are not offsets from within a 32 GPIO bank. Fix the GPIO numbers as well as remove the misleading comment. Fixes: c4dc56be7e26 ("ARM: davinci: fix the GPIO lookup for omapl138-hawk") Reviewed-by: David Lechner Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 0bf4a2db29648e1a7df776de41b1177aa7a037f2 Author: Sekhar Nori Date: Tue Apr 24 20:05:04 2018 +0530 ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD [ Upstream commit 67c6b6ff221f807180aea6dd597246f87e1dd98a ] The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers as they are not offsets within a bank. Note that it is the gpio-davinci driver that sets the gpiochip label to davinci_gpio.0. Fixes: bdf0e8364fd3 ("ARM: davinci: da850-evm: use gpio descriptor for mmc pins") Reviewed-by: David Lechner Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 38ffd4d581ff5448926dc72fc25e1cecb817de27 Author: Sekhar Nori Date: Tue Apr 24 20:05:03 2018 +0530 ARM: davinci: board-da830-evm: fix GPIO lookup for MMC/SD [ Upstream commit 51e9f12163223546bd3aa9f7af6817931f980da8 ] The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers as they are not offsets within a bank. Note that it is the gpio-davinci driver that sets the gpiochip label to davinci_gpio.0. Fixes: b5e1438cf98a ("ARM: davinci: da830-evm: use gpio descriptor for mmc pins") Reported-by: David Lechner Reviewed-by: David Lechner Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 13e4a2083d2b5286ecfecfe98aa1bace6eee7a3e Author: Håkon Bugge Date: Wed Apr 18 16:24:50 2018 +0200 IB/core: Make ib_mad_client_id atomic [ Upstream commit db82476f37413eaeff5f836a9d8b022d6544accf ] Currently, the kernel protects access to the agent ID allocator on a per port basis using a spinlock, so it is impossible for two apps/threads on the same port to get the same TID, but it is entirely possible for two threads on different ports to end up with the same TID. As this can be confusing (regardless of it being legal according to the IB Spec 1.3, C13-18.1.1, in section 13.4.6.4 - TransactionID usage), and as the rdma-core user space API for /dev/umad devices implies unique TIDs even across ports, make the TID an atomic type so that no two allocations, regardless of port number, will be the same. Signed-off-by: Håkon Bugge Reviewed-by: Jack Morgenstein Reviewed-by: Ira Weiny Reviewed-by: Zhu Yanjun Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5cb0ba254fee3c3ef61a3c02892e010851bbf54f Author: Amir Goldstein Date: Mon Feb 5 19:32:18 2018 +0200 : fix end_name_hash() for 64bit long [ Upstream commit 19b9ad67310ed2f685062a00aec602bec33835f0 ] The comment claims that this helper will try not to loose bits, but for 64bit long it looses the high bits before hashing 64bit long into 32bit int. Use the helper hash_long() to do the right thing for 64bit long. For 32bit long, there is no change. All the callers of end_name_hash() either assign the result to qstr->hash, which is u32 or return the result as an int value (e.g. full_name_hash()). Change the helper return type to int to conform to its users. [ It took me a while to apply this, because my initial reaction to it was - incorrectly - that it could make for slower code. After having looked more at it, I take back all my complaints about the patch, Amir was right and I was mis-reading things or just being stupid. I also don't worry too much about the possible performance impact of this on 64-bit, since most architectures that actually care about performance end up not using this very much (the dcache code is the most performance-critical, but the word-at-a-time case uses its own hashing anyway). So this ends up being mostly used for filesystems that do their own degraded hashing (usually because they want a case-insensitive comparison function). A _tiny_ worry remains, in that not everybody uses DCACHE_WORD_ACCESS, and then this potentially makes things more expensive on 64-bit architectures with slow or lacking multipliers even for the normal case. That said, realistically the only such architecture I can think of is PA-RISC. Nobody really cares about performance on that, it's more of a "look ma, I've got warts^W an odd machine" platform. So the patch is fine, and all my initial worries were just misplaced from not looking at this properly. - Linus ] Signed-off-by: Amir Goldstein Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3fbbdb44cead49ab5e0913e3db143954979f6174 Author: Zhu Yanjun Date: Thu Apr 26 00:41:10 2018 -0400 IB/rxe: avoid double kfree_skb [ Upstream commit 9fd4350ba8953804f05215999e11a6cfb7b41f2b ] When skb is sent, it will pass the following functions in soft roce. rxe_send [rdma_rxe] ip_local_out __ip_local_out ip_output ip_finish_output ip_finish_output2 dev_queue_xmit __dev_queue_xmit dev_hard_start_xmit In the above functions, if error occurs in the above functions or iptables rules drop skb after ip_local_out, kfree_skb will be called. So it is not necessary to call kfree_skb in soft roce module again. Or else crash will occur. The steps to reproduce: server client --------- --------- |1.1.1.1|<----rxe-channel--->|1.1.1.2| --------- --------- On server: rping -s -a 1.1.1.1 -v -C 10000 -S 512 On client: rping -c -a 1.1.1.1 -v -C 10000 -S 512 The kernel configs CONFIG_DEBUG_KMEMLEAK and CONFIG_DEBUG_OBJECTS are enabled on both server and client. When rping runs, run the following command in server: iptables -I OUTPUT -p udp --dport 4791 -j DROP Without this patch, crash will occur. CC: Srinivas Eeda CC: Junxiao Bi Signed-off-by: Zhu Yanjun Reviewed-by: Yuval Shaia Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b4f6e28c801ac69406ecf1a2d5e27b03dc4644c2 Author: Jianchao Wang Date: Thu Apr 26 11:52:39 2018 +0800 IB/rxe: add RXE_START_MASK for rxe_opcode IB_OPCODE_RC_SEND_ONLY_INV [ Upstream commit 2da36d44a9d54a2c6e1f8da1f7ccc26b0bc6cfec ] w/o RXE_START_MASK, the last_psn of IB_OPCODE_RC_SEND_ONLY_INV will not be updated in update_wqe_psn, and the corresponding wqe will not be acked in rxe_completer due to its last_psn is zero. Finally, the other wqe will also not be able to be acked, because the wqe of IB_OPCODE_RC_SEND_ONLY_INV with last_psn 0 is still there. This causes large amount of io timeout when nvmeof is over rxe. Add RXE_START_MASK for IB_OPCODE_RC_SEND_ONLY_INV to fix this. Signed-off-by: Jianchao Wang Reviewed-by: Zhu Yanjun Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2be557eef15dad24e1acef1f4179a5e207cf2ef Author: Colin Ian King Date: Wed Apr 25 17:24:04 2018 +0100 RDMA/iwpm: fix memory leak on map_info [ Upstream commit f96416cea7bce9afe619c15e87fced70f93f9098 ] In the cases where iwpm_hash_bucket is NULL and where function get_mapinfo_hash_bucket returns NULL then the map_info is never added to hash_bucket_head and hence there is a leak of map_info. Fix this by nullifying hash_bucket_head and if that is null we know that that map_info was not added to hash_bucket_head and hence map_info should be free'd. Detected by CoverityScan, CID#1222481 ("Resource Leak") Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Signed-off-by: Colin Ian King Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 019ce25a4ee05e14a879289881e9883d4583beb8 Author: Parav Pandit Date: Tue Apr 24 20:13:45 2018 +0300 RDMA/cma: Fix use after destroy access to net namespace for IPoIB [ Upstream commit 2918c1a900252b4a0c730715ec205437c7daf79d ] There are few issues with validation of netdevice and listen id lookup for IB (IPoIB) while processing incoming CM request as below. 1. While performing lookup of bind_list in cma_ps_find(), net namespace of the netdevice can get deleted in cma_exit_net(), resulting in use after free access of idr and/or net namespace structures. This lookup occurs from the workqueue context (and not userspace context where net namespace is always valid). CPU0 CPU1 ==== ==== bind_list = cma_ps_find(); move netdevice to new namespace delete net namespace cma_exit_net() idr_destroy(idr); [..] cma_find_listener(bind_list, ..); 2. While netdevice is validated for IP address in given net namespace, netdevice's net namespace and/or ifindex can change in cma_get_net_dev() and cma_match_net_dev(). Above issues are overcome by using rcu lock along with netdevice UP/DOWN state as described below. When a net namespace is getting deleted, netdevice is closed and shutdown before moving it back to init_net namespace. change_net_namespace() synchronizes with any existing use of netdevice before changing the netdev properties such as net or ifindex. Once netdevice IFF_UP flags is cleared, such fields are not guaranteed to be valid. Therefore, rcu lock along with netdevice state check ensures that, while route lookup and cm_id lookup is in progress, netdevice of interest won't migrate to any other net namespace. This ensures that associated net namespace of netdevice won't get deleted while rcu lock is held for netdevice which is in IFF_UP state. Fixes: fa20105e09e9 ("IB/cma: Add support for network namespaces") Fixes: 4be74b42a6d0 ("IB/cma: Separate port allocation to network namespaces") Fixes: f887f2ac87c2 ("IB/cma: Validate routing of incoming requests") Signed-off-by: Parav Pandit Signed-off-by: Leon Romanovsky Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84f66378da20a4efc07f6d7b35f31cd3327639f1 Author: Matan Barak Date: Tue Apr 24 08:15:20 2018 +0000 IB/uverbs: Fix validating mandatory attributes [ Upstream commit f604db645a66b7ba4f21c426fe73253928dada41 ] Previously, if a method contained mandatory attributes in a namespace that wasn't given by the user, these attributes weren't validated. Fixing this by iterating over all specification namespaces. Fixes: fac9658cabb9 ("IB/core: Add new ioctl interface") Signed-off-by: Matan Barak Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fb019834bf8e717a0fc0c67f4a61d4455e3cfec1 Author: Greg Thelen Date: Thu Apr 26 11:19:35 2018 -0700 IB: make INFINIBAND_ADDR_TRANS configurable [ Upstream commit f7cb7b85be55a4906b4b4b30596db1043dae6335 ] Allow INFINIBAND without INFINIBAND_ADDR_TRANS because fuzzing has been finding fair number of CM bugs. So provide option to disable it. Signed-off-by: Greg Thelen Cc: Tarick Bedeir Reviewed-by: Bart Van Assche Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b8500e6e8eb538c520136d92d35d0e8894210dcb Author: Greg Thelen Date: Thu Apr 26 11:19:34 2018 -0700 ib_srp: depend on INFINIBAND_ADDR_TRANS [ Upstream commit 5a3bc8a4abbd2d553430218d3a320400dce811b7 ] INFINIBAND_SRP code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir Reviewed-by: Bart Van Assche Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 08088b8a079331d80ca4e6f54892a9801c0eef32 Author: Greg Thelen Date: Thu Apr 26 11:19:32 2018 -0700 ib_srpt: depend on INFINIBAND_ADDR_TRANS [ Upstream commit 346a47b65d10e450778ec0d21e4a9409f25daaa8 ] INFINIBAND_SRPT code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir Reviewed-by: Bart Van Assche Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4e2b7d1687c4c4aeeed55e8cb9ff040a68cbf90e Author: Greg Thelen Date: Thu Apr 26 11:19:31 2018 -0700 nvmet-rdma: depend on INFINIBAND_ADDR_TRANS [ Upstream commit d6fc6a22fc7d3df987666725496ed5dd2dd30f23 ] NVME_TARGET_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8e6dba9166ed125f52287354541a753b6a532f9c Author: Greg Thelen Date: Thu Apr 26 11:19:30 2018 -0700 nvme: depend on INFINIBAND_ADDR_TRANS [ Upstream commit 3af7a156bdc356946098e13180be66b6420619bf ] NVME_RDMA code depends on INFINIBAND_ADDR_TRANS provided symbols. So declare the kconfig dependency. This is necessary to allow for enabling INFINIBAND without INFINIBAND_ADDR_TRANS. Signed-off-by: Greg Thelen Cc: Tarick Bedeir Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5d33c9d0fbd8a5a5f2dfc4affb7f9f97cb86afd0 Author: Jon Maloy Date: Wed Apr 25 18:29:25 2018 +0200 tipc: fix bug in function tipc_nl_node_dump_monitor [ Upstream commit 7dbc73e6124ce4d0cfbdd6166de388e9367c47ad ] Commit 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor summary") intended to fix a problem with user tool looping when max number of bearers are enabled. Unfortunately, the wrong version of the commit was posted, so the problem was not solved at all. This commit adds the missing part. Fixes: 36a50a989ee8 ("tipc: fix infinite loop when dumping link monitor summary") Signed-off-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit f1e5bbe86ec13618fc39d2b01ad166cfa335b488 Author: Baolin Wang Date: Mon Apr 9 14:40:55 2018 +0800 i2c: sprd: Fix the i2c count issue [ Upstream commit 2a010461207cc96bee5ab81748325dec1972976f ] We found the I2C controller count register is unreliable sometimes, that will cause I2C to lose data. Thus we can read the data count from 'i2c_dev->count' instead of the I2C controller count register. Signed-off-by: Baolin Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 201dc1345bfe7228d74830767f2a8de7be9b9723 Author: Baolin Wang Date: Mon Apr 9 14:40:54 2018 +0800 i2c: sprd: Prevent i2c accesses after suspend is called [ Upstream commit da33aa03fa34c918faf2c371ebda0dd961d7ccb2 ] Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by: Baolin Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 40d526e672125a75342b779a9305b64f8792e1b0 Author: John Fastabend Date: Wed Apr 25 15:08:53 2018 -0700 bpf: fix uninitialized variable in bpf tools [ Upstream commit 815425567dea6c54494e85050631d6bdda907c5d ] Here the variable cont is used as the saved_pointer for a call to strtok_r(). It is safe to use the value uninitialized in this context however and the later reference is only ever used if the strtok_r is successful. But, 'gcc-5' at least doesn't have all this knowledge so initialize cont to NULL. Additionally, do the natural NULL check before accessing just for completness. The warning is the following: ./bpf/tools/bpf/bpf_dbg.c: In function ‘cmd_load’: ./bpf/tools/bpf/bpf_dbg.c:1077:13: warning: ‘cont’ may be used uninitialized in this function [-Wmaybe-uninitialized] } else if (matches(subcmd, "pcap") == 0) { Fixes: fd981e3c321a "filter: bpf_dbg: add minimal bpf debugger" Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 09daf2df8db88672ae8060eee7802d93a371f244 Author: jacek.tomaka@poczta.fm Date: Tue Apr 24 00:14:25 2018 +0800 x86/cpu/intel: Add missing TLB cpuid values [ Upstream commit b837913fc2d9061bf9b8c0dd6bf2d24e2f98b84a ] Make kernel print the correct number of TLB entries on Intel Xeon Phi 7210 (and others) Before: [ 0.320005] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 After: [ 0.320005] Last level dTLB entries: 4KB 256, 2MB 128, 4MB 128, 1GB 16 The entries do exist in the official Intel SMD but the type column there is incorrect (states "Cache" where it should read "TLB"), but the entries for the values 0x6B, 0x6C and 0x6D are correctly described as 'Data TLB'. Signed-off-by: Jacek Tomaka Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20180423161425.24366-1-jacekt@dugeo.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 75b0436b24d6806c10108c4743c1c816aa026289 Author: Evan Wang Date: Fri Apr 13 12:32:31 2018 +0800 ata: ahci: mvebu: override ahci_stop_engine for mvebu AHCI [ Upstream commit daa2e3bdbb0b3e691cf20a042350817310cb8cb5 ] There is an issue(Errata Ref#226) that the SATA can not be detected via SATA Port-MultiPlayer(PMP) with following error log: ata1.15: PMP product ID mismatch ata1.15: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata1.15: Port Multiplier vendor mismatch '0x1b4b'!='0x0' ata1.15: PMP revalidation failed (errno=-19) After debugging, the reason is found that the value Port-x FIS-based Switching Control(PxFBS@0x40) become wrong. According to design, the bits[11:8, 0] of register PxFBS are cleared when Port Command and Status (0x18) bit[0] changes its value from 1 to 0, i.e. falling edge of Port Command and Status bit[0] sends PULSE that resets PxFBS bits[11:8; 0]. So it needs a mvebu SATA WA to save the port PxFBS register before PxCMD ST write and restore it afterwards. This patch implements the WA in a separate function of ahci_mvebu_stop_engine to override ahci_stop_gngine. Signed-off-by: Evan Wang Cc: Ofer Heifetz Cc: Tejun Heo Cc: Thomas Petazzoni Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 48c0bf9af16115adda818dcff78871f547643a1b Author: Evan Wang Date: Fri Apr 13 12:32:30 2018 +0800 libahci: Allow drivers to override stop_engine [ Upstream commit fa89f53bd7288d6aa7a982841119e7123faf5a53 ] Marvell armada37xx, armada7k and armada8k share the same AHCI sata controller IP, and currently there is an issue (Errata Ref#226)that the SATA can not be detected via SATA Port-MultiPlayer(PMP). After debugging, the reason is found that the value of Port-x FIS-based Switching Control (PxFBS@0x40) became wrong. According to design, the bits[11:8, 0] of register PxFBS are cleared when Port Command and Status (0x18) bit[0] changes its value from 1 to 0, i.e. falling edge of Port Command and Status bit[0] sends PULSE that resets PxFBS bits[11:8; 0]. So it needs save the port PxFBS register before PxCMD ST write and restore the port PxFBS register afterwards in ahci_stop_engine(). This commit allows drivers to override ahci_stop_engine behavior for use by the Marvell AHCI driver(and potentially other drivers in the future). Signed-off-by: Evan Wang Cc: Ofer Heifetz Cc: Tejun Heo Cc: Thomas Petazzoni Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 81d27c6ed637d5088901de01f0f5c7a624dad119 Author: Mark Rutland Date: Wed Apr 25 17:13:42 2018 +0100 KVM: arm/arm64: vgic: fix possible spectre-v1 in vgic_mmio_read_apr() [ Upstream commit 5e1ca5e23b167987d5b6d8b08f2d5b7dd2d13f49 ] It's possible for userspace to control n. Sanitize n when using it as an array index. Note that while it appears that n must be bound to the interval [0,3] due to the way it is extracted from addr, we cannot guarantee that compiler transformations (and/or future refactoring) will ensure this is the case, and given this is a slow path it's better to always perform the masking. Found by smatch. Signed-off-by: Mark Rutland Acked-by: Christoffer Dall Acked-by: Marc Zyngier Cc: kvmarm@lists.cs.columbia.edu Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e3d1002e14cede45fc543c82b469dd21c5ba027f Author: Mark Rutland Date: Wed Apr 25 17:13:40 2018 +0100 arm64: fix possible spectre-v1 in ptrace_hbp_get_event() [ Upstream commit 19791a7ca674fb3009bb068260e852a2f05b605c ] It's possible for userspace to control idx. Sanitize idx when using it as an array index. Found by smatch. Signed-off-by: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 06beec8716407961d6c4a74f1feaecd72013fa8b Author: Omar Sandoval Date: Thu Apr 26 00:21:59 2018 -0700 blk-mq: fix sysfs inflight counter [ Upstream commit bf0ddaba65ddbb2715af97041da8e7a45b2d8628 ] When the blk-mq inflight implementation was added, /proc/diskstats was converted to use it, but /sys/block/$dev/inflight was not. Fix it by adding another helper to count in-flight requests by data direction. Fixes: f299b7c7a9de ("blk-mq: provide internal in-flight variant") Signed-off-by: Omar Sandoval Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 11ac08bd73ebfda3bb0c7b748d0306bdb658e6fe Author: Arvind Yadav Date: Fri Mar 30 16:56:10 2018 +0530 HID: intel-ish-hid: use put_device() instead of kfree() [ Upstream commit a4eb490a41a0da3b1275fc7427084cf9ae2c3c1c ] Never directly free @dev after calling device_register(), even if it returned an error. Always use put_device() to give up the reference initialized. Signed-off-by: Arvind Yadav Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d803d94a3fcde7f317c40cc846d7c585532119f0 Author: Ramon Fried Date: Fri Mar 23 00:09:12 2018 -0400 rpmsg: added MODULE_ALIAS for rpmsg_char [ Upstream commit 93dd4e73c0d9cc32f835d76a54257020b0bfc75a ] Added "rpmsg:rpmsg_chrdev" MODULE_ALIAS to autoload rpmg_chrdev module automatically. Signed-off-by: Ramon Fried Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bb7894391aad325ffe83e84b412022324ce345ef Author: Tobias Jordan Date: Thu Feb 15 16:12:55 2018 +0100 remoteproc: qcom: Fix potential device node leaks [ Upstream commit 278d744c46fd4f1925aec77752d18a0e4a9cbec3 ] Add missing of_node_put()s at two places for device nodes returned by of_parse_phandle(). Fixes: 051fb70fd4ea ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5") Signed-off-by: Tobias Jordan Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af22d1b7705a130ccf917d806a139ea9ff1e9703 Author: Kan Liang Date: Wed Apr 25 14:57:17 2018 -0400 perf/x86/intel: Don't enable freeze-on-smi for PerfMon V1 [ Upstream commit 4e949e9b9d1e3edcdab3b54656c5851bd9e49c67 ] The SMM freeze feature was introduced since PerfMon V2. But the current code unconditionally enables the feature for all platforms. It can generate #GP exception, if the related FREEZE_WHILE_SMM bit is set for the machine with PerfMon V1. To disable the feature for PerfMon V1, perf needs to - Remove the freeze_on_smi sysfs entry by moving intel_pmu_attrs to intel_pmu, which is only applied to PerfMon V2 and later. - Check the PerfMon version before flipping the SMM bit when starting CPU Fixes: 6089327f5424 ("perf/x86: Add sysfs entry to freeze counters on SMI") Signed-off-by: Kan Liang Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: ak@linux.intel.com Cc: eranian@google.com Cc: acme@redhat.com Link: https://lkml.kernel.org/r/1524682637-63219-1-git-send-email-kan.liang@linux.intel.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3958294c661e35e8454147c7fc7df60c35d989c2 Author: Dag Moxnes Date: Wed Apr 25 13:22:01 2018 +0200 rds: ib: Fix missing call to rds_ib_dev_put in rds_ib_setup_qp [ Upstream commit 91a825290ca4eae88603bc811bf74a45f94a3f46 ] The function rds_ib_setup_qp is calling rds_ib_get_client_data and should correspondingly call rds_ib_dev_put. This call was lost in the non-error path with the introduction of error handling done in commit 3b12f73a5c29 ("rds: ib: add error handle") Signed-off-by: Dag Moxnes Reviewed-by: Håkon Bugge Acked-by: Santosh Shilimkar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9079946f612b25f4db25c9fbb074c2cb60c0c31d Author: Masami Hiramatsu Date: Thu Apr 5 18:29:12 2018 +0900 selftests: ftrace: Add a testcase for multiple actions on trigger [ Upstream commit 25aa50e0ca397a5e5d4d6fcecefa8107877d1dd0 ] Add a testcase for multiple actions with different parameters on an event trigger, which has been fixed by commit 192c283e93bd ("tracing: Add action comparisons when testing matching hist triggers"). Link: http://lkml.kernel.org/r/152292055227.15769.6327959816123227152.stgit@devbox Reviewed-by: Tom Zanussi Tested-by: Tom Zanussi Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 27e13b330dd2dae63b41855640d2b70517bd67e1 Author: Arvind Yadav Date: Tue Apr 24 13:33:03 2018 +0530 HID: wacom: Release device resource data obtained by devres_alloc() [ Upstream commit 097b8f62dd793e08f1732fc74dbb64596c7fbff9 ] Free device resource data, if __wacom_devm_sysfs_create_group is not successful. Signed-off-by: Arvind Yadav Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 2f3ca3908fc06af250172cf08210778cfecb66aa Author: pgzh Date: Thu Apr 12 19:36:47 2018 +0200 HID: lenovo: Add support for IBM/Lenovo Scrollpoint mice [ Upstream commit a230cd52b8a2be39cd6e9a13b3e62af57f21372a ] The IBM/Lenovo Scrollpoint mice feature a trackpoint-like stick instead of a scrolling wheel capable of 2-D (vertical+horizontal) scrolling. hid-generic does only expose 1-D (vertical) scrolling functionality for these mice. This patch adds support for horizontal scrolling for the IBM/Lenovo Scrollpoint mice to hid-lenovo. [jkosina@suse.cz: remove change versioning from git changelog] Signed-off-by: Peter Ganzhorn Reviewed-by: Benjamin Tissoires Signed-off-by: Peter De Wachter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e6ec885f5f4ce93f5fb446c52131ac159e7e63f6 Author: Mark Rutland Date: Tue Apr 24 13:11:22 2018 +0100 arm64: ptrace: remove addr_limit manipulation [ Upstream commit 59275a0c037ed6fabd6354730f1e3104264ab719 ] We transiently switch to KERNEL_DS in compat_ptrace_gethbpregs() and compat_ptrace_sethbpregs(), but in either case this is pointless as we don't perform any uaccess during this window. let's rip out the redundant addr_limit manipulation. Acked-by: Catalin Marinas Signed-off-by: Mark Rutland Cc: Will Deacon Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ef0fa5e6f52b5850440bd3cf144220b688af8b3a Author: Florian Fainelli Date: Mon Apr 23 15:51:38 2018 -0700 net: ethtool: Add missing kernel doc for FEC parameters [ Upstream commit d805c5209350ae725e3a1ee0204ba27d9e75ce3e ] While adding support for ethtool::get_fecparam and set_fecparam, kernel doc for these functions was missed, add those. Fixes: 1a5f3da20bd9 ("net: ethtool: add support for forward error correction modes") Signed-off-by: Florian Fainelli Acked-by: Roopa Prabhu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b1d0907c6feddcfe13f26b901d7e28c22d6650c0 Author: Hans de Goede Date: Sun Apr 22 19:56:17 2018 +0200 thermal: int3403_thermal: Fix NULL pointer deref on module load / probe [ Upstream commit 13b86f50eaaddaea4bdd2fe476fd12e6a0951add ] Starting with kernel 4.17 thermal_cooling_device_register() will call the get_max_state() op during register. Since we deref priv->priv in int3403_get_max_state() this means we must set priv->priv before calling thermal_cooling_device_register(). Signed-off-by: Hans de Goede Signed-off-by: Zhang Rui Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 56dfe52e04a287eb8c1d25d8fcfaef9e32fcd2e8 Author: Andres Rodriguez Date: Tue Apr 10 17:32:33 2018 -0400 drm/amdkfd: fix clock counter retrieval for node without GPU [ Upstream commit 1cf6cc74bbeb85bb87c3ca3f3df97a283c3aa737 ] Currently if a user requests clock counters for a node without a GPU resource we will always return EINVAL. Instead if no GPU resource is attached, fill the gpu_clock_counter argument with zeroes so that we may proceed and return valid CPU counters. Signed-off-by: Andres Rodriguez Signed-off-by: Felix Kuehling Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 73ea96beb771e7a1670eeb9d945a00d6bf1855d5 Author: Mika Westerberg Date: Mon Apr 23 14:16:03 2018 +0300 ACPI / watchdog: Prefer iTCO_wdt on Lenovo Z50-70 [ Upstream commit a0a37862a4e1844793d39aca9ccb8fecbdcb8659 ] WDAT table on Lenovo Z50-70 is using RTC SRAM (ports 0x70 and 0x71) to store state of the timer. This conflicts with Linux RTC driver (rtc-cmos.c) who fails to reserve those ports for itself preventing RTC from functioning. In addition the WDAT table seems not to be fully functional because it does not reset the system when the watchdog times out. On this system iTCO_wdt works just fine so we simply prefer to use it instead of WDAT. This makes RTC working again and also results working watchdog via iTCO_wdt. Reported-by: Peter Milley Link: https://bugzilla.kernel.org/show_bug.cgi?id=199033 Signed-off-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 00a85086e51fc213d66d15d5693dc4ff29ab68bd Author: Sekhar Nori Date: Tue Apr 17 18:06:00 2018 +0530 ARM: dts: da850: fix W=1 warnings with pinmux node [ Upstream commit 94a82284ad4711b7f9fd78981fdc7a1cb645030b ] Remove unused #address-cells and #size-cells from pinmux node. This fixes W=1 warnings of the type: arch/arm/boot/dts/da850-lcdk.dtb: Warning (avoid_unnecessary_addr_size): /soc@1c00000/pinmux@14120: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property Tested on DA850 LCDK by checking output of: /sys/kernel/debug/pinctrl/1c14120.pinmux-pinctrl-single/pins before and after the change. Reviewed-by: David Lechner Signed-off-by: Sekhar Nori Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9148e21d7624fd4d6b69383c8988978c7ec84ef8 Author: Jingju Hou Date: Mon Apr 23 15:22:49 2018 +0800 net: phy: marvell: clear wol event before setting it [ Upstream commit b6a930fa88083b41d26ddf1cab95cbd740936c22 ] If WOL event happened once, the LED[2] interrupt pin will not be cleared unless we read the CSISR register. If interrupts are in use, the normal interrupt handling will clear the WOL event. Let's clear the WOL event before enabling it if !phy_interrupt_is_valid(). Signed-off-by: Jingju Hou Signed-off-by: Jisheng Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b0471926ceb538d1bd75576a853dbb19722eff25 Author: Balbir Singh Date: Fri Apr 6 15:24:24 2018 +1000 powerpc/powernv/memtrace: Let the arch hotunplug code flush cache [ Upstream commit 7fd6641de28fe9b5bce0c38d2adee0a72a72619e ] Don't do this via custom code, instead now that we have support in the arch hotplug/hotunplug code, rely on those routines to do the right thing. The existing flush doesn't work because it uses ppc64_caches.l1d.size instead of ppc64_caches.l1d.line_size. Fixes: 9d5171a8f248 ("powerpc/powernv: Enable removal of memory for in memory tracing") Signed-off-by: Balbir Singh Reviewed-by: Rashmica Gupta Signed-off-by: Michael Ellerman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a4fa9189d6084067a7faa384ae1a405267caa48e Author: Geert Uytterhoeven Date: Mon Apr 23 09:32:40 2018 +0200 dt-bindings: meson-uart: DT fix s/clocks-names/clock-names/ [ Upstream commit 34df2466b48dfe258e14fe2a7bc4641416575ade ] Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 71c8e7432a2e2ed11bb78dd524bc1cbe0fbea1d6 Author: Chen Yu Date: Tue Apr 10 23:07:51 2018 +0800 ACPI / PM: Blacklist Low Power S0 Idle _DSM for ThinkPad X1 Tablet(2016) [ Upstream commit 855c1c2fce8bdbd796cba1d1456ca8f0e876c2f1 ] ThinkPad X1 Tablet(2016) is reported to have issues with the Low Power S0 Idle _DSM interface and since this machine model generally can do ACPI S3 just fine, and user would like to use S3 as default sleep model, add a blacklist entry to disable that interface for ThinkPad X1 Tablet(2016). Link: https://bugzilla.kernel.org/show_bug.cgi?id=199057 Reported-and-tested-by: Robin Lee Signed-off-by: Chen Yu Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d3bd4954286b95471c676722f21964ab36cec4d7 Author: Tobias Regnery Date: Tue Apr 10 10:38:06 2018 +0200 usb: typec: ucsi: fix tracepoint related build error [ Upstream commit 2f860691c2d2e3af1404ffeb2d22dd5c3dbca811 ] There is the following build error with CONFIG_TYPEC_UCSI=m, CONFIG_FTRACE=y and CONFIG_TRACING=n: ERROR: "__tracepoint_ucsi_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_register_port" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_notify" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_reset_ppm" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_run_command" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_ack" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! ERROR: "__tracepoint_ucsi_connector_change" [drivers/usb/typec/ucsi/typec_ucsi.ko] undefined! This compination is quite hard to create because CONFIG_TRACING gets selected only in rare cases without CONFIG_FTRACE. The build failure is caused by conditionally compiling trace.c depending on the wrong option CONFIG_FTRACE. Change this to depend on CONFIG_TRACING like other users of tracepoints do. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Signed-off-by: Tobias Regnery Acked-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6d2707f26892a07c19286c9472e2e32bd441f55e Author: Minchan Kim Date: Fri Apr 20 14:56:17 2018 -0700 mm: memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create() [ Upstream commit c892fd82cc0632d425ae011a4dd75eb59e9f84ee ] If there is heavy memory pressure, page allocation with __GFP_NOWAIT fails easily although it's order-0 request. I got below warning 9 times for normal boot. : page allocation failure: order:0, mode:0x2200000(GFP_NOWAIT|__GFP_NOTRACK) .. snip .. Call trace: dump_backtrace+0x0/0x4 dump_stack+0xa4/0xc0 warn_alloc+0xd4/0x15c __alloc_pages_nodemask+0xf88/0x10fc alloc_slab_page+0x40/0x18c new_slab+0x2b8/0x2e0 ___slab_alloc+0x25c/0x464 __kmalloc+0x394/0x498 memcg_kmem_get_cache+0x114/0x2b8 kmem_cache_alloc+0x98/0x3e8 mmap_region+0x3bc/0x8c0 do_mmap+0x40c/0x43c vm_mmap_pgoff+0x15c/0x1e4 sys_mmap+0xb0/0xc8 el0_svc_naked+0x24/0x28 Mem-Info: active_anon:17124 inactive_anon:193 isolated_anon:0 active_file:7898 inactive_file:712955 isolated_file:55 unevictable:0 dirty:27 writeback:18 unstable:0 slab_reclaimable:12250 slab_unreclaimable:23334 mapped:19310 shmem:212 pagetables:816 bounce:0 free:36561 free_pcp:1205 free_cma:35615 Node 0 active_anon:68496kB inactive_anon:772kB active_file:31592kB inactive_file:2851820kB unevictable:0kB isolated(anon):0kB isolated(file):220kB mapped:77240kB dirty:108kB writeback:72kB shmem:848kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no DMA free:142188kB min:3056kB low:3820kB high:4584kB active_anon:10052kB inactive_anon:12kB active_file:312kB inactive_file:1412620kB unevictable:0kB writepending:0kB present:1781412kB managed:1604728kB mlocked:0kB slab_reclaimable:3592kB slab_unreclaimable:876kB kernel_stack:400kB pagetables:52kB bounce:0kB free_pcp:1436kB local_pcp:124kB free_cma:142492kB lowmem_reserve[]: 0 1842 1842 Normal free:4056kB min:4172kB low:5212kB high:6252kB active_anon:58376kB inactive_anon:760kB active_file:31348kB inactive_file:1439040kB unevictable:0kB writepending:180kB present:2000636kB managed:1923688kB mlocked:0kB slab_reclaimable:45408kB slab_unreclaimable:92460kB kernel_stack:9680kB pagetables:3212kB bounce:0kB free_pcp:3392kB local_pcp:688kB free_cma:0kB lowmem_reserve[]: 0 0 0 DMA: 0*4kB 0*8kB 1*16kB (C) 0*32kB 0*64kB 0*128kB 1*256kB (C) 1*512kB (C) 0*1024kB 1*2048kB (C) 34*4096kB (C) = 142096kB Normal: 228*4kB (UMEH) 172*8kB (UMH) 23*16kB (UH) 24*32kB (H) 5*64kB (H) 1*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3872kB 721350 total pagecache pages 0 pages in swap cache Swap cache stats: add 0, delete 0, find 0/0 Free swap = 0kB Total swap = 0kB 945512 pages RAM 0 pages HighMem/MovableOnly 63408 pages reserved 51200 pages cma reserved __memcg_schedule_kmem_cache_create() tries to create a shadow slab cache and the worker allocation failure is not really critical because we will retry on the next kmem charge. We might miss some charges but that shouldn't be critical. The excessive allocation failure report is not very helpful. [mhocko@kernel.org: changelog update] Link: http://lkml.kernel.org/r/20180418022912.248417-1-minchan@kernel.org Signed-off-by: Minchan Kim Acked-by: Johannes Weiner Reviewed-by: Andrew Morton Cc: Michal Hocko Cc: Vladimir Davydov Cc: Minchan Kim Cc: Matthew Wilcox Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit cd2cc6d131709b28032e026f81baa2f9a0d9b88d Author: Dave Young Date: Fri Apr 20 14:56:10 2018 -0700 kexec_file: do not add extra alignment to efi memmap [ Upstream commit a841aa83dff0af75c88aa846ba610a8af4c5ee21 ] Chun-Yi reported a kernel warning message below: WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:182 early_iounmap+0x4f/0x12c() early_iounmap(ffffffffff200180, 00000118) [0] size not consistent 00000120 The problem is x86 kexec_file_load adds extra alignment to the efi memmap: in bzImage64_load(): efi_map_sz = efi_get_runtime_map_size(); efi_map_sz = ALIGN(efi_map_sz, 16); And __efi_memmap_init maps with the size including the alignment bytes but efi_memmap_unmap use nr_maps * desc_size which does not include the extra bytes. The alignment in kexec code is only needed for the kexec buffer internal use Actually kexec should pass exact size of the efi memmap to 2nd kernel. Link: http://lkml.kernel.org/r/20180417083600.GA1972@dhcp-128-65.nay.redhat.com Signed-off-by: Dave Young Reported-by: joeyli Tested-by: Randy Wright Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d497efd805fe5e2c2bd77f98bcc0f1700f090f0b Author: Alexey Dobriyan Date: Fri Apr 20 14:56:03 2018 -0700 proc: revalidate kernel thread inodes to root:root [ Upstream commit 2e0ad552f5f8cd0fda02bc45fcd2b89821c62fd1 ] task_dump_owner() has the following code: mm = task->mm; if (mm) { if (get_dumpable(mm) != SUID_DUMP_USER) { uid = ... } } Check for ->mm is buggy -- kernel thread might be borrowing mm and inode will go to some random uid:gid pair. Link: http://lkml.kernel.org/r/20180412220109.GA20978@avx2 Signed-off-by: Alexey Dobriyan Cc: "Eric W. Biederman" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit a20600762300154bb6ed99eea6b16abd1163dbea Author: Huang Ying Date: Fri Apr 20 14:55:38 2018 -0700 mm, pagemap: fix swap offset value for PMD migration entry [ Upstream commit 88c28f2469151b031f8cea9b28ed5be1b74a4172 ] The swap offset reported by /proc//pagemap may be not correct for PMD migration entries. If addr passed into pagemap_pmd_range() isn't aligned with PMD start address, the swap offset reported doesn't reflect this. And in the loop to report information of each sub-page, the swap offset isn't increased accordingly as that for PFN. This may happen after opening /proc//pagemap and seeking to a page whose address doesn't align with a PMD start address. I have verified this with a simple test program. BTW: migration swap entries have PFN information, do we need to restrict whether to show them? [akpm@linux-foundation.org: fix typo, per Huang, Ying] Link: http://lkml.kernel.org/r/20180408033737.10897-1-ying.huang@intel.com Signed-off-by: "Huang, Ying" Cc: Michal Hocko Cc: "Kirill A. Shutemov" Cc: Andrei Vagin Cc: Dan Williams Cc: "Jerome Glisse" Cc: Daniel Colascione Cc: Zi Yan Cc: Naoya Horiguchi Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6385f2da8b3bda687ae5e9f7c60655cfeb16632a Author: Colin Ian King Date: Fri Apr 20 10:57:16 2018 +0100 scsi: isci: Fix infinite loop in while loop [ Upstream commit 4bc83b3f272fe8f36450f9c003df49cf07ffe5fd ] In the case when the phy_mask is bitwise anded with the phy_index bit is zero the continue statement currently jumps to the next iteration of the while loop and phy_index is never actually incremented, potentially causing an infinite loop if phy_index is less than SCI_MAX_PHS. Fix this by turning the while loop into a for loop. Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 12f9bb1a273e29c0b51b5894803f8076dc5e4a8e Author: Long Li Date: Thu Mar 22 14:47:18 2018 -0700 scsi: storvsc: Set up correct queue depth values for IDE devices [ Upstream commit f286299c1d0ba5e2ca0377610307b370fe178767 ] Unlike SCSI and FC, we don't use multiple channels for IDE. Also fix the calculation for sub-channels. Signed-off-by: Long Li Reviewed-by: Michael Kelley Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit fc0d99fde0d2439ac7802efcb2f390013198db3b Author: Baolin Wang Date: Thu Apr 19 14:51:03 2018 +0800 parisc: time: Convert read_persistent_clock() to read_persistent_clock64() [ Upstream commit f76cdd00ef0e39d880139b074e3b247594dff95a ] The read_persistent_clock() uses a timespec, which is not year 2038 safe on 32bit systems. On parisc architecture, we have implemented generic RTC drivers that can be used to compensate the system suspend time, but the RTC time can not represent the nanosecond resolution, so this patch just converts to read_persistent_clock64() with timespec64. Signed-off-by: Baolin Wang Acked-by: Arnd Bergmann Signed-off-by: Helge Deller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 6bf379f26a549f06a6b38a9594a06b1b213e18de Author: David Howells Date: Fri Apr 20 13:35:02 2018 +0100 vfs: Undo an overly zealous MS_RDONLY -> SB_RDONLY conversion [ Upstream commit a9e5b73288cf1595ac2e05cf1acd1924ceea05fa ] In do_mount() when the MS_* flags are being converted to MNT_* flags, MS_RDONLY got accidentally convered to SB_RDONLY. Undo this change. Fixes: e462ec50cb5f ("VFS: Differentiate mount flags (MS_*) from internal superblock flags") Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd595dbfcbd640e8270e8fdfe8b91226a80242ac Author: dann frazier Date: Wed Apr 18 21:55:41 2018 -0600 net: hns: Avoid action name truncation [ Upstream commit f4ea89110df237da6fbcaab76af431e85f07d904 ] When longer interface names are used, the action names exposed in /proc/interrupts and /proc/irq/* maybe truncated. For example, when using the predictable name algorithm in systemd on a HiSilicon D05, I see: ubuntu@d05-3:~$ grep enahisic2i0-tx /proc/interrupts | sed 's/.* //' enahisic2i0-tx0 enahisic2i0-tx1 [...] enahisic2i0-tx8 enahisic2i0-tx9 enahisic2i0-tx1 enahisic2i0-tx1 enahisic2i0-tx1 enahisic2i0-tx1 enahisic2i0-tx1 enahisic2i0-tx1 Increase the max ring name length to allow for an interface name of IFNAMSIZE. After this change, I now see: $ grep enahisic2i0-tx /proc/interrupts | sed 's/.* //' enahisic2i0-tx0 enahisic2i0-tx1 enahisic2i0-tx2 [...] enahisic2i0-tx8 enahisic2i0-tx9 enahisic2i0-tx10 enahisic2i0-tx11 enahisic2i0-tx12 enahisic2i0-tx13 enahisic2i0-tx14 enahisic2i0-tx15 Signed-off-by: dann frazier Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ea7246c258922565a53319ddc54684d081d1b4c8 Author: Jiang Biao Date: Thu Apr 19 12:06:09 2018 +0800 blkcg: init root blkcg_gq under lock [ Upstream commit 901932a3f9b2b80352896be946c6d577c0a9652c ] The initializing of q->root_blkg is currently outside of queue lock and rcu, so the blkg may be destroied before the initializing, which may cause dangling/null references. On the other side, the destroys of blkg are protected by queue lock or rcu. Put the initializing inside the queue lock and rcu to make it safer. Signed-off-by: Jiang Biao Signed-off-by: Wen Yang CC: Tejun Heo CC: Jens Axboe Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b6126afd64d069384e41605779e8e27288185359 Author: Emil Velikov Date: Wed Mar 28 17:22:16 2018 +0100 drm/msm: don't deref error pointer in the msm_fbdev_create error path [ Upstream commit 789d4c300e10eb2096ee83c3497118e67ccc951e ] Currently the error pointer returned by msm_alloc_stolen_fb gets passed to drm_framebuffer_remove. The latter handles only NULL pointers, thus a nasty crash will occur. Drop the unnecessary fail label and the associated checks - both err and fb will be set at this stage. Cc: Rob Clark Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Signed-off-by: Emil Velikov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5151a0c8d730509cc92ac2d1a2697dd0fe48be59 Author: Stefan Agner Date: Mon Mar 19 22:26:32 2018 +0100 drm/msm/dsi: use correct enum in dsi_get_cmd_fmt [ Upstream commit a4af89286f8fc382459308764ea05935dc477cdc ] The function dsi_get_cmd_fmt returns enum dsi_cmd_dst_format, use the correct enum value also for MIPI_DSI_FMT_RGB666/_PACKED. This has been discovered using clang: drivers/gpu/drm/msm/dsi/dsi_host.c:743:35: warning: implicit conversion from enumeration type 'enum dsi_vid_dst_format' to different enumeration type 'enum dsi_cmd_dst_format' [-Wenum-conversion] case MIPI_DSI_FMT_RGB666: return VID_DST_FORMAT_RGB666; ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Stefan Agner Reviewed-by: Archit Taneja Signed-off-by: Rob Clark Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit be04f7301d8dc92a0c54392da26bd9b474ed7a2b Author: Ben Hutchings Date: Tue Apr 3 23:38:45 2018 +0100 drm/msm: Fix possible null dereference on failure of get_pages() [ Upstream commit 3976626ea3d2011f8fd3f3a47070a8b792018253 ] Commit 62e3a3e342af changed get_pages() to initialise msm_gem_object::pages before trying to initialise msm_gem_object::sgt, so that put_pages() would properly clean up pages in the failure case. However, this means that put_pages() now needs to check that msm_gem_object::sgt is not null before trying to clean it up, and this check was only applied to part of the cleanup code. Move it all into the conditional block. (Strictly speaking we don't need to make the kfree() conditional, but since we can't avoid checking for null ourselves we may as well do so.) Fixes: 62e3a3e342af ("drm/msm: fix leak in failed get_pages") Signed-off-by: Ben Hutchings Reviewed-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 625b5b8c76d42afdf5ebcd7fa8da9fa2fcebfd67 Author: Srinivas Kandagatla Date: Wed Apr 18 18:46:37 2018 +0100 ASoC: msm8916-wcd-analog: use threaded context for mbhc events [ Upstream commit a8419a0cd98ddf628a9e38a92110af7cc650dde7 ] As snd_soc_jack_report() can sleep, move handling of mbhc events to a thread context rather than in interrupt context. Fixes: de66b3455023 ('ASoC: codecs: msm8916-wcd-analog: add MBHC support') Reported-by: Bjorn Andersson Signed-off-by: Srinivas Kandagatla Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 705fd605237b384051cf64b1bfeb223f6478d6cb Author: Taehee Yoo Date: Wed Apr 18 23:35:34 2018 +0900 netfilter: nf_tables: fix out-of-bounds in nft_chain_commit_update [ Upstream commit d71efb599ad42ef1e564c652d8084252bdc85edf ] When chain name is changed, nft_chain_commit_update is called. In the nft_chain_commit_update, trans->ctx.chain->name has old chain name and nft_trans_chain_name(trans) has new chain name. If new chain name is longer than old chain name, KASAN warns slab-out-of-bounds. [ 175.015012] BUG: KASAN: slab-out-of-bounds in strcpy+0x9e/0xb0 [ 175.022735] Write of size 1 at addr ffff880114e022da by task iptables-compat/1458 [ 175.031353] CPU: 0 PID: 1458 Comm: iptables-compat Not tainted 4.16.0-rc7+ #146 [ 175.031353] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015 [ 175.031353] Call Trace: [ 175.031353] dump_stack+0x68/0xa0 [ 175.031353] print_address_description+0xd0/0x260 [ 175.031353] ? strcpy+0x9e/0xb0 [ 175.031353] kasan_report+0x234/0x350 [ 175.031353] __asan_report_store1_noabort+0x1c/0x20 [ 175.031353] strcpy+0x9e/0xb0 [ 175.031353] nf_tables_commit+0x1ccc/0x2990 [ 175.031353] nfnetlink_rcv+0x141e/0x16c0 [ 175.031353] ? nfnetlink_net_init+0x150/0x150 [ 175.031353] ? lock_acquire+0x370/0x370 [ 175.031353] ? lock_acquire+0x370/0x370 [ 175.031353] netlink_unicast+0x444/0x640 [ 175.031353] ? netlink_attachskb+0x700/0x700 [ 175.031353] ? _copy_from_iter_full+0x180/0x740 [ 175.031353] ? kasan_check_write+0x14/0x20 [ 175.031353] ? _copy_from_user+0x9b/0xd0 [ 175.031353] netlink_sendmsg+0x845/0xc70 [ ... ] Steps to reproduce: iptables-compat -N 1 iptables-compat -E 1 aaaaaaaaa Signed-off-by: Taehee Yoo Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d11b04c348940a0331689551385858298e7e1a84 Author: Pablo Neira Ayuso Date: Wed Apr 18 12:23:39 2018 +0200 netfilter: nf_tables: NAT chain and extensions require NF_TABLES [ Upstream commit 39f2ff0816e5421476c2bc538b68b4bb0708a78e ] Move these options inside the scope of the 'if' NF_TABLES and NF_TABLES_IPV6 dependencies. This patch fixes: net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_nat_do_chain': >> net/ipv6/netfilter/nft_chain_nat_ipv6.c:37: undefined reference to `nft_do_chain' net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_chain_nat_ipv6_exit': >> net/ipv6/netfilter/nft_chain_nat_ipv6.c:94: undefined reference to `nft_unregister_chain_type' net/ipv6/netfilter/nft_chain_nat_ipv6.o: In function `nft_chain_nat_ipv6_init': >> net/ipv6/netfilter/nft_chain_nat_ipv6.c:87: undefined reference to `nft_register_chain_type' that happens with: CONFIG_NF_TABLES=m CONFIG_NFT_CHAIN_NAT_IPV6=y Fixes: 02c7b25e5f54 ("netfilter: nf_tables: build-in filter chain type") Reported-by: kbuild test robot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 348288a2699c046a524aac1a43a1fa1d508945ba Author: Ming Lei Date: Mon Apr 16 17:48:41 2018 +0800 scsi: target: fix crash with iscsi target and dvd [ Upstream commit 8e1ceafe50ec4d1bcfae154dd70e7cb6946a6177 ] When the current page can't be added to bio, one new bio should be created for adding this page again, instead of ignoring this page. This patch fixes kernel crash with iscsi target and dvd, as reported by Wakko. Cc: Wakko Warner Cc: Bart Van Assche Cc: target-devel@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: "Nicholas A. Bellinger" Cc: Christoph Hellwig Fixes: 84c8590646d5b35804 ("target: avoid accessing .bi_vcnt directly") Signed-off-by: Ming Lei Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 4fb7926bba584ed7045551f8a40d0a4b0a89d2fd Author: Vinson Lee Date: Wed Mar 21 21:04:12 2018 +0000 scsi: megaraid_sas: Do not log an error if FW successfully initializes. [ Upstream commit fb1633d56b0025233ed3dc49b44544748d509d9d ] Fixes: 2d2c2331673c ("scsi: megaraid_sas: modified few prints in OCR and IOC INIT path") Signed-off-by: Vinson Lee Acked-by: Shivasharan S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit af2cc1d2e75c50ce0dbbd3455608790c4fe07fbd Author: Chris Leech Date: Mon Apr 9 15:15:28 2018 -0700 scsi: iscsi: respond to netlink with unicast when appropriate [ Upstream commit af17092810a887178195276255b7b31f8fbe7dbe ] Instead of always multicasting responses, send a unicast netlink message directed at the correct pid. This will be needed if we ever want to support multiple userspace processes interacting with the kernel over iSCSI netlink simultaneously. Limitations can currently be seen if you attempt to run multiple iscsistart commands in parallel. We've fixed up the userspace issues in iscsistart that prevented multiple instances from running, so now attempts to speed up booting by bringing up multiple iscsi sessions at once in the initramfs are just running into misrouted responses that this fixes. Signed-off-by: Chris Leech Reviewed-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f64c0c502ef050846c6dc1b56a9510afee53328 Author: Tung Nguyen Date: Tue Apr 17 21:58:27 2018 +0200 tipc: fix infinite loop when dumping link monitor summary [ Upstream commit 36a50a989ee8267588de520b8704b85f045a3220 ] When configuring the number of used bearers to MAX_BEARER and issuing command "tipc link monitor summary", the command enters infinite loop in user space. This issue happens because function tipc_nl_node_dump_monitor() returns the wrong 'prev_bearer' value when all potential monitors have been scanned. The correct behavior is to always try to scan all monitors until either the netlink message is full, in which case we return the bearer identity of the affected monitor, or we continue through the whole bearer array until we can return MAX_BEARERS. This solution also caters for the case where there may be gaps in the bearer array. Signed-off-by: Tung Nguyen Signed-off-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d5e2d69705fed4ab527f5a283b90ae602f4e0fd Author: Jiang Biao Date: Wed Apr 18 08:37:18 2018 -0600 blkcg: don't hold blkcg lock when deactivating policy [ Upstream commit 946b81da114b8ba5c74bb01e57c0c6eca2bdc801 ] As described in the comment of blkcg_activate_policy(), *Update of each blkg is protected by both queue and blkcg locks so that holding either lock and testing blkcg_policy_enabled() is always enough for dereferencing policy data.* with queue lock held, there is no need to hold blkcg lock in blkcg_deactivate_policy(). Similar case is in blkcg_activate_policy(), which has removed holding of blkcg lock in commit 4c55f4f9ad3001ac1fefdd8d8ca7641d18558e23. Signed-off-by: Jiang Biao Signed-off-by: Wen Yang CC: Tejun Heo Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c5b6316c3f5139cbc1d9a37cd6b86bb7be3802bf Author: sxauwsk Date: Tue Apr 17 04:01:27 2018 +0800 spi: cadence: Add usleep_range() for cdns_spi_fill_tx_fifo() [ Upstream commit 49530e6411789c1b9ea3ebc58e520c19d1c3752f ] In case of xspi work in busy condition, may send bytes failed. once something wrong, spi controller did't work any more My test found this situation appear in both of read/write process. so when TX FIFO is full, add one byte delay before send data; Signed-off-by: sxauwsk Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5f4bf078e779927200b246d05f569dbe75543ace Author: Liam Girdwood Date: Tue Mar 27 14:30:44 2018 +0100 ASoC: topology: Check widget kcontrols before deref. [ Upstream commit 05bdcf12905533b8628627b6634608cd3b57c607 ] Validate the topology input before we dereference the pointer. Signed-off-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ff3080bab10dcbd694b903eb8d70586c6f48b64b Author: Simon Gaiser Date: Thu Mar 15 04:08:03 2018 +0100 xen: xenbus_dev_frontend: Really return response string [ Upstream commit ebf04f331fa15a966262341a7dc6b1a0efd633e4 ] xenbus_command_reply() did not actually copy the response string and leaked stack content instead. Fixes: 9a6161fe73bd ("xen: return xenstore command failures via response instead of rc") Signed-off-by: Simon Gaiser Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d5cf1ed8d3ae37a6115a0696a4885df1c777a9e9 Author: Yan Wang Date: Mon Mar 26 16:48:00 2018 +0100 ASoC: topology: Fix bugs of freeing soc topology [ Upstream commit feb12f0cd8d7b1e8df2e6fce19fc9a026a468cc2 ] In snd_soc_tplg_component_remove(), it should compare index and not dobj->index with SND_SOC_TPLG_INDEX_ALL for removing all topology objects. Signed-off-by: Yan Wang Signed-off-by: Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit bd8acfd77dd336afa8f22bb6f0ed24a7d479c355 Author: Loic Poulain Date: Tue Apr 3 11:19:01 2018 +0200 PCI: kirin: Fix reset gpio name [ Upstream commit 5db8f8d1099bd93a64a80b609dbcce887327ffc8 ] As documented in the devicetree bindings (pci/kirin-pcie.txt) and the reset gpio name must be 'reset-gpios'. However, current driver erroneously looks for a 'reset-gpio' resource which makes the driver probe fail. Fix it. Fixes: fc5165db245a ("PCI: kirin: Add HiSilicon Kirin SoC PCIe controller driver") Signed-off-by: Loic Poulain [lorenzo.pieralisi@arm.com: updated the commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Xiaowei Song Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 150efd30c3a0d0f1fc250ebdb198dff80bf86730 Author: Geert Uytterhoeven Date: Sun Apr 8 11:05:15 2018 +0200 soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure [ Upstream commit 144345a4a8c3b497a3f60d3af9d6071a37660186 ] If CONFIG_RASPBERRYPI_FIRMWARE=n: drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_polarity’: drivers/gpio/gpio-raspberrypi-exp.c:71: warning: ‘get.polarity’ is used uninitialized in this function drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_direction’: drivers/gpio/gpio-raspberrypi-exp.c:150: warning: ‘get.direction’ is used uninitialized in this function The dummy firmware interface functions return 0, which means success, causing subsequent code to make use of the never initialized output parameter. Fix this by making the dummy functions return an error code (-ENOSYS) instead. Note that this assumes the firmware always fills in the requested data in the CONFIG_RASPBERRYPI_FIRMWARE=y case. Fixes: d45f1a563b92dac7 ("staging: vc04_services: fix up rpi firmware functions") Signed-off-by: Geert Uytterhoeven Reviewed-by: Eric Anholt Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3050437392722eb9eaad327dcd5d10a069010670 Author: Florian Fainelli Date: Sun Apr 1 09:42:25 2018 -0700 soc: bcm: raspberrypi-power: Fix use of __packed [ Upstream commit 0a12e80ce4230434c2ed66ad0d65af0b7ccecea8 ] Commit a09cd356586d ("ARM: bcm2835: add rpi power domain driver") attempted to annotate the structure rpi_power_domain_packet with __packed but introduced a typo and made it named __packet instead. Just drop the annotation since the structure is naturally aligned already. Fixes: a09cd356586d ("ARM: bcm2835: add rpi power domain driver") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d066fd9d7e9b41d60c5dca81ec5d5dbb0664a32f Author: Tyler Hicks Date: Wed Mar 28 23:41:52 2018 +0000 eCryptfs: don't pass up plaintext names when using filename encryption [ Upstream commit e86281e700cca8a773f9a572fa406adf2784ba5c ] Both ecryptfs_filldir() and ecryptfs_readlink_lower() use ecryptfs_decode_and_decrypt_filename() to translate lower filenames to upper filenames. The function correctly passes up lower filenames, unchanged, when filename encryption isn't in use. However, it was also passing up lower filenames when the filename wasn't encrypted or when decryption failed. Since 88ae4ab9802e, eCryptfs refuses to lookup lower plaintext names when filename encryption is enabled so this resulted in a situation where userspace would see lower plaintext filenames in calls to getdents(2) but then not be able to lookup those filenames. An example of this can be seen when enabling filename encryption on an eCryptfs mount at the root directory of an Ext4 filesystem: $ ls -1i /lower 12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE-- 11 lost+found $ ls -1i /upper ls: cannot access '/upper/lost+found': No such file or directory ? lost+found 12 test With this change, the lower lost+found dentry is ignored: $ ls -1i /lower 12 ECRYPTFS_FNEK_ENCRYPTED.FWYZD8TcW.5FV-TKTEYOHsheiHX9a-w.NURCCYIMjI8pn5BDB9-h3fXwrE-- 11 lost+found $ ls -1i /upper 12 test Additionally, some potentially noisy error/info messages in the related code paths are turned into debug messages so that the logs can't be easily filled. Fixes: 88ae4ab9802e ("ecryptfs_lookup(): try either only encrypted or plaintext name") Reported-by: Guenter Roeck Cc: Al Viro Signed-off-by: Tyler Hicks Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3f54483edea26a11f24085cd299707c212762e95 Author: oder_chiou@realtek.com Date: Fri Mar 30 15:41:55 2018 +0800 ASoC: rt5514: Add the missing register in the readable table [ Upstream commit 5ef5ac8de125fe6b4b23293bee026ca7ea1529b9 ] The patch adds the missing register in the readable table. Signed-off-by: Oder Chiou Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9d33f89c40e9c9ae42a69e49566a3efdc165b0dd Author: Jerome Brunet Date: Mon Apr 9 15:59:20 2018 +0200 clk: honor CLK_MUX_ROUND_CLOSEST in generic clk mux [ Upstream commit 4ad69b80e886a845f56ce0a3d10211208693d92b ] CLK_MUX_ROUND_CLOSEST is part of the clk_mux documentation but clk_mux directly calls __clk_mux_determine_rate(), which overrides the flag. As result, if clk_mux is instantiated with CLK_MUX_ROUND_CLOSEST, the flag will be ignored and the clock rounded down. To solve this, this patch expose clk_mux_determine_rate_flags() in the clk-provider API and uses it in the determine_rate() callback of clk_mux. Fixes: 15a02c1f6dd7 ("clk: Add __clk_mux_determine_rate_closest") Signed-off-by: Jerome Brunet Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dccf9862a7f5afe8c81bd52302918c33d9ba57d6 Author: Jacopo Mondi Date: Mon Apr 16 15:56:08 2018 +0200 dt-bindings: dmaengine: rcar-dmac: document R8A77965 support [ Upstream commit b89bc283286b105e50aab9ab35992c0237ac77d8 ] Add documentation for r8a77965 compatible string to rcar-dmac device tree bindings documentation. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Rob Herring Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20d68135933707021bdd708cf2238a66975f0dc3 Author: Jacopo Mondi Date: Mon Apr 16 15:55:28 2018 +0200 dt-bindings: serial: sh-sci: Add support for r8a77965 (H)SCIF [ Upstream commit 7de5b7e5f6a67c285b86d1478e8e150929c93482 ] Add documentation for r8a77965 compatible string to Renesas sci-serial device tree bindings documentation. Signed-off-by: Jacopo Mondi Reviewed-by: Geert Uytterhoeven Signed-off-by: Rob Herring Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 20d3d7fa75b2edf6618d288367ec8de5cac1cf84 Author: Matheus Castello Date: Wed Apr 11 01:17:03 2018 -0400 dt-bindings: pinctrl: sunxi: Fix reference to driver [ Upstream commit b614e905a0bc8fc5d4fa72665ac26ae00c874a4e ] Bindings describe hardware, not drivers. Use reference to hardware Allwinner A1X Pin Controller instead driver. Signed-off-by: Matheus Castello Signed-off-by: Rob Herring Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 5eeb26c58c0a66cade30410aaeb112e866cb8c2e Author: Lukasz Majewski Date: Wed Apr 4 09:52:04 2018 +0200 doc: Add vendor prefix for Kieback & Peter GmbH [ Upstream commit 99bf8f27f3f94d2a37291354b8dc83f13728f75f ] The 'kiebackpeter' entry has been added to vendor-prefixes.txt to indicate products from Kieback & Peter GmbH. Signed-off-by: Lukasz Majewski Signed-off-by: Rob Herring Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 3ca7dddaa13f8e7f4e618bf54dad2d18e9efc251 Author: Vladimir Zapolskiy Date: Fri Apr 13 15:44:16 2018 +0300 spi: sh-msiof: Fix bit field overflow writes to TSCR/RSCR [ Upstream commit 10b4640833e95eeacaef8060bc1b35e636df3218 ] The change fixes a bit field overflow which allows to write to higher bits while calculating SPI transfer clock and setting BRPS and BRDV bit fields, the problem is reproduced if 'parent_rate' to 'spi_hz' ratio is greater than 1024, for instance p->min_div = 2, MSO rate = 33333333, SPI device rate = 10000 results in k = 5, i.e. BRDV = 0b100 or 1/32 prescaler output, BRPS = 105, TSCR value = 0x6804, thus MSSEL and MSIMM bit fields are non-zero. Fixes: 65d5665bb260 ("spi: sh-msiof: Update calculation of frequency dividing") Signed-off-by: Vladimir Zapolskiy Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b3ccb8a77ed11c366fe8d3c3d64a71b5ddf44a75 Author: Matt Redfearn Date: Fri Apr 13 09:50:44 2018 +0100 MIPS: dts: Boston: Fix PCI bus dtc warnings: [ Upstream commit 2c2bf522ed8cbfaac666f7dc65cfd38de2b89f0f ] dtc recently (v1.4.4-8-g756ffc4f52f6) added PCI bus checks. Fix the warnings now emitted: arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@10000000: missing bus-range for PCI bridge arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@12000000: missing bus-range for PCI bridge arch/mips/boot/dts/img/boston.dtb: Warning (pci_bridge): /pci@14000000: missing bus-range for PCI bridge Signed-off-by: Matt Redfearn Cc: Ralf Baechle Cc: Paul Burton Cc: Rob Herring Cc: Mark Rutland Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/19070/ Signed-off-by: James Hogan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit ba041775a9a8291327f958d6337d130217de1bee Author: Chengguang Xu Date: Sat Apr 14 20:16:06 2018 +0800 isofs: fix potential memory leak in mount option parsing [ Upstream commit 4f34a5130a471f32f2fe7750769ab4057dc3eaa0 ] When specifying string type mount option (e.g., iocharset) several times in a mount, current option parsing may cause memory leak. Hence, call kfree for previous one in this case. Meanwhile, check memory allocation result for it. Signed-off-by: Chengguang Xu Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d27cd5cb9b384803d69204b07b447e9abe32f127 Author: Martin Schwidefsky Date: Tue Apr 3 11:08:52 2018 +0200 s390/smsgiucv: disable SMSG on module unload [ Upstream commit 760dd0eeaec1689430243ead14e5a429613d8c52 ] The module exit function of the smsgiucv module uses the incorrect CP command to disable SMSG messages. The correct command is "SET SMSG OFF". Use it. Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit e7b720ef94d8582a1346e6aebf03f8a59e682b17 Author: Sinan Kaya Date: Thu Apr 12 22:30:44 2018 -0400 MIPS: io: Add barrier after register read in readX() [ Upstream commit a1cc7034e33d12dc17d13fbcd7d597d552889097 ] While a barrier is present in the writeX() functions before the register write, a similar barrier is missing in the readX() functions after the register read. This could allow memory accesses following readX() to observe stale data. Signed-off-by: Sinan Kaya Reported-by: Arnd Bergmann Cc: Ralf Baechle Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/19069/ [jhogan@kernel.org: Tidy commit message] Signed-off-by: James Hogan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit dc94ac5fc41054c16824b01683fade1b77a07c7a Author: Amir Goldstein Date: Thu Apr 5 16:18:03 2018 +0300 fsnotify: fix ignore mask logic in send_to_group() [ Upstream commit 92183a42898dc400b89da35685d1814ac6acd3d8 ] The ignore mask logic in send_to_group() does not match the logic in fanotify_should_send_event(). In the latter, a vfsmount mark ignore mask precedes an inode mark mask and in the former, it does not. That difference may cause events to be sent to fanotify backend for no reason. Fix the logic in send_to_group() to match that of fanotify_should_send_event(). Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 025e42a5e7a318572d0ea2b94b508011bcaff306 Author: Arnaldo Carvalho de Melo Date: Thu Apr 12 14:58:24 2018 -0300 perf report: Fix switching to another perf.data file [ Upstream commit 7b366142a50ad79e48de8e67c5b3e8cfb9fa82dd ] In the TUI the 's' hotkey can be used to switch to another perf.data file in the current directory, but that got broken in Fixes: b01141f4f59c ("perf annotate: Initialize the priv are in symbol__new()"), that would show this once another file was chosen: ┌─Fatal Error─────────────────────────────────────┐ │Annotation needs to be init before symbol__init()│ │ │ │ │ │Press any key... │ └─────────────────────────────────────────────────┘ Fix it by just silently bailing out if symbol__annotation_init() was already called, just like is done with symbol__init(), i.e. they are done just once at session start, not when switching to a new perf.data file. Cc: Adrian Hunter Cc: Andi Kleen Cc: David Ahern Cc: Jin Yao Cc: Jiri Olsa Cc: Martin Liška Cc: Namhyung Kim Cc: Ravi Bangoria Cc: Thomas Richter Cc: Wang Nan Fixes: b01141f4f59c ("perf annotate: Initialize the priv are in symbol__new()") Link: https://lkml.kernel.org/n/tip-ogppdtpzfax7y1h6gjdv5s6u@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 7bb0c4bd79ab318225f4dfd9e2394c998a6bd566 Author: Jakub Kicinski Date: Wed Apr 11 16:47:35 2018 -0700 nfp: ignore signals when communicating with management FW [ Upstream commit 5496295aefe86995e41398b0f76de601308fc3f5 ] We currently allow signals to interrupt the wait for management FW commands. Exiting the wait should not cause trouble, the FW will just finish executing the command in the background and new commands will wait for the old one to finish. However, this may not be what users expect (Ctrl-C not actually stopping the command). Moreover some systems routinely request link information with signals pending (Ubuntu 14.04 runs a landscape-sysinfo python tool from MOTD) worrying users with errors like these: nfp 0000:04:00.0: nfp_nsp: Error -512 waiting for code 0x0007 to start nfp 0000:04:00.0: nfp: reading port table failed -512 Make the wait for management FW responses non-interruptible. Fixes: 1a64821c6af7 ("nfp: add support for service processor access") Signed-off-by: Jakub Kicinski Reviewed-by: Dirk van der Merwe Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d96da2acac5dcf3d8187794b5ef86481ddcf2791 Author: Sinan Kaya Date: Tue Apr 3 08:55:03 2018 -0400 MIPS: io: Prevent compiler reordering writeX() [ Upstream commit f6b7aeee8f167409195fbf1364d02988fecad1d0 ] writeX() has strong ordering semantics with respect to memory updates. In the absence of a write barrier or a compiler barrier, the compiler can reorder register and memory update instructions. This breaks the writeX() API. Signed-off-by: Sinan Kaya Cc: Arnd Bergmann Cc: Ralf Baechle Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/18997/ [jhogan@kernel.org: Tidy commit message] Signed-off-by: James Hogan Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit df5524e5483b6a29c011721131a510fae3ce0f45 Author: Krish Sadhukhan Date: Wed Apr 11 01:10:16 2018 -0400 x86: Add check for APIC access address for vmentry of L2 guests [ Upstream commit f0f4cf5b306620282db0c59ff963012e1973e025 ] According to the sub-section titled 'VM-Execution Control Fields' in the section titled 'Basic VM-Entry Checks' in Intel SDM vol. 3C, the following vmentry check must be enforced: If the 'virtualize APIC-accesses' VM-execution control is 1, the APIC-access address must satisfy the following checks: - Bits 11:0 of the address must be 0. - The address should not set any bits beyond the processor's physical-address width. This patch adds the necessary check to conform to this rule. If the check fails, we cause the L2 VMENTRY to fail which is what the associated unit test (following patch) expects. Reviewed-by: Mihai Carabas Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Jim Mattson Reviewed-by: Wanpeng Li Signed-off-by: Krish Sadhukhan Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 9b78e9ddc47ac2da31db600065ea6577dc9f8170 Author: hu huajun Date: Wed Apr 11 15:16:40 2018 +0800 KVM: X86: fix incorrect reference of trace_kvm_pi_irte_update [ Upstream commit 2698d82e519413c6ad287e6f14b29e0373ed37f8 ] In arch/x86/kvm/trace.h, this function is declared as host_irq the first input, and vcpu_id the second, instead of otherwise. Signed-off-by: hu huajun Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 176ebf4df9710fefe751d6565c35da5a45aeece3 Author: Christophe JAILLET Date: Fri Apr 6 15:36:11 2018 -0700 Input: synaptics-rmi4 - fix an unchecked out of memory error path [ Upstream commit 839c42273617787318da7baf6151d553108f5e17 ] When extending the rmi_spi buffers, we must check that no out of memory error occurs, otherwise we may access data above the currently allocated memory. Propagate the error code returned by 'rmi_spi_manage_pools()' instead. Signed-off-by: Christophe JAILLET Reviewed-by: Andrew Duggan Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 65783949c813d0cad88b6a30f47737e8dfc00c86 Author: Anson Huang Date: Wed Mar 28 11:22:37 2018 +0800 clocksource/drivers/imx-tpm: Correct some registers operation flow [ Upstream commit 506a7be93ff773d5d4cf75a59f342865605b4910 ] According to i.MX7ULP reference manual, TPM_SC_CPWMS can ONLY be written when counter is disabled, TPM_SC_TOF is write-1-clear, TPM_C0SC_CHF is also write-1-clear, correct these registers initialization flow; Signed-off-by: Anson Huang Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman