March 2025 - Linux-stable-mirror

queue-5.10: Panic on shutdown at platform_shutdown+0x9

by Chuck Lever

Hi - For the past 3-4 days, NFSD CI runs on queue-5.10.y have been failing. I looked into it today, and the test guest fails to reboot because it panics during a reboot shutdown: [ 146.793087] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 146.793918] #PF: supervisor read access in kernel mode [ 146.794544] #PF: error_code(0x0000) - not-present page [ 146.795172] PGD 3d5c14067 P4D 3d5c15067 PUD 3d5c17067 PMD 0 [ 146.795865] Oops: 0000 [#1] SMP NOPTI [ 146.796326] CPU: 3 PID: 1 Comm: systemd-shutdow Not tainted 5.10.234-g99349f441fe1 #1 [ 146.797256] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 146.798267] RIP: 0010:platform_shutdown+0x9/0x20 [ 146.798838] Code: b7 46 08 c3 cc cc cc cc 31 c0 83 bf a8 02 00 00 ff 75 ec c3 cc cc cc cc 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 68 <48> 8b 40 e8 48 85 c0 74 09 48 83 ef 10 ff e0 0f 1f 00 c3 cc cc cc [ 146.801012] RSP: 0018:ff7f86f440013de0 EFLAGS: 00010246 [ 146.801651] RAX: 0000000000000000 RBX: ff4f0637469df418 RCX: 0000000000000000 [ 146.802500] RDX: 0000000000000001 RSI: ff4f0637469df418 RDI: ff4f0637469df410 [ 146.803350] RBP: ffffffffb2e79220 R08: ff4f0637469dd808 R09: ffffffffb2c5c698 [ 146.804203] R10: 0000000000000000 R11: 0000000000000000 R12: ff4f0637469df410 [ 146.805059] R13: ff4f0637469df490 R14: 00000000fee1dead R15: 0000000000000000 [ 146.805909] FS: 00007f4e7ecc6b80(0000) GS:ff4f063aafd80000(0000) knlGS:0000000000000000 [ 146.806866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 146.807558] CR2: ffffffffffffffe8 CR3: 000000010ecb2001 CR4: 0000000000771ee0 [ 146.808412] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 146.809262] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 146.810109] PKRU: 55555554 [ 146.810460] Call Trace: [ 146.810791] ? __die_body.cold+0x1a/0x1f [ 146.811282] ? no_context.constprop.0+0xf8/0x2f0 [ 146.811854] ? exc_page_fault+0xc5/0x150 [ 146.812342] ? asm_exc_page_fault+0x1e/0x30 [ 146.812862] ? platform_shutdown+0x9/0x20 [ 146.813362] device_shutdown+0x158/0x1c0 [ 146.813853] __do_sys_reboot.cold+0x2f/0x5b [ 146.814370] ? vfs_writev+0x9b/0x110 [ 146.814824] ? do_writev+0x57/0xf0 [ 146.815254] do_syscall_64+0x30/0x40 [ 146.815708] entry_SYSCALL_64_after_hwframe+0x67/0xd1 Let me know how to further assist. -- Chuck Lever

6 months

3
8
0 0

[PATCH v2 1/2] PCI: Forcefully set the PCI_REASSIGN_ALL_BUS flag for Marvell CN96XX/CN10XXX boards

by Bo Sun

---8<--- Changes in v2: - Added explicit comment about the quirk, as requested by Mani. - Made commit message more clear, as requested by Bjorn. ---8<--- On our Marvell OCTEON CN96XX board, we observed the following panic on the latest kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc6 #20 Hardware name: Marvell OcteonTX CN96XX board (DT) pc : of_pci_add_properties+0x278/0x4c8 Call trace: of_pci_add_properties+0x278/0x4c8 (P) of_pci_make_dev_node+0xe0/0x158 pci_bus_add_device+0x158/0x228 pci_bus_add_devices+0x40/0x98 pci_host_probe+0x94/0x118 pci_host_common_probe+0x130/0x1b0 platform_probe+0x70/0xf0 The dmesg logs indicated that the PCI bridge was scanning with an invalid bus range: pci-host-generic 878020000000.pci: PCI host bridge to bus 0002:00 pci_bus 0002:00: root bus resource [bus 00-ff] pci 0002:00:00.0: scanning [bus f9-f9] behind bridge, pass 0 pci 0002:00:01.0: scanning [bus fa-fa] behind bridge, pass 0 pci 0002:00:02.0: scanning [bus fb-fb] behind bridge, pass 0 pci 0002:00:03.0: scanning [bus fc-fc] behind bridge, pass 0 pci 0002:00:04.0: scanning [bus fd-fd] behind bridge, pass 0 pci 0002:00:05.0: scanning [bus fe-fe] behind bridge, pass 0 pci 0002:00:06.0: scanning [bus ff-ff] behind bridge, pass 0 pci 0002:00:07.0: scanning [bus 00-00] behind bridge, pass 0 pci 0002:00:07.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci 0002:00:08.0: scanning [bus 01-01] behind bridge, pass 0 pci 0002:00:09.0: scanning [bus 02-02] behind bridge, pass 0 pci 0002:00:0a.0: scanning [bus 03-03] behind bridge, pass 0 pci 0002:00:0b.0: scanning [bus 04-04] behind bridge, pass 0 pci 0002:00:0c.0: scanning [bus 05-05] behind bridge, pass 0 pci 0002:00:0d.0: scanning [bus 06-06] behind bridge, pass 0 pci 0002:00:0e.0: scanning [bus 07-07] behind bridge, pass 0 pci 0002:00:0f.0: scanning [bus 08-08] behind bridge, pass 0 This regression was introduced by commit 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags"). On our board, the 0002:00:07.0 bridge is misconfigured by the bootloader. Both its secondary and subordinate bus numbers are initialized to 0, while its fixed secondary bus number is set to 8. However, bus number 8 is also assigned to another bridge (0002:00:0f.0). Although this is a bootloader issue, before the change in commit 7246a4520b4b, the PCI_REASSIGN_ALL_BUS flag was set by default when PCI_PROBE_ONLY was not enabled, ensuing that all the bus number for these bridges were reassigned, avoiding any conflicts. After the change introduced in commit 7246a4520b4b, the bus numbers assigned by the bootloader are reused by all other bridges, except the misconfigured 0002:00:07.0 bridge. The kernel attempt to reconfigure 0002:00:07.0 by reusing the fixed secondary bus number 8 assigned by bootloader. However, since a pci_bus has already been allocated for bus 8 due to the probe of 0002:00:0f.0, no new pci_bus allocated for 0002:00:07.0. This results in a pci bridge device without a pci_bus attached (pdev->subordinate == NULL). Consequently, accessing pdev->subordinate in of_pci_prop_bus_range() leads to a NULL pointer dereference. To summarize, we need to set the PCI_REASSIGN_ALL_BUS flag when PCI_PROBE_ONLY is not enabled in order to work around issue like the one described above. Cc: stable(a)vger.kernel.org Fixes: 7246a4520b4b ("PCI: Use preserve_config in place of pci_flags") Signed-off-by: Bo Sun <Bo.Sun.CN(a)windriver.com> --- drivers/pci/quirks.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 82b21e34c545..cec58c7479e1 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -6181,6 +6181,23 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1536, rom_bar_overlap_defect); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1537, rom_bar_overlap_defect); DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1538, rom_bar_overlap_defect); +/* + * Quirk for Marvell CN96XX/CN10XXX boards: + * + * Adds PCI_REASSIGN_ALL_BUS unless PCI_PROBE_ONLY is set, forcing bus number + * reassignment to avoid conflicts caused by bootloader misconfigured PCI bridges. + * + * This resolves a regression introduced by commit 7246a4520b4b ("PCI: Use + * preserve_config in place of pci_flags"), which removed this behavior. + */ +static void quirk_marvell_cn96xx_cn10xxx_reassign_all_busnr(struct pci_dev *dev) +{ + if (!pci_has_flag(PCI_PROBE_ONLY)) + pci_add_flags(PCI_REASSIGN_ALL_BUS); +} +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_CAVIUM, 0xa002, + quirk_marvell_cn96xx_cn10xxx_reassign_all_busnr); + #ifdef CONFIG_PCIEASPM /* * Several Intel DG2 graphics devices advertise that they can only tolerate -- 2.48.1

