- Linux-stable-mirror - lists.linaro.org

[PATCH] libata/ahci: Fix PCS quirk application

by Dan Williams

Commit c312ef176399 "libata/ahci: Drop PCS quirk for Denverton and beyond" got the polarity wrong on the check for which board-ids should have the quirk applied. The board type board_ahci_pcs7 is defined at the end of the list such that "pcs7" boards can be special cased in the future if they need the quirk. All prior Intel board ids "< board_ahci_pcs7" should proceed with applying the quirk. Reported-by: Andreas Friedrich <afrie(a)gmx.net> Reported-by: Stephen Douthit <stephend(a)silicom-usa.com> Fixes: c312ef176399 ("libata/ahci: Drop PCS quirk for Denverton and beyond") Cc: <stable(a)vger.kernel.org> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- drivers/ata/ahci.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index dd92faf197d5..05c2b32dcc4d 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1600,7 +1600,9 @@ static void ahci_intel_pcs_quirk(struct pci_dev *pdev, struct ahci_host_priv *hp */ if (!id || id->vendor != PCI_VENDOR_ID_INTEL) return; - if (((enum board_ids) id->driver_data) < board_ahci_pcs7) + + /* Skip applying the quirk on Denverton and beyond */ + if (((enum board_ids) id->driver_data) >= board_ahci_pcs7) return; /*

5 years, 9 months

3
3
0 0

+ zram-fix-race-between-backing_dev_show-and-backing_dev_store.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: zram: fix race between backing_dev_show and backing_dev_store has been added to the -mm tree. Its filename is zram-fix-race-between-backing_dev_show-and-backing_dev_store.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/zram-fix-race-between-backing_dev_… and later at http://ozlabs.org/~akpm/mmotm/broken-out/zram-fix-race-between-backing_dev_… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Chenwandun <chenwandun(a)huawei.com> Subject: zram: fix race between backing_dev_show and backing_dev_store CPU0: CPU1: backing_dev_show backing_dev_store ...... ...... file = zram->backing_dev; down_read(&zram->init_lock); down_read(&zram->init_init_lock) file_path(file, ...); zram->backing_dev = backing_dev; up_read(&zram->init_lock); up_read(&zram->init_lock); gets the value of zram->backing_dev too early in backing_dev_show, which resultin the value being NULL at the beginning, and not NULL later. backtrace: [<ffffff8570e0f3ec>] d_path+0xcc/0x174 [<ffffff8570decd90>] file_path+0x10/0x18 [<ffffff85712f7630>] backing_dev_show+0x40/0xb4 [<ffffff85712c776c>] dev_attr_show+0x20/0x54 [<ffffff8570e835e4>] sysfs_kf_seq_show+0x9c/0x10c [<ffffff8570e82b98>] kernfs_seq_show+0x28/0x30 [<ffffff8570e1c580>] seq_read+0x184/0x488 [<ffffff8570e81ec4>] kernfs_fop_read+0x5c/0x1a4 [<ffffff8570dee0fc>] __vfs_read+0x44/0x128 [<ffffff8570dee310>] vfs_read+0xa0/0x138 [<ffffff8570dee860>] SyS_read+0x54/0xb4 Link: http://lkml.kernel.org/r/1571046839-16814-1-git-send-email-chenwandun@huawe… Signed-off-by: Chenwandun <chenwandun(a)huawei.com> Acked-by: Minchan Kim <minchan(a)kernel.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work(a)gmail.com> Cc: Jens Axboe <axboe(a)kernel.dk> Cc: <stable(a)vger.kernel.org> [4.14+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/block/zram/zram_drv.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/block/zram/zram_drv.c~zram-fix-race-between-backing_dev_show-and-backing_dev_store +++ a/drivers/block/zram/zram_drv.c @@ -413,13 +413,14 @@ static void reset_bdev(struct zram *zram static ssize_t backing_dev_show(struct device *dev, struct device_attribute *attr, char *buf) { + struct file *file; struct zram *zram = dev_to_zram(dev); - struct file *file = zram->backing_dev; char *p; ssize_t ret; down_read(&zram->init_lock); - if (!zram->backing_dev) { + file = zram->backing_dev; + if (!file) { memcpy(buf, "none\n", 5); up_read(&zram->init_lock); return 5; _ Patches currently in -mm which might be from chenwandun(a)huawei.com are zram-fix-race-between-backing_dev_show-and-backing_dev_store.patch

5 years, 9 months

1
0
0 0

Re: [PATCH] zram: fix race between backing_dev_show and backing_dev_store

by Minchan Kim

On Mon, Oct 14, 2019 at 05:53:59PM +0800, Chen Wandun wrote: > From: Chenwandun <chenwandun(a)huawei.com> > > CPU0: CPU1: > backing_dev_show backing_dev_store > ...... ...... > file = zram->backing_dev; > down_read(&zram->init_lock); down_read(&zram->init_init_lock) > file_path(file, ...); zram->backing_dev = backing_dev; > up_read(&zram->init_lock); up_read(&zram->init_lock); > > get the value of zram->backing_dev too early in backing_dev_show, > that will result the value may be NULL at the begining, and not > NULL later. > > backtrace: > [<ffffff8570e0f3ec>] d_path+0xcc/0x174 > [<ffffff8570decd90>] file_path+0x10/0x18 > [<ffffff85712f7630>] backing_dev_show+0x40/0xb4 > [<ffffff85712c776c>] dev_attr_show+0x20/0x54 > [<ffffff8570e835e4>] sysfs_kf_seq_show+0x9c/0x10c > [<ffffff8570e82b98>] kernfs_seq_show+0x28/0x30 > [<ffffff8570e1c580>] seq_read+0x184/0x488 > [<ffffff8570e81ec4>] kernfs_fop_read+0x5c/0x1a4 > [<ffffff8570dee0fc>] __vfs_read+0x44/0x128 > [<ffffff8570dee310>] vfs_read+0xa0/0x138 > [<ffffff8570dee860>] SyS_read+0x54/0xb4 > > Signed-off-by: Chenwandun <chenwandun(a)huawei.com> It should be stable material. Cc: <stable(a)vger.kernel.org> [4.14+] Acked-by: Minchan Kim <minchan(a)kernel.org> Thanks!

5 years, 9 months

1
0
0 0

Re: [git:media_tree/master] media: usbvision: Fix races among open, close, and disconnect

by Alan Stern

On Mon, 14 Oct 2019, Sasha Levin wrote: > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v5.3.5, v5.2.20, v4.19.78, v4.14.148, v4.9.196, v4.4.196. > > v5.3.5: Build OK! > v5.2.20: Build OK! > v4.19.78: Build OK! > v4.14.148: Build OK! > v4.9.196: Build OK! > v4.4.196: Failed to apply! Possible dependencies: > Unable to calculate > > > NOTE: The patch will not be queued to stable trees until it is upstream. > > How should we proceed with this patch? As far as I'm concerned, it's probably not worth the effort of backporting this to 4.4.y. Alan Stern

5 years, 9 months

1
0
0 0

+ ocfs2-fix-panic-due-to-ocfs2_wq-is-null.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: ocfs2: fix panic due to ocfs2_wq is null has been added to the -mm tree. Its filename is ocfs2-fix-panic-due-to-ocfs2_wq-is-null.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/ocfs2-fix-panic-due-to-ocfs2_wq-is… and later at http://ozlabs.org/~akpm/mmotm/broken-out/ocfs2-fix-panic-due-to-ocfs2_wq-is… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Yi Li <yilikernel(a)gmail.com> Subject: ocfs2: fix panic due to ocfs2_wq is null mount.ocfs2 failed when reading ocfs2 filesystem superblock encounters an error. ocfs2_initialize_super() returns before allocating ocfs2_wq. ocfs2_dismount_volume() triggers the following panic. Oct 15 16:09:27 cnwarekv-205120 kernel: On-disk corruption discovered.Please run fsck.ocfs2 once the filesystem is unmounted. Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_read_locked_inode:537 ERROR: status = -30 Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_init_global_system_inodes:458 ERROR: status = -30 Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_init_global_system_inodes:491 ERROR: status = -30 Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_initialize_super:2313 ERROR: status = -30 Oct 15 16:09:27 cnwarekv-205120 kernel: (mount.ocfs2,22804,44): ocfs2_fill_super:1033 ERROR: status = -30 ------------[ cut here ]------------ Oops: 0002 [#1] SMP NOPTI Modules linked in: ocfs2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs sunrpc ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 ovmapi ppdev parport_pc parport fb_sys_fops sysimgblt sysfillrect syscopyarea acpi_cpufreq pcspkr i2c_piix4 i2c_core sg ext4 jbd2 mbcache2 sr_mod cdrom CPU: 1 PID: 11753 Comm: mount.ocfs2 Tainted: G E 4.14.148-200.ckv.x86_64 #1 Hardware name: Sugon H320-G30/35N16-US, BIOS 0SSDX017 12/21/2018 task: ffff967af0520000 task.stack: ffffa5f05484000 RIP: 0010:mutex_lock+0x19/0x20 Call Trace: flush_workqueue+0x81/0x460 ocfs2_shutdown_local_alloc+0x47/0x440 [ocfs2] ocfs2_dismount_volume+0x84/0x400 [ocfs2] ocfs2_fill_super+0xa4/0x1270 [ocfs2] ? ocfs2_initialize_super.isa.211+0xf20/0xf20 [ocfs2] mount_bdev+0x17f/0x1c0 mount_fs+0x3a/0x160 Link: http://lkml.kernel.org/r/1571139611-24107-1-git-send-email-yili@winhong.com Signed-off-by: Yi Li <yilikernel(a)gmail.com> Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/ocfs2/journal.c | 3 ++- fs/ocfs2/localalloc.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/fs/ocfs2/journal.c~ocfs2-fix-panic-due-to-ocfs2_wq-is-null +++ a/fs/ocfs2/journal.c @@ -217,7 +217,8 @@ void ocfs2_recovery_exit(struct ocfs2_su /* At this point, we know that no more recovery threads can be * launched, so wait for any recovery completion work to * complete. */ - flush_workqueue(osb->ocfs2_wq); + if (osb->ocfs2_wq) + flush_workqueue(osb->ocfs2_wq); /* * Now that recovery is shut down, and the osb is about to be --- a/fs/ocfs2/localalloc.c~ocfs2-fix-panic-due-to-ocfs2_wq-is-null +++ a/fs/ocfs2/localalloc.c @@ -377,7 +377,8 @@ void ocfs2_shutdown_local_alloc(struct o struct ocfs2_dinode *alloc = NULL; cancel_delayed_work(&osb->la_enable_wq); - flush_workqueue(osb->ocfs2_wq); + if (osb->ocfs2_wq) + flush_workqueue(osb->ocfs2_wq); if (osb->local_alloc_state == OCFS2_LA_UNUSED) goto out; _ Patches currently in -mm which might be from yilikernel(a)gmail.com are ocfs2-fix-panic-due-to-ocfs2_wq-is-null.patch

5 years, 9 months

1
0
0 0

+ hugetlbfs-dont-access-uninitialized-memmaps-in-pfn_range_valid_gigantic.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: hugetlbfs: don't access uninitialized memmaps in pfn_range_valid_gigantic() has been added to the -mm tree. Its filename is hugetlbfs-dont-access-uninitialized-memmaps-in-pfn_range_valid_gigantic.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/hugetlbfs-dont-access-uninitialize… and later at http://ozlabs.org/~akpm/mmotm/broken-out/hugetlbfs-dont-access-uninitialize… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: David Hildenbrand <david(a)redhat.com> Subject: hugetlbfs: don't access uninitialized memmaps in pfn_range_valid_gigantic() Uninitialized memmaps contain garbage and in the worst case trigger kernel BUGs, especially with CONFIG_PAGE_POISONING. They should not get touched. Let's make sure that we only consider online memory (managed by the buddy) that has initialized memmaps. ZONE_DEVICE is not applicable. page_zone() will call page_to_nid(), which will trigger VM_BUG_ON_PGFLAGS(PagePoisoned(page), page) with CONFIG_PAGE_POISONING and CONFIG_DEBUG_VM_PGFLAGS when called on uninitialized memmaps. This can be the case when an offline memory block (e.g., never onlined) is spanned by a zone. Note: As explained by Michal in [1], alloc_contig_range() will verify the range. So it boils down to the wrong access in this function. [1] http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz Link: http://lkml.kernel.org/r/20191015120717.4858-1-david@redhat.com Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") [visible after d0dc12e86b319] Signed-off-by: David Hildenbrand <david(a)redhat.com> Reported-by: Michal Hocko <mhocko(a)kernel.org> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: <stable(a)vger.kernel.org> [4.13+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/hugetlb.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) --- a/mm/hugetlb.c~hugetlbfs-dont-access-uninitialized-memmaps-in-pfn_range_valid_gigantic +++ a/mm/hugetlb.c @@ -1084,11 +1084,10 @@ static bool pfn_range_valid_gigantic(str struct page *page; for (i = start_pfn; i < end_pfn; i++) { - if (!pfn_valid(i)) + page = pfn_to_online_page(i); + if (!page) return false; - page = pfn_to_page(i); - if (page_zone(page) != z) return false; _ Patches currently in -mm which might be from david(a)redhat.com are drivers-base-memoryc-dont-access-uninitialized-memmaps-in-soft_offline_page_store.patch mm-dont-access-uninitialized-memmaps-in-fs-proc-pagec.patch mm-memory-failurec-dont-access-uninitialized-memmaps-in-memory_failure.patch mm-memory_hotplug-dont-access-uninitialized-memmaps-in-shrink_pgdat_span.patch hugetlbfs-dont-access-uninitialized-memmaps-in-pfn_range_valid_gigantic.patch mm-memory_hotplug-export-generic_online_page.patch hv_balloon-use-generic_online_page.patch mm-memory_hotplug-remove-__online_page_free-and-__online_page_increment_counters.patch mm-memory_hotplug-dont-access-uninitialized-memmaps-in-shrink_zone_span.patch mm-memory_hotplug-shrink-zones-when-offlining-memory.patch mm-memory_hotplug-poison-memmap-in-remove_pfn_range_from_zone.patch mm-memory_hotplug-we-always-have-a-zone-in-find_smallestbiggest_section_pfn.patch mm-memory_hotplug-dont-check-for-all-holes-in-shrink_zone_span.patch mm-memory_hotplug-drop-local-variables-in-shrink_zone_span.patch mm-memory_hotplug-cleanup-__remove_pages.patch

5 years, 9 months

1
0
0 0

[PATCH v1] hugetlbfs: don't access uninitialized memmaps in pfn_range_valid_gigantic()

by David Hildenbrand

Uninitialized memmaps contain garbage and in the worst case trigger kernel BUGs, especially with CONFIG_PAGE_POISONING. They should not get touched. Let's make sure that we only consider online memory (managed by the buddy) that has initialized memmaps. ZONE_DEVICE is not applicable. page_zone() will call page_to_nid(), which will trigger VM_BUG_ON_PGFLAGS(PagePoisoned(page), page) with CONFIG_PAGE_POISONING and CONFIG_DEBUG_VM_PGFLAGS when called on uninitialized memmaps. This can be the case when an offline memory block (e.g., never onlined) is spanned by a zone. Note: As explained by Michal in [1], alloc_contig_range() will verify the range. So it boils down to the wrong access in this function. [1] http://lkml.kernel.org/r/20180423000943.GO17484@dhcp22.suse.cz Reported-by: Michal Hocko <mhocko(a)kernel.org> Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online") # visible after d0dc12e86b319 Cc: stable(a)vger.kernel.org # v4.13+ Cc: Anshuman Khandual <anshuman.khandual(a)arm.com> Cc: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Michal Hocko <mhocko(a)kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- mm/hugetlb.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index ef37c85423a5..b45a95363a84 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1084,11 +1084,10 @@ static bool pfn_range_valid_gigantic(struct zone *z, struct page *page; for (i = start_pfn; i < end_pfn; i++) { - if (!pfn_valid(i)) + page = pfn_to_online_page(i); + if (!page) return false; - page = pfn_to_page(i); - if (page_zone(page) != z) return false; -- 2.21.0

5 years, 9 months

3
2
0 0

patch "USB: usblp: fix use-after-free on disconnect" added to usb-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: usblp: fix use-after-free on disconnect to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 7a759197974894213621aa65f0571b51904733d6 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Tue, 15 Oct 2019 19:55:22 +0200 Subject: USB: usblp: fix use-after-free on disconnect A recent commit addressing a runtime PM use-count regression, introduced a use-after-free by not making sure we held a reference to the struct usb_interface for the lifetime of the driver data. Fixes: 9a31535859bf ("USB: usblp: fix runtime PM after driver unbind") Cc: stable <stable(a)vger.kernel.org> Reported-by: syzbot+cd24df4d075c319ebfc5(a)syzkaller.appspotmail.com Signed-off-by: Johan Hovold <johan(a)kernel.org> Link: https://lore.kernel.org/r/20191015175522.18490-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/class/usblp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/usb/class/usblp.c b/drivers/usb/class/usblp.c index fb8bd60c83f4..0d8e3f3804a3 100644 --- a/drivers/usb/class/usblp.c +++ b/drivers/usb/class/usblp.c @@ -445,6 +445,7 @@ static void usblp_cleanup(struct usblp *usblp) kfree(usblp->readbuf); kfree(usblp->device_id_string); kfree(usblp->statusbuf); + usb_put_intf(usblp->intf); kfree(usblp); } @@ -1113,7 +1114,7 @@ static int usblp_probe(struct usb_interface *intf, init_waitqueue_head(&usblp->wwait); init_usb_anchor(&usblp->urbs); usblp->ifnum = intf->cur_altsetting->desc.bInterfaceNumber; - usblp->intf = intf; + usblp->intf = usb_get_intf(intf); /* Malloc device ID string buffer to the largest expected length, * since we can re-query it on an ioctl and a dynamic string @@ -1198,6 +1199,7 @@ static int usblp_probe(struct usb_interface *intf, kfree(usblp->readbuf); kfree(usblp->statusbuf); kfree(usblp->device_id_string); + usb_put_intf(usblp->intf); kfree(usblp); abort_ret: return retval; -- 2.23.0

5 years, 9 months

1
0
0 0

[merged] mm-memory-failure-poison-read-receives-sigkill-instead-of-sigbus-if-mmaped-more-than-once.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/memory-failure: poison read receives SIGKILL instead of SIGBUS if mmaped more than once has been removed from the -mm tree. Its filename was mm-memory-failure-poison-read-receives-sigkill-instead-of-sigbus-if-mmaped-more-than-once.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Jane Chu <jane.chu(a)oracle.com> Subject: mm/memory-failure: poison read receives SIGKILL instead of SIGBUS if mmaped more than once Mmap /dev/dax more than once, then read the poison location using address from one of the mappings. The other mappings due to not having the page mapped in will cause SIGKILLs delivered to the process. SIGKILL succeeds over SIGBUS, so user process loses the opportunity to handle the UE. Although one may add MAP_POPULATE to mmap(2) to work around the issue, MAP_POPULATE makes mapping 128GB of pmem several magnitudes slower, so isn't always an option. Details - ndctl inject-error --block=10 --count=1 namespace6.0 ./read_poison -x dax6.0 -o 5120 -m 2 mmaped address 0x7f5bb6600000 mmaped address 0x7f3cf3600000 doing local read at address 0x7f3cf3601400 Killed Console messages in instrumented kernel - mce: Uncorrected hardware memory error in user-access at edbe201400 Memory failure: tk->addr = 7f5bb6601000 Memory failure: address edbe201: call dev_pagemap_mapping_shift dev_pagemap_mapping_shift: page edbe201: no PUD Memory failure: tk->size_shift == 0 Memory failure: Unable to find user space address edbe201 in read_poison Memory failure: tk->addr = 7f3cf3601000 Memory failure: address edbe201: call dev_pagemap_mapping_shift Memory failure: tk->size_shift = 21 Memory failure: 0xedbe201: forcibly killing read_poison:22434 because of failure to unmap corrupted page => to deliver SIGKILL Memory failure: 0xedbe201: Killing read_poison:22434 due to hardware memory corruption => to deliver SIGBUS Link: http://lkml.kernel.org/r/1565112345-28754-3-git-send-email-jane.chu@oracle.… Signed-off-by: Jane Chu <jane.chu(a)oracle.com> Suggested-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Acked-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) --- a/mm/memory-failure.c~mm-memory-failure-poison-read-receives-sigkill-instead-of-sigbus-if-mmaped-more-than-once +++ a/mm/memory-failure.c @@ -199,7 +199,6 @@ struct to_kill { struct task_struct *tsk; unsigned long addr; short size_shift; - char addr_valid; }; /* @@ -324,22 +323,27 @@ static void add_to_kill(struct task_stru } } tk->addr = page_address_in_vma(p, vma); - tk->addr_valid = 1; if (is_zone_device_page(p)) tk->size_shift = dev_pagemap_mapping_shift(p, vma); else tk->size_shift = compound_order(compound_head(p)) + PAGE_SHIFT; /* - * In theory we don't have to kill when the page was - * munmaped. But it could be also a mremap. Since that's - * likely very rare kill anyways just out of paranoia, but use - * a SIGKILL because the error is not contained anymore. + * Send SIGKILL if "tk->addr == -EFAULT". Also, as + * "tk->size_shift" is always non-zero for !is_zone_device_page(), + * so "tk->size_shift == 0" effectively checks no mapping on + * ZONE_DEVICE. Indeed, when a devdax page is mmapped N times + * to a process' address space, it's possible not all N VMAs + * contain mappings for the page, but at least one VMA does. + * Only deliver SIGBUS with payload derived from the VMA that + * has a mapping for the page. */ - if (tk->addr == -EFAULT || tk->size_shift == 0) { + if (tk->addr == -EFAULT) { pr_info("Memory failure: Unable to find user space address %lx in %s\n", page_to_pfn(p), tsk->comm); - tk->addr_valid = 0; + } else if (tk->size_shift == 0) { + kfree(tk); + return; } get_task_struct(tsk); tk->tsk = tsk; @@ -366,7 +370,7 @@ static void kill_procs(struct list_head * make sure the process doesn't catch the * signal and then access the memory. Just kill it. */ - if (fail || tk->addr_valid == 0) { + if (fail || tk->addr == -EFAULT) { pr_err("Memory failure: %#lx: forcibly killing %s:%d because of failure to unmap corrupted page\n", pfn, tk->tsk->comm, tk->tsk->pid); do_send_sig_info(SIGKILL, SEND_SIG_PRIV, _ Patches currently in -mm which might be from jane.chu(a)oracle.com are mm-memory-failurec-clean-up-around-tk-pre-allocation.patch

5 years, 9 months

1
0
0 0

[merged] mm-compaction-fix-wrong-pfn-handling-in-__reset_isolation_pfn.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, compaction: fix wrong pfn handling in __reset_isolation_pfn() has been removed from the -mm tree. Its filename was mm-compaction-fix-wrong-pfn-handling-in-__reset_isolation_pfn.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Vlastimil Babka <vbabka(a)suse.cz> Subject: mm, compaction: fix wrong pfn handling in __reset_isolation_pfn() Florian and Dave reported [1] a NULL pointer dereference in __reset_isolation_pfn(). While the exact cause is unclear, staring at the code revealed two bugs, which might be related. One bug is that if zone starts in the middle of pageblock, block_page might correspond to different pfn than block_pfn, and then the pfn_valid_within() checks will check different pfn's than those accessed via struct page. This might result in acessing an unitialized page in CONFIG_HOLES_IN_ZONE configs. The other bug is that end_page refers to the first page of next pageblock and not last page of current pageblock. The online and valid check is then wrong and with sections, the while (page < end_page) loop might wander off actual struct page arrays. [1] https://lore.kernel.org/linux-xfs/87o8z1fvqu.fsf@mid.deneb.enyo.de/ Link: http://lkml.kernel.org/r/20191008152915.24704-1-vbabka@suse.cz Fixes: 6b0868c820ff ("mm/compaction.c: correct zone boundary handling when resetting pageblock skip hints") Signed-off-by: Vlastimil Babka <vbabka(a)suse.cz> Reported-by: Florian Weimer <fw(a)deneb.enyo.de> Reported-by: Dave Chinner <david(a)fromorbit.com> Acked-by: Mel Gorman <mgorman(a)techsingularity.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/compaction.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/mm/compaction.c~mm-compaction-fix-wrong-pfn-handling-in-__reset_isolation_pfn +++ a/mm/compaction.c @@ -270,14 +270,15 @@ __reset_isolation_pfn(struct zone *zone, /* Ensure the start of the pageblock or zone is online and valid */ block_pfn = pageblock_start_pfn(pfn); - block_page = pfn_to_online_page(max(block_pfn, zone->zone_start_pfn)); + block_pfn = max(block_pfn, zone->zone_start_pfn); + block_page = pfn_to_online_page(block_pfn); if (block_page) { page = block_page; pfn = block_pfn; } /* Ensure the end of the pageblock or zone is online and valid */ - block_pfn += pageblock_nr_pages; + block_pfn = pageblock_end_pfn(pfn) - 1; block_pfn = min(block_pfn, zone_end_pfn(zone) - 1); end_page = pfn_to_online_page(block_pfn); if (!end_page) @@ -303,7 +304,7 @@ __reset_isolation_pfn(struct zone *zone, page += (1 << PAGE_ALLOC_COSTLY_ORDER); pfn += (1 << PAGE_ALLOC_COSTLY_ORDER); - } while (page < end_page); + } while (page <= end_page); return false; } _ Patches currently in -mm which might be from vbabka(a)suse.cz are

5 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror