commit eb982e5ed56821880e35073c45df01562eb850b0 Author: Ben Hutchings Date: Thu Apr 4 16:14:13 2019 +0100 Linux 3.16.65 commit cbf513cb2080cc507f4b1f2d1a95141e64c87db3 Author: Pavel Shilovsky Date: Mon Nov 7 18:20:50 2016 -0800 CIFS: Enable encryption during session setup phase commit cabfb3680f78981d26c078a26e5c748531257ebb upstream. In order to allow encryption on SMB connection we need to exchange a session key and generate encryption and decryption keys. Signed-off-by: Pavel Shilovsky [bwh: Backported to 3.16: - SMB2_sess_establish_session() has not been split out from SMB2_sess_setup() and there is additional cleanup to do on error, so keep the 'goto keygen_exit' - Adjust context] Signed-off-by: Ben Hutchings commit 553ae0f9207b1779e4da88b53f3a1f0cb0c127c6 Author: Ben Hutchings Date: Mon Apr 1 03:01:57 2019 +0100 Revert "cifs: empty TargetInfo leads to crash on recovery" Revert commit 36a0db05310fbee38b59fed7e1306c1a095f8c8f, a minimal backport of commit cabfb3680f78981d26c078a26e5c748531257ebb upstream. We need a complete backport to avoid a regression for SMB3 authenticated mounts. Reported-by: Stephan Seitz References: https://lists.debian.org/debian-lts/2019/03/msg00071.html Cc: Dan Aloni Signed-off-by: Ben Hutchings commit ac6c8783b756a5c42d7cb808f929d9c5fc94a1c5 Author: Shrikrishna Khare Date: Wed Jan 6 10:44:27 2016 -0800 Driver: Vmxnet3: Fix regression caused by 5738a09 commit 58caf637365fef97c8e84ea5699a8e34d68fce93 upstream. Reported-by: Bingkuo Liu Signed-off-by: Shrikrishna Khare Signed-off-by: David S. Miller [bwh: Backported to 3.16: - Bump version from 1.2.2.0-k to 1.2.3.0-k, which wasn't used in mainline - Adjust context, indentation] Signed-off-by: Ben Hutchings commit f232ef2904b7411d31e9504e53e968cdd28e8ef7 Author: Eric Dumazet Date: Wed Jan 2 04:24:20 2019 -0800 net/hamradio/6pack: use mod_timer() to rearm timers commit 202700e30740c6568b5a6943662f3829566dd533 upstream. Using del_timer() + add_timer() is generally unsafe on SMP, as noticed by syzbot. Use mod_timer() instead. kernel BUG at kernel/time/timer.c:1136! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 1026 Comm: kworker/u4:4 Not tainted 4.20.0+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events_unbound flush_to_ldisc RIP: 0010:add_timer kernel/time/timer.c:1136 [inline] RIP: 0010:add_timer+0xa81/0x1470 kernel/time/timer.c:1134 Code: 4d 89 7d 40 48 c7 85 70 fe ff ff 00 00 00 00 c7 85 7c fe ff ff ff ff ff ff 48 89 85 90 fe ff ff e9 e6 f7 ff ff e8 cf 42 12 00 <0f> 0b e8 c8 42 12 00 0f 0b e8 c1 42 12 00 4c 89 bd 60 fe ff ff e9 RSP: 0018:ffff8880a7fdf5a8 EFLAGS: 00010293 RAX: ffff8880a7846340 RBX: dffffc0000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff816f3ee1 RDI: ffff88808a514ff8 RBP: ffff8880a7fdf760 R08: 0000000000000007 R09: ffff8880a7846c58 R10: ffff8880a7846340 R11: 0000000000000000 R12: ffff88808a514ff8 R13: ffff88808a514ff8 R14: ffff88808a514dc0 R15: 0000000000000030 FS: 0000000000000000(0000) GS:ffff8880ae700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000061c500 CR3: 00000000994d9000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: decode_prio_command drivers/net/hamradio/6pack.c:903 [inline] sixpack_decode drivers/net/hamradio/6pack.c:971 [inline] sixpack_receive_buf drivers/net/hamradio/6pack.c:457 [inline] sixpack_receive_buf+0xf9c/0x1470 drivers/net/hamradio/6pack.c:434 tty_ldisc_receive_buf+0x164/0x1c0 drivers/tty/tty_buffer.c:465 tty_port_default_receive_buf+0x114/0x190 drivers/tty/tty_port.c:38 receive_buf drivers/tty/tty_buffer.c:481 [inline] flush_to_ldisc+0x3b2/0x590 drivers/tty/tty_buffer.c:533 process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153 worker_thread+0x143/0x14a0 kernel/workqueue.c:2296 kthread+0x357/0x430 kernel/kthread.c:246 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Andreas Koensgen Signed-off-by: David S. Miller [bwh: Backported to 3.16: Move initialisation of resync_t.data and resync_t.function to sixpack_open(), as done by upstream commit 8e763de0b91d "net/hamradio/6pack: Convert timers to use timer_setup()".] Signed-off-by: Ben Hutchings commit 43cbb7c1e73072f70be348263d33a266ce839b00 Author: Sameer Pujar Date: Wed Dec 26 16:04:49 2018 +0530 ALSA: hda/tegra: clear pending irq handlers commit 63d2a9ec310d8bcc955574220d4631aa55c1a80c upstream. Even after disabling interrupts on the module, it could be possible that irq handlers are still running. System hang is seen during suspend path. It was found that, there were pending writes on the HDA bus and clock was disabled by that time. Above mentioned issue is fixed by clearing any pending irq handlers before disabling clocks and returning from hda suspend. Suggested-by: Mohan Kumar Suggested-by: Dara Ramesh Signed-off-by: Sameer Pujar Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: - Use azx::irq instead of hdac_bus::irq - Adjust context] Signed-off-by: Ben Hutchings commit 61b77ece53982b821849f49fcd64968a77787388 Author: Theodore Ts'o Date: Mon Dec 31 22:34:31 2018 -0500 ext4: fix special inode number checks in __ext4_iget() commit 191ce17876c9367819c4b0a25b503c0f6d9054d8 upstream. The check for special (reserved) inode number checks in __ext4_iget() was broken by commit 8a363970d1dc: ("ext4: avoid declaring fs inconsistent due to invalid file handles"). This was caused by a botched reversal of the sense of the flag now known as EXT4_IGET_SPECIAL (when it was previously named EXT4_IGET_NORMAL). Fix the logic appropriately. Fixes: 8a363970d1dc ("ext4: avoid declaring fs inconsistent...") Signed-off-by: Theodore Ts'o Reported-by: Dan Carpenter Signed-off-by: Ben Hutchings commit 2afa3fc1724c1c77837c6f6b7acfc5bab6081389 Author: Tyrel Datwyler Date: Mon Dec 31 15:43:01 2018 -0600 ibmveth: fix DMA unmap error in ibmveth_xmit_start error path commit 756af9c642329d54f048bac2a62f829b391f6944 upstream. Commit 33a48ab105a7 ("ibmveth: Fix DMA unmap error") fixed an issue in the normal code path of ibmveth_xmit_start() that was originally introduced by Commit 6e8ab30ec677 ("ibmveth: Add scatter-gather support"). This original fix missed the error path where dma_unmap_page is wrongly called on the header portion in descs[0] which was mapped with dma_map_single. As a result a failure to DMA map any of the frags results in a dmesg warning when CONFIG_DMA_API_DEBUG is enabled. ------------[ cut here ]------------ DMA-API: ibmveth 30000002: device driver frees DMA memory with wrong function [device address=0x000000000a430000] [size=172 bytes] [mapped as page] [unmapped as single] WARNING: CPU: 1 PID: 8426 at kernel/dma/debug.c:1085 check_unmap+0x4fc/0xe10 ... ... DMA-API: Mapped at: ibmveth_start_xmit+0x30c/0xb60 dev_hard_start_xmit+0x100/0x450 sch_direct_xmit+0x224/0x490 __qdisc_run+0x20c/0x980 __dev_queue_xmit+0x1bc/0xf20 This fixes the API misuse by unampping descs[0] with dma_unmap_single. Fixes: 6e8ab30ec677 ("ibmveth: Add scatter-gather support") Signed-off-by: Tyrel Datwyler Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings commit c4712cd74e68cd49c55b07b3648af2f20fe2938f Author: Finn Thain Date: Mon Dec 31 16:44:09 2018 +1100 block/swim3: Fix -EBUSY error when re-opening device after unmount commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 upstream. When the block device is opened with FMODE_EXCL, ref_count is set to -1. This value doesn't get reset when the device is closed which means the device cannot be opened again. Fix this by checking for refcount <= 0 in the release method. Reported-and-tested-by: Stan Johnson Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Finn Thain Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit ca323c61656c51dd1c96233b178b58ba8aa6ca5b Author: Theodore Ts'o Date: Sun Dec 30 23:20:39 2018 -0500 ext4: avoid kernel warning when writing the superblock to a dead device commit e86807862e6880809f191c4cea7f88a489f0ed34 upstream. The xfstests generic/475 test switches the underlying device with dm-error while running a stress test. This results in a large number of file system errors, and since we can't lock the buffer head when marking the superblock dirty in the ext4_grp_locked_error() case, it's possible the superblock to be !buffer_uptodate() without buffer_write_io_error() being true. We need to set buffer_uptodate() before we call mark_buffer_dirty() or this will trigger a WARN_ON. It's safe to do this since the superblock must have been properly read into memory or the mount would have been successful. So if buffer_uptodate() is not set, we can safely assume that this happened due to a failed attempt to write the superblock. Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 85ef35ab972b7484f41c3bb2bbc79de212e19129 Author: Michal Hocko Date: Fri Dec 28 00:38:01 2018 -0800 hwpoison, memory_hotplug: allow hwpoisoned pages to be offlined commit b15c87263a69272423771118c653e9a1d0672caa upstream. We have received a bug report that an injected MCE about faulty memory prevents memory offline to succeed on 4.4 base kernel. The underlying reason was that the HWPoison page has an elevated reference count and the migration keeps failing. There are two problems with that. First of all it is dubious to migrate the poisoned page because we know that accessing that memory is possible to fail. Secondly it doesn't make any sense to migrate a potentially broken content and preserve the memory corruption over to a new location. Oscar has found out that 4.4 and the current upstream kernels behave slightly differently with his simply testcase === int main(void) { int ret; int i; int fd; char *array = malloc(4096); char *array_locked = malloc(4096); fd = open("/tmp/data", O_RDONLY); read(fd, array, 4095); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; ret = mlock((void *)PAGE_ALIGN((unsigned long)array_locked), sizeof(array_locked)); if (ret) perror("mlock"); sleep (20); ret = madvise((void *)PAGE_ALIGN((unsigned long)array_locked), 4096, MADV_HWPOISON); if (ret) perror("madvise"); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; return 0; } === + offline this memory. In 4.4 kernels he saw the hwpoisoned page to be returned back to the LRU list kernel: [] dump_trace+0x59/0x340 kernel: [] show_stack_log_lvl+0xea/0x170 kernel: [] show_stack+0x21/0x40 kernel: [] dump_stack+0x5c/0x7c kernel: [] warn_slowpath_common+0x81/0xb0 kernel: [] __pagevec_lru_add_fn+0x14c/0x160 kernel: [] pagevec_lru_move_fn+0xad/0x100 kernel: [] __lru_cache_add+0x6c/0xb0 kernel: [] add_to_page_cache_lru+0x46/0x70 kernel: [] extent_readpages+0xc3/0x1a0 [btrfs] kernel: [] __do_page_cache_readahead+0x177/0x200 kernel: [] ondemand_readahead+0x168/0x2a0 kernel: [] generic_file_read_iter+0x41f/0x660 kernel: [] __vfs_read+0xcd/0x140 kernel: [] vfs_read+0x7a/0x120 kernel: [] kernel_read+0x3b/0x50 kernel: [] do_execveat_common.isra.29+0x490/0x6f0 kernel: [] do_execve+0x28/0x30 kernel: [] call_usermodehelper_exec_async+0xfb/0x130 kernel: [] ret_from_fork+0x55/0x80 And that latter confuses the hotremove path because an LRU page is attempted to be migrated and that fails due to an elevated reference count. It is quite possible that the reuse of the HWPoisoned page is some kind of fixed race condition but I am not really sure about that. With the upstream kernel the failure is slightly different. The page doesn't seem to have LRU bit set but isolate_movable_page simply fails and do_migrate_range simply puts all the isolated pages back to LRU and therefore no progress is made and scan_movable_pages finds same set of pages over and over again. Fix both cases by explicitly checking HWPoisoned pages before we even try to get reference on the page, try to unmap it if it is still mapped. As explained by Naoya: : Hwpoison code never unmapped those for no big reason because : Ksm pages never dominate memory, so we simply didn't have strong : motivation to save the pages. Also put WARN_ON(PageLRU) in case there is a race and we can hit LRU HWPoison pages which shouldn't happen but I couldn't convince myself about that. Naoya has noted the following: : Theoretically no such gurantee, because try_to_unmap() doesn't have a : guarantee of success and then memory_failure() returns immediately : when hwpoison_user_mappings fails. : Or the following code (comes after hwpoison_user_mappings block) also impli= : es : that the target page can still have PageLRU flag. : : /* : * Torn down by someone else? : */ : if (PageLRU(p) && !PageSwapCache(p) && p->mapping =3D=3D NULL) { : action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED); : res =3D -EBUSY; : goto out; : } : : So I think it's OK to keep "if (WARN_ON(PageLRU(page)))" block in : current version of your patch. Link: http://lkml.kernel.org/r/20181206120135.14079-1-mhocko@kernel.org Signed-off-by: Michal Hocko Reviewed-by: Oscar Salvador Debugged-by: Oscar Salvador Tested-by: Oscar Salvador Acked-by: David Hildenbrand Acked-by: Naoya Horiguchi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 21de2791382684e0b2292a5f55e796d0641db1b9 Author: Michal Hocko Date: Fri Dec 28 00:34:13 2018 -0800 mm, memory_hotplug: do not clear numa_node association after hot_remove commit 46a3679b8190101e4ebdfe252ef79e6150a4f2ac upstream. Per-cpu numa_node provides a default node for each possible cpu. The association gets initialized during the boot when the architecture specific code explores cpu->NUMA affinity. When the whole NUMA node is removed though we are clearing this association try_offline_node check_and_unmap_cpu_on_node unmap_cpu_on_node numa_clear_node numa_set_node(cpu, NUMA_NO_NODE) This means that whoever calls cpu_to_node for a cpu associated with such a node will get NUMA_NO_NODE. This is problematic for two reasons. First it is fragile because __alloc_pages_node would simply blow up on an out-of-bound access. We have encountered this when loading kvm module BUG: unable to handle kernel paging request at 00000000000021c0 IP: __alloc_pages_nodemask+0x93/0xb70 PGD 800000ffe853e067 PUD 7336bbc067 PMD 0 Oops: 0000 [#1] SMP [...] CPU: 88 PID: 1223749 Comm: modprobe Tainted: G W 4.4.156-94.64-default #1 RIP: __alloc_pages_nodemask+0x93/0xb70 RSP: 0018:ffff887354493b40 EFLAGS: 00010202 RAX: 00000000000021c0 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 00000000014000c0 RBP: 00000000014000c0 R08: ffffffffffffffff R09: 0000000000000000 R10: ffff88fffc89e790 R11: 0000000000014000 R12: 0000000000000101 R13: ffffffffa0772cd4 R14: ffffffffa0769ac0 R15: 0000000000000000 FS: 00007fdf2f2f1700(0000) GS:ffff88fffc880000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000021c0 CR3: 00000077205ee000 CR4: 0000000000360670 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: alloc_vmcs_cpu+0x3d/0x90 [kvm_intel] hardware_setup+0x781/0x849 [kvm_intel] kvm_arch_hardware_setup+0x28/0x190 [kvm] kvm_init+0x7c/0x2d0 [kvm] vmx_init+0x1e/0x32c [kvm_intel] do_one_initcall+0xca/0x1f0 do_init_module+0x5a/0x1d7 load_module+0x1393/0x1c90 SYSC_finit_module+0x70/0xa0 entry_SYSCALL_64_fastpath+0x1e/0xb7 DWARF2 unwinder stuck at entry_SYSCALL_64_fastpath+0x1e/0xb7 on an older kernel but the code is basically the same in the current Linus tree as well. alloc_vmcs_cpu could use alloc_pages_nodemask which would recognize NUMA_NO_NODE and use alloc_pages_node which would translate it to numa_mem_id but that is wrong as well because it would use a cpu affinity of the local CPU which might be quite far from the original node. It is also reasonable to expect that cpu_to_node will provide a sane value and there might be many more callers like that. The second problem is that __register_one_node relies on cpu_to_node to properly associate cpus back to the node when it is onlined. We do not want to lose that link as there is no arch independent way to get it from the early boot time AFAICS. Drop the whole check_and_unmap_cpu_on_node machinery and keep the association to fix both issues. The NODE_DATA(nid) is not deallocated so it will stay in place and if anybody wants to allocate from that node then a fallback node will be used. Thanks to Vlastimil Babka for his live system debugging skills that helped debugging the issue. Link: http://lkml.kernel.org/r/20181108100413.966-1-mhocko@kernel.org Fixes: e13fe8695c57 ("cpu-hotplug,memory-hotplug: clear cpu_to_node() when offlining the node") Signed-off-by: Michal Hocko Debugged-by: Vlastimil Babka Reported-by: Miroslav Benes Acked-by: Anshuman Khandual Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 284aa5470ebc78e7ce9139288abe9b3c1fc95a2c Author: Mike Kravetz Date: Fri Oct 5 15:51:29 2018 -0700 mm: migration: fix migration of huge PMD shared pages commit 017b1660df89f5fb4bfe66c34e35f7d2031100c7 upstream. The page migration code employs try_to_unmap() to try and unmap the source page. This is accomplished by using rmap_walk to find all vmas where the page is mapped. This search stops when page mapcount is zero. For shared PMD huge pages, the page map count is always 1 no matter the number of mappings. Shared mappings are tracked via the reference count of the PMD page. Therefore, try_to_unmap stops prematurely and does not completely unmap all mappings of the source page. This problem can result is data corruption as writes to the original source page can happen after contents of the page are copied to the target page. Hence, data is lost. This problem was originally seen as DB corruption of shared global areas after a huge page was soft offlined due to ECC memory errors. DB developers noticed they could reproduce the issue by (hotplug) offlining memory used to back huge pages. A simple testcase can reproduce the problem by creating a shared PMD mapping (note that this must be at least PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using migrate_pages() to migrate process pages between nodes while continually writing to the huge pages being migrated. To fix, have the try_to_unmap_one routine check for huge PMD sharing by calling huge_pmd_unshare for hugetlbfs huge pages. If it is a shared mapping it will be 'unshared' which removes the page table entry and drops the reference on the PMD page. After this, flush caches and TLB. mmu notifiers are called before locking page tables, but we can not be sure of PMD sharing until page tables are locked. Therefore, check for the possibility of PMD sharing before locking so that notifiers can prepare for the worst possible case. Link: http://lkml.kernel.org/r/20180823205917.16297-2-mike.kravetz@oracle.com [mike.kravetz@oracle.com: make _range_in_vma() a static inline] Link: http://lkml.kernel.org/r/6063f215-a5c8-2f0c-465a-2c515ddc952d@oracle.com Fixes: 39dde65c9940 ("shared page table for hugetlb page") Signed-off-by: Mike Kravetz Acked-by: Kirill A. Shutemov Reviewed-by: Naoya Horiguchi Acked-by: Michal Hocko Cc: Vlastimil Babka Cc: Davidlohr Bueso Cc: Jerome Glisse Cc: Mike Kravetz Signed-off-by: Andrew Morton Signed-off-by: Mike Kravetz Acked-by: Michal Hocko Reviewed-by: Jérôme Glisse Signed-off-by: Greg Kroah-Hartman [bwh: Backported from 4.4 to 3.16: adjust context] Signed-off-by: Ben Hutchings commit f6e0937e8f6cb40b548c1a62698c4267cea3c511 Author: Hugh Dickins Date: Thu Nov 5 18:49:33 2015 -0800 mm: rmap use pte lock not mmap_sem to set PageMlocked commit b87537d9e2feb30f6a962f27eb32768682698d3b upstream. KernelThreadSanitizer (ktsan) has shown that the down_read_trylock() of mmap_sem in try_to_unmap_one() (when going to set PageMlocked on a page found mapped in a VM_LOCKED vma) is ineffective against races with exit_mmap()'s munlock_vma_pages_all(), because mmap_sem is not held when tearing down an mm. But that's okay, those races are benign; and although we've believed for years in that ugly down_read_trylock(), it's unsuitable for the job, and frustrates the good intention of setting PageMlocked when it fails. It just doesn't matter if here we read vm_flags an instant before or after a racing mlock() or munlock() or exit_mmap() sets or clears VM_LOCKED: the syscalls (or exit) work their way up the address space (taking pt locks after updating vm_flags) to establish the final state. We do still need to be careful never to mark a page Mlocked (hence unevictable) by any race that will not be corrected shortly after. The page lock protects from many of the races, but not all (a page is not necessarily locked when it's unmapped). But the pte lock we just dropped is good to cover the rest (and serializes even with munlock_vma_pages_all(), so no special barriers required): now hold on to the pte lock while calling mlock_vma_page(). Is that lock ordering safe? Yes, that's how follow_page_pte() calls it, and how page_remove_rmap() calls the complementary clear_page_mlock(). This fixes the following case (though not a case which anyone has complained of), which mmap_sem did not: truncation's preliminary unmap_mapping_range() is supposed to remove even the anonymous COWs of filecache pages, and that might race with try_to_unmap_one() on a VM_LOCKED vma, so that mlock_vma_page() sets PageMlocked just after zap_pte_range() unmaps the page, causing "Bad page state (mlocked)" when freed. The pte lock protects against this. You could say that it also protects against the more ordinary case, racing with the preliminary unmapping of a filecache page itself: but in our current tree, that's independently protected by i_mmap_rwsem; and that race would be why "Bad page state (mlocked)" was seen before commit 48ec833b7851 ("Revert mm/memory.c: share the i_mmap_rwsem"). Vlastimil Babka points out another race which this patch protects against. try_to_unmap_one() might reach its mlock_vma_page() TestSetPageMlocked a moment after munlock_vma_pages_all() did its Phase 1 TestClearPageMlocked: leaving PageMlocked and unevictable when it should be evictable. mmap_sem is ineffective because exit_mmap() does not hold it; page lock ineffective because __munlock_pagevec() only takes it afterwards, in Phase 2; pte lock is effective because __munlock_pagevec_fill() takes it to get the page, after VM_LOCKED was cleared from vm_flags, so visible to try_to_unmap_one. Kirill Shutemov points out that if the compiler chooses to implement a "vma->vm_flags &= VM_WHATEVER" or "vma->vm_flags |= VM_WHATEVER" operation with an intermediate store of unrelated bits set, since I'm here foregoing its usual protection by mmap_sem, try_to_unmap_one() might catch sight of a spurious VM_LOCKED in vm_flags, and make the wrong decision. This does not appear to be an immediate problem, but we may want to define vm_flags accessors in future, to guard against such a possibility. While we're here, make a related optimization in try_to_munmap_one(): if it's doing TTU_MUNLOCK, then there's no point at all in descending the page tables and getting the pt lock, unless the vma is VM_LOCKED. Yes, that can change racily, but it can change racily even without the optimization: it's not critical. Far better not to waste time here. Stopped short of separating try_to_munlock_one() from try_to_munmap_one() on this occasion, but that's probably the sensible next step - with a rename, given that try_to_munlock()'s business is to try to set Mlocked. Updated the unevictable-lru Documentation, to remove its reference to mmap semaphore, but found a few more updates needed in just that area. Signed-off-by: Hugh Dickins Cc: Christoph Lameter Cc: "Kirill A. Shutemov" Cc: Rik van Riel Acked-by: Vlastimil Babka Cc: Davidlohr Bueso Cc: Oleg Nesterov Cc: Sasha Levin Cc: Dmitry Vyukov Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16 in preparation for commit 017b1660df89 "mm: migration: fix migration of huge PMD shared pages". Adjusted context.] Signed-off-by: Ben Hutchings commit 13ce4686ec6305ad434be261f7bd7618ff22e999 Author: Hugh Dickins Date: Thu Nov 5 18:49:30 2015 -0800 mm Documentation: undoc non-linear vmas commit 7a14239a8fff45a241b6943a3ac444d5b67fcbed upstream. While updating some mm Documentation, I came across a few straggling references to the non-linear vmas which were happily removed in v4.0. Delete them. Signed-off-by: Hugh Dickins Cc: Christoph Lameter Cc: "Kirill A. Shutemov" Cc: Rik van Riel Acked-by: Vlastimil Babka Cc: Davidlohr Bueso Cc: Oleg Nesterov Cc: Sasha Levin Cc: Dmitry Vyukov Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.16 in preparation for commit 017b1660df89 "mm: migration: fix migration of huge PMD shared pages"] Signed-off-by: Ben Hutchings commit 4cc902b67ba63de864a9dd34fcb4fb49bf19a8d1 Author: Vasily Averin Date: Mon Dec 24 14:44:42 2018 +0300 sunrpc: use SVC_NET() in svcauth_gss_* functions commit b8be5674fa9a6f3677865ea93f7803c4212f3e10 upstream. Signed-off-by: Vasily Averin Signed-off-by: J. Bruce Fields Signed-off-by: Ben Hutchings commit 7b0464f293218ba89d99f8adad0facd984b9f744 Author: Yan, Zheng Date: Thu Nov 29 11:22:50 2018 +0800 ceph: don't update importing cap's mseq when handing cap export commit 3c1392d4c49962a31874af14ae9ff289cb2b3851 upstream. Updating mseq makes client think importer mds has accepted all prior cap messages and importer mds knows what caps client wants. Actually some cap messages may have been dropped because of mseq mismatch. If mseq is left untouched, importing cap's mds_wanted later will get reset by cap import message. Signed-off-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Ben Hutchings commit e7f628ebdfc5a9e13fc62727a4b349649e4e9f0b Author: zhengbin Date: Wed Mar 13 16:01:37 2019 +0800 9p/net: fix memory leak in p9_client_create commit bb06c388fa20ae24cfe80c52488de718a7e3a53f upstream. If msize is less than 4096, we should close and put trans, destroy tagpool, not just free client. This patch fixes that. Link: http://lkml.kernel.org/m/1552464097-142659-1-git-send-email-zhengbin13@huawei.com Fixes: 574d356b7a02 ("9p/net: put a lower bound on msize") Reported-by: Hulk Robot Signed-off-by: zhengbin Signed-off-by: Dominique Martinet Signed-off-by: Ben Hutchings commit ae64770e5d8f8674032cd17d13e2f955c35af254 Author: Dominique Martinet Date: Mon Nov 5 09:52:48 2018 +0100 9p/net: put a lower bound on msize commit 574d356b7a02c7e1b01a1d9cba8a26b3c2888f45 upstream. If the requested msize is too small (either from command line argument or from the server version reply), we won't get any work done. If it's *really* too small, nothing will work, and this got caught by syzbot recently (on a new kmem_cache_create_usercopy() call) Just set a minimum msize to 4k in both code paths, until someone complains they have a use-case for a smaller msize. We need to check in both mount option and server reply individually because the msize for the first version request would be unchecked with just a global check on clnt->msize. Link: http://lkml.kernel.org/r/1541407968-31350-1-git-send-email-asmadeus@codewreck.org Reported-by: syzbot+0c1d61e4db7db94102ca@syzkaller.appspotmail.com Signed-off-by: Dominique Martinet Cc: Eric Van Hensbergen Cc: Latchesar Ionkov Signed-off-by: Ben Hutchings commit ee21615443472f57e622c8242648fad6e4b00ee4 Author: Theodore Ts'o Date: Tue Dec 25 00:56:33 2018 -0500 ext4: fix a potential fiemap/page fault deadlock w/ inline_data commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream. The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent() while still holding the xattr semaphore. This is not necessary and it triggers a circular lockdep warning. This is because fiemap_fill_next_extent() could trigger a page fault when it writes into page which triggers a page fault. If that page is mmaped from the inline file in question, this could very well result in a deadlock. This problem can be reproduced using generic/519 with a file system configuration which has the inline_data feature enabled. Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit 5b25a6d0d3d9830a7bd08236de0e7ee532e3b28c Author: Dmitry Monakhov Date: Tue Dec 2 16:11:20 2014 -0500 ext4: ext4_inline_data_fiemap should respect callers argument commit d952d69e268f833c85c0bafee9f67f9dba85044b upstream. Currently ext4_inline_data_fiemap ignores requested arguments (start and len) which may lead endless loop if start != 0. Also fix incorrect extent length determination. Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit a0b9c0610345fdd4b46d95d5d35763f84698d293 Author: Theodore Ts'o Date: Mon Dec 24 20:27:08 2018 -0500 ext4: make sure enough credits are reserved for dioread_nolock writes commit 812c0cab2c0dfad977605dbadf9148490ca5d93f upstream. There are enough credits reserved for most dioread_nolock writes; however, if the extent tree is sufficiently deep, and/or quota is enabled, the code was not allowing for all eventualities when reserving journal credits for the unwritten extent conversion. This problem can be seen using xfstests ext4/034: WARNING: CPU: 1 PID: 257 at fs/ext4/ext4_jbd2.c:271 __ext4_handle_dirty_metadata+0x10c/0x180 Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work RIP: 0010:__ext4_handle_dirty_metadata+0x10c/0x180 ... EXT4-fs: ext4_free_blocks:4938: aborting transaction: error 28 in __ext4_handle_dirty_metadata EXT4: jbd2_journal_dirty_metadata failed: handle type 11 started at line 4921, credits 4/0, errcode -28 EXT4-fs error (device dm-1) in ext4_free_blocks:4950: error 28 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 7c54b30bc793e58c4172c2b38d2d71b5648063b6 Author: Georgy A Bystrenin Date: Fri Dec 21 00:11:42 2018 -0600 CIFS: Fix error mapping for SMB2_LOCK command which caused OFD lock problem commit 9a596f5b39593414c0ec80f71b94a226286f084e upstream. While resolving a bug with locks on samba shares found a strange behavior. When a file locked by one node and we trying to lock it from another node it fail with errno 5 (EIO) but in that case errno must be set to (EACCES | EAGAIN). This isn't happening when we try to lock file second time on same node. In this case it returns EACCES as expected. Also this issue not reproduces when we use SMB1 protocol (vers=1.0 in mount options). Further investigation showed that the mapping from status_to_posix_error is different for SMB1 and SMB2+ implementations. For SMB1 mapping is [NT_STATUS_LOCK_NOT_GRANTED to ERRlock] (See fs/cifs/netmisc.c line 66) but for SMB2+ mapping is [STATUS_LOCK_NOT_GRANTED to -EIO] (see fs/cifs/smb2maperror.c line 383) Quick changes in SMB2+ mapping from EIO to EACCES has fixed issue. BUG: https://bugzilla.kernel.org/show_bug.cgi?id=201971 Signed-off-by: Georgy A Bystrenin Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Ben Hutchings commit db29de82f26b1f2e6b5a6991d72fa99bbbb1f166 Author: Jonas Gorski Date: Mon Dec 10 12:40:38 2018 +0100 MIPS: BCM63XX: fix switch core reset on BCM6368 commit 8a38dacf87180738d42b058334c951eba15d2d47 upstream. The Ethernet Switch core mask was set to 0, causing the switch core to be not reset on BCM6368 on boot. Provide the proper mask so the switch core gets reset to a known good state. Fixes: 799faa626c71 ("MIPS: BCM63XX: add core reset helper") Signed-off-by: Jonas Gorski Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org Cc: Ralf Baechle Cc: James Hogan Cc: Florian Fainelli Signed-off-by: Ben Hutchings commit f106af9cab756c4bfd18938359a8da9a983c0d2e Author: Sean Christopherson Date: Thu Dec 20 14:21:08 2018 -0800 KVM: x86: Use jmp to invoke kvm_spurious_fault() from .fixup commit e81434995081fd7efb755fd75576b35dbb0850b1 upstream. ____kvm_handle_fault_on_reboot() provides a generic exception fixup handler that is used to cleanly handle faults on VMX/SVM instructions during reboot (or at least try to). If there isn't a reboot in progress, ____kvm_handle_fault_on_reboot() treats any exception as fatal to KVM and invokes kvm_spurious_fault(), which in turn generates a BUG() to get a stack trace and die. When it was originally added by commit 4ecac3fd6dc2 ("KVM: Handle virtualization instruction #UD faults during reboot"), the "call" to kvm_spurious_fault() was handcoded as PUSH+JMP, where the PUSH'd value is the RIP of the faulting instructing. The PUSH+JMP trickery is necessary because the exception fixup handler code lies outside of its associated function, e.g. right after the function. An actual CALL from the .fixup code would show a slightly bogus stack trace, e.g. an extra "random" function would be inserted into the trace, as the return RIP on the stack would point to no known function (and the unwinder will likely try to guess who owns the RIP). Unfortunately, the JMP was replaced with a CALL when the macro was reworked to not spin indefinitely during reboot (commit b7c4145ba2eb "KVM: Don't spin on virt instruction faults during reboot"). This causes the aforementioned behavior where a bogus function is inserted into the stack trace, e.g. my builds like to blame free_kvm_area(). Revert the CALL back to a JMP. The changelog for commit b7c4145ba2eb ("KVM: Don't spin on virt instruction faults during reboot") contains nothing that indicates the switch to CALL was deliberate. This is backed up by the fact that the PUSH was left intact. Note that an alternative to the PUSH+JMP magic would be to JMP back to the "real" code and CALL from there, but that would require adding a JMP in the non-faulting path to avoid calling kvm_spurious_fault() and would add no value, i.e. the stack trace would be the same. Using CALL: ------------[ cut here ]------------ kernel BUG at /home/sean/go/src/kernel.org/linux/arch/x86/kvm/x86.c:356! invalid opcode: 0000 [#1] SMP CPU: 4 PID: 1057 Comm: qemu-system-x86 Not tainted 4.20.0-rc6+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_spurious_fault+0x5/0x10 [kvm] Code: <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41 RSP: 0018:ffffc900004bbcc8 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffffffffff RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff888273fd8000 R08: 00000000000003e8 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000784 R12: ffffc90000371fb0 R13: 0000000000000000 R14: 000000026d763cf4 R15: ffff888273fd8000 FS: 00007f3d69691700(0000) GS:ffff888277800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f89bc56fe0 CR3: 0000000271a5a001 CR4: 0000000000362ee0 Call Trace: free_kvm_area+0x1044/0x43ea [kvm_intel] ? vmx_vcpu_run+0x156/0x630 [kvm_intel] ? kvm_arch_vcpu_ioctl_run+0x447/0x1a40 [kvm] ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm] ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm] ? __set_task_blocked+0x38/0x90 ? __set_current_blocked+0x50/0x60 ? __fpu__restore_sig+0x97/0x490 ? do_vfs_ioctl+0xa1/0x620 ? __x64_sys_futex+0x89/0x180 ? ksys_ioctl+0x66/0x70 ? __x64_sys_ioctl+0x16/0x20 ? do_syscall_64+0x4f/0x100 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Modules linked in: vhost_net vhost tap kvm_intel kvm irqbypass bridge stp llc ---[ end trace 9775b14b123b1713 ]--- Using JMP: ------------[ cut here ]------------ kernel BUG at /home/sean/go/src/kernel.org/linux/arch/x86/kvm/x86.c:356! invalid opcode: 0000 [#1] SMP CPU: 6 PID: 1067 Comm: qemu-system-x86 Not tainted 4.20.0-rc6+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvm_spurious_fault+0x5/0x10 [kvm] Code: <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 49 89 fd 41 RSP: 0018:ffffc90000497cd0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffffffffff RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88827058bd40 R08: 00000000000003e8 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000784 R12: ffffc90000369fb0 R13: 0000000000000000 R14: 00000003c8fc6642 R15: ffff88827058bd40 FS: 00007f3d7219e700(0000) GS:ffff888277900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3d64001000 CR3: 0000000271c6b004 CR4: 0000000000362ee0 Call Trace: vmx_vcpu_run+0x156/0x630 [kvm_intel] ? kvm_arch_vcpu_ioctl_run+0x447/0x1a40 [kvm] ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm] ? kvm_vcpu_ioctl+0x368/0x5c0 [kvm] ? __set_task_blocked+0x38/0x90 ? __set_current_blocked+0x50/0x60 ? __fpu__restore_sig+0x97/0x490 ? do_vfs_ioctl+0xa1/0x620 ? __x64_sys_futex+0x89/0x180 ? ksys_ioctl+0x66/0x70 ? __x64_sys_ioctl+0x16/0x20 ? do_syscall_64+0x4f/0x100 ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 Modules linked in: vhost_net vhost tap kvm_intel kvm irqbypass bridge stp llc ---[ end trace f9daedb85ab3ddba ]--- Fixes: b7c4145ba2eb ("KVM: Don't spin on virt instruction faults during reboot") Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Ben Hutchings commit e713956a01a48b1b714237a727bc409e42a55b19 Author: Jim Mattson Date: Mon Dec 17 13:53:33 2018 -0800 kvm: Disallow wraparound in kvm_gfn_to_hva_cache_init commit f1b9dd5eb86cec1fcf66aad17e7701d98d024a9a upstream. Previously, in the case where (gpa + len) wrapped around, the entire region was not validated, as the comment claimed. It doesn't actually seem that wraparound should be allowed here at all. Furthermore, since some callers don't check the return code from this function, it seems prudent to clear ghc->memslot in the event of an error. Fixes: 8f964525a121f ("KVM: Allow cross page reads and writes from cached translations.") Reported-by: Cfir Cohen Signed-off-by: Jim Mattson Reviewed-by: Cfir Cohen Reviewed-by: Marc Orr Cc: Andrew Honig Signed-off-by: Radim Krčmář [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 08476ed344b5ca73f36fcbd711cc5e3f7df2db2a Author: Dan Carpenter Date: Fri Dec 21 00:38:30 2018 -0800 Input: nomadik-ske-keypad - fix a loop timeout test commit 4d8f727b83bcd6702c2d210330872c9122d2d360 upstream. The loop exits with "timeout" set to -1 not to 0. Fixes: 1158f0f16224 ("Input: add support for Nomadik SKE keypad controller") Signed-off-by: Dan Carpenter Signed-off-by: Dmitry Torokhov Signed-off-by: Ben Hutchings commit ae3575e241d102da3893e46e2f3c5a6c44cbc9e9 Author: Breno Leitao Date: Wed Jan 9 11:16:45 2019 -0200 powerpc/tm: Limit TM code inside PPC_TRANSACTIONAL_MEM commit 897bc3df8c5aebb54c32d831f917592e873d0559 upstream. Commit e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint") moved a code block around and this block uses a 'msr' variable outside of the CONFIG_PPC_TRANSACTIONAL_MEM, however the 'msr' variable is declared inside a CONFIG_PPC_TRANSACTIONAL_MEM block, causing a possible error when CONFIG_PPC_TRANSACTION_MEM is not defined. error: 'msr' undeclared (first use in this function) This is not causing a compilation error in the mainline kernel, because 'msr' is being used as an argument of MSR_TM_ACTIVE(), which is defined as the following when CONFIG_PPC_TRANSACTIONAL_MEM is *not* set: #define MSR_TM_ACTIVE(x) 0 This patch just fixes this issue avoiding the 'msr' variable usage outside the CONFIG_PPC_TRANSACTIONAL_MEM block, avoiding trusting in the MSR_TM_ACTIVE() definition. Reported-by: Christoph Biedl Fixes: e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to recheckpoint") Signed-off-by: Breno Leitao Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings commit 928e6dafd6934241f2b49c1dae58b15d9c38bda2 Author: Breno Leitao Date: Mon Nov 26 18:12:00 2018 -0200 powerpc/tm: Unset MSR[TS] if not recheckpointing commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream. There is a TM Bad Thing bug that can be caused when you return from a signal context in a suspended transaction but with ucontext MSR[TS] unset. This forces regs->msr[TS] to be set at syscall entrance (since the CPU state is transactional). It also calls treclaim() to flush the transaction state, which is done based on the live (mfmsr) MSR state. Since user context MSR[TS] is not set, then restore_tm_sigcontexts() is not called, thus, not executing recheckpoint, keeping the CPU state as not transactional. When calling rfid, SRR1 will have MSR[TS] set, but the CPU state is non transactional, causing the TM Bad Thing with the following stack: [ 33.862316] Bad kernel stack pointer 3fffd9dce3e0 at c00000000000c47c cpu 0x8: Vector: 700 (Program Check) at [c00000003ff7fd40] pc: c00000000000c47c: fast_exception_return+0xac/0xb4 lr: 00003fff865f442c sp: 3fffd9dce3e0 msr: 8000000102a03031 current = 0xc00000041f68b700 paca = 0xc00000000fb84800 softe: 0 irq_happened: 0x01 pid = 1721, comm = tm-signal-sigre Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) WARNING: exception is not recoverable, can't continue The same problem happens on 32-bits signal handler, and the fix is very similar, if tm_recheckpoint() is not executed, then regs->msr[TS] should be zeroed. This patch also fixes a sparse warning related to lack of indentation when CONFIG_PPC_TRANSACTIONAL_MEM is set. Fixes: 2b0a576d15e0e ("powerpc: Add new transactional memory state to the signal context") Signed-off-by: Breno Leitao Tested-by: Michal Suchánek Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c9d7639d95e5e3ff536034b266b3d05d38290329 Author: Breno Leitao Date: Wed Nov 21 17:21:09 2018 -0200 powerpc/tm: Set MSR[TS] just prior to recheckpoint commit e1c3743e1a20647c53b719dbf28b48f45d23f2cd upstream. On a signal handler return, the user could set a context with MSR[TS] bits set, and these bits would be copied to task regs->msr. At restore_tm_sigcontexts(), after current task regs->msr[TS] bits are set, several __get_user() are called and then a recheckpoint is executed. This is a problem since a page fault (in kernel space) could happen when calling __get_user(). If it happens, the process MSR[TS] bits were already set, but recheckpoint was not executed, and SPRs are still invalid. The page fault can cause the current process to be de-scheduled, with MSR[TS] active and without tm_recheckpoint() being called. More importantly, without TEXASR[FS] bit set also. Since TEXASR might not have the FS bit set, and when the process is scheduled back, it will try to reclaim, which will be aborted because of the CPU is not in the suspended state, and, then, recheckpoint. This recheckpoint will restore thread->texasr into TEXASR SPR, which might be zero, hitting a BUG_ON(). kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434! cpu 0xb: Vector: 700 (Program Check) at [c00000041f1576d0] pc: c000000000054550: restore_gprs+0xb0/0x180 lr: 0000000000000000 sp: c00000041f157950 msr: 8000000100021033 current = 0xc00000041f143000 paca = 0xc00000000fb86300 softe: 0 irq_happened: 0x01 pid = 1021, comm = kworker/11:1 kernel BUG at /build/linux-sf3Co9/linux-4.9.30/arch/powerpc/kernel/tm.S:434! Linux version 4.9.0-3-powerpc64le (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) enter ? for help [c00000041f157b30] c00000000001bc3c tm_recheckpoint.part.11+0x6c/0xa0 [c00000041f157b70] c00000000001d184 __switch_to+0x1e4/0x4c0 [c00000041f157bd0] c00000000082eeb8 __schedule+0x2f8/0x990 [c00000041f157cb0] c00000000082f598 schedule+0x48/0xc0 [c00000041f157ce0] c0000000000f0d28 worker_thread+0x148/0x610 [c00000041f157d80] c0000000000f96b0 kthread+0x120/0x140 [c00000041f157e30] c00000000000c0e0 ret_from_kernel_thread+0x5c/0x7c This patch simply delays the MSR[TS] set, so, if there is any page fault in the __get_user() section, it does not have regs->msr[TS] set, since the TM structures are still invalid, thus avoiding doing TM operations for in-kernel exceptions and possible process reschedule. With this patch, the MSR[TS] will only be set just before recheckpointing and setting TEXASR[FS] = 1, thus avoiding an interrupt with TM registers in invalid state. Other than that, if CONFIG_PREEMPT is set, there might be a preemption just after setting MSR[TS] and before tm_recheckpoint(), thus, this block must be atomic from a preemption perspective, thus, calling preempt_disable/enable() on this code. It is not possible to move tm_recheckpoint to happen earlier, because it is required to get the checkpointed registers from userspace, with __get_user(), thus, the only way to avoid this undesired behavior is delaying the MSR[TS] set. The 32-bits signal handler seems to be safe this current issue, but, it might be exposed to the preemption issue, thus, disabling preemption in this chunk of code. Changes from v2: * Run the critical section with preempt_disable. Fixes: 87b4e5393af7 ("powerpc/tm: Fix return of active 64bit signals") Signed-off-by: Breno Leitao Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: - We don't forceably enable TM here; don't change that, and drop the comment about it - Adjust context] Signed-off-by: Ben Hutchings commit 100897f4487ac739bb3f941a6672c96f99ff1946 Author: Kai-Heng Feng Date: Mon Dec 3 13:54:38 2018 +0800 igb: Fix an issue that PME is not enabled during runtime suspend commit 1fb3a7a75e2efcc83ef21f2434069cddd6fae6f5 upstream. I210 ethernet card doesn't wakeup when a cable gets plugged. It's because its PME is not set. Since commit 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops calling pci_finish_runtime_suspend(), which enables the PCI PME. To fix the issue, let's not to save PCI states when it's runtime suspend, to let the PCI subsystem enables PME. Fixes: 42eca2302146 ("PCI: Don't touch card regs after runtime suspend D3") Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Ben Hutchings commit 763ae3d61a9b1a22b856e1340b4eb35597cebe17 Author: Noralf Trønnes Date: Thu Dec 20 19:13:09 2018 +0100 fbdev: fbcon: Fix unregister crash when more than one framebuffer commit 2122b40580dd9d0620398739c773d07a7b7939d0 upstream. When unregistering fbdev using unregister_framebuffer(), any bound console will unbind automatically. This is working fine if this is the only framebuffer, resulting in a switch to the dummy console. However if there is a fb0 and I unregister fb1 having a bound console, I eventually get a crash. The fastest way for me to trigger the crash is to do a reboot, resulting in this splat: [ 76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 __queue_work+0x2d4/0x41c [ 76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight bcm2835_rng rng_core [last unloaded: tinydrm] [ 76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4 [ 76.478933] Hardware name: BCM2835 [ 76.478949] Backtrace: [ 76.478995] [] (dump_backtrace) from [] (show_stack+0x20/0x24) [ 76.479022] r6:00000000 r5:c0bc73be r4:00000000 r3:6fb5bf81 [ 76.479060] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 76.479102] [] (dump_stack) from [] (__warn+0xec/0x12c) [ 76.479134] [] (__warn) from [] (warn_slowpath_null+0x4c/0x58) [ 76.479165] r9:c0eb6944 r8:00000001 r7:c0e927f8 r6:c0bc73be r5:000005a2 r4:c0139e84 [ 76.479197] [] (warn_slowpath_null) from [] (__queue_work+0x2d4/0x41c) [ 76.479222] r6:d7666a00 r5:c0e918ee r4:dbc4e700 [ 76.479251] [] (__queue_work) from [] (queue_work_on+0x60/0x88) [ 76.479281] r10:c0496bf8 r9:00000100 r8:c0e92ae0 r7:00000001 r6:d9403700 r5:d7666a00 [ 76.479298] r4:20000113 [ 76.479348] [] (queue_work_on) from [] (cursor_timer_handler+0x30/0x54) [ 76.479374] r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc [ 76.479413] [] (cursor_timer_handler) from [] (call_timer_fn+0x100/0x230) [ 76.479435] r4:c0e9192f r3:d758a340 [ 76.479465] [] (call_timer_fn) from [] (expire_timers+0x10c/0x12c) [ 76.479495] r10:40000000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 r5:c0496bf8 [ 76.479513] r4:d8a8fabc [ 76.479541] [] (expire_timers) from [] (run_timer_softirq+0xa8/0x184) [ 76.479570] r9:00000001 r8:c0e19280 r7:00000000 r6:c0e08088 r5:c0e1a3e0 r4:c0e19280 [ 76.479603] [] (run_timer_softirq) from [] (__do_softirq+0x1ac/0x3fc) [ 76.479632] r10:c0e91680 r9:d8afc020 r8:0000000a r7:00000100 r6:00000001 r5:00000002 [ 76.479650] r4:c0eb65ec [ 76.479686] [] (__do_softirq) from [] (irq_exit+0xe8/0x168) [ 76.479716] r10:d8d1a9b0 r9:d8afc000 r8:00000001 r7:d949c000 r6:00000000 r5:c0e8b3f0 [ 76.479734] r4:00000000 [ 76.479764] [] (irq_exit) from [] (__handle_domain_irq+0x94/0xb0) [ 76.479793] [] (__handle_domain_irq) from [] (bcm2835_handle_irq+0x3c/0x48) [ 76.479823] r8:d8afdebc r7:d8afddfc r6:ffffffff r5:c0e089f8 r4:d8afddc8 r3:d8afddc8 [ 76.479851] [] (bcm2835_handle_irq) from [] (__irq_svc+0x70/0x98) The problem is in the console rebinding in fbcon_fb_unbind(). It uses the virtual console index as the new framebuffer index to bind the console(s) to. The correct way is to use the con2fb_map lookup table to find the framebuffer index. Fixes: cfafca8067c6 ("fbdev: fbcon: console unregistration from unregister_framebuffer") Signed-off-by: Noralf Trønnes Reviewed-by: Mikulas Patocka Acked-by: Daniel Vetter Signed-off-by: Bartlomiej Zolnierkiewicz [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit b78fc783c6203125d299154492a704d3fd5853c8 Author: Peter Rosin Date: Thu Dec 20 19:13:07 2018 +0100 fbdev: fbmem: behave better with small rotated displays and many CPUs commit f75df8d4b4fabfad7e3cba2debfad12741c6fde7 upstream. Blitting an image with "negative" offsets is not working since there is no clipping. It hopefully just crashes. For the bootup logo, there is protection so that blitting does not happen as the image is drawn further and further to the right (ROTATE_UR) or further and further down (ROTATE_CW). There is however no protection when drawing in the opposite directions (ROTATE_UD and ROTATE_CCW). Add back this protection. The regression is 20-odd years old but the mindless warning-killing mentality displayed in commit 34bdb666f4b2 ("fbdev: fbmem: remove positive test on unsigned values") is also to blame, methinks. Fixes: 448d479747b8 ("fbdev: fb_do_show_logo() updates") Signed-off-by: Peter Rosin Cc: Tomi Valkeinen Cc: Fabian Frederick Cc: Geert Uytterhoeven cc: Geoff Levand Cc: James Simmons Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Ben Hutchings commit b669ce7d02c52a7aafea486bceb0bbd5e9996b6e Author: Macpaul Lin Date: Wed Dec 19 12:11:03 2018 +0800 cdc-acm: fix abnormal DATA RX issue for Mediatek Preloader. commit eafb27fa5283599ce6c5492ea18cf636a28222bb upstream. Mediatek Preloader is a proprietary embedded boot loader for loading Little Kernel and Linux into device DRAM. This boot loader also handle firmware update. Mediatek Preloader will be enumerated as a virtual COM port when the device is connected to Windows or Linux OS via CDC-ACM class driver. When the USB enumeration has been done, Mediatek Preloader will send out handshake command "READY" to PC actively instead of waiting command from the download tool. Since Linux 4.12, the commit "tty: reset termios state on device registration" (93857edd9829e144acb6c7e72d593f6e01aead66) causes Mediatek Preloader receiving some abnoraml command like "READYXX" as it sent. This will be recognized as an incorrect response. The behavior change also causes the download handshake fail. This change only affects subsequent connects if the reconnected device happens to get the same minor number. By disabling the ECHO termios flag could avoid this problem. However, it cannot be done by user space configuration when download tool open /dev/ttyACM0. This is because the device running Mediatek Preloader will send handshake command "READY" immediately once the CDC-ACM driver is ready. This patch wants to fix above problem by introducing "DISABLE_ECHO" property in driver_info. When Mediatek Preloader is connected, the CDC-ACM driver could disable ECHO flag in termios to avoid the problem. Signed-off-by: Macpaul Lin Reviewed-by: Johan Hovold Acked-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 3b8631a2502a184e72b94c10a7133d231c5853f3 Author: Michael Ellerman Date: Sat Dec 15 00:57:11 2018 +1100 powerpc/configs: Don't enable PPC_EARLY_DEBUG in defconfigs commit 2b874a5c7b75fdc90fdd1e2ffaa3ec5a9d21e253 upstream. This reverts the remains of commit b9ef7d6b11c1 ("powerpc: Update default configurations"). That commit was proceeded by a commit which added a config option to control use of BOOTX for early debug, ie. PPC_EARLY_DEBUG_BOOTX, and then the update of the defconfigs was intended to not change behaviour by then enabling the new config option. However enabling PPC_EARLY_DEBUG had other consequences, notably causing us to register the udbg console at the end of udbg_early_init(). This means on a system which doesn't have anything that BOOTX can use (most systems), we register the udbg console very early but the bootx code just throws everything away, meaning early boot messages are never printed to the console. What we want to happen is for the udbg console to only be registered later (from setup_arch()) once we've setup udbg_putc, and then all early boot messages will be replayed. Fixes: b9ef7d6b11c1 ("powerpc: Update default configurations") Reported-by: Torsten Duwe Signed-off-by: Michael Ellerman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit cce129f7b3cd77cdc17571f15ce56ee16056cf04 Author: Kyle Roeschley Date: Wed Dec 5 09:43:11 2018 +0200 ath6kl: Only use match sets when firmware supports it commit fb376a495fbdb886f38cfaf5a3805401b9e46f13 upstream. Commit dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan") merged the probed and matched SSID lists before sending them to the firmware. In the process, it assumed match set support is always available in ath6kl_set_probed_ssids, which breaks scans for hidden SSIDs. Now, check that the firmware supports matching SSIDs in scheduled scans before setting MATCH_SSID_FLAG. Fixes: dd45b7598f1c ("ath6kl: Include match ssid list in scheduled scan") Signed-off-by: Kyle Roeschley Signed-off-by: Kalle Valo Signed-off-by: Ben Hutchings commit ab3d7e75427a3f80ecec7f70cf179732a0127fc4 Author: Shivasharan S Date: Tue Dec 18 05:59:54 2018 -0800 scsi: megaraid_sas: Use 63-bit DMA addressing commit 894169db12463cea08d0e2a9e35f42b291340e5a upstream. Although MegaRAID controllers support 64-bit DMA addressing, as per hardware design, DMA address with all 64-bits set (0xFFFFFFFF-FFFFFFFF) results in a firmware fault. Driver will set 63-bit DMA mask to ensure the above address will not be used. Signed-off-by: Shivasharan S Signed-off-by: Martin K. Petersen [bwh: Backported to 3.16: Only one instance of a 64-bit mask needs changing] Signed-off-by: Ben Hutchings commit 607ac35fcd12d4f446fc0038fd17dbb68f18bc0e Author: Theodore Ts'o Date: Wed Dec 19 14:36:58 2018 -0500 ext4: check for shutdown and r/o file system in ext4_write_inode() commit 18f2c4fcebf2582f96cbd5f2238f4f354a0e4847 upstream. If the file system has been shut down or is read-only, then ext4_write_inode() needs to bail out early. Also use jbd2_complete_transaction() instead of ext4_force_commit() so we only force a commit if it is needed. Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: - Open-code sb_rdonly() - Drop ext4_forced_shutdown() check] Signed-off-by: Ben Hutchings commit df3654402e4201a19f0ee33208779a3989f4c70f Author: Theodore Ts'o Date: Wed Dec 19 14:07:58 2018 -0500 ext4: force inode writes when nfsd calls commit_metadata() commit fde872682e175743e0c3ef939c89e3c6008a1529 upstream. Some time back, nfsd switched from calling vfs_fsync() to using a new commit_metadata() hook in export_operations(). If the file system did not provide a commit_metadata() hook, it fell back to using sync_inode_metadata(). Unfortunately doesn't work on all file systems. In particular, it doesn't work on ext4 due to how the inode gets journalled --- the VFS writeback code will not always call ext4_write_inode(). So we need to provide our own ext4_nfs_commit_metdata() method which calls ext4_write_inode() directly. Google-Bug-Id: 121195940 Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit faab0f009fc34b57dadba9734c2029adde282009 Author: Theodore Ts'o Date: Wed Dec 19 12:29:13 2018 -0500 ext4: avoid declaring fs inconsistent due to invalid file handles commit 8a363970d1dc38c4ec4ad575c862f776f468d057 upstream. If we receive a file handle, either from NFS or open_by_handle_at(2), and it points at an inode which has not been initialized, and the file system has metadata checksums enabled, we shouldn't try to get the inode, discover the checksum is invalid, and then declare the file system as being inconsistent. This can be reproduced by creating a test file system via "mke2fs -t ext4 -O metadata_csum /tmp/foo.img 8M", mounting it, cd'ing into that directory, and then running the following program. #define _GNU_SOURCE #include struct handle { struct file_handle fh; unsigned char fid[MAX_HANDLE_SZ]; }; int main(int argc, char **argv) { struct handle h = {{8, 1 }, { 12, }}; open_by_handle_at(AT_FDCWD, &h.fh, O_RDONLY); return 0; } Google-Bug-Id: 120690101 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: - Keep using EIO instead of EFSCORRUPTED and EFSBADCRC - Drop inapplicable changes - Adjust context] Signed-off-by: Ben Hutchings commit fd0fcc1c458c98e4e8ea97b11e6f63398da984b5 Author: Theodore Ts'o Date: Wed Dec 19 12:28:13 2018 -0500 ext4: include terminating u32 in size of xattr entries when expanding inodes commit a805622a757b6d7f65def4141d29317d8e37b8a1 upstream. In ext4_expand_extra_isize_ea(), we calculate the total size of the xattr header, plus the xattr entries so we know how much of the beginning part of the xattrs to move when expanding the inode extra size. We need to include the terminating u32 at the end of the xattr entries, or else if there is uninitialized, non-zero bytes after the xattr entries and before the xattr values, the list of xattr entries won't be properly terminated. Reported-by: Steve Graham Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit c05d2eacd080e7b550a3af1ef30433259a978a6c Author: Gustavo A. R. Silva Date: Tue Dec 18 11:52:16 2018 -0600 ALSA: emu10k1: Fix potential Spectre v1 vulnerabilities commit 5ae4f61f012a097df93de2285070ec8e34716d29 upstream. ipcm->substream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/pci/emu10k1/emufx.c:1031 snd_emu10k1_ipcm_poke() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap) sound/pci/emu10k1/emufx.c:1075 snd_emu10k1_ipcm_peek() warn: potential spectre issue 'emu->fx8010.pcm' [r] (local cap) Fix this by sanitizing ipcm->substream before using it to index emu->fx8010.pcm Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 7650fd8d8b6a1bebbcdb6bd47d4df313df11d066 Author: Gustavo A. R. Silva Date: Tue Dec 18 11:18:34 2018 -0600 ALSA: rme9652: Fix potential Spectre v1 vulnerability commit 0b84304ef5da92add8dc75a1b07879c5374cdb05 upstream. info->channel is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/pci/rme9652/hdsp.c:4100 snd_hdsp_channel_info() warn: potential spectre issue 'hdsp->channel_map' [r] (local cap) Fix this by sanitizing info->channel before using it to index hdsp->channel_map Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. Also, notice that I refactored the code a bit in order to get rid of the following checkpatch warning: ERROR: do not use assignment in if condition FILE: sound/pci/rme9652/hdsp.c:4103: if ((mapped_channel = hdsp->channel_map[info->channel]) < 0) [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit eee6261d6b889633b414541319fc1d918b5a89c1 Author: Christian Borntraeger Date: Wed Dec 12 14:45:18 2018 +0100 genwqe: Fix size check commit fdd669684655c07dacbdb0d753fd13833de69a33 upstream. Calling the test program genwqe_cksum with the default buffer size of 2MB triggers the following kernel warning on s390: WARNING: CPU: 30 PID: 9311 at mm/page_alloc.c:3189 __alloc_pages_nodemask+0x45c/0xbe0 CPU: 30 PID: 9311 Comm: genwqe_cksum Kdump: loaded Not tainted 3.10.0-957.el7.s390x #1 task: 00000005e5d13980 ti: 00000005e7c6c000 task.ti: 00000005e7c6c000 Krnl PSW : 0704c00180000000 00000000002780ac (__alloc_pages_nodemask+0x45c/0xbe0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3 Krnl GPRS: 00000000002932b8 0000000000b73d7c 0000000000000010 0000000000000009 0000000000000041 00000005e7c6f9b8 0000000000000001 00000000000080d0 0000000000000000 0000000000b70500 0000000000000001 0000000000000000 0000000000b70528 00000000007682c0 0000000000277df2 00000005e7c6f9a0 Krnl Code: 000000000027809e: de7195001000 ed 1280(114,%r9),0(%r1) 00000000002780a4: a774fead brc 7,277dfe #00000000002780a8: a7f40001 brc 15,2780aa >00000000002780ac: 92011000 mvi 0(%r1),1 00000000002780b0: a7f4fea7 brc 15,277dfe 00000000002780b4: 9101c6b6 tm 1718(%r12),1 00000000002780b8: a784ff3a brc 8,277f2c 00000000002780bc: a7f4fe2e brc 15,277d18 Call Trace: ([<0000000000277df2>] __alloc_pages_nodemask+0x1a2/0xbe0) [<000000000013afae>] s390_dma_alloc+0xfe/0x310 [<000003ff8065f362>] __genwqe_alloc_consistent+0xfa/0x148 [genwqe_card] [<000003ff80658f7a>] genwqe_mmap+0xca/0x248 [genwqe_card] [<00000000002b2712>] mmap_region+0x4e2/0x778 [<00000000002b2c54>] do_mmap+0x2ac/0x3e0 [<0000000000292d7e>] vm_mmap_pgoff+0xd6/0x118 [<00000000002b081c>] SyS_mmap_pgoff+0xdc/0x268 [<00000000002b0a34>] SyS_old_mmap+0x8c/0xb0 [<000000000074e518>] sysc_tracego+0x14/0x1e [<000003ffacf87dc6>] 0x3ffacf87dc6 turns out the check in __genwqe_alloc_consistent uses "> MAX_ORDER" while the mm code uses ">= MAX_ORDER". Fix genwqe. Signed-off-by: Christian Borntraeger Signed-off-by: Frank Haverkamp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 77937a5d84a309e4fbaa0b197cb60f138101a3c3 Author: Jia-Ju Bai Date: Tue Dec 18 20:04:25 2018 +0800 usb: r8a66597: Fix a possible concurrency use-after-free bug in r8a66597_endpoint_disable() commit c85400f886e3d41e69966470879f635a2b50084c upstream. The function r8a66597_endpoint_disable() and r8a66597_urb_enqueue() may be concurrently executed. The two functions both access a possible shared variable "hep->hcpriv". This shared variable is freed by r8a66597_endpoint_disable() via the call path: r8a66597_endpoint_disable kfree(hep->hcpriv) (line 1995 in Linux-4.19) This variable is read by r8a66597_urb_enqueue() via the call path: r8a66597_urb_enqueue spin_lock_irqsave(&r8a66597->lock) init_pipe_info enable_r8a66597_pipe pipe = hep->hcpriv (line 802 in Linux-4.19) The read operation is protected by a spinlock, but the free operation is not protected by this spinlock, thus a concurrency use-after-free bug may occur. To fix this bug, the spin-lock and spin-unlock function calls in r8a66597_endpoint_disable() are moved to protect the free operation. Signed-off-by: Jia-Ju Bai Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit e2eb0bb27803f8477daed97a424bb1b6355d917a Author: Dan Carpenter Date: Mon Dec 17 10:05:36 2018 +0300 IB/qib: Fix an error code in qib_sdma_verbs_send() commit 5050ae5fa3d54c8e83e1e447cc7e3591110a7f57 upstream. We accidentally return success on this error path. Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters") Signed-off-by: Dan Carpenter Signed-off-by: Jason Gunthorpe Signed-off-by: Ben Hutchings commit 9765097ba2ab822c42bbac9f955ab9e2d99f7e46 Author: Christoffer Dall Date: Tue Dec 11 13:23:57 2018 +0100 KVM: arm/arm64: Fix VMID alloc race by reverting to lock-less commit fb544d1ca65a89f7a3895f7531221ceeed74ada7 upstream. We recently addressed a VMID generation race by introducing a read/write lock around accesses and updates to the vmid generation values. However, kvm_arch_vcpu_ioctl_run() also calls need_new_vmid_gen() but does so without taking the read lock. As far as I can tell, this can lead to the same kind of race: VM 0, VCPU 0 VM 0, VCPU 1 ------------ ------------ update_vttbr (vmid 254) update_vttbr (vmid 1) // roll over read_lock(kvm_vmid_lock); force_vm_exit() local_irq_disable need_new_vmid_gen == false //because vmid gen matches enter_guest (vmid 254) kvm_arch.vttbr = : read_unlock(kvm_vmid_lock); enter_guest (vmid 1) Which results in running two VCPUs in the same VM with different VMIDs and (even worse) other VCPUs from other VMs could now allocate clashing VMID 254 from the new generation as long as VCPU 0 is not exiting. Attempt to solve this by making sure vttbr is updated before another CPU can observe the updated VMID generation. Fixes: f0cf47d939d0 "KVM: arm/arm64: Close VMID generation race" Reviewed-by: Julien Thierry Signed-off-by: Christoffer Dall Signed-off-by: Marc Zyngier [bwh: Backported to 3.16: - Use ACCESS_ONCE() instead of {READ,WRITE}_ONCE() - Adjust filename] Signed-off-by: Ben Hutchings commit d13575fe09c3b9e93bc2d61c81f4225b2a23d945 Author: Geert Uytterhoeven Date: Thu Dec 13 14:41:11 2018 +0100 pinctrl: sh-pfc: sh7734: Fix shifted values in IPSR10 commit 054f2400f706327f96770219c3065b5131f8f154 upstream. Some values in the Peripheral Function Select Register 10 descriptor are shifted by one position, which may cause a peripheral function to be programmed incorrectly. Fixing this makes all HSCIF0 pins use Function 4 (value 3), like was already the case for the HSCK0 pin in field IP10[5:3]. Fixes: ac1ebc2190f575fc ("sh-pfc: Add sh7734 pinmux support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit e1c81cb8b43fa40f019c03dc5296350c7e31e013 Author: Geert Uytterhoeven Date: Thu Dec 13 14:32:34 2018 +0100 pinctrl: sh-pfc: sh7734: Remove bogus IPSR10 value commit 4d374bacd7c9665179f9752a52d5d602c45d8190 upstream. The IP10[5:3] field in Peripheral Function Select Register 10 has a width of 3 bits, i.e. it allows programming one out of 8 different configurations. However, 9 values are provided instead of 8, overflowing into the subsequent field in the register, and thus breaking the configuration of the latter. Fix this by dropping a bogus zero value. Fixes: ac1ebc2190f575fc ("sh-pfc: Add sh7734 pinmux support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit d3dcc40a44e2fe1a4cfb2933bd2d2d8bcce5517c Author: Geert Uytterhoeven Date: Thu Dec 13 14:27:56 2018 +0100 pinctrl: sh-pfc: sh7269: Add missing PCIOR0 field commit 9540cbdfcd861caf67a6f0e4bb7f46d41c4aad86 upstream. The Port C I/O Register 0 contains 7 reserved bits, but the descriptor contains only dummy configuration values for 6 reserved bits, thus breaking the configuration of all subsequent fields in the register. Fix this by adding the two missing configuration values. Fixes: f5e811f2a43117b2 ("sh-pfc: Add sh7269 pinmux support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit 519815e0606335f5faad8cedd4d6898f62bb40ef Author: Geert Uytterhoeven Date: Thu Dec 13 14:09:56 2018 +0100 pinctrl: sh-pfc: sh7264: Fix PFCR3 and PFCR0 register configuration commit 1b99d0c80bbe1810572c2cb77b90f67886adfa8d upstream. The Port F Control Register 3 (PFCR3) contains only a single field. However, counting from left to right, it is the fourth field, not the first field. Insert the missing dummy configuration values (3 fields of 16 values) to fix this. The descriptor for the Port F Control Register 0 (PFCR0) lacks the description for the 4th field (PF0 Mode, PF0MD[2:0]). Add the missing configuration values to fix this. Fixes: a8d42fc4217b1ea1 ("sh-pfc: Add sh7264 pinmux support") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit 5323c2998bd4f26cff6851043737bcb6729b1a5d Author: Geert Uytterhoeven Date: Wed Dec 12 14:42:16 2018 +0100 pinctrl: sh-pfc: sh7734: Add missing IPSR11 field commit 94482af7055e1ffa211c1135256b85590ebcac99 upstream. The Peripheral Function Select Register 11 contains 3 reserved bits and 15 variable-width fields, but the variable field descriptor does not contain the 3-bit field IP11[25:23]. Fixes: 856cb4bb337ee504 ("sh: Add support pinmux for SH7734") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit b858b1e4b1111589e406d4322efaf5926341a8c9 Author: Geert Uytterhoeven Date: Wed Dec 12 11:20:14 2018 +0100 pinctrl: sh-pfc: sh73a0: Add missing TO pin to tpu4_to3 group commit 124cde98f856b6206b804acbdec3b7c80f8c3427 upstream. The tpu4_to3_mux[] array contains the TPU4TO3 pin mark, but the tpu4_to3_pins[] array lacks the corresponding pin number. Add the missing pin number, for non-GPIO pin F26. Fixes: 5da4eb049de803c7 ("sh-pfc: sh73a0: Add TPU pin groups and functions") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit 74176a56187dc7d05cca58a78de45a49c71d99b1 Author: Geert Uytterhoeven Date: Wed Dec 12 11:12:20 2018 +0100 pinctrl: sh-pfc: r8a7791: Remove bogus marks from vin1_b_data18 group commit 0d6256cb880166a4111bebce35790019e56b6e1b upstream. The vin1_b_data18_mux[] arrays contains pin marks for the 2 LSB bits of the color components. The vin1_b_data18_pins[] array rightfully does not include the corresponding pin numbers, as RGB18 is subset of RGB24, containing only the 6 MSB bits of each component. Fixes: 8e32c9671f84acd8 ("pinctrl: sh-pfc: r8a7791: Add VIN pins") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit 9dd0862826450711a2b8c46a3c594d5551a5ba44 Author: Geert Uytterhoeven Date: Wed Dec 12 11:05:57 2018 +0100 pinctrl: sh-pfc: r8a7791: Remove bogus ctrl marks from qspi_data4_b group commit 884fa25fb6e5e63ab970d612a628313bb68f37cc upstream. The qspi_data4_b_mux[] array contains pin marks for the clock and chip select pins. The qspi_data4_b_pins[] array rightfully does not contain the corresponding pin numbers, as the control pins are provided by a separate group (qspi_ctrl_b). Fixes: 2d0c386f135e4186 ("pinctrl: sh-pfc: r8a7791: Add QSPI pin groups") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit 7d67cf3ed01f9a7b59e6bb72b3b477e398be594e Author: Geert Uytterhoeven Date: Wed Dec 12 11:00:27 2018 +0100 pinctrl: sh-pfc: r8a7740: Add missing LCD0 marks to lcd0_data24_1 group commit 96bb2a6ab4eca10e5b6490b3f0738e9f7ec22c2b upstream. The lcd0_data24_1_pins[] array contains the LCD0 D1[2-5] pin numbers, but the lcd0_data24_1_mux[] array lacks the corresponding pin marks. Fixes: 06c7dd866da70f6c ("sh-pfc: r8a7740: Add LCDC0 and LCDC1 pin groups and functions") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit b84a2dba8f80c4b373eff564c9a9a1d020b6a159 Author: Geert Uytterhoeven Date: Wed Dec 12 10:57:27 2018 +0100 pinctrl: sh-pfc: r8a7740: Add missing REF125CK pin to gether_gmii group commit 1ebc589a7786f17f97b9e87b44e0fb4d0290d8f8 upstream. The gether_gmii_mux[] array contains the REF125CK pin mark, but the gether_gmii_pins[] array lacks the corresponding pin number. Fixes: bae11d30d0cafdc5 ("sh-pfc: r8a7740: Add GETHER pin groups and functions") Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Signed-off-by: Ben Hutchings commit 20b72762a4ae87c68c2706e8bb22da1d567a52b8 Author: Scott Chen Date: Thu Dec 13 06:01:47 2018 -0500 USB: serial: pl2303: add ids for Hewlett-Packard HP POS pole displays commit 8d503f206c336677954160ac62f0c7d9c219cd89 upstream. Add device ids to pl2303 for the HP POS pole displays: LM920: 03f0:026b TD620: 03f0:0956 LD960TA: 03f0:4439 LD220TA: 03f0:4349 LM940: 03f0:5039 Signed-off-by: Scott Chen Signed-off-by: Johan Hovold Signed-off-by: Ben Hutchings commit 4629b8c79542b537ecfb8e43d0fd6dd487289f3a Author: Leon Romanovsky Date: Thu Dec 13 13:15:11 2018 +0200 net/mlx5: Continue driver initialization despite debugfs failure commit 199fa087dc6b503baad06712716fac645a983e8a upstream. The failure to create debugfs entry is unpleasant event, but not enough to abort drier initialization. Align the mlx5_core code to debugfs design and continue execution whenever debugfs_create_dir() successes or not. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Reviewed-by: Saeed Mahameed Signed-off-by: Leon Romanovsky Signed-off-by: Saeed Mahameed [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 02cef97b6a303cff834237cab72cd304c13c2402 Author: Arnaldo Carvalho de Melo Date: Thu Dec 6 13:52:13 2018 -0300 perf parse-events: Fix unchecked usage of strncpy() commit bd8d57fb7e25e9fcf67a9eef5fa13aabe2016e07 upstream. The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: util/parse-events.c: In function 'print_symbol_events': util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] strncpy(name, syms->symbol, MAX_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'print_symbol_events.constprop', inlined from 'print_events' at util/parse-events.c:2508:2: util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] strncpy(name, syms->symbol, MAX_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'print_symbol_events.constprop', inlined from 'print_events' at util/parse-events.c:2511:2: util/parse-events.c:2465:4: error: 'strncpy' specified bound 100 equals destination size [-Werror=stringop-truncation] strncpy(name, syms->symbol, MAX_NAME_LEN); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Fixes: 947b4ad1d198 ("perf list: Fix max event string size") Link: https://lkml.kernel.org/n/tip-b663e33bm6x8hrkie4uxh7u2@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ben Hutchings commit 9ce83b56ae88f0143a94c9495e4e5414a969df86 Author: Arnaldo Carvalho de Melo Date: Thu Dec 6 11:41:03 2018 -0300 perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit set nul commit 4d0f16d059ddb91424480d88473f7392f24aebdc upstream. The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. In this case we are actually setting the null byte at the right place, but since we pass the buffer size as the limit to strncpy() and not it minus one, gcc ends up warning us about that, see below. So, lets just switch to the shorter form provided by strlcpy(). This fixes this warning on an Alpine Linux Edge system with gcc 8.2: ui/tui/helpline.c: In function 'tui_helpline__push': ui/tui/helpline.c:27:2: error: 'strncpy' specified bound 512 equals destination size [-Werror=stringop-truncation] strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0'; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Fixes: e6e904687949 ("perf ui: Introduce struct ui_helpline") Link: https://lkml.kernel.org/n/tip-d1wz0hjjsh19xbalw69qpytj@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ben Hutchings commit b58aa3982e9a3f3281777146b13281f1d9728d4f Author: Arnaldo Carvalho de Melo Date: Thu Dec 6 11:29:48 2018 -0300 perf svghelper: Fix unchecked usage of strncpy() commit 2f5302533f306d5ee87bd375aef9ca35b91762cb upstream. The strncpy() function may leave the destination string buffer unterminated, better use strlcpy() that we have a __weak fallback implementation for systems without it. In this specific case this would only happen if fgets() was buggy, as its man page states that it should read one less byte than the size of the destination buffer, so that it can put the nul byte at the end of it, so it would never copy 255 non-nul chars, as fgets reads into the orig buffer at most 254 non-nul chars and terminates it. But lets just switch to strlcpy to keep the original intent and silence the gcc 8.2 warning. This fixes this warning on an Alpine Linux Edge system with gcc 8.2: In function 'cpu_model', inlined from 'svg_cpu_box' at util/svghelper.c:378:2: util/svghelper.c:337:5: error: 'strncpy' output may be truncated copying 255 bytes from a string of length 255 [-Werror=stringop-truncation] strncpy(cpu_m, &buf[13], 255); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Cc: Arjan van de Ven Fixes: f48d55ce7871 ("perf: Add a SVG helper library file") Link: https://lkml.kernel.org/n/tip-xzkoo0gyr56gej39ltivuh9g@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ben Hutchings commit 7c06c9d8719ff61ac9d2df15c12c29f638022fdd Author: Arnaldo Carvalho de Melo Date: Thu Dec 6 11:20:21 2018 -0300 perf help: Remove needless use of strncpy() commit b6313899f4ed2e76b8375cf8069556f5b94fbff0 upstream. Since we make sure the destination buffer has at least strlen(orig) + 1, no need to do a strncpy(dest, orig, strlen(orig)), just use strcpy(dest, orig). This silences this gcc 8.2 warning on Alpine Linux: In function 'add_man_viewer', inlined from 'perf_help_config' at builtin-help.c:284:3: builtin-help.c:192:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation] strncpy((*p)->name, name, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ builtin-help.c: In function 'perf_help_config': builtin-help.c:187:15: note: length computed here size_t len = strlen(name); ^~~~~~~~~~~~ Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Fixes: 078006012401 ("perf_counter tools: add in basic glue from Git") Link: https://lkml.kernel.org/n/tip-2f69l7drca427ob4km8i7kvo@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Ben Hutchings commit 5c07cc757dc91539d96790328df35844691bea19 Author: Filipe Manana Date: Wed Nov 28 14:54:28 2018 +0000 Btrfs: fix fsync of files with multiple hard links in new directories commit 41bd60676923822de1df2c50b3f9a10171f4338a upstream. The log tree has a long standing problem that when a file is fsync'ed we only check for new ancestors, created in the current transaction, by following only the hard link for which the fsync was issued. We follow the ancestors using the VFS' dget_parent() API. This means that if we create a new link for a file in a directory that is new (or in an any other new ancestor directory) and then fsync the file using an old hard link, we end up not logging the new ancestor, and on log replay that new hard link and ancestor do not exist. In some cases, involving renames, the file will not exist at all. Example: mkfs.btrfs -f /dev/sdb mount /dev/sdb /mnt mkdir /mnt/A touch /mnt/foo ln /mnt/foo /mnt/A/bar xfs_io -c fsync /mnt/foo In this example after log replay only the hard link named 'foo' exists and directory A does not exist, which is unexpected. In other major linux filesystems, such as ext4, xfs and f2fs for example, both hard links exist and so does directory A after mounting again the filesystem. Checking if any new ancestors are new and need to be logged was added in 2009 by commit 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes"), however only for the ancestors of the hard link (dentry) for which the fsync was issued, instead of checking for all ancestors for all of the inode's hard links. So fix this by tracking the id of the last transaction where a hard link was created for an inode and then on fsync fallback to a full transaction commit when an inode has more than one hard link and at least one new hard link was created in the current transaction. This is the simplest solution since this is not a common use case (adding frequently hard links for which there's an ancestor created in the current transaction and then fsync the file). In case it ever becomes a common use case, a solution that consists of iterating the fs/subvol btree for each hard link and check if any ancestor is new, could be implemented. This solves many unexpected scenarios reported by Jayashree Mohan and Vijay Chidambaram, and for which there is a new test case for fstests under review. Fixes: 12fcfd22fe5b ("Btrfs: tree logging unlink/rename fixes") Reported-by: Vijay Chidambaram Reported-by: Jayashree Mohan Signed-off-by: Filipe Manana Signed-off-by: David Sterba [bwh: Backported to 3.16: - In btrfs_log_inode_parent(), inode is a struct inode pointer not a struct btrfs_inode pointer - Adjust context] Signed-off-by: Ben Hutchings commit 7da21d44b8523cdef750ac5edbef0ae51dd06c2b Author: Filipe Manana Date: Fri Jul 24 00:00:19 2015 +0100 Btrfs: fix stale dir entries after unlink, inode eviction and fsync commit bde6c242027b0f1d697d5333950b3a05761d40e4 upstream. If we remove a hard link from an inode, the inode gets evicted, then we fsync the inode and then power fail/crash, when the log tree is replayed, the parent directory inode still has entries pointing to the name that no longer exists, while our inode no longer has the BTRFS_INODE_REF_KEY item matching the deleted hard link (as expected), leaving the filesystem in an inconsistent state. The stale directory entries can not be deleted (an attempt to delete them causes -ESTALE errors), which makes it impossible to delete the parent directory. This happens because we track the id of the transaction where the last unlink operation for the inode happened (last_unlink_trans) in an in-memory only field of the inode, that is, a value that is never persisted in the inode item stored on the fs/subvol btree. So if an inode is evicted and loaded again, the value for last_unlink_trans is set to 0, which prevents the fsync from logging the parent directory at btrfs_log_inode_parent(). So fix this by setting last_unlink_trans to the id of the transaction that last modified the inode when we load the inode. This is a pessimistic approach but it always ensures correctness with the trade off of ocassional full transaction commits when an fsync is done against the inode in the same transaction where it was evicted and reloaded when our inode is a directory and often logging its parent unnecessarily when our inode is not a directory. The following test case for fstests triggers the problem: seq=`basename $0` seqres=$RESULT_DIR/$seq echo "QA output created by $seq" tmp=/tmp/$$ status=1 # failure is the default! trap "_cleanup; exit \$status" 0 1 2 3 15 _cleanup() { _cleanup_flakey rm -f $tmp.* } # get standard environment, filters and checks . ./common/rc . ./common/filter . ./common/dmflakey # real QA test starts here _need_to_be_root _supported_fs generic _supported_os Linux _require_scratch _require_dm_flakey _require_metadata_journaling $SCRATCH_DEV rm -f $seqres.full _scratch_mkfs >>$seqres.full 2>&1 _init_flakey _mount_flakey # Create our test file with 2 hard links. mkdir $SCRATCH_MNT/testdir touch $SCRATCH_MNT/testdir/foo ln $SCRATCH_MNT/testdir/foo $SCRATCH_MNT/testdir/bar # Make sure everything done so far is durably persisted. sync # Now remove one of the links, trigger inode eviction and then fsync # our inode. unlink $SCRATCH_MNT/testdir/bar echo 2 > /proc/sys/vm/drop_caches $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir/foo # Silently drop all writes on our scratch device to simulate a power failure. _load_flakey_table $FLAKEY_DROP_WRITES _unmount_flakey # Allow writes again and mount the fs to trigger log/journal replay. _load_flakey_table $FLAKEY_ALLOW_WRITES _mount_flakey # Now verify our directory entries. echo "Entries in testdir:" ls -1 $SCRATCH_MNT/testdir # If we remove our inode, its parent should become empty and therefore we should # be able to remove the parent. rm -f $SCRATCH_MNT/testdir/* rmdir $SCRATCH_MNT/testdir _unmount_flakey # The fstests framework will call fsck against our filesystem which will verify # that all metadata is in a consistent state. status=0 exit The test failed on btrfs with: generic/098 4s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/098.out.bad) > --- tests/generic/098.out 2015-07-23 18:01:12.616175932 +0100 > +++ /home/fdmanana/git/hub/xfstests/results//generic/098.out.bad 2015-07-23 18:04:58.924138308 +0100 @@ -1,3 +1,6 @@ QA output created by 098 Entries in testdir: +bar foo +rm: cannot remove '/home/fdmanana/btrfs-tests/scratch_1/testdir/foo': Stale file handle +rmdir: failed to remove '/home/fdmanana/btrfs-tests/scratch_1/testdir': Directory not empty ... (Run 'diff -u tests/generic/098.out /home/fdmanana/git/hub/xfstests/results//generic/098.out.bad' to see the entire diff) _check_btrfs_filesystem: filesystem on /dev/sdc is inconsistent (see /home/fdmanana/git/hub/xfstests/results//generic/098.full) $ cat /home/fdmanana/git/hub/xfstests/results//generic/098.full (...) checking fs roots root 5 inode 258 errors 2001, no inode item, link count wrong unresolved ref dir 257 index 0 namelen 3 name foo filetype 1 errors 6, no dir index, no inode ref unresolved ref dir 257 index 3 namelen 3 name bar filetype 1 errors 5, no dir item, no inode ref Checking filesystem on /dev/sdc (...) Signed-off-by: Filipe Manana Signed-off-by: Chris Mason Signed-off-by: Ben Hutchings commit 52a768d42b72d9cfe9f4f866fa7c718eaeffb5fb Author: Yang Dongsheng Date: Thu Apr 9 12:08:43 2015 +0800 Btrfs: fill ->last_trans for delayed inode in btrfs_fill_inode. commit 6e17d30bfaf43e04d991392d8484f1c556810c33 upstream. We need to fill inode when we found a node for it in delayed_nodes_tree. But we did not fill the ->last_trans currently, it will cause the test of xfstest/generic/311 fail. Scenario of the 311 is shown as below: Problem: (1). test_fd = open(fname, O_RDWR|O_DIRECT) (2). pwrite(test_fd, buf, 4096, 0) (3). close(test_fd) (4). drop_all_caches() <-------- "echo 3 > /proc/sys/vm/drop_caches" (5). test_fd = open(fname, O_RDWR|O_DIRECT) (6). fsync(test_fd); <-------- we did not get the correct log entry for the file Reason: When we re-open this file in (5), we would find a node in delayed_nodes_tree and fill the inode we are lookup with the information. But the ->last_trans is not filled, then the fsync() will check the ->last_trans and found it's 0 then say this inode is already in our tree which is commited, not recording the extents for it. Fix: This patch fill the ->last_trans properly and set the runtime_flags if needed in this situation. Then we can get the log entries we expected after (6) and generic/311 passed. Signed-off-by: Dongsheng Yang Reviewed-by: Miao Xie Signed-off-by: Chris Mason Signed-off-by: Ben Hutchings commit 18267f5f84f5ec9ead05a508405f9dc19800e80b Author: Anand Jain Date: Sun Nov 11 22:22:17 2018 +0800 btrfs: dev-replace: go back to suspended state if target device is missing commit 0d228ece59a35a9b9e8ff0d40653234a6d90f61e upstream. At the time of forced unmount we place the running replace to BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state, so when the system comes back and expect the target device is missing. Then let the replace state continue to be in BTRFS_IOCTL_DEV_REPLACE_STATE_SUSPENDED state instead of BTRFS_IOCTL_DEV_REPLACE_STATE_STARTED as there isn't any matching scrub running as part of replace. Fixes: e93c89c1aaaa ("Btrfs: add new sources for device replace code") Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit f6491fdd2c61bdecdcd604345c108fa6009a8fc1 Author: Jim Mattson Date: Wed Dec 5 15:28:58 2018 -0800 kvm: vmx: Set IA32_TSC_AUX for legacy mode guests commit 0023ef39dc35c773c436eaa46ca539a26b308b55 upstream. RDTSCP is supported in legacy mode as well as long mode. The IA32_TSC_AUX MSR should be set to the correct guest value before entering any guest that supports RDTSCP. Fixes: 4e47c7a6d714 ("KVM: VMX: Add instruction rdtscp support for guest") Signed-off-by: Jim Mattson Reviewed-by: Peter Shier Reviewed-by: Marc Orr Reviewed-by: Liran Alon Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini [bwh: Backported to 3.16: - Keep testing vmx->rdtscp_enabled instead of guest_cpuid_has() - Adjust filename] Signed-off-by: Ben Hutchings commit a3777d9cafa6742063a6e3b0e4cf6d62b26910be Author: Krzysztof Kozlowski Date: Thu Dec 6 10:45:49 2018 +0100 gpiolib: Fix return value of gpio_to_desc() stub if !GPIOLIB commit c5510b8dafce5f3f5a039c9b262ebcae0092c462 upstream. If CONFIG_GPOILIB is not set, the stub of gpio_to_desc() should return the same type of error as regular version: NULL. All the callers compare the return value of gpio_to_desc() against NULL, so returned ERR_PTR would be treated as non-error case leading to dereferencing of error value. Fixes: 79a9becda894 ("gpiolib: export descriptor-based GPIO interface") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Linus Walleij Signed-off-by: Ben Hutchings commit e6f592986433f9b3ef79ab5c2197b9badac370f4 Author: Eric Biggers Date: Thu Dec 6 15:55:41 2018 -0800 crypto: user - support incremental algorithm dumps commit 0ac6b8fb23c724b015d9ca70a89126e8d1563166 upstream. CRYPTO_MSG_GETALG in NLM_F_DUMP mode sometimes doesn't return all registered crypto algorithms, because it doesn't support incremental dumps. crypto_dump_report() only permits itself to be called once, yet the netlink subsystem allocates at most ~64 KiB for the skb being dumped to. Thus only the first recvmsg() returns data, and it may only include a subset of the crypto algorithms even if the user buffer passed to recvmsg() is large enough to hold all of them. Fix this by using one of the arguments in the netlink_callback structure to keep track of the current position in the algorithm list. Then userspace can do multiple recvmsg() on the socket after sending the dump request. This is the way netlink dumps work elsewhere in the kernel; it's unclear why this was different (probably just an oversight). Also fix an integer overflow when calculating the dump buffer size hint. Fixes: a38f7907b926 ("crypto: Add userspace configuration API") Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit b2bf1147c25726d907972e4800d5b5da14f66977 Author: Gustavo A. R. Silva Date: Wed Dec 12 15:36:28 2018 -0600 ALSA: pcm: Fix potential Spectre v1 vulnerability commit 94ffb030b6d31ec840bb811be455dd2e26a4f43e upstream. stream is indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: sound/core/pcm.c:140 snd_pcm_control_ioctl() warn: potential spectre issue 'pcm->streams' [r] (local cap) Fix this by sanitizing stream before using it to index pcm->streams Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings commit 913fc5d772ddde218ac1623d1c6416cd1fe01b70 Author: Gustavo A. R. Silva Date: Wed Dec 12 11:20:49 2018 -0600 ALSA: emux: Fix potential Spectre v1 vulnerabilities commit 4aea96f4237cea0c51a8bc87c0db31f0f932f1f0 upstream. info.mode and info.port are indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. These issues were detected with the help of Smatch: sound/synth/emux/emux_hwdep.c:72 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[i]->ctrls' [w] (local cap) sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs' [w] (local cap) sound/synth/emux/emux_hwdep.c:75 snd_emux_hwdep_misc_mode() warn: potential spectre issue 'emu->portptrs[info.port]->ctrls' [w] (local cap) Fix this by sanitizing both info.mode and info.port before using them to index emu->portptrs[i]->ctrls, emu->portptrs[info.port]->ctrls and emu->portptrs. Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Signed-off-by: Gustavo A. R. Silva Signed-off-by: Takashi Iwai [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 94f1f42384f2477adea2929804dd29e54013beeb Author: Bart Van Assche Date: Thu Dec 6 17:11:29 2018 -0800 tools/lib/lockdep: Rename "trywlock" into "trywrlock" commit 7f3c7952d111ac93573fb86f4d5aeff527a07fcc upstream. This patch avoids that the following compiler warning is reported while compiling the lockdep unit tests: include/liblockdep/rwlock.h: In function 'liblockdep_pthread_rwlock_trywlock': include/liblockdep/rwlock.h:66:9: warning: implicit declaration of function 'pthread_rwlock_trywlock'; did you mean 'pthread_rwlock_trywrlock'? [-Wimplicit-function-declaration] return pthread_rwlock_trywlock(&lock->rwlock) == 0 ? 1 : 0; ^~~~~~~~~~~~~~~~~~~~~~~ pthread_rwlock_trywrlock Signed-off-by: Bart Van Assche Signed-off-by: Peter Zijlstra (Intel) Cc: Johannes Berg Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sasha Levin Cc: Sasha Levin Cc: Thomas Gleixner Cc: Waiman Long Cc: johannes.berg@intel.com Cc: tj@kernel.org Fixes: 5a52c9b480e0 ("liblockdep: Add public headers for pthread_rwlock_t implementation") Link: https://lkml.kernel.org/r/20181207011148.251812-6-bvanassche@acm.org Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings commit 44d0080b9c746af532632386ef2a9f47d8dbfdd6 Author: Sergei Shtylyov Date: Sat Nov 24 21:14:16 2018 +0300 sata_rcar: fix deferred probing commit 9f83cfdb1ace3ef268ecc6fda50058d2ec37d603 upstream. The driver overrides the error codes returned by platform_get_irq() to -EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq") Reviewed-by: Simon Horman Reviewed-by: Geert Uytterhoeven Signed-off-by: Sergei Shtylyov Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings commit 550eb492817c82a4960a037ecfb080cb2665ab6d Author: Steffen Maier Date: Thu Dec 6 17:31:20 2018 +0100 scsi: zfcp: fix posting too many status read buffers leading to adapter shutdown commit 60a161b7e5b2a252ff0d4c622266a7d8da1120ce upstream. Suppose adapter (open) recovery is between opened QDIO queues and before (the end of) initial posting of status read buffers (SRBs). This time window can be seconds long due to FSF_PROT_HOST_CONNECTION_INITIALIZING causing by design looping with exponential increase sleeps in the function performing exchange config data during recovery [zfcp_erp_adapter_strat_fsf_xconf()]. Recovery triggered by local link up. Suppose an event occurs for which the FCP channel would send an unsolicited notification to zfcp by means of a previously posted SRB. We saw it with local cable pull (link down) in multi-initiator zoning with multiple NPIV-enabled subchannels of the same shared FCP channel. As soon as zfcp_erp_adapter_strategy_open_fsf() starts posting the initial status read buffers from within the adapter's ERP thread, the channel does send an unsolicited notification. Since v2.6.27 commit d26ab06ede83 ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall"), zfcp_fsf_status_read_handler() schedules adapter->stat_work to re-fill the just consumed SRB from a work item. Now the ERP thread and the work item post SRBs in parallel. Both contexts call the helper function zfcp_status_read_refill(). The tracking of missing (to be posted / re-filled) SRBs is not thread-safe due to separate atomic_read() and atomic_dec(), in order to depend on posting success. Hence, both contexts can see atomic_read(&adapter->stat_miss) == 1. One of the two contexts posts one too many SRB. Zfcp gets QDIO_ERROR_SLSB_STATE on the output queue (trace tag "qdireq1") leading to zfcp_erp_adapter_shutdown() in zfcp_qdio_handler_error(). An obvious and seemingly clean fix would be to schedule stat_work from the ERP thread and wait for it to finish. This would serialize all SRB re-fills. However, we already have another work item wait on the ERP thread: adapter->scan_work runs zfcp_fc_scan_ports() which calls zfcp_fc_eval_gpn_ft(). The latter calls zfcp_erp_wait() to wait for all the open port recoveries during zfcp auto port scan, but in fact it waits for any pending recovery including an adapter recovery. This approach leads to a deadlock. [see also v3.19 commit 18f87a67e6d6 ("zfcp: auto port scan resiliency"); v2.6.37 commit d3e1088d6873 ("[SCSI] zfcp: No ERP escalation on gpn_ft eval"); v2.6.28 commit fca55b6fb587 ("[SCSI] zfcp: fix deadlock between wq triggered port scan and ERP") fixing v2.6.27 commit c57a39a45a76 ("[SCSI] zfcp: wait until adapter is finished with ERP during auto-port"); v2.6.27 commit cc8c282963bd ("[SCSI] zfcp: Automatically attach remote ports")] Instead make the accounting of missing SRBs atomic for parallel execution in both the ERP thread and adapter->stat_work. Signed-off-by: Steffen Maier Fixes: d26ab06ede83 ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall") Reviewed-by: Jens Remus Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings commit 7e533b91d84a9ce15f6a37e3e5f23b3b77b09690 Author: Jiong Wang Date: Mon Dec 3 17:27:54 2018 -0500 mips: bpf: fix encoding bug for mm_srlv32_op commit 17f6c83fb5ebf7db4fcc94a5be4c22d5a7bfe428 upstream. For micro-mips, srlv inside POOL32A encoding space should use 0x50 sub-opcode, NOT 0x90. Some early version ISA doc describes the encoding as 0x90 for both srlv and srav, this looks to me was a typo. I checked Binutils libopcode implementation which is using 0x50 for srlv and 0x90 for srav. v1->v2: - Keep mm_srlv32_op sorted by value. Fixes: f31318fdf324 ("MIPS: uasm: Add srlv uasm instruction") Cc: Markos Chandras Cc: Paul Burton Cc: linux-mips@vger.kernel.org Acked-by: Jakub Kicinski Acked-by: Song Liu Signed-off-by: Jiong Wang Signed-off-by: Alexei Starovoitov Signed-off-by: Ben Hutchings commit 7fe29a1565321021652748f63406e3fe5f51ee3e Author: Dan Carpenter Date: Mon Dec 3 17:52:19 2018 +0300 misc: vexpress: Off by one in vexpress_syscfg_exec() commit f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream. The > comparison should be >= to prevent reading beyond the end of the func->template[] array. (The func->template array is allocated in vexpress_syscfg_regmap_init() and it has func->num_templates elements.) Fixes: 974cc7b93441 ("mfd: vexpress: Define the device as MFD cells") Signed-off-by: Dan Carpenter Acked-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit aeebd7582b278ea798ee4f50f14679da5273ed8e Author: Paul Burton Date: Tue Dec 4 23:44:12 2018 +0000 MIPS: Expand MIPS32 ASIDs to 64 bits commit ff4dd232ec45a0e45ea69f28f069f2ab22b4908a upstream. ASIDs have always been stored as unsigned longs, ie. 32 bits on MIPS32 kernels. This is problematic because it is feasible for the ASID version to overflow & wrap around to zero. We currently attempt to handle this overflow by simply setting the ASID version to 1, using asid_first_version(), but we make no attempt to account for the fact that there may be mm_structs with stale ASIDs that have versions which we now reuse due to the overflow & wrap around. Encountering this requires that: 1) A struct mm_struct X is active on CPU A using ASID (V,n). 2) That mm is not used on CPU A for the length of time that it takes for CPU A's asid_cache to overflow & wrap around to the same version V that the mm had in step 1. During this time tasks using the mm could either be sleeping or only scheduled on other CPUs. 3) Some other mm Y becomes active on CPU A and is allocated the same ASID (V,n). 4) mm X now becomes active on CPU A again, and now incorrectly has the same ASID as mm Y. Where struct mm_struct ASIDs are represented above in the format (version, EntryHi.ASID), and on a typical MIPS32 system version will be 24 bits wide & EntryHi.ASID will be 8 bits wide. The length of time required in step 2 is highly dependent upon the CPU & workload, but for a hypothetical 2GHz CPU running a workload which generates a new ASID every 10000 cycles this period is around 248 days. Due to this long period of time & the fact that tasks need to be scheduled in just the right (or wrong, depending upon your inclination) way, this is obviously a difficult bug to encounter but it's entirely possible as evidenced by reports. In order to fix this, simply extend ASIDs to 64 bits even on MIPS32 builds. This will extend the period of time required for the hypothetical system above to encounter the problem from 28 days to around 3 trillion years, which feels safely outside of the realms of possibility. The cost of this is slightly more generated code in some commonly executed paths, but this is pretty minimal: | Code Size Gain | Percentage -----------------------|----------------|------------- decstation_defconfig | +270 | +0.00% 32r2el_defconfig | +652 | +0.01% 32r6el_defconfig | +1000 | +0.01% I have been unable to measure any change in performance of the LMbench lat_ctx or lat_proc tests resulting from the 64b ASIDs on either 32r2el_defconfig+interAptiv or 32r6el_defconfig+I6500 systems. Signed-off-by: Paul Burton Suggested-by: James Hogan References: https://lore.kernel.org/linux-mips/80B78A8B8FEE6145A87579E8435D78C30205D5F3@fzex.ruijie.com.cn/ References: https://lore.kernel.org/linux-mips/1488684260-18867-1-git-send-email-jiwei.sun@windriver.com/ Cc: Jiwei Sun Cc: Yu Huabing Cc: linux-mips@vger.kernel.org [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit 1226f6af04f4a2c3eebf1b4ad8a827a65a0b809c Author: Dmitry Safonov Date: Thu Nov 1 00:24:46 2018 +0000 tty/ldsem: Wake up readers after timed out down_write() commit 231f8fd0cca078bd4396dd7e380db813ac5736e2 upstream. ldsem_down_read() will sleep if there is pending writer in the queue. If the writer times out, readers in the queue should be woken up, otherwise they may miss a chance to acquire the semaphore until the last active reader will do ldsem_up_read(). There was a couple of reports where there was one active reader and other readers soft locked up: Showing all locks held in the system: 2 locks held by khungtaskd/17: #0: (rcu_read_lock){......}, at: watchdog+0x124/0x6d1 #1: (tasklist_lock){.+.+..}, at: debug_show_all_locks+0x72/0x2d3 2 locks held by askfirst/123: #0: (&tty->ldisc_sem){.+.+.+}, at: ldsem_down_read+0x46/0x58 #1: (&ldata->atomic_read_lock){+.+...}, at: n_tty_read+0x115/0xbe4 Prevent readers wait for active readers to release ldisc semaphore. Link: lkml.kernel.org/r/20171121132855.ajdv4k6swzhvktl6@wfg-t540p.sh.intel.com Link: lkml.kernel.org/r/20180907045041.GF1110@shao2-debian Cc: Jiri Slaby Cc: Peter Zijlstra Reported-by: kernel test robot Signed-off-by: Dmitry Safonov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 06c27396e84044b55a4ebe9edb2c9c873784e4a1 Author: Vasily Averin Date: Wed Nov 28 11:45:57 2018 +0300 sunrpc: fix cache_head leak due to queued request commit 4ecd55ea074217473f94cfee21bb72864d39f8d7 upstream. After commit d202cce8963d, an expired cache_head can be removed from the cache_detail's hash. However, the expired cache_head may be waiting for a reply from a previously submitted request. Such a cache_head has an increased refcounter and therefore it won't be freed after cache_put(freeme). Because the cache_head was removed from the hash it cannot be found during cache_clean() and can be leaked forever, together with stalled cache_request and other taken resources. In our case we noticed it because an entry in the export cache was holding a reference on a filesystem. Fixes d202cce8963d ("sunrpc: never return expired entries in sunrpc_cache_lookup") Cc: Pavel Tikhomirov Signed-off-by: Vasily Averin Reviewed-by: NeilBrown Signed-off-by: J. Bruce Fields [bwh: Backported to 3.16: - cache_fresh_lock() doesn't take a struct cache_detail pointer - Adjust context] Signed-off-by: Ben Hutchings commit e605566013882b36b44766e18ebe8005858d413a Author: Maurizio Lombardi Date: Tue Dec 4 00:06:53 2018 -0500 ext4: missing unlock/put_page() in ext4_try_to_write_inline_data() commit 132d00becb31e88469334e1e62751c81345280e0 upstream. In case of error, ext4_try_to_write_inline_data() should unlock and release the page it holds. Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data") Signed-off-by: Maurizio Lombardi Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings commit dd7ed5143c62e5d2becd70e513478f9d59b9ccd5 Author: Larry Finger Date: Mon Nov 19 20:01:24 2018 +0200 b43: Fix error in cordic routine commit 8ea3819c0bbef57a51d8abe579e211033e861677 upstream. The cordic routine for calculating sines and cosines that was added in commit 6f98e62a9f1b ("b43: update cordic code to match current specs") contains an error whereby a quantity declared u32 can in fact go negative. This problem was detected by Priit Laes who is switching b43 to use the routine in the library functions of the kernel. Fixes: 986504540306 ("b43: make cordic common (LP-PHY and N-PHY need it)") Reported-by: Priit Laes Cc: Rafał Miłecki Signed-off-by: Larry Finger Signed-off-by: Priit Laes Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit dc7933209440a197bb7780f93778db91dc41c667 Author: Stefan Agner Date: Wed Nov 14 18:49:38 2018 +0100 serial: imx: fix error handling in console_setup commit 63fd4b94b948c14eeb27a3bbf50ea0f7f0593bad upstream. The ipg clock only needs to be unprepared in case preparing per clock fails. The ipg clock has already disabled at the point. Fixes: 1cf93e0d5488 ("serial: imx: remove the uart_console() check") Signed-off-by: Stefan Agner Reviewed-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings commit 47cf54a6b6edae510890398b209bd8476fc4ef82 Author: Colin Ian King Date: Sat Nov 24 12:34:10 2018 +0000 altera-stapl: check for a null key before strcasecmp'ing it commit 9ccb645683ef46e3c52c12c088a368baa58447d4 upstream. Currently the null check on key is occurring after the strcasecmp on the key, hence there is a potential null pointer dereference on key. Fix this by checking if key is null first. Also replace the == 0 check on strcasecmp with just the ! operator. Detected by CoverityScan, CID#1248787 ("Dereference before null check") Fixes: fa766c9be58b ("[media] Altera FPGA firmware download module") Signed-off-by: Colin Ian King Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: old code used strnicmp()] Signed-off-by: Ben Hutchings commit 6acfa0b5a8cd7bc4ff805be7f5a9914a0eff7f3c Author: Rasmus Villemoes Date: Mon Oct 13 15:54:25 2014 -0700 lib/string.c: remove duplicated function commit cd514e727b18ff4d189b8e268db13729a4175091 upstream. lib/string.c contains two functions, strnicmp and strncasecmp, which do roughly the same thing, namely compare two strings case-insensitively up to a given bound. They have slightly different implementations, but the only important difference is that strncasecmp doesn't handle len==0 appropriately; it effectively becomes strcasecmp in that case. strnicmp correctly says that two strings are always equal in their first 0 characters. strncasecmp is the POSIX name for this functionality. So rename the non-broken function to the standard name. To minimize the impact on the rest of the kernel (and since both are exported to modules), make strnicmp a wrapper for strncasecmp. Signed-off-by: Rasmus Villemoes Cc: Grant Likely Cc: Andi Kleen Cc: Dan Carpenter Cc: "H. Peter Anvin" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings commit 358101ff5ccc00d5e47b60c72db892ef977649b9 Author: Pan Bian Date: Thu Nov 22 18:58:46 2018 +0800 f2fs: read page index before freeing commit 0ea295dd853e0879a9a30ab61f923c26be35b902 upstream. The function truncate_node frees the page with f2fs_put_page. However, the page index is read after that. So, the patch reads the index before freeing the page. Fixes: bf39c00a9a7f ("f2fs: drop obsolete node page when it is truncated") Signed-off-by: Pan Bian Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings commit eeaac833ba9c44f78d31a0d0cb58617bde98f54c Author: Laurent Pinchart Date: Wed Oct 17 22:08:31 2018 +0300 drm: rcar-du: Fix vblank initialization commit 3d61fe5f59dd3e6f96fc0772156d257cb04dc656 upstream. The drm_vblank_init() takes the total number of CRTCs as an argument, but the rcar-du driver passes a bitmask of the CRTC indices. Fix it. Fixes: 4bf8e1962f91 ("drm: Renesas R-Car Display Unit DRM driver") Reported-by: Tomi Valkeinen Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham [bwh: Backported to 3.16: adjust filename, context] Signed-off-by: Ben Hutchings commit e79b5482b190fbadda112d351d0f9bcefc7a1797 Author: Sergey Senozhatsky Date: Thu Oct 25 19:10:36 2018 +0900 panic: avoid deadlocks in re-entrant console drivers commit c7c3f05e341a9a2bd1a92993d4f996cfd6e7348e upstream. From printk()/serial console point of view panic() is special, because it may force CPU to re-enter printk() or/and serial console driver. Therefore, some of serial consoles drivers are re-entrant. E.g. 8250: serial8250_console_write() { if (port->sysrq) locked = 0; else if (oops_in_progress) locked = spin_trylock_irqsave(&port->lock, flags); else spin_lock_irqsave(&port->lock, flags); ... } panic() does set oops_in_progress via bust_spinlocks(1), so in theory we should be able to re-enter serial console driver from panic(): CPU0 uart_console_write() serial8250_console_write() // if (oops_in_progress) // spin_trylock_irqsave() call_console_drivers() console_unlock() console_flush_on_panic() bust_spinlocks(1) // oops_in_progress++ panic() spin_lock_irqsave(&port->lock, flags) // spin_lock_irqsave() serial8250_console_write() call_console_drivers() console_unlock() printk() ... However, this does not happen and we deadlock in serial console on port->lock spinlock. And the problem is that console_flush_on_panic() called after bust_spinlocks(0): void panic(const char *fmt, ...) { bust_spinlocks(1); ... bust_spinlocks(0); console_flush_on_panic(); ... } bust_spinlocks(0) decrements oops_in_progress, so oops_in_progress can go back to zero. Thus even re-entrant console drivers will simply spin on port->lock spinlock. Given that port->lock may already be locked either by a stopped CPU, or by the very same CPU we execute panic() on (for instance, NMI panic() on printing CPU) the system deadlocks and does not reboot. Fix this by removing bust_spinlocks(0), so oops_in_progress is always set in panic() now and, thus, re-entrant console drivers will trylock the port->lock instead of spinning on it forever, when we call them from console_flush_on_panic(). Link: http://lkml.kernel.org/r/20181025101036.6823-1-sergey.senozhatsky@gmail.com Cc: Steven Rostedt Cc: Daniel Wang Cc: Peter Zijlstra Cc: Andrew Morton Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: Alan Cox Cc: Jiri Slaby Cc: Peter Feiner Cc: linux-serial@vger.kernel.org Cc: Sergey Senozhatsky Signed-off-by: Sergey Senozhatsky Signed-off-by: Petr Mladek Signed-off-by: Ben Hutchings commit 53a7435c0be8aa7516b03ddab4cc30208cdd77d9 Author: Ben Hutchings Date: Sun Nov 11 18:45:24 2018 +0000 perf pmu: Suppress potential format-truncation warning commit 11a64a05dc649815670b1be9fe63d205cb076401 upstream. Depending on which functions are inlined in util/pmu.c, the snprintf() calls in perf_pmu__parse_{scale,unit,per_pkg,snapshot}() might trigger a warning: util/pmu.c: In function 'pmu_aliases': util/pmu.c:178:31: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=] snprintf(path, PATH_MAX, "%s/%s.unit", dir, name); ^~ I found this when trying to build perf from Linux 3.16 with gcc 8. However I can reproduce the problem in mainline if I force __perf_pmu__new_alias() to be inlined. Suppress this by using scnprintf() as has been done elsewhere in perf. Signed-off-by: Ben Hutchings Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20181111184524.fux4taownc6ndbx6@decadent.org.uk Signed-off-by: Arnaldo Carvalho de Melo [bwh: Dropped the parts that don't apply to 3.16] Signed-off-by: Ben Hutchings commit 3c75eb57cb788d8eda880b587ed8e5d36cefd2ce Author: Huacai Chen Date: Thu Nov 15 15:53:56 2018 +0800 MIPS: Align kernel load address to 64KB commit bec0de4cfad21bd284dbddee016ed1767a5d2823 upstream. KEXEC needs the new kernel's load address to be aligned on a page boundary (see sanity_check_segment_list()), but on MIPS the default vmlinuz load address is only explicitly aligned to 16 bytes. Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase the alignment calculated by calc_vmlinuz_load_addr to 64KB. Signed-off-by: Huacai Chen Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21131/ Cc: Ralf Baechle Cc: James Hogan Cc: Steven J . Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Signed-off-by: Ben Hutchings commit 05373fbc97a91773beb3cf5961398bc90c83b553 Author: Huacai Chen Date: Thu Nov 15 15:53:54 2018 +0800 MIPS: Ensure pmd_present() returns false after pmd_mknotpresent() commit 92aa0718c9fa5160ad2f0e7b5bffb52f1ea1e51a upstream. This patch is borrowed from ARM64 to ensure pmd_present() returns false after pmd_mknotpresent(). This is needed for THP. References: 5bb1cc0ff9a6 ("arm64: Ensure pmd_present() returns false after pmd_mknotpresent()") Reviewed-by: James Hogan Signed-off-by: Huacai Chen Signed-off-by: Paul Burton Patchwork: https://patchwork.linux-mips.org/patch/21135/ Cc: Ralf Baechle Cc: James Hogan Cc: Steven J . Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Signed-off-by: Ben Hutchings commit e4046d5d6c52101ec1cbb962102d8f4c99edd255 Author: Lubomir Rintel Date: Fri Nov 16 17:23:47 2018 +0100 power: supply: olpc_battery: correct the temperature units commit ed54ffbe554f0902689fd6d1712bbacbacd11376 upstream. According to [1] and [2], the temperature values are in tenths of degree Celsius. Exposing the Celsius value makes the battery appear on fire: $ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery ... temperature: 236.9 degrees C Tested on OLPC XO-1 and OLPC XO-1.75 laptops. [1] include/linux/power_supply.h [2] Documentation/power/power_supply_class.txt Fixes: fb972873a767 ("[BATTERY] One Laptop Per Child power/battery driver") Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek Signed-off-by: Sebastian Reichel [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings commit f2110302482d641671d4c97690eaa78feaf2e0be Author: Maciej W. Rozycki Date: Tue Nov 13 22:42:37 2018 +0000 MIPS: SiByte: Enable ZONE_DMA32 for LittleSur commit 756d6d836dbfb04a5a486bc2ec89397aa4533737 upstream. The LittleSur board is marked for high memory support and therefore clearly must provide a way to have enough memory installed for some to be present outside the low 4GiB physical address range. With the memory map of the BCM1250 SOC it has been built around it means over 1GiB of actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical address range[1]. Complement commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") then and also enable ZONE_DMA32 for LittleSur. References: [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R, Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview", "Memory Map", pp. 34-38 Signed-off-by: Maciej W. Rozycki Signed-off-by: Paul Burton Reviewed-by: Christoph Hellwig Patchwork: https://patchwork.linux-mips.org/patch/21107/ Fixes: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.") Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ben Hutchings commit 4116da8b4d1966f851fbc90d71c555232776cd4c Author: Vasily Averin Date: Thu Nov 15 13:18:56 2018 +0300 dlm: memory leaks on error path in dlm_user_request() commit d47b41aceeadc6b58abc9c7c6485bef7cfb75636 upstream. According to comment in dlm_user_request() ua should be freed in dlm_free_lkb() after successful attach to lkb. However ua is attached to lkb not in set_lock_args() but later, inside request_lock(). Fixes 597d0cae0f99 ("[DLM] dlm: user locks") Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Ben Hutchings commit 34ca3283984f5a1c67ac6cdd13084e5242a14702 Author: Vasily Averin Date: Thu Nov 15 13:18:24 2018 +0300 dlm: lost put_lkb on error path in receive_convert() and receive_unlock() commit c0174726c3976e67da8649ac62cae43220ae173a upstream. Fixes 6d40c4a708e0 ("dlm: improve error and debug messages") Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Ben Hutchings commit 9244efe0a77a0b656c5f67e74924d73c23b1a45a Author: Vasily Averin Date: Thu Nov 15 13:18:18 2018 +0300 dlm: possible memory leak on error path in create_lkb() commit 23851e978f31eda8b2d01bd410d3026659ca06c7 upstream. Fixes 3d6aa675fff9 ("dlm: keep lkbs in idr") Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Ben Hutchings commit c9e13155b1e67efeafaf9bb92943f2501f91ceab Author: Vasily Averin Date: Thu Nov 15 13:15:05 2018 +0300 dlm: fixed memory leaks after failed ls_remove_names allocation commit b982896cdb6e6a6b89d86dfb39df489d9df51e14 upstream. If allocation fails on last elements of array need to free already allocated elements. v2: just move existing out_rsbtbl label to right place Fixes 789924ba635f ("dlm: fix race between remove and lookup") Signed-off-by: Vasily Averin Signed-off-by: David Teigland Signed-off-by: Ben Hutchings commit 8c9874721f886bb11464ba1d132a9cc0efe8536e Author: Colin Ian King Date: Sat Oct 27 15:49:26 2018 +0100 pcrypt: use format specifier in kobject_add commit b1e3874c75ab15288f573b3532e507c37e8e7656 upstream. Passing string 'name' as the format specifier is potentially hazardous because name could (although very unlikely to) have a format specifier embedded in it causing issues when parsing the non-existent arguments to these. Follow best practice by using the "%s" format string for the string 'name'. Cleans up clang warning: crypto/pcrypt.c:397:40: warning: format string is not a string literal (potentially insecure) [-Wformat-security] Fixes: a3fb1e330dd2 ("pcrypt: Added sysfs interface to pcrypt") Signed-off-by: Colin Ian King Signed-off-by: Herbert Xu Signed-off-by: Ben Hutchings commit 8bd55c2283ca142fd9aa7682ce1acd1edc66ca9b Author: Colin Ian King Date: Thu Oct 25 14:52:31 2018 +0100 x86/PCI: Fix Broadcom CNB20LE unintended sign extension (redux) commit 53bb565fc5439f2c8c57a786feea5946804aa3e9 upstream. In the expression "word1 << 16", word1 starts as u16, but is promoted to a signed int, then sign-extended to resource_size_t, which is probably not what was intended. Cast to resource_size_t to avoid the sign extension. This fixes an identical issue as fixed by commit 0b2d70764bb3 ("x86/PCI: Fix Broadcom CNB20LE unintended sign extension") back in 2014. Detected by CoverityScan, CID#138749, 138750 ("Unintended sign extension") Fixes: 3f6ea84a3035 ("PCI: read memory ranges out of Broadcom CNB20LE host bridge") Signed-off-by: Colin Ian King Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings commit c2c2c89ac4e9fc133bd4b4d01657470508c88dd6 Author: Chris Wilson Date: Mon Nov 5 09:43:05 2018 +0000 drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5 commit 55f99bf2a9c331838c981694bc872cd1ec4070b2 upstream. Exercising the gpu reloc path strenuously revealed an issue where the updated relocations (from MI_STORE_DWORD_IMM) were not being observed upon execution. After some experiments with adding pipecontrols (a lot of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe controls or even the current on), it was discovered that we merely needed to delay the EMIT_INVALIDATE by several flushes. It is important to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that needs the delay as opposed to what one might first expect -- that the delay is required for the TLB invalidation to take effect (one presumes to purge any CS buffers) as opposed to a delay after flushing to ensure the writes have landed before triggering invalidation. Testcase: igt/gem_tiled_fence_blits Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20181105094305.5767-1-chris@chris-wilson.co.uk [bwh: Backported to 3.16: - Use intel_ring_emit() instead of assignments - Use ring->scratch.gtt_offset instead of i915_ggtt_offset() - Use (invalidate_domains & I915_GEM_DOMAIN_INSTRUCTION) instead of (mode & EMIT_INVALIDATE) - Adjust context] Signed-off-by: Ben Hutchings commit 6d276ecc808f00628a0c3dbfe8c4b308745471b6 Author: Dan Carpenter Date: Wed Oct 24 11:33:34 2018 +0300 wireless: airo: potential buffer overflow in sprintf() commit 3d39e1bb1c88f32820c5f9271f2c8c2fb9a52bac upstream. It looks like we wanted to print a maximum of BSSList_rid.ssidLen bytes of the ssid, but we accidentally use "%*s" (width) instead of "%.*s" (precision) so if the ssid doesn't have a NUL terminator this could lead to an overflow. Static analysis. Not tested. Fixes: e174961ca1a0 ("net: convert print_mac to %pM") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings