- 20 Oct, 2016 26 commits
-
-
Steven Rostedt authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 15301a57 upstream. Łukasz Daniluk reported that on a RHEL kernel that his machine would lock up after enabling function tracer. I asked him to bisect the functions within available_filter_functions, which he did and it came down to three: _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64() It was found that this is only an issue when noreplace-paravirt is added to the kernel command line. This means that those functions are most likely called within critical sections of the funtion tracer, and must not be traced. In newer kenels _paravirt_nop() is defined within gcc asm(), and is no longer an issue. But both _paravirt_ident_{32,64}() causes the following splat when they are traced: mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054) mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070) mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054) mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054) NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469] Modules linked in: e1000e CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000 RIP: 0010:[<ffffffff81134148>] [<ffffffff81134148>] queued_spin_lock_slowpath+0x118/0x1a0 RSP: 0018:ffff8800d4aefb90 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40 RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030 RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000 R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8 R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0 FS: 00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0 Call Trace: _raw_spin_lock+0x27/0x30 handle_pte_fault+0x13db/0x16b0 handle_mm_fault+0x312/0x670 __do_page_fault+0x1b1/0x4e0 do_page_fault+0x22/0x30 page_fault+0x28/0x30 __vfs_read+0x28/0xe0 vfs_read+0x86/0x130 SyS_read+0x46/0xa0 entry_SYSCALL_64_fastpath+0x1e/0xa8 Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b Reported-by:
Łukasz Daniluk <lukasz.daniluk@intel.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Vineet Gupta authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 1c3c9093 upstream. | CC mm/memory.o | In file included from ../mm/memory.c:53:0: | ../include/linux/pfn_t.h: In function ‘pfn_t_pte’: | ../include/linux/pfn_t.h:78:2: error: conversion to non-scalar type requested | return pfn_pte(pfn_t_to_pfn(pfn), pgprot); With STRICT_MM_TYPECHECKS pte_t is a struct and the offending code forces a cast which ends up shifting a struct and hence the gcc warning. Note that in recent past some of the arches (aarch64, s390) made STRICT_MM_TYPECHECKS default, but we don't for ARC as this leads to slightly worse generated code, given ARC ABI definition of returning structs (which pte_t would become) Quoting from ARC ABI... "Results of type struct are returned in a caller-supplied temporary variable whose address is passed in r0. For such functions, the arguments are shifted so that they are passed in r1 and up." So - struct to be returned would be allocated on stack requiring extra code at call sites - callee updates stack memory to facilitate the return (vs. simple MOV into return reg r0) Hence STRICT_MM_TYPECHECKS is not enabled by default for ARC Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit d1e09f30 upstream. Fixes an oops that might happen if uverbs_close races with remove_one. Both contexts may run ib_uverbs_cleanup_ucontext, it depends on the flow. Currently, there is no protection for a case that remove_one didn't make the cleanup it runs to its end, the underlying ib_device was freed then uverbs_close will call ib_uverbs_cleanup_ucontext and OOPs. Above might happen if uverbs_close deleted the file from the list then remove_one didn't find it and runs to its end. Fixes to protect against that case by a new cleanup lock so that ib_uverbs_cleanup_ucontext will be called always before that remove_one is ended. Fixes: 35d4a0b6 ("IB/uverbs: Fix race between ib_uverbs_open and remove_one") Reported-by:
Devesh Sharma <devesh.sharma@broadcom.com> Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Mike Snitzer authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 299f6230 upstream. v4.8-rc3 commit 99f3c90d ("dm flakey: error READ bios during the down_interval") overlooked the 'drop_writes' feature, which is meant to allow reads to be issued rather than errored, during the down_interval. Fixes: 99f3c90d ("dm flakey: error READ bios during the down_interval") Reported-by:
Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mateusz Guzik authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 5efc2443 upstream. Prior to the change the function would blindly deference mm, exe_file and exe_file->f_inode, each of which could have been NULL or freed. Use get_task_exe_file to safely obtain stable exe_file. Signed-off-by:
Mateusz Guzik <mguzik@redhat.com> Acked-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Acked-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Mateusz Guzik authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit cd81a917 upstream. For more convenient access if one has a pointer to the task. As a minor nit take advantage of the fact that only task lock + rcu are needed to safely grab ->exe_file. This saves mm refcount dance. Use the helper in proc_exe_link. Signed-off-by:
-
Thiago Jung Bauermann authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 070c43ee upstream. If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs and pi->purgatory_buf. This is redundant, because in case of error kimage_file_prepare_segments calls kimage_file_post_load_cleanup, which will also free those buffers. This causes two warnings like the following, one for pi->sechdrs and the other for pi->purgatory_buf: kexec-bzImage64: Loading purgatory failed ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 __vunmap+0xc1/0xd0 Trying to vfree() nonexistent vm area (ffffc90000e91000) Modules linked in: CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x4d/0x65 __warn+0xcb/0xf0 warn_slowpath_fmt+0x4f/0x60 ? find_vmap_area+0x19/0x70 ? kimage_file_post_load_cleanup+0x47/0xb0 __vunmap+0xc1/0xd0 vfree+0x2e/0x70 kimage_file_post_load_cleanup+0x5e/0xb0 SyS_kexec_file_load+0x448/0x680 ? putname+0x54/0x60 ? do_sys_open+0x190/0x1f0 entry_SYSCALL_64_fastpath+0x13/0x8f ---[ end trace 158bb74f5950ca2b ]--- Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree won't try to free a NULL pointer. Link: http://lkml.kernel.org/r/1472083546-23683-1-git-send-email-bauerman@linux.vnet.ibm.comSigned-off-by:
Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com> Acked-by:
Baoquan He <bhe@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: Dave Young <dyoung@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit b519d408 upstream. Ensure that we conform to the algorithm described in RFC5661, section 18.36.4 for when to bump the sequence id. In essence we do it for all cases except when the RPC call timed out, or in case of the server returning NFS4ERR_DELAY or NFS4ERR_STALE_CLIENTID. Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit bf0291dd upstream. According to RFC5661, the client is responsible for serialising LAYOUTGET and LAYOUTRETURN to avoid ambiguity. Consider the case where we send both in parallel. Client Server ====== ====== LAYOUTGET(seqid=X) LAYOUTRETURN(seqid=X) LAYOUTGET return seqid=X+1 LAYOUTRETURN return seqid=X+2 Process LAYOUTRETURN Forget layout stateid Process LAYOUTGET Set seqid=X+1 The client processes the layoutget/layoutreturn in the wrong order, and since the result of the layoutreturn was to clear the only existing layout segment, the client forgets the layout stateid. When the LAYOUTGET comes in, it is treated as having a completely new stateid, and so the client sets the wrong sequence id... Fix is to check if there are outstanding LAYOUTGET requests before we send the LAYOUTRETURN (note that LAYOUGET will already wait if it sees an outstanding LAYOUTRETURN). Signed-off-by:
-
Chuck Lever authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 88584818 upstream. nfsd4_release_lockowner finds a lock owner that has no lock state, and drops cl_lock. Then release_lockowner picks up cl_lock and unhashes the lock owner. During the window where cl_lock is dropped, I don't see anything preventing a concurrent nfsd4_lock from finding that same lock owner and adding lock state to it. Move release_lockowner() into nfsd4_release_lockowner and hang onto the cl_lock until after the lock owner's state cannot be found again. Found by inspection, we don't currently have a reproducer. Fixes: 2c41beb0 ("nfsd: reduce cl_lock thrashing in ... ") Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 98b0f80c upstream. On error, the callers expect us to return without bumping nn->cb_users[]. Signed-off-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit b88fa69e upstream. Ensure that the client conforms to the normative behaviour described in RFC5661 Section 12.7.2: "If a client believes its lease has expired, it MUST NOT send I/O to the storage device until it has validated its lease." So ensure that we wait for the lease to be validated before using the layout. Signed-off-by:
-
Tejun Heo authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit df6a58c5 upstream. kernfs_notify_workfn() sends out file modified events for the scheduled kernfs_nodes. Because the modifications aren't from userland, it doesn't have the matching file struct at hand and can't use fsnotify_modify(). Instead, it looked up the inode and then used d_find_any_alias() to find the dentry and used fsnotify_parent() and fsnotify() directly to generate notifications. The assumption was that the relevant dentries would have been pinned if there are listeners, which isn't true as inotify doesn't pin dentries at all and watching the parent doesn't pin the child dentries even for dnotify. This led to, for example, inotify watchers not getting notifications if the system is under memory pressure and the matching dentries got reclaimed. It can also be triggered through /proc/sys/vm/drop_caches or a remount attempt which involves shrinking dcache. fsnotify_parent() only uses the dentry to access the parent inode, which kernfs can do easily. Update kernfs_notify_workfn() so that it uses fsnotify() directly for both the parent and target inodes without going through d_find_any_alias(). While at it, supply the target file name to fsnotify() from kernfs_node->name. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Evgeny Vereshchagin <evvers@ya.ru> Fixes: d911d987 ("kernfs: make kernfs_notify() trigger inotify events too") Cc: John McCutchan <john@johnmccutchan.com> Cc: Robert Love <rlove@rlove.org> Cc: Eric Paris <eparis@parisplace.org> Signed-off-by:
-
Paul Mackerras authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit f077aaf0 upstream. In commit c60ac569 ("powerpc: Update kernel VSID range", 2013-03-13) we lost a check on the region number (the top four bits of the effective address) for addresses below PAGE_OFFSET. That commit replaced a check that the top 18 bits were all zero with a check that bits 46 - 59 were zero (performed for all addresses, not just user addresses). This means that userspace can access an address like 0x1000_0xxx_xxxx_xxxx and we will insert a valid SLB entry for it. The VSID used will be the same as if the top 4 bits were 0, but the page size will be some random value obtained by indexing beyond the end of the mm_ctx_high_slices_psize array in the paca. If that page size is the same as would be used for region 0, then userspace just has an alias of the region 0 space. If the page size is different, then no HPTE will be found for the access, and the process will get a SIGSEGV (since hash_page_mm() will refuse to create a HPTE for the bogus address). The access beyond the end of the mm_ctx_high_slices_psize can be at most 5.5MB past the array, and so will be in RAM somewhere. Since the access is a load performed in real mode, it won't fault or crash the kernel. At most this bug could perhaps leak a little bit of information about blocks of 32 bytes of memory located at offsets of i * 512kB past the paca->mm_ctx_high_slices_psize array, for 1 <= i <= 11. Fixes: c60ac569 ("powerpc: Update kernel VSID range") Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Reviewed-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nicholas Piggin authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit cc7786d3 upstream. tabort_syscall runs with RI=1, so a nested recoverable machine check will load the paca into r13 and overwrite what we loaded it with, because exceptions returning to privileged mode do not restore r13. Fixes: b4b56f9e (powerpc/tm: Abort syscalls in active transactions) Signed-off-by:
Nick Piggin <npiggin@gmail.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Wenwei Tao authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 16c6d048 upstream. The bio is not returned if the data page cannot be allocated. Signed-off-by:
Wenwei Tao <ww.tao0320@gmail.com> Signed-off-by:
Matias Bjørling <m@bjorling.me> Signed-off-by:
Jens Axboe <axboe@fb.com> Cc: Ben Hutchings <ben.hutchings@codethink.co.uk> Signed-off-by:
-
Eric Biggers authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit ba63f23d upstream. Since setting an encryption policy requires writing metadata to the filesystem, it should be guarded by mnt_want_write/mnt_drop_write. Otherwise, a user could cause a write to a frozen or readonly filesystem. This was handled correctly by f2fs but not by ext4. Make fscrypt_process_policy() handle it rather than relying on the filesystem to get it right. Signed-off-by:
Eric Biggers <ebiggers@google.com> Cc: stable@vger.kernel.org # 4.1+; check fs/{ext4,f2fs} Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Acked-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit ba913e4f upstream. When mapping a page into the guest we error check using is_error_pfn(), however this doesn't detect a value of KVM_PFN_NOSLOT, indicating an error HVA for the page. This can only happen on MIPS right now due to unusual memslot management (e.g. being moved / removed / resized), or with an Enhanced Virtual Memory (EVA) configuration where the default KVM_HVA_ERR_* and kvm_is_error_hva() definitions are unsuitable (fixed in a later patch). This case will be treated as a pfn of zero, mapping the first page of physical memory into the guest. It would appear the MIPS KVM port wasn't updated prior to being merged (in v3.10) to take commit 81c52c56 ("KVM: do not treat noslot pfn as a error pfn") into account (merged v3.8), which converted a bunch of is_error_pfn() calls to is_error_noslot_pfn(). Switch to using is_error_noslot_pfn() instead to catch this case properly. Fixes: 858dd5d4 ("KVM/MIPS32: MMU/TLB operations for the Guest.") Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> [james.hogan@imgtec.com: Backport to v4.7.y] Signed-off-by:
-
Chen-Yu Tsai authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit b53e7d00 upstream. The bootloader (U-boot) sometimes uses this timer for various delays. It uses it as a ongoing counter, and does comparisons on the current counter value. The timer counter is never stopped. In some cases when the user interacts with the bootloader, or lets it idle for some time before loading Linux, the timer may expire, and an interrupt will be pending. This results in an unexpected interrupt when the timer interrupt is enabled by the kernel, at which point the event_handler isn't set yet. This results in a NULL pointer dereference exception, panic, and no way to reboot. Clear any pending interrupts after we stop the timer in the probe function to avoid this. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Eric Biggers authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit 163ae1c6 upstream. On an ext4 or f2fs filesystem with file encryption supported, a user could set an encryption policy on any empty directory(*) to which they had readonly access. This is obviously problematic, since such a directory might be owned by another user and the new encryption policy would prevent that other user from creating files in their own directory (for example). Fix this by requiring inode_owner_or_capable() permission to set an encryption policy. This means that either the caller must own the file, or the caller must have the capability CAP_FOWNER. (*) Or also on any regular file, for f2fs v4.6 and later and ext4 v4.8-rc1 and later; a separate bug fix is coming for that. Signed-off-by:
-
Konstantin Khlebnikov authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit adb7ef60 upstream. This might be unexpected but pages allocated for sbi->s_buddy_cache are charged to current memory cgroup. So, GFP_NOFS allocation could fail if current task has been killed by OOM or if current memory cgroup has no free memory left. Block allocator cannot handle such failures here yet. Signed-off-by:
-
Li Zhong authored
BugLink: http://bugs.launchpad.net/bugs/1613295 walk.iv is not assigned a value in blkcipher_walk_init. It makes iv uninitialized. It is possibly a null value(as shown below), which is then used by aes_p8_encrypt. This patch moves iv = walk.iv after blkcipher_walk_virt, in which walk.iv is set. [17856.268050] Unable to handle kernel paging request for data at address 0x00000000 [17856.268212] Faulting instruction address: 0xd000000002ff04bc 7:mon> t [link register ] d000000002ff47b8 p8_aes_xts_crypt+0x168/0x2a0 [vmx_crypto] (938) [c000000013b77960] d000000002ff4794 p8_aes_xts_crypt+0x144/0x2a0 [vmx_crypto] (unreliable) [c000000013b77a70] c000000000544d64 skcipher_decrypt_blkcipher+0x64/0x80 [c000000013b77ac0] d000000003c0175c crypt_convert+0x53c/0x620 [dm_crypt] [c000000013b77ba0] d000000003c043fc kcryptd_crypt+0x3cc/0x440 [dm_crypt] [c000000013b77c50] c0000000000f3070 process_one_work+0x1e0/0x590 [c000000013b77ce0] c0000000000f34c8 worker_thread+0xa8/0x660 [c000000013b77d80] c0000000000fc0b0 kthread+0x110/0x130 [c000000013b77e30] c0000000000098f0 ret_from_kernel_thread+0x5c/0x6c Signed-off-by:
Li Zhong <zhong@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 901d3d4f) Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Acked-by:
Colin King <colin.king@canonical.com>
-
Tushar Dave authored
BugLink: http://bugs.launchpad.net/bugs/1626782 On systems with 128 CPUs, turning off TSO results in errors, i40e 0000:03:00.0: failed to get tracking for 1 vectors for VSI 400, err=-12 i40e 0000:03:00.0: Couldn't create FDir VSI i40e 0000:03:00.0: i40e_ptp_init: PTP not supported on eth0 i40e 0000:03:00.0: couldn't add VEB, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_ENOENT i40e 0000:03:00.0: rebuild of switch failed: -1, will try to set up simple PF connection i40e 0000:03:00.0 eth0: adding 00:10:e0:8a:24:b6 vid=0 Enabling FD_SB without checking availability of MSI-X vector is the root cause. This change adds necessary check. Signed-off-by:
Tushar Dave <tushar.n.dave@oracle.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit a70e407f) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1626222 Since we will remove items off the list using list_del() we need to use a safe version of the list_for_each() macro aptly named list_for_each_safe(). Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 96183182) Signed-off-by:
-
Tyrel Datwyler authored
BugLink: http://bugs.launchpad.net/bugs/1625986 The underlying slot hotplug registration code assumed multiple slots, but the actual implementation is broken for multiple slots. This went unnoticed for years do to the fact that PowerVM seems to only ever provide a single hotplug slot per PHB. Under qemu/kvm the hotplug slot model aligns more with x86 where multiple slots are presented under a single PHB. As seen in the following each additional slot after the first fails to register due to each slot always being compared against the first child node of the PHB in the device tree. rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpaphp: Slot [Slot 0] registered rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 The registration logic is fixed so that each slot is compared against the existing child devices of the PHB in the device tree to determine present slots vs empty slots. rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpaphp: Slot [C0] registered rpaphp: Slot [C1] registered rpaphp: Slot [C2] registered rpaphp: Slot [C3] registered rpaphp: Slot [C4] registered Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Reviewed-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> [mpe: Massage changelog] Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1628520 Commit 5706aca74fe4 ("NVMe: Don't unmap controller registers on reset"), which backported b00a726a to the 4.4.y kernel introduced a regression in which it didn't call pci_disable_device in the error path of nvme_pci_enable. Reported-by:
Jiri Slaby <jslaby@suse.cz> Embarassed-developer: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
-
- 19 Oct, 2016 4 commits
-
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1611078 This reverts commit 63f6655e, which is superseded by later patches. Signed-off-by:
-
Seth Forshee authored
Ignore: yes Signed-off-by: -
Stefan Bader authored
Signed-off-by: -
John Johansen authored
path_put() call dput() which might sleep on some paths. When it does sleep from these code paths, the per cpu work buffer may get reused overwriting the data that was just placed in the buffer. This causes the following mediation to fail as the work buffer no longer has valid data for the current operation. BugLink: http://bugs.launchpad.net/bugs/1634753Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by:
-
- 18 Oct, 2016 1 commit
-
-
Linus Torvalds authored
This is an ancient bug that was actually attrempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9 ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f4 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can once more try to fix it by checking the pte_dirty() bit properly (and do it better). Also, the VM has become more scalable, and what was a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by:
Phil "not Paul" Oester <kernel@linuxace.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- 17 Oct, 2016 1 commit
-
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 12 Oct, 2016 2 commits
-
-
Seth Forshee authored
Signed-off-by: -
Gavin Guo authored
BugLink: http://bugs.launchpad.net/bugs/1518457 On an AWS t2.micro instance (Xeon E5-2670, 991MiB of memory). Occasionally (about once a day), kswapd0 falls into a busy loop and spins on 100% CPU usage indefinitely. Reject to do the zone balance when the memory is too small. Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Tested-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Acked-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
- 11 Oct, 2016 1 commit
-
-
Seth Forshee authored
Ignore: yes Signed-off-by:
-
- 07 Oct, 2016 4 commits
-
-
Seth Forshee authored
Signed-off-by: -
Sabrina Dubroca authored
BugLink: http://bugs.launchpad.net/bugs/1631287 Currently, GRO can do unlimited recursion through the gro_receive handlers. This was fixed for tunneling protocols by limiting tunnel GRO to one level with encap_mark, but both VLAN and TEB still have this problem. Thus, the kernel is vulnerable to a stack overflow, if we receive a packet composed entirely of VLAN headers. This patch adds a recursion counter to the GRO layer to prevent stack overflow. When a gro_receive function hits the recursion limit, GRO is aborted for this skb and it is processed normally. Fixes: 9b174d88 ("net: Add Transparent Ethernet Bridging GRO support.") Fixes: 66e5133f ("vlan: Add GRO support for non hardware accelerated vlan") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Reviewed-by:
Jiri Benc <jbenc@redhat.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Steve Beattie <steve.beattie@canonical.com> [ saf: backported to xenial - Fix up gro_receive callback invocation in udb_gro_receive() - Adjust context ] CVE-2016-7039 Acked-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1631287 This patch should fix the issues seen with a recent fix to prevent tunnel-in-tunnel frames from being generated with GRO. The fix itself is correct for now as long as we do not add any devices that support NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the potential to mess things up due to the fact that the outer transport header points to the outer UDP header and not the GRE header as would be expected. Fixes: fac8e0f5 ("tunnels: Don't apply GRO to multiple layers of encapsulation.") Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
Jesse Gross authored
BugLink: http://bugs.launchpad.net/bugs/1631287 When drivers express support for TSO of encapsulated packets, they only mean that they can do it for one layer of encapsulation. Supporting additional levels would mean updating, at a minimum, more IP length fields and they are unaware of this. No encapsulation device expresses support for handling offloaded encapsulated packets, so we won't generate these types of frames in the transmit path. However, GRO doesn't have a check for multiple levels of encapsulation and will attempt to build them. UDP tunnel GRO actually does prevent this situation but it only handles multiple UDP tunnels stacked on top of each other. This generalizes that solution to prevent any kind of tunnel stacking that would cause problems. Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack") Signed-off-by:
Jesse Gross <jesse@kernel.org> Signed-off-by:
-
- 28 Sep, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