6 months

1
1
0 0

[PATCH v9] arm64: mm: Populate vmemmap at the page level if not section aligned

by Zhenhua Huang

On the arm64 platform with 4K base page config, SECTION_SIZE_BITS is set to 27, making one section 128M. The related page struct which vmemmap points to is 2M then. Commit c1cc1552616d ("arm64: MMU initialisation") optimizes the vmemmap to populate at the PMD section level which was suitable initially since hot plug granule is always one section(128M). However, commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") introduced a 2M(SUBSECTION_SIZE) hot plug granule, which disrupted the existing arm64 assumptions. The first problem is that if start or end is not aligned to a section boundary, such as when a subsection is hot added, populating the entire section is wasteful. The next problem is if we hotplug something that spans part of 128 MiB section (subsections, let's call it memblock1), and then hotplug something that spans another part of a 128 MiB section(subsections, let's call it memblock2), and subsequently unplug memblock1, vmemmap_free() will clear the entire PMD entry which also supports memblock2 even though memblock2 is still active. Assuming hotplug/unplug sizes are guaranteed to be symmetric. Do the fix similar to x86-64: populate to pages levels if start/end is not aligned with section boundary. Cc: <stable(a)vger.kernel.org> # v5.4+ Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") Acked-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Zhenhua Huang <quic_zhenhuah(a)quicinc.com> --- arch/arm64/mm/mmu.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index b4df5bc5b1b8..1dfe1a8efdbe 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -1177,8 +1177,11 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, struct vmem_altmap *altmap) { WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END)); + /* [start, end] should be within one section */ + WARN_ON_ONCE(end - start > PAGES_PER_SECTION * sizeof(struct page)); - if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES)) + if (!IS_ENABLED(CONFIG_ARM64_4K_PAGES) || + (end - start < PAGES_PER_SECTION * sizeof(struct page))) return vmemmap_populate_basepages(start, end, node, altmap); else return vmemmap_populate_hugepages(start, end, node, altmap); -- 2.25.1

6 months, 1 week

4
3
0 0

[PATCH] media: ov08x40: Extend sleep after reset to 5 ms

by Hans de Goede

Some users are reporting that ov08x40_identify_module() fails to identify the chip reading 0x00 as value for OV08X40_REG_CHIP_ID. Intel's out of tree IPU6 drivers include some ov08x40 changes including adding support for the reset GPIO for older kernels and Intel's patch for this uses 5 ms. Extend the sleep to 5 ms following Intel's example, this fixes the ov08x40_identify_module() problem. Link: https://github.com/intel/ipu6-drivers/blob/c09e2198d801e1eb701984d294837312… Fixes: df1ae2251a50 ("media: ov08x40: Add OF probe support") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/media/i2c/ov08x40.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov08x40.c b/drivers/media/i2c/ov08x40.c index cf0e41fc3071..54575eea3c49 100644 --- a/drivers/media/i2c/ov08x40.c +++ b/drivers/media/i2c/ov08x40.c @@ -1341,7 +1341,7 @@ static int ov08x40_power_on(struct device *dev) } gpiod_set_value_cansleep(ov08x->reset_gpio, 0); - usleep_range(1500, 1800); + usleep_range(5000, 5500); return 0; -- 2.48.1

