January 2019 - Linux-stable-mirror

FAILED: patch "[PATCH] drm/atomic_helper: Disallow new modesets on unregistered" failed to apply to 4.20-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.20-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 4d80273976bf880c4bed9359b8f2d45663140c86 Mon Sep 17 00:00:00 2001 From: Lyude Paul <lyude(a)redhat.com> Date: Mon, 8 Oct 2018 19:24:30 -0400 Subject: [PATCH] drm/atomic_helper: Disallow new modesets on unregistered connectors With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: stable(a)vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20181008232437.5571-2-lyude@r… diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 3cf1aa132778..c1a35078b2b9 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -308,6 +308,26 @@ update_connector_routing(struct drm_atomic_state *state, return 0; } + crtc_state = drm_atomic_get_new_crtc_state(state, + new_connector_state->crtc); + /* + * For compatibility with legacy users, we want to make sure that + * we allow DPMS On->Off modesets on unregistered connectors. Modesets + * which would result in anything else must be considered invalid, to + * avoid turning on new displays on dead connectors. + * + * Since the connector can be unregistered at any point during an + * atomic check or commit, this is racy. But that's OK: all we care + * about is ensuring that userspace can't do anything but shut off the + * display on a connector that was destroyed after its been notified, + * not before. + */ + if (!READ_ONCE(connector->registered) && crtc_state->active) { + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n", + connector->base.id, connector->name); + return -EINVAL; + } + funcs = connector->helper_private; if (funcs->atomic_best_encoder) @@ -352,7 +372,6 @@ update_connector_routing(struct drm_atomic_state *state, set_best_encoder(state, new_connector_state, new_encoder); - crtc_state = drm_atomic_get_new_crtc_state(state, new_connector_state->crtc); crtc_state->connectors_changed = true; DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n",

5 years, 11 months

2
1
0 0

Stable queue: queue-4.20

by CKI

Hello, We ran automated tests on a patchset that was proposed for merging into this kernel tree. The patches were applied to: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Commit: 8aab2b4410a2 Linux 4.20.2 The results of these automated tests are provided below. Overall result: FAILED (see details below) Patch merge: OK Compile: FAILED We attempted to compile the kernel for multiple architectures, but the compile failed on one or more architectures: s390x: FAILED (build log attached: build_s390.log.gz) powerpc64le: FAILED (build log attached: build_powerpc.log.gz) aarch64: FAILED (build log attached: build_arm64.log.gz) x86_64: FAILED (build log attached: build_x86_64.log.gz) We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Merge testing ------------- We cloned this repository and checked out a ref: Repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git Ref: 8aab2b4410a2 Linux 4.20.2 We then merged the following patches with `git am`: powerpc-tm-unset-msr-if-not-recheckpointing.patch btrfs-fix-deadlock-when-using-free-space-tree-due-to-block-group-creation.patch usbcore-select-only-first-configuration-for-non-uac3-compliant-devices.patch staging-rtl8188eu-fix-module-loading-from-tasklet-for-ccmp-encryption.patch staging-rtl8188eu-fix-module-loading-from-tasklet-for-wep-encryption.patch cpufreq-scpi-scmi-fix-freeing-of-dynamic-opps.patch cpufreq-scmi-fix-frequency-invariance-in-slow-path.patch x86-modpost-replace-last-remnants-of-retpoline-with-config_retpoline.patch alsa-hda-realtek-support-dell-headset-mode-for-new-aio-platform.patch alsa-hda-realtek-add-unplug-function-into-unplug-state-of-headset-mode-for-alc225.patch alsa-hda-realtek-disable-headset-mic-vref-for-headset-mode-of-alc225.patch cifs-fix-adjustment-of-credits-for-mtu-requests.patch cifs-do-not-set-credits-to-1-if-the-server-didn-t-grant-anything.patch cifs-do-not-hide-eintr-after-sending-network-packets.patch cifs-fix-credit-computation-for-compounded-requests.patch cifs-fix-potential-oob-access-of-lock-element-array.patch cifs-check-kzalloc-return.patch arm-davinci-dm355-evm-fix-label-names-in-gpio-lookup-entries.patch arm-davinci-da850-evm-fix-label-names-in-gpio-lookup-entries.patch arm-davinci-omapl138-hawk-fix-label-names-in-gpio-lookup-entries.patch arm-davinci-dm644x-evm-fix-label-names-in-gpio-lookup-entries.patch arm-davinci-da830-evm-fix-label-names-in-gpio-lookup-entries.patch usb-cdc-acm-send-zlp-for-telit-3g-intel-based-modems.patch usb-storage-don-t-insert-sane-sense-for-spc3-when-bad-sense-specified.patch usb-storage-add-quirk-for-smi-sm3350.patch usb-add-usb_quirk_delay_ctrl_msg-quirk-for-corsair-k70-rgb.patch fork-memcg-fix-cached_stacks-case.patch slab-alien-caches-must-not-be-initialized-if-the-allocation-of-the-alien-cache-failed.patch mm-usercopy.c-no-check-page-span-for-stack-objects.patch mm-memcg-fix-reclaim-deadlock-with-writeback.patch mm-page_mapped-don-t-assume-compound-page-is-huge-or-thp.patch Compile testing --------------- We compiled the kernel for 4 architectures: s390x: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: powerpc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: Hardware testing ---------------- We booted each kernel and ran the following tests: s390: powerpc: arm64: x86_64:

5 years, 11 months

2
1
0 0

FAILED: patch "[PATCH] mm, memcg: fix reclaim deadlock with writeback" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 63f3655f950186752236bb88a22f8252c11ce394 Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko(a)suse.com> Date: Tue, 8 Jan 2019 15:23:07 -0800 Subject: [PATCH] mm, memcg: fix reclaim deadlock with writeback Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the ext4 writeback task1: wait_on_page_bit+0x82/0xa0 shrink_page_list+0x907/0x960 shrink_inactive_list+0x2c7/0x680 shrink_node_memcg+0x404/0x830 shrink_node+0xd8/0x300 do_try_to_free_pages+0x10d/0x330 try_to_free_mem_cgroup_pages+0xd5/0x1b0 try_charge+0x14d/0x720 memcg_kmem_charge_memcg+0x3c/0xa0 memcg_kmem_charge+0x7e/0xd0 __alloc_pages_nodemask+0x178/0x260 alloc_pages_current+0x95/0x140 pte_alloc_one+0x17/0x40 __pte_alloc+0x1e/0x110 alloc_set_pte+0x5fe/0xc20 do_fault+0x103/0x970 handle_mm_fault+0x61e/0xd10 __do_page_fault+0x252/0x4d0 do_page_fault+0x30/0x80 page_fault+0x28/0x30 task2: __lock_page+0x86/0xa0 mpage_prepare_extent_to_map+0x2e7/0x310 [ext4] ext4_writepages+0x479/0xd60 do_writepages+0x1e/0x30 __writeback_single_inode+0x45/0x320 writeback_sb_inodes+0x272/0x600 __writeback_inodes_wb+0x92/0xc0 wb_writeback+0x268/0x300 wb_workfn+0xb4/0x390 process_one_work+0x189/0x420 worker_thread+0x4e/0x4b0 kthread+0xe6/0x100 ret_from_fork+0x41/0x50 He adds "task1 is waiting for the PageWriteback bit of the page that task2 has collected in mpd->io_submit->io_bio, and tasks2 is waiting for the LOCKED bit the page which tasks1 has locked" More precisely task1 is handling a page fault and it has a page locked while it charges a new page table to a memcg. That in turn hits a memory limit reclaim and the memcg reclaim for legacy controller is waiting on the writeback but that is never going to finish because the writeback itself is waiting for the page locked in the #PF path. So this is essentially ABBA deadlock: lock_page(A) SetPageWriteback(A) unlock_page(A) lock_page(B) lock_page(B) pte_alloc_pne shrink_page_list wait_on_page_writeback(A) SetPageWriteback(B) unlock_page(B) # flush A, B to clear the writeback This accumulating of more pages to flush is used by several filesystems to generate a more optimal IO patterns. Waiting for the writeback in legacy memcg controller is a workaround for pre-mature OOM killer invocations because there is no dirty IO throttling available for the controller. There is no easy way around that unfortunately. Therefore fix this specific issue by pre-allocating the page table outside of the page lock. We have that handy infrastructure for that already so simply reuse the fault-around pattern which already does this. There are probably other hidden __GFP_ACCOUNT | GFP_KERNEL allocations from under a fs page locked but they should be really rare. I am not aware of a better solution unfortunately. [akpm(a)linux-foundation.org: fix mm/memory.c:__do_fault()] [akpm(a)linux-foundation.org: coding-style fixes] [mhocko(a)kernel.org: enhance comment, per Johannes] Link: http://lkml.kernel.org/r/20181214084948.GA5624@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages") Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Liu Bo <bo.liu(a)linux.alibaba.com> Debugged-by: Liu Bo <bo.liu(a)linux.alibaba.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Reviewed-by: Liu Bo <bo.liu(a)linux.alibaba.com> Cc: Jan Kara <jack(a)suse.cz> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Theodore Ts'o <tytso(a)mit.edu> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/memory.c b/mm/memory.c index a52663c0612d..5e46836714dc 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2994,6 +2994,28 @@ static vm_fault_t __do_fault(struct vm_fault *vmf) struct vm_area_struct *vma = vmf->vma; vm_fault_t ret; + /* + * Preallocate pte before we take page_lock because this might lead to + * deadlocks for memcg reclaim which waits for pages under writeback: + * lock_page(A) + * SetPageWriteback(A) + * unlock_page(A) + * lock_page(B) + * lock_page(B) + * pte_alloc_pne + * shrink_page_list + * wait_on_page_writeback(A) + * SetPageWriteback(B) + * unlock_page(B) + * # flush A, B to clear the writeback + */ + if (pmd_none(*vmf->pmd) && !vmf->prealloc_pte) { + vmf->prealloc_pte = pte_alloc_one(vmf->vma->vm_mm); + if (!vmf->prealloc_pte) + return VM_FAULT_OOM; + smp_wmb(); /* See comment in __pte_alloc() */ + } + ret = vma->vm_ops->fault(vmf); if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE | VM_FAULT_RETRY | VM_FAULT_DONE_COW)))

5 years, 11 months

1
0
0 0

FAILED: patch "[PATCH] mm, memcg: fix reclaim deadlock with writeback" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 63f3655f950186752236bb88a22f8252c11ce394 Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko(a)suse.com> Date: Tue, 8 Jan 2019 15:23:07 -0800 Subject: [PATCH] mm, memcg: fix reclaim deadlock with writeback Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the ext4 writeback task1: wait_on_page_bit+0x82/0xa0 shrink_page_list+0x907/0x960 shrink_inactive_list+0x2c7/0x680 shrink_node_memcg+0x404/0x830 shrink_node+0xd8/0x300 do_try_to_free_pages+0x10d/0x330 try_to_free_mem_cgroup_pages+0xd5/0x1b0 try_charge+0x14d/0x720 memcg_kmem_charge_memcg+0x3c/0xa0 memcg_kmem_charge+0x7e/0xd0 __alloc_pages_nodemask+0x178/0x260 alloc_pages_current+0x95/0x140 pte_alloc_one+0x17/0x40 __pte_alloc+0x1e/0x110 alloc_set_pte+0x5fe/0xc20 do_fault+0x103/0x970 handle_mm_fault+0x61e/0xd10 __do_page_fault+0x252/0x4d0 do_page_fault+0x30/0x80 page_fault+0x28/0x30 task2: __lock_page+0x86/0xa0 mpage_prepare_extent_to_map+0x2e7/0x310 [ext4] ext4_writepages+0x479/0xd60 do_writepages+0x1e/0x30 __writeback_single_inode+0x45/0x320 writeback_sb_inodes+0x272/0x600 __writeback_inodes_wb+0x92/0xc0 wb_writeback+0x268/0x300 wb_workfn+0xb4/0x390 process_one_work+0x189/0x420 worker_thread+0x4e/0x4b0 kthread+0xe6/0x100 ret_from_fork+0x41/0x50 He adds "task1 is waiting for the PageWriteback bit of the page that task2 has collected in mpd->io_submit->io_bio, and tasks2 is waiting for the LOCKED bit the page which tasks1 has locked" More precisely task1 is handling a page fault and it has a page locked while it charges a new page table to a memcg. That in turn hits a memory limit reclaim and the memcg reclaim for legacy controller is waiting on the writeback but that is never going to finish because the writeback itself is waiting for the page locked in the #PF path. So this is essentially ABBA deadlock: lock_page(A) SetPageWriteback(A) unlock_page(A) lock_page(B) lock_page(B) pte_alloc_pne shrink_page_list wait_on_page_writeback(A) SetPageWriteback(B) unlock_page(B) # flush A, B to clear the writeback This accumulating of more pages to flush is used by several filesystems to generate a more optimal IO patterns. Waiting for the writeback in legacy memcg controller is a workaround for pre-mature OOM killer invocations because there is no dirty IO throttling available for the controller. There is no easy way around that unfortunately. Therefore fix this specific issue by pre-allocating the page table outside of the page lock. We have that handy infrastructure for that already so simply reuse the fault-around pattern which already does this. There are probably other hidden __GFP_ACCOUNT | GFP_KERNEL allocations from under a fs page locked but they should be really rare. I am not aware of a better solution unfortunately. [akpm(a)linux-foundation.org: fix mm/memory.c:__do_fault()] [akpm(a)linux-foundation.org: coding-style fixes] [mhocko(a)kernel.org: enhance comment, per Johannes] Link: http://lkml.kernel.org/r/20181214084948.GA5624@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages") Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Liu Bo <bo.liu(a)linux.alibaba.com> Debugged-by: Liu Bo <bo.liu(a)linux.alibaba.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Reviewed-by: Liu Bo <bo.liu(a)linux.alibaba.com> Cc: Jan Kara <jack(a)suse.cz> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Theodore Ts'o <tytso(a)mit.edu> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/memory.c b/mm/memory.c index a52663c0612d..5e46836714dc 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2994,6 +2994,28 @@ static vm_fault_t __do_fault(struct vm_fault *vmf) struct vm_area_struct *vma = vmf->vma; vm_fault_t ret; + /* + * Preallocate pte before we take page_lock because this might lead to + * deadlocks for memcg reclaim which waits for pages under writeback: + * lock_page(A) + * SetPageWriteback(A) + * unlock_page(A) + * lock_page(B) + * lock_page(B) + * pte_alloc_pne + * shrink_page_list + * wait_on_page_writeback(A) + * SetPageWriteback(B) + * unlock_page(B) + * # flush A, B to clear the writeback + */ + if (pmd_none(*vmf->pmd) && !vmf->prealloc_pte) { + vmf->prealloc_pte = pte_alloc_one(vmf->vma->vm_mm); + if (!vmf->prealloc_pte) + return VM_FAULT_OOM; + smp_wmb(); /* See comment in __pte_alloc() */ + } + ret = vma->vm_ops->fault(vmf); if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE | VM_FAULT_RETRY | VM_FAULT_DONE_COW)))

5 years, 11 months

1
0
0 0

FAILED: patch "[PATCH] mm, memcg: fix reclaim deadlock with writeback" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 63f3655f950186752236bb88a22f8252c11ce394 Mon Sep 17 00:00:00 2001 From: Michal Hocko <mhocko(a)suse.com> Date: Tue, 8 Jan 2019 15:23:07 -0800 Subject: [PATCH] mm, memcg: fix reclaim deadlock with writeback Liu Bo has experienced a deadlock between memcg (legacy) reclaim and the ext4 writeback task1: wait_on_page_bit+0x82/0xa0 shrink_page_list+0x907/0x960 shrink_inactive_list+0x2c7/0x680 shrink_node_memcg+0x404/0x830 shrink_node+0xd8/0x300 do_try_to_free_pages+0x10d/0x330 try_to_free_mem_cgroup_pages+0xd5/0x1b0 try_charge+0x14d/0x720 memcg_kmem_charge_memcg+0x3c/0xa0 memcg_kmem_charge+0x7e/0xd0 __alloc_pages_nodemask+0x178/0x260 alloc_pages_current+0x95/0x140 pte_alloc_one+0x17/0x40 __pte_alloc+0x1e/0x110 alloc_set_pte+0x5fe/0xc20 do_fault+0x103/0x970 handle_mm_fault+0x61e/0xd10 __do_page_fault+0x252/0x4d0 do_page_fault+0x30/0x80 page_fault+0x28/0x30 task2: __lock_page+0x86/0xa0 mpage_prepare_extent_to_map+0x2e7/0x310 [ext4] ext4_writepages+0x479/0xd60 do_writepages+0x1e/0x30 __writeback_single_inode+0x45/0x320 writeback_sb_inodes+0x272/0x600 __writeback_inodes_wb+0x92/0xc0 wb_writeback+0x268/0x300 wb_workfn+0xb4/0x390 process_one_work+0x189/0x420 worker_thread+0x4e/0x4b0 kthread+0xe6/0x100 ret_from_fork+0x41/0x50 He adds "task1 is waiting for the PageWriteback bit of the page that task2 has collected in mpd->io_submit->io_bio, and tasks2 is waiting for the LOCKED bit the page which tasks1 has locked" More precisely task1 is handling a page fault and it has a page locked while it charges a new page table to a memcg. That in turn hits a memory limit reclaim and the memcg reclaim for legacy controller is waiting on the writeback but that is never going to finish because the writeback itself is waiting for the page locked in the #PF path. So this is essentially ABBA deadlock: lock_page(A) SetPageWriteback(A) unlock_page(A) lock_page(B) lock_page(B) pte_alloc_pne shrink_page_list wait_on_page_writeback(A) SetPageWriteback(B) unlock_page(B) # flush A, B to clear the writeback This accumulating of more pages to flush is used by several filesystems to generate a more optimal IO patterns. Waiting for the writeback in legacy memcg controller is a workaround for pre-mature OOM killer invocations because there is no dirty IO throttling available for the controller. There is no easy way around that unfortunately. Therefore fix this specific issue by pre-allocating the page table outside of the page lock. We have that handy infrastructure for that already so simply reuse the fault-around pattern which already does this. There are probably other hidden __GFP_ACCOUNT | GFP_KERNEL allocations from under a fs page locked but they should be really rare. I am not aware of a better solution unfortunately. [akpm(a)linux-foundation.org: fix mm/memory.c:__do_fault()] [akpm(a)linux-foundation.org: coding-style fixes] [mhocko(a)kernel.org: enhance comment, per Johannes] Link: http://lkml.kernel.org/r/20181214084948.GA5624@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20181213092221.27270-1-mhocko@kernel.org Fixes: c3b94f44fcb0 ("memcg: further prevent OOM with too many dirty pages") Signed-off-by: Michal Hocko <mhocko(a)suse.com> Reported-by: Liu Bo <bo.liu(a)linux.alibaba.com> Debugged-by: Liu Bo <bo.liu(a)linux.alibaba.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Reviewed-by: Liu Bo <bo.liu(a)linux.alibaba.com> Cc: Jan Kara <jack(a)suse.cz> Cc: Dave Chinner <david(a)fromorbit.com> Cc: Theodore Ts'o <tytso(a)mit.edu> Cc: Vladimir Davydov <vdavydov.dev(a)gmail.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> diff --git a/mm/memory.c b/mm/memory.c index a52663c0612d..5e46836714dc 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2994,6 +2994,28 @@ static vm_fault_t __do_fault(struct vm_fault *vmf) struct vm_area_struct *vma = vmf->vma; vm_fault_t ret; + /* + * Preallocate pte before we take page_lock because this might lead to + * deadlocks for memcg reclaim which waits for pages under writeback: + * lock_page(A) + * SetPageWriteback(A) + * unlock_page(A) + * lock_page(B) + * lock_page(B) + * pte_alloc_pne + * shrink_page_list + * wait_on_page_writeback(A) + * SetPageWriteback(B) + * unlock_page(B) + * # flush A, B to clear the writeback + */ + if (pmd_none(*vmf->pmd) && !vmf->prealloc_pte) { + vmf->prealloc_pte = pte_alloc_one(vmf->vma->vm_mm); + if (!vmf->prealloc_pte) + return VM_FAULT_OOM; + smp_wmb(); /* See comment in __pte_alloc() */ + } + ret = vma->vm_ops->fault(vmf); if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE | VM_FAULT_RETRY | VM_FAULT_DONE_COW)))

5 years, 11 months

1
0
0 0

Security fixes for 4.4 - btrfs

by Ben Hutchings

I've backported fixes for several security issues involving filesystem validation in btrfs. All of these are already fixed in the later stable branches. I tested with the reproducers where available. I also checked for regressions with xfstests and didn't find any (but many tests fail with or without these changes). Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom

5 years, 11 months

2
1
0 0

[PATCH 1/2] mmc: sdhci-iproc: handle mmc_of_parse() errors during probe

by Stefan Wahren

We need to handle mmc_of_parse() errors during probe. This finally fixes the wifi regression on Raspberry Pi 3 series. In error case the wifi chip was permanently in reset because of the power sequence depending on the deferred probe of the GPIO expander. Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver") Cc: stable(a)vger.kernel.org Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> --- drivers/mmc/host/sdhci-iproc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c index 0db9905..9d12c06 100644 --- a/drivers/mmc/host/sdhci-iproc.c +++ b/drivers/mmc/host/sdhci-iproc.c @@ -296,7 +296,10 @@ static int sdhci_iproc_probe(struct platform_device *pdev) iproc_host->data = iproc_data; - mmc_of_parse(host->mmc); + ret = mmc_of_parse(host->mmc); + if (ret) + goto err; + sdhci_get_property(pdev); host->mmc->caps |= iproc_host->data->mmc_caps; -- 2.7.4

5 years, 11 months

3
4
0 0

[PATCH v2] xen: Fix x86 sched_clock() interface for xen

by Juergen Gross

Commit f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") broke Xen guest time handling across migration: [ 187.249951] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 187.251137] OOM killer disabled. [ 187.251137] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 187.252299] suspending xenstore... [ 187.266987] xen:grant_table: Grant tables using version 1 layout [18446743811.706476] OOM killer enabled. [18446743811.706478] Restarting tasks ... done. [18446743811.720505] Setting capacity to 16777216 Fix that by setting xen_sched_clock_offset at resume time to ensure a monotonic clock value. Fixes: f94c8d11699759 ("sched/clock, x86/tsc: Rework the x86 'unstable' sched_clock() interface") Cc: <stable(a)vger.kernel.org> # 4.11 Reported-by: Hans van Kranenburg <hans(a)knorrie.org> Signed-off-by: Juergen Gross <jgross(a)suse.com> --- arch/x86/xen/time.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c index 72bf446c3fee..3c1dfdf26284 100644 --- a/arch/x86/xen/time.c +++ b/arch/x86/xen/time.c @@ -379,12 +379,15 @@ static const struct pv_time_ops xen_time_ops __initconst = { }; static struct pvclock_vsyscall_time_info *xen_clock __read_mostly; +static u64 xen_clock_value_saved; void xen_save_time_memory_area(void) { struct vcpu_register_time_memory_area t; int ret; + xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset; + if (!xen_clock) return; @@ -404,7 +407,7 @@ void xen_restore_time_memory_area(void) int ret; if (!xen_clock) - return; + goto out; t.addr.v = &xen_clock->pvti; @@ -421,6 +424,11 @@ void xen_restore_time_memory_area(void) if (ret != 0) pr_notice("Cannot restore secondary vcpu_time_info (err %d)", ret); + +out: + /* Need pvclock_resume() before using xen_clocksource_read(). */ + pvclock_resume(); + xen_sched_clock_offset = xen_clocksource_read() - xen_clock_value_saved; } static void xen_setup_vsyscall_time_info(void) -- 2.16.4

5 years, 11 months

3
6
0 0

[PATCH] mmc: sdhci-esdhc-imx: fix HS400 timing issue

by BOUGH CHEN

Now tuning reset will be done when the timing is MMC_TIMING_LEGACY/ MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS. But for timing MMC_TIMING_MMC_HS, we can not do tuning reset, otherwise HS400 timing is not right. Here is the process of init HS400, first finish tuning in HS200 mode, then switch to HS mode and 8 bit DDR mode, finally switch to HS400 mode. If we do tuning reset in HS mode, this will cause HS400 mode lost the tuning setting, which will cause CRC error. This fix commit d9370424c948 ("mmc: sdhci-esdhc-imx: reset tuning circuit when power on mmc card"). Signed-off-by: Haibo Chen <haibo.chen(a)nxp.com> Cc: stable(a)vger.kernel.org # v4.12+ --- drivers/mmc/host/sdhci-esdhc-imx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c index d0d319398a54..984cc1a788cb 100644 --- a/drivers/mmc/host/sdhci-esdhc-imx.c +++ b/drivers/mmc/host/sdhci-esdhc-imx.c @@ -979,6 +979,7 @@ static void esdhc_set_uhs_signaling(struct sdhci_host *host, unsigned timing) case MMC_TIMING_UHS_SDR25: case MMC_TIMING_UHS_SDR50: case MMC_TIMING_UHS_SDR104: + case MMC_TIMING_MMC_HS: case MMC_TIMING_MMC_HS200: writel(m, host->ioaddr + ESDHC_MIX_CTRL); break; -- 2.17.1

5 years, 11 months

3
2
0 0

[PATCH 2/5] staging: erofs: fix fast symlink w/o xattr when fs xattr is on

by Gao Xiang

Currently, this will hit a BUG_ON for these symlinks as follows: - kernel message ------------[ cut here ]------------ kernel BUG at drivers/staging/erofs/xattr.c:59! SMP PTI CPU: 1 PID: 1170 Comm: getllxattr Not tainted 4.20.0-rc6+ #92 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014 RIP: 0010:init_inode_xattrs+0x22b/0x270 Code: 48 0f 45 ea f0 ff 4d 34 74 0d 41 83 4c 24 e0 01 31 c0 e9 00 fe ff ff 48 89 ef e8 e0 31 9e ff eb e9 89 e8 e9 ef fd ff ff 0f 0$ <0f> 0b 48 89 ef e8 fb f6 9c ff 48 8b 45 08 a8 01 75 24 f0 ff 4d 34 RSP: 0018:ffffa03ac026bdf8 EFLAGS: 00010246 ------------[ cut here ]------------ ... Call Trace: erofs_listxattr+0x30/0x2c0 ? selinux_inode_listxattr+0x5a/0x80 ? kmem_cache_alloc+0x33/0x170 ? security_inode_listxattr+0x27/0x40 listxattr+0xaf/0xc0 path_listxattr+0x5a/0xa0 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ... ---[ end trace 3c24b49408dc0c72 ]--- Fix it by checking ->xattr_isize in init_inode_xattrs(), and it also fixes improper return value -ENOTSUPP (it should be -ENODATA if xattr is enabled) for those inodes. Fixes: b17500a0fdba ("staging: erofs: introduce xattr & acl support") Cc: <stable(a)vger.kernel.org> # 4.19+ Reported-by: Li Guifu <bluce.liguifu(a)huawei.com> Tested-by: Li Guifu <bluce.liguifu(a)huawei.com> Reviewed-by: Chao Yu <yuchao0(a)huawei.com> Signed-off-by: Gao Xiang <gaoxiang25(a)huawei.com> --- drivers/staging/erofs/inode.c | 8 ++++---- drivers/staging/erofs/xattr.c | 25 ++++++++++++++++++++----- 2 files changed, 24 insertions(+), 9 deletions(-) diff --git a/drivers/staging/erofs/inode.c b/drivers/staging/erofs/inode.c index d7fbf5f4600f..f99954dbfdb5 100644 --- a/drivers/staging/erofs/inode.c +++ b/drivers/staging/erofs/inode.c @@ -185,16 +185,16 @@ static int fill_inode(struct inode *inode, int isdir) /* setup the new inode */ if (S_ISREG(inode->i_mode)) { #ifdef CONFIG_EROFS_FS_XATTR - if (vi->xattr_isize) - inode->i_op = &erofs_generic_xattr_iops; + inode->i_op = &erofs_generic_xattr_iops; #endif inode->i_fop = &generic_ro_fops; } else if (S_ISDIR(inode->i_mode)) { inode->i_op = #ifdef CONFIG_EROFS_FS_XATTR - vi->xattr_isize ? &erofs_dir_xattr_iops : -#endif + &erofs_dir_xattr_iops; +#else &erofs_dir_iops; +#endif inode->i_fop = &erofs_dir_fops; } else if (S_ISLNK(inode->i_mode)) { /* by default, page_get_link is used for symlink */ diff --git a/drivers/staging/erofs/xattr.c b/drivers/staging/erofs/xattr.c index 80dca6a4adbe..e30de2476fd0 100644 --- a/drivers/staging/erofs/xattr.c +++ b/drivers/staging/erofs/xattr.c @@ -56,7 +56,26 @@ static int init_inode_xattrs(struct inode *inode) return 0; vi = EROFS_V(inode); - BUG_ON(!vi->xattr_isize); + + /* + * bypass all xattr operations if ->xattr_isize is not greater than + * sizeof(struct erofs_xattr_ibody_header), in detail: + * 1) it is not enough to contain erofs_xattr_ibody_header then + * ->xattr_isize should be 0 (it means no xattr); + * 2) it is just to contain erofs_xattr_ibody_header, which is on-disk + * undefined right now (maybe use later with some new sb feature). + */ + if (vi->xattr_isize == sizeof(struct erofs_xattr_ibody_header)) { + errln("xattr_isize %d of nid %llu is not supported yet", + vi->xattr_isize, vi->nid); + return -ENOTSUPP; + } else if (vi->xattr_isize < sizeof(struct erofs_xattr_ibody_header)) { + if (unlikely(vi->xattr_isize)) { + DBG_BUGON(1); + return -EIO; /* xattr ondisk layout error */ + } + return -ENOATTR; + } sb = inode->i_sb; sbi = EROFS_SB(sb); @@ -422,7 +441,6 @@ static int erofs_xattr_generic_get(const struct xattr_handler *handler, struct dentry *unused, struct inode *inode, const char *name, void *buffer, size_t size) { - struct erofs_vnode *const vi = EROFS_V(inode); struct erofs_sb_info *const sbi = EROFS_I_SB(inode); switch (handler->flags) { @@ -440,9 +458,6 @@ static int erofs_xattr_generic_get(const struct xattr_handler *handler, return -EINVAL; } - if (!vi->xattr_isize) - return -ENOATTR; - return erofs_getxattr(inode, handler->flags, name, buffer, size); } -- 2.14.4

5 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2019