August 2020 - Linux-stable-mirror

[PATCH AUTOSEL 5.8 01/62] ALSA: hda/hdmi: Add quirk to force connectivity

by Sasha Levin

From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> [ Upstream commit cd72c317a0a11f64225b9a3f1fe503bb8c7327b5 ] HDMI on some platforms doesn't enable audio support because its Port Connectivity [31:30] is set to AC_JACK_PORT_NONE: Node 0x05 [Pin Complex] wcaps 0x40778d: 8-Channels Digital Amp-Out CP Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0b000094: OUT Detect HBR HDMI DP Pin Default 0x58560010: [N/A] Digital Out at Int HDMI Conn = Digital, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Devices: 0 Connection: 3 0x02 0x03* 0x04 For now, use a quirk to force connectivity based on SSID. If there are more platforms affected by the same issue, we can eye for a more generic solution. Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Link: https://lore.kernel.org/r/20200804155836.16252-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/pci/hda/patch_hdmi.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index cd46247988e4d..b62cd3abb8273 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -160,6 +160,7 @@ struct hdmi_spec { bool use_acomp_notifier; /* use eld_notify callback for hotplug */ bool acomp_registered; /* audio component registered in this driver */ + bool force_connect; /* force connectivity */ struct drm_audio_component_audio_ops drm_audio_ops; int (*port2pin)(struct hda_codec *, int); /* reverse port/pin mapping */ @@ -1701,7 +1702,8 @@ static int hdmi_add_pin(struct hda_codec *codec, hda_nid_t pin_nid) * all device entries on the same pin */ config = snd_hda_codec_get_pincfg(codec, pin_nid); - if (get_defcfg_connect(config) == AC_JACK_PORT_NONE) + if (get_defcfg_connect(config) == AC_JACK_PORT_NONE && + !spec->force_connect) return 0; /* @@ -1803,11 +1805,18 @@ static int hdmi_add_cvt(struct hda_codec *codec, hda_nid_t cvt_nid) return 0; } +static const struct snd_pci_quirk force_connect_list[] = { + SND_PCI_QUIRK(0x103c, 0x871a, "HP", 1), + {} +}; + static int hdmi_parse_codec(struct hda_codec *codec) { + struct hdmi_spec *spec = codec->spec; hda_nid_t start_nid; unsigned int caps; int i, nodes; + const struct snd_pci_quirk *q; nodes = snd_hda_get_sub_nodes(codec, codec->core.afg, &start_nid); if (!start_nid || nodes < 0) { @@ -1815,6 +1824,11 @@ static int hdmi_parse_codec(struct hda_codec *codec) return -EINVAL; } + q = snd_pci_quirk_lookup(codec->bus->pci, force_connect_list); + + if (q && q->value) + spec->force_connect = true; + /* * hdmi_add_pin() assumes total amount of converters to * be known, so first discover all converters -- 2.25.1

4 years, 4 months

3
66
0 0

[PATCH v3 1/2] dt-bindings: nvmem: Add syscon to Vybrid OCOTP driver

by Chris Healy