6 months, 1 week

2
1
0 0

Re: [PATCH] parport: Add Brainboxes XC cards.

by Cameron Williams

Cc'ing stable Cc: stable(a)vger.kernel.org On 10 March 2025 22:25:08 GMT, Cameron Williams <cang1(a)live.co.uk> wrote: >Add ExpressCard parport cards. > >Signed-off-by: Cameron Williams <cang1(a)live.co.uk> >--- > drivers/parport/parport_pc.c | 6 ++++++ > 1 file changed, 6 insertions(+) > >diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c >index f33b5d1dd..787e894bb 100644 >--- a/drivers/parport/parport_pc.c >+++ b/drivers/parport/parport_pc.c >@@ -2854,6 +2854,12 @@ static const struct pci_device_id parport_pc_pci_tbl[] = { > /* Brainboxes PX-475 */ > { PCI_VENDOR_ID_INTASHIELD, 0x401f, > PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, >+ /* Brainboxes XC-157 */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4020, >+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, >+ /* Brainboxes XC-475 */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4022, >+ PCI_ANY_ID, PCI_ANY_ID, 0, 0, oxsemi_pcie_pport }, > { 0, } /* terminate list */ > }; > MODULE_DEVICE_TABLE(pci, parport_pc_pci_tbl);

6 months, 1 week

2
1
0 0

Re: [PATCH] tty: serial: 8250: Add Brainboxes XC devices

by Greg KH

On Tue, Mar 11, 2025 at 06:54:00AM +0000, Cameron Williams wrote: > Cc'ing stable > > Cc: stable(a)vger.kernel.org > <formletter> This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly. </formletter>

6 months, 1 week

1
0
0 0

Re: [PATCH] tty: serial: 8250: Add Brainboxes XC devices

by Cameron Williams

Cc'ing stable Cc: stable(a)vger.kernel.org On 10 March 2025 22:27:10 GMT, Cameron Williams <cang1(a)live.co.uk> wrote: >These ExpressCard devices use the OxPCIE chip and can be used with >this driver. > >Signed-off-by: Cameron Williams <cang1(a)live.co.uk> >--- > drivers/tty/serial/8250/8250_pci.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > >diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c >index df4d0d832..911774fb8 100644 >--- a/drivers/tty/serial/8250/8250_pci.c >+++ b/drivers/tty/serial/8250/8250_pci.c >@@ -2727,6 +2727,22 @@ static struct pci_serial_quirk pci_serial_quirks[] = { > .init = pci_oxsemi_tornado_init, > .setup = pci_oxsemi_tornado_setup, > }, >+ { >+ .vendor = PCI_VENDOR_ID_INTASHIELD, >+ .device = 0x4026, >+ .subvendor = PCI_ANY_ID, >+ .subdevice = PCI_ANY_ID, >+ .init = pci_oxsemi_tornado_init, >+ .setup = pci_oxsemi_tornado_setup, >+ }, >+ { >+ .vendor = PCI_VENDOR_ID_INTASHIELD, >+ .device = 0x4021, >+ .subvendor = PCI_ANY_ID, >+ .subdevice = PCI_ANY_ID, >+ .init = pci_oxsemi_tornado_init, >+ .setup = pci_oxsemi_tornado_setup, >+ }, > { > .vendor = PCI_VENDOR_ID_INTEL, > .device = 0x8811, >@@ -5599,6 +5615,20 @@ static const struct pci_device_id serial_pci_tbl[] = { > PCI_ANY_ID, PCI_ANY_ID, > 0, 0, > pbn_oxsemi_1_15625000 }, >+ /* >+ * Brainboxes XC-235 >+ */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4026, >+ PCI_ANY_ID, PCI_ANY_ID, >+ 0, 0, >+ pbn_oxsemi_1_15625000 }, >+ /* >+ * Brainboxes XC-475 >+ */ >+ { PCI_VENDOR_ID_INTASHIELD, 0x4021, >+ PCI_ANY_ID, PCI_ANY_ID, >+ 0, 0, >+ pbn_oxsemi_1_15625000 }, > > /* > * Perle PCI-RAS cards

6 months, 1 week

1
0
0 0

[PATCH V4] drm/sched: Fix fence reference count leak

by Qianyi Liu

From: qianyi liu <liuqianyi125(a)gmail.com> The last_scheduled fence leaks when an entity is being killed and adding the cleanup callback fails. Decrement the reference count of prev when dma_fence_add_callback() fails, ensuring proper balance. Cc: stable(a)vger.kernel.org Fixes: 2fdb8a8f07c2 ("drm/scheduler: rework entity flush, kill and fini") Signed-off-by: qianyi liu <liuqianyi125(a)gmail.com> --- v3 -> v4: Improve commit message and add code comments (Philipp) v2 -> v3: Rework commit message (Markus) v1 -> v2: Added 'Fixes:' tag and clarified commit message (Philipp and Matthew) --- drivers/gpu/drm/scheduler/sched_entity.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 69bcf0e99d57..da00572d7d42 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -259,9 +259,16 @@ static void drm_sched_entity_kill(struct drm_sched_entity *entity) struct drm_sched_fence *s_fence = job->s_fence; dma_fence_get(&s_fence->finished); - if (!prev || dma_fence_add_callback(prev, &job->finish_cb, - drm_sched_entity_kill_jobs_cb)) + if (!prev || + dma_fence_add_callback(prev, &job->finish_cb, + drm_sched_entity_kill_jobs_cb)) { + /* + * Adding callback above failed. + * dma_fence_put() checks for NULL. + */ + dma_fence_put(prev); drm_sched_entity_kill_jobs_cb(NULL, &job->finish_cb); + } prev = &s_fence->finished; } -- 2.25.1

6 months, 1 week

1
0
0 0

+ memcg-drain-obj-stock-on-cpu-hotplug-teardown.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: memcg: drain obj stock on cpu hotplug teardown has been added to the -mm mm-hotfixes-unstable branch. Its filename is memcg-drain-obj-stock-on-cpu-hotplug-teardown.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Shakeel Butt <shakeel.butt(a)linux.dev> Subject: memcg: drain obj stock on cpu hotplug teardown Date: Mon, 10 Mar 2025 16:09:34 -0700 Currently on cpu hotplug teardown, only memcg stock is drained but we need to drain the obj stock as well otherwise we will miss the stats accumulated on the target cpu as well as the nr_bytes cached. The stats include MEMCG_KMEM, NR_SLAB_RECLAIMABLE_B & NR_SLAB_UNRECLAIMABLE_B. In addition we are leaking reference to struct obj_cgroup object. Link: https://lkml.kernel.org/r/20250310230934.2913113-1-shakeel.butt@linux.dev Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") Signed-off-by: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memcontrol.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/mm/memcontrol.c~memcg-drain-obj-stock-on-cpu-hotplug-teardown +++ a/mm/memcontrol.c @@ -1921,9 +1921,18 @@ void drain_all_stock(struct mem_cgroup * static int memcg_hotplug_cpu_dead(unsigned int cpu) { struct memcg_stock_pcp *stock; + struct obj_cgroup *old; + unsigned long flags; stock = &per_cpu(memcg_stock, cpu); + + /* drain_obj_stock requires stock_lock */ + local_lock_irqsave(&memcg_stock.stock_lock, flags); + old = drain_obj_stock(stock); + local_unlock_irqrestore(&memcg_stock.stock_lock, flags); + drain_stock(stock); + obj_cgroup_put(old); return 0; } _ Patches currently in -mm which might be from shakeel.butt(a)linux.dev are memcg-drain-obj-stock-on-cpu-hotplug-teardown.patch memcg-add-hierarchical-effective-limits-for-v2.patch memcg-dont-call-propagate_protected_usage-for-v1.patch page_counter-track-failcnt-only-for-legacy-cgroups.patch page_counter-reduce-struct-page_counter-size.patch memcg-bypass-root-memcg-check-for-skmem-charging.patch