From: Chris Healy <cphealy(a)gmail.com> Add syscon compatibility with Vybrid OCOTP driver binding. This is required to access the UID. Fixes: fa8d20c8dbb77 ("ARM: dts: vfxxx: Add node corresponding to OCOTP") Cc: stable(a)vger.kernel.org Signed-off-by: Chris Healy <cphealy(a)gmail.com> --- Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt index 56ed481c3e26..5db39f399568 100644 --- a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt @@ -11,7 +11,7 @@ Required Properties: Example for Vybrid VF5xx/VF6xx: ocotp: ocotp@400a5000 { - compatible = "fsl,vf610-ocotp"; + compatible = "fsl,vf610-ocotp", "syscon"; #address-cells = <1>; #size-cells = <1>; reg = <0x400a5000 0xCF0>; -- 2.26.2

4 years, 4 months

2
3
0 0

[PATCH] MIPS: VZ: Only include loongson_regs.h for CPU_LOONGSON64

by Huacai Chen

Only Loongson64 platform has and needs loongson_regs.h, including it unconditionally will cause build errors. Fixes: 7f2a83f1c2a941ebfee5 ("KVM: MIPS: Add CPUCFG emulation for Loongson-3") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Huacai Chen <chenhc(a)lemote.com> --- arch/mips/kvm/vz.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/mips/kvm/vz.c b/arch/mips/kvm/vz.c index 3932f76..a474578 100644 --- a/arch/mips/kvm/vz.c +++ b/arch/mips/kvm/vz.c @@ -29,7 +29,9 @@ #include <linux/kvm_host.h> #include "interrupt.h" +#ifdef CONFIG_CPU_LOONGSON64 #include "loongson_regs.h" +#endif #include "trace.h" -- 2.7.0

4 years, 4 months

7
12
0 0

[merged] mm-page_alloc-fix-core-hung-in-free_pcppages_bulk.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm, page_alloc: fix core hung in free_pcppages_bulk() has been removed from the -mm tree. Its filename was mm-page_alloc-fix-core-hung-in-free_pcppages_bulk.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Charan Teja Reddy <charante(a)codeaurora.org> Subject: mm, page_alloc: fix core hung in free_pcppages_bulk() The following race is observed with the repeated online, offline and a delay between two successive online of memory blocks of movable zone. P1 P2 Online the first memory block in the movable zone. The pcp struct values are initialized to default values,i.e., pcp->high = 0 & pcp->batch = 1. Allocate the pages from the movable zone. Try to Online the second memory block in the movable zone thus it entered the online_pages() but yet to call zone_pcp_update(). This process is entered into the exit path thus it tries to release the order-0 pages to pcp lists through free_unref_page_commit(). As pcp->high = 0, pcp->count = 1 proceed to call the function free_pcppages_bulk(). Update the pcp values thus the new pcp values are like, say, pcp->high = 378, pcp->batch = 63. Read the pcp's batch value using READ_ONCE() and pass the same to free_pcppages_bulk(), pcp values passed here are, batch = 63, count = 1. Since num of pages in the pcp lists are less than ->batch, then it will stuck in while(list_empty(list)) loop with interrupts disabled thus a core hung. Avoid this by ensuring free_pcppages_bulk() is called with proper count of pcp list pages. The mentioned race is some what easily reproducible without [1] because pcp's are not updated for the first memory block online and thus there is a enough race window for P2 between alloc+free and pcp struct values update through onlining of second memory block. With [1], the race still exists but it is very narrow as we update the pcp struct values for the first memory block online itself. This is not limited to the movable zone, it could also happen in cases with the normal zone (e.g., hotplug to a node that only has DMA memory, or no other memory yet). [1]: https://patchwork.kernel.org/patch/11696389/ Link: http://lkml.kernel.org/r/1597150703-19003-1-git-send-email-charante@codeaur… Fixes: 5f8dcc21211a ("page-allocator: split per-cpu list into one-list-per-migrate-type") Signed-off-by: Charan Teja Reddy <charante(a)codeaurora.org> Acked-by: David Hildenbrand <david(a)redhat.com> Acked-by: David Rientjes <rientjes(a)google.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Vinayak Menon <vinmenon(a)codeaurora.org> Cc: <stable(a)vger.kernel.org> [2.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/mm/page_alloc.c~mm-page_alloc-fix-core-hung-in-free_pcppages_bulk +++ a/mm/page_alloc.c @@ -1302,6 +1302,11 @@ static void free_pcppages_bulk(struct zo struct page *page, *tmp; LIST_HEAD(head); + /* + * Ensure proper count is passed which otherwise would stuck in the + * below while (list_empty(list)) loop. + */ + count = min(pcp->count, count); while (count) { struct list_head *list; _ Patches currently in -mm which might be from charante(a)codeaurora.org are

4 years, 4 months

1
0
0 0

[merged] mm-include-cma-pages-in-lowmem_reserve-at-boot.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: include CMA pages in lowmem_reserve at boot has been removed from the -mm tree. Its filename was mm-include-cma-pages-in-lowmem_reserve-at-boot.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Doug Berger <opendmb(a)gmail.com> Subject: mm: include CMA pages in lowmem_reserve at boot The lowmem_reserve arrays provide a means of applying pressure against allocations from lower zones that were targeted at higher zones. Its values are a function of the number of pages managed by higher zones and are assigned by a call to the setup_per_zone_lowmem_reserve() function. The function is initially called at boot time by the function init_per_zone_wmark_min() and may be called later by accesses of the /proc/sys/vm/lowmem_reserve_ratio sysctl file. The function init_per_zone_wmark_min() was moved up from a module_init to a core_initcall to resolve a sequencing issue with khugepaged. Unfortunately this created a sequencing issue with CMA page accounting. The CMA pages are added to the managed page count of a zone when cma_init_reserved_areas() is called at boot also as a core_initcall. This makes it uncertain whether the CMA pages will be added to the managed page counts of their zones before or after the call to init_per_zone_wmark_min() as it becomes dependent on link order. With the current link order the pages are added to the managed count after the lowmem_reserve arrays are initialized at boot. This means the lowmem_reserve values at boot may be lower than the values used later if /proc/sys/vm/lowmem_reserve_ratio is accessed even if the ratio values are unchanged. In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout [ 0.000000] cma: Reserved 256 MiB at 0x0000000030000000 [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x000000002fffffff] [ 0.000000] Normal empty [ 0.000000] HighMem [mem 0x0000000030000000-0x000000003fffffff] would result in 0 lowmem_reserve for the DMA zone. This would allow userspace to deplete the DMA zone easily. Funnily enough $ cat /proc/sys/vm/lowmem_reserve_ratio would fix up the situation because it forces setup_per_zone_lowmem_reserve as a side effect. This commit breaks the link order dependency by invoking init_per_zone_wmark_min() as a postcore_initcall so that the CMA pages have the chance to be properly accounted in their zone(s) and allowing the lowmem_reserve arrays to receive consistent values. Link: http://lkml.kernel.org/r/1597423766-27849-1-git-send-email-opendmb@gmail.com Fixes: bc22af74f271 ("mm: update min_free_kbytes from khugepaged after core initialization") Signed-off-by: Doug Berger <opendmb(a)gmail.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Jason Baron <jbaron(a)akamai.com> Cc: David Rientjes <rientjes(a)google.com> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/page_alloc.c~mm-include-cma-pages-in-lowmem_reserve-at-boot +++ a/mm/page_alloc.c @@ -7888,7 +7888,7 @@ int __meminit init_per_zone_wmark_min(vo return 0; } -core_initcall(init_per_zone_wmark_min) +postcore_initcall(init_per_zone_wmark_min) /* * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so _ Patches currently in -mm which might be from opendmb(a)gmail.com are

4 years, 4 months

1
0
0 0

[merged] squashfs-avoid-bio_alloc-failure-with-1mbyte-blocks.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: squashfs: avoid bio_alloc() failure with 1Mbyte blocks has been removed from the -mm tree. Its filename was squashfs-avoid-bio_alloc-failure-with-1mbyte-blocks.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Phillip Lougher <phillip(a)squashfs.org.uk> Subject: squashfs: avoid bio_alloc() failure with 1Mbyte blocks This is a regression introduced by the patch "migrate from ll_rw_block usage to BIO". Bio_alloc() is limited to 256 pages (1 Mbyte). This can cause a failure when reading 1 Mbyte block filesystems. The problem is a datablock can be fully (or almost uncompressed), requiring 256 pages, but, because blocks are not aligned to page boundaries, it may require 257 pages to read. Bio_kmalloc() can handle 1024 pages, and so use this for the edge condition. Link: http://lkml.kernel.org/r/20200815035637.15319-1-phillip@squashfs.org.uk Fixes: 93e72b3c612a ("squashfs: migrate from ll_rw_block usage to BIO") Signed-off-by: Phillip Lougher <phillip(a)squashfs.org.uk> Reported-by: Nicolas Prochazka <nicolas.prochazka(a)gmail.com> Reported-by: Tomoatsu Shimada <shimada(a)walbrix.com> Reviewed-by: Guenter Roeck <groeck(a)chromium.org> Cc: Philippe Liard <pliard(a)google.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Adrien Schildknecht <adrien+dev(a)schischi.me> Cc: Daniel Rosenberg <drosen(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/squashfs/block.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/fs/squashfs/block.c~squashfs-avoid-bio_alloc-failure-with-1mbyte-blocks +++ a/fs/squashfs/block.c @@ -87,7 +87,11 @@ static int squashfs_bio_read(struct supe int error, i; struct bio *bio; - bio = bio_alloc(GFP_NOIO, page_count); + if (page_count <= BIO_MAX_PAGES) + bio = bio_alloc(GFP_NOIO, page_count); + else + bio = bio_kmalloc(GFP_NOIO, page_count); + if (!bio) return -ENOMEM; _ Patches currently in -mm which might be from phillip(a)squashfs.org.uk are

4 years, 4 months

1
0
0 0

[merged] uprobes-__replace_page-avoid-bug-in-munlock_vma_page.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: uprobes: __replace_page() avoid BUG in munlock_vma_page() has been removed from the -mm tree. Its filename was uprobes-__replace_page-avoid-bug-in-munlock_vma_page.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Hugh Dickins <hughd(a)google.com> Subject: uprobes: __replace_page() avoid BUG in munlock_vma_page() syzbot crashed on the VM_BUG_ON_PAGE(PageTail) in munlock_vma_page(), when called from uprobes __replace_page(). Which of many ways to fix it? Settled on not calling when PageCompound (since Head and Tail are equals in this context, PageCompound the usual check in uprobes.c, and the prior use of FOLL_SPLIT_PMD will have cleared PageMlocked already). Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2008161338360.20413@eggly.anvils Fixes: 5a52c9df62b4 ("uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT") Signed-off-by: Hugh Dickins <hughd(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Acked-by: Song Liu <songliubraving(a)fb.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Reviewed-by: Srikar Dronamraju <srikar(a)linux.vnet.ibm.com> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> [5.4+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/events/uprobes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/events/uprobes.c~uprobes-__replace_page-avoid-bug-in-munlock_vma_page +++ a/kernel/events/uprobes.c @@ -205,7 +205,7 @@ static int __replace_page(struct vm_area try_to_free_swap(old_page); page_vma_mapped_walk_done(&pvmw); - if (vma->vm_flags & VM_LOCKED) + if ((vma->vm_flags & VM_LOCKED) && !PageCompound(old_page)) munlock_vma_page(old_page); put_page(old_page); _ Patches currently in -mm which might be from hughd(a)google.com are

4 years, 4 months

1
0
0 0

[merged] kernel-relayc-fix-memleak-on-destroy-relay-channel.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: kernel/relay.c: fix memleak on destroy relay channel has been removed from the -mm tree. Its filename was kernel-relayc-fix-memleak-on-destroy-relay-channel.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Wei Yongjun <weiyongjun1(a)huawei.com> Subject: kernel/relay.c: fix memleak on destroy relay channel kmemleak report memory leak as follows: unreferenced object 0x607ee4e5f948 (size 8): comm "syz-executor.1", pid 2098, jiffies 4295031601 (age 288.468s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [<00000000ca1de2fa>] relay_open kernel/relay.c:583 [inline] [<00000000ca1de2fa>] relay_open+0xb6/0x970 kernel/relay.c:563 [<0000000038ae5a4b>] do_blk_trace_setup+0x4a8/0xb20 kernel/trace/blktrace.c:557 [<00000000d5e778e9>] __blk_trace_setup+0xb6/0x150 kernel/trace/blktrace.c:597 [<0000000038fdf803>] blk_trace_ioctl+0x146/0x280 kernel/trace/blktrace.c:738 [<00000000ce25a0ca>] blkdev_ioctl+0xb2/0x6a0 block/ioctl.c:613 [<00000000579e47e0>] block_ioctl+0xe5/0x120 fs/block_dev.c:1871 [<00000000b1588c11>] vfs_ioctl fs/ioctl.c:48 [inline] [<00000000b1588c11>] __do_sys_ioctl fs/ioctl.c:753 [inline] [<00000000b1588c11>] __se_sys_ioctl fs/ioctl.c:739 [inline] [<00000000b1588c11>] __x64_sys_ioctl+0x170/0x1ce fs/ioctl.c:739 [<0000000088fc9942>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<000000004f6dd57a>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 'chan->buf' is malloced in relay_open() by alloc_percpu() but not free while destroy the relay channel. Fix it by adding free_percpu() before return from relay_destroy_channel(). Link: http://lkml.kernel.org/r/20200817122826.48518-1-weiyongjun1@huawei.com Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Reported-by: Hulk Robot <hulkci(a)huawei.com> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Michael Ellerman <mpe(a)ellerman.id.au> Cc: David Rientjes <rientjes(a)google.com> Cc: Michel Lespinasse <walken(a)google.com> Cc: Daniel Axtens <dja(a)axtens.net> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Akash Goel <akash.goel(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/relay.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/relay.c~kernel-relayc-fix-memleak-on-destroy-relay-channel +++ a/kernel/relay.c @@ -197,6 +197,7 @@ free_buf: static void relay_destroy_channel(struct kref *kref) { struct rchan *chan = container_of(kref, struct rchan, kref); + free_percpu(chan->buf); kfree(chan); } _ Patches currently in -mm which might be from weiyongjun1(a)huawei.com are

4 years, 4 months

1
0
0 0

[merged] romfs-fix-uninitialized-memory-leak-in-romfs_dev_read.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: romfs: fix uninitialized memory leak in romfs_dev_read() has been removed from the -mm tree. Its filename was romfs-fix-uninitialized-memory-leak-in-romfs_dev_read.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Jann Horn <jannh(a)google.com> Subject: romfs: fix uninitialized memory leak in romfs_dev_read() romfs has a superblock field that limits the size of the filesystem; data beyond that limit is never accessed. romfs_dev_read() fetches a caller-supplied number of bytes from the backing device. It returns 0 on success or an error code on failure; therefore, its API can't represent short reads, it's all-or-nothing. However, when romfs_dev_read() detects that the requested operation would cross the filesystem size limit, it currently silently truncates the requested number of bytes. This e.g. means that when the content of a file with size 0x1000 starts one byte before the filesystem size limit, ->readpage() will only fill a single byte of the supplied page while leaving the rest uninitialized, leaking that uninitialized memory to userspace. Fix it by returning an error code instead of truncating the read when the requested read operation would go beyond the end of the filesystem. Link: http://lkml.kernel.org/r/20200818013202.2246365-1-jannh@google.com Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly") Signed-off-by: Jann Horn <jannh(a)google.com> Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: David Howells <dhowells(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/romfs/storage.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) --- a/fs/romfs/storage.c~romfs-fix-uninitialized-memory-leak-in-romfs_dev_read +++ a/fs/romfs/storage.c @@ -217,10 +217,8 @@ int romfs_dev_read(struct super_block *s size_t limit; limit = romfs_maxsize(sb); - if (pos >= limit) + if (pos >= limit || buflen > limit - pos) return -EIO; - if (buflen > limit - pos) - buflen = limit - pos; #ifdef CONFIG_ROMFS_ON_MTD if (sb->s_mtd) _ Patches currently in -mm which might be from jannh(a)google.com are

4 years, 4 months

1
0
0 0

[merged] mm-vunmap-add-cond_resched-in-vunmap_pmd_range.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/vunmap: add cond_resched() in vunmap_pmd_range has been removed from the -mm tree. Its filename was mm-vunmap-add-cond_resched-in-vunmap_pmd_range.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: "Aneesh Kumar K.V" <aneesh.kumar(a)linux.ibm.com> Subject: mm/vunmap: add cond_resched() in vunmap_pmd_range Like zap_pte_range add cond_resched so that we can avoid softlockups as reported below. On non-preemptible kernel with large I/O map region (like the one we get when using persistent memory with sector mode), an unmap of the namespace can report below softlockups. 22724.027334] watchdog: BUG: soft lockup - CPU#49 stuck for 23s! [ndctl:50777] NIP [c0000000000dc224] plpar_hcall+0x38/0x58 LR [c0000000000d8898] pSeries_lpar_hpte_invalidate+0x68/0xb0 Call Trace: [c0000004e87a7780] [c0000004fb197c00] 0xc0000004fb197c00 (unreliable) [c0000004e87a7810] [c00000000007f4e4] flush_hash_page+0x114/0x200 [c0000004e87a7890] [c0000000000833cc] hpte_need_flush+0x2dc/0x540 [c0000004e87a7950] [c0000000003f5798] vunmap_page_range+0x538/0x6f0 [c0000004e87a7a70] [c0000000003f76d0] free_unmap_vmap_area+0x30/0x70 [c0000004e87a7aa0] [c0000000003f7a6c] remove_vm_area+0xfc/0x140 [c0000004e87a7ad0] [c0000000003f7dd8] __vunmap+0x68/0x270 [c0000004e87a7b50] [c000000000079de4] __iounmap.part.0+0x34/0x60 [c0000004e87a7bb0] [c000000000376394] memunmap+0x54/0x70 [c0000004e87a7bd0] [c000000000881d7c] release_nodes+0x28c/0x300 [c0000004e87a7c40] [c00000000087a65c] device_release_driver_internal+0x16c/0x280 [c0000004e87a7c80] [c000000000876fc4] unbind_store+0x124/0x170 [c0000004e87a7cd0] [c000000000875be4] drv_attr_store+0x44/0x60 [c0000004e87a7cf0] [c00000000057c734] sysfs_kf_write+0x64/0x90 [c0000004e87a7d10] [c00000000057bc10] kernfs_fop_write+0x1b0/0x290 [c0000004e87a7d60] [c000000000488e6c] __vfs_write+0x3c/0x70 [c0000004e87a7d80] [c00000000048c868] vfs_write+0xd8/0x260 [c0000004e87a7dd0] [c00000000048ccac] ksys_write+0xdc/0x130 [c0000004e87a7e20] [c00000000000b588] system_call+0x5c/0x70 Link: http://lkml.kernel.org/r/20200807075933.310240-1-aneesh.kumar@linux.ibm.com Signed-off-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.ibm.com> Reported-by: Harish Sriram <harish(a)linux.ibm.com> Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmalloc.c | 2 ++ 1 file changed, 2 insertions(+) --- a/mm/vmalloc.c~mm-vunmap-add-cond_resched-in-vunmap_pmd_range +++ a/mm/vmalloc.c @@ -104,6 +104,8 @@ static void vunmap_pmd_range(pud_t *pud, if (pmd_none_or_clear_bad(pmd)) continue; vunmap_pte_range(pmd, addr, next, mask); + + cond_resched(); } while (pmd++, addr = next, addr != end); } _ Patches currently in -mm which might be from aneesh.kumar(a)linux.ibm.com are

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2020