6 months, 1 week

1
0
0 0

+ mm-huge_memory-drop-beyond-eof-folios-with-the-right-number-of-refs.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/huge_memory: drop beyond-EOF folios with the right number of refs. has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-huge_memory-drop-beyond-eof-folios-with-the-right-number-of-refs.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Zi Yan <ziy(a)nvidia.com> Subject: mm/huge_memory: drop beyond-EOF folios with the right number of refs. Date: Mon, 10 Mar 2025 11:57:27 -0400 When an after-split folio is large and needs to be dropped due to EOF, folio_put_refs(folio, folio_nr_pages(folio)) should be used to drop all page cache refs. Otherwise, the folio will not be freed, causing memory leak. This leak would happen on a filesystem with blocksize > page_size and a truncate is performed, where the blocksize makes folios split to >0 order ones, causing truncated folios not being freed. Link: https://lkml.kernel.org/r/20250310155727.472846-1-ziy@nvidia.com Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Signed-off-by: Zi Yan <ziy(a)nvidia.com> Reported-by: Hugh Dickins <hughd(a)google.com> Closes: https://lore.kernel.org/all/fcbadb7f-dd3e-21df-f9a7-2853b53183c4@google.com/ Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Kirill A. Shuemov <kirill.shutemov(a)linux.intel.com> Cc: Luis Chamberalin <mcgrof(a)kernel.org> Cc: Matthew Wilcow (Oracle) <willy(a)infradead.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Pankaj Raghav <p.raghav(a)samsung.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Yang Shi <yang(a)os.amperecomputing.com> Cc: Yu Zhao <yuzhao(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/huge_memory.c~mm-huge_memory-drop-beyond-eof-folios-with-the-right-number-of-refs +++ a/mm/huge_memory.c @@ -3304,7 +3304,7 @@ static void __split_huge_page(struct pag folio_account_cleaned(tail, inode_to_wb(folio->mapping->host)); __filemap_remove_folio(tail, NULL); - folio_put(tail); + folio_put_refs(tail, folio_nr_pages(tail)); } else if (!folio_test_anon(folio)) { __xa_store(&folio->mapping->i_pages, tail->index, tail, 0); _ Patches currently in -mm which might be from ziy(a)nvidia.com are mm-migrate-fix-shmem-xarray-update-during-migration.patch mm-huge_memory-drop-beyond-eof-folios-with-the-right-number-of-refs.patch selftests-mm-make-file-backed-thp-split-work-by-writing-pmd-size-data.patch mm-huge_memory-allow-split-shmem-large-folio-to-any-lower-order.patch selftests-mm-test-splitting-file-backed-thp-to-any-lower-order.patch xarray-add-xas_try_split-to-split-a-multi-index-entry.patch mm-huge_memory-add-two-new-not-yet-used-functions-for-folio_split.patch mm-huge_memory-add-two-new-not-yet-used-functions-for-folio_split-fix.patch mm-huge_memory-move-folio-split-common-code-to-__folio_split.patch mm-huge_memory-add-buddy-allocator-like-non-uniform-folio_split.patch mm-huge_memory-remove-the-old-unused-__split_huge_page.patch mm-huge_memory-add-folio_split-to-debugfs-testing-interface.patch mm-truncate-use-folio_split-in-truncate-operation.patch selftests-mm-add-tests-for-folio_split-buddy-allocator-like-split.patch mm-filemap-use-xas_try_split-in-__filemap_add_folio.patch mm-shmem-use-xas_try_split-in-shmem_split_large_entry.patch

6 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025