February 2025 - Linux-stable-mirror

[6.1.y] Regression from b1e6e80a1b42 ("xen/swiotlb: add alignment check for dma buffers") when booting with Xen and mpt3sas_cm0 _scsih_probe failures

by Salvatore Bonaccorso

Hi Juergen, hi all, Radoslav Bodó reported in Debian an issue after updating our kernel from 6.1.112 to 6.1.115. His report in full is at: https://bugs.debian.org/1088159 He reports that after switching to 6.1.115 (and present in any of the later 6.1.y series) booting under xen, the mptsas devices are not anymore accessible, the boot shows: mpt3sas version 43.100.00.00 loaded mpt3sas_cm0: 63 BIT PCI BUS DMA ADDRESSING SUPPORTED, total mem (8086116 kB) mpt3sas_cm0: CurrentHostPageSize is 0: Setting default host page size to 4k mpt3sas_cm0: MSI-X vectors supported: 96 mpt3sas_cm0: 0 40 40 mpt3sas_cm0: High IOPs queues : disabled mpt3sas0-msix0: PCI-MSI-X enabled: IRQ 447 mpt3sas0-msix1: PCI-MSI-X enabled: IRQ 448 mpt3sas0-msix2: PCI-MSI-X enabled: IRQ 449 mpt3sas0-msix3: PCI-MSI-X enabled: IRQ 450 mpt3sas0-msix4: PCI-MSI-X enabled: IRQ 451 mpt3sas0-msix5: PCI-MSI-X enabled: IRQ 452 mpt3sas0-msix6: PCI-MSI-X enabled: IRQ 453 mpt3sas0-msix7: PCI-MSI-X enabled: IRQ 454 mpt3sas0-msix8: PCI-MSI-X enabled: IRQ 455 mpt3sas0-msix9: PCI-MSI-X enabled: IRQ 456 mpt3sas0-msix10: PCI-MSI-X enabled: IRQ 457 mpt3sas0-msix11: PCI-MSI-X enabled: IRQ 458 mpt3sas0-msix12: PCI-MSI-X enabled: IRQ 459 mpt3sas0-msix13: PCI-MSI-X enabled: IRQ 460 mpt3sas0-msix14: PCI-MSI-X enabled: IRQ 461 mpt3sas0-msix15: PCI-MSI-X enabled: IRQ 462 mpt3sas0-msix16: PCI-MSI-X enabled: IRQ 463 mpt3sas0-msix17: PCI-MSI-X enabled: IRQ 464 mpt3sas0-msix18: PCI-MSI-X enabled: IRQ 465 mpt3sas0-msix19: PCI-MSI-X enabled: IRQ 466 mpt3sas0-msix20: PCI-MSI-X enabled: IRQ 467 mpt3sas0-msix21: PCI-MSI-X enabled: IRQ 468 mpt3sas0-msix22: PCI-MSI-X enabled: IRQ 469 mpt3sas0-msix23: PCI-MSI-X enabled: IRQ 470 mpt3sas0-msix24: PCI-MSI-X enabled: IRQ 471 mpt3sas0-msix25: PCI-MSI-X enabled: IRQ 472 mpt3sas0-msix26: PCI-MSI-X enabled: IRQ 473 mpt3sas0-msix27: PCI-MSI-X enabled: IRQ 474 mpt3sas0-msix28: PCI-MSI-X enabled: IRQ 475 mpt3sas0-msix29: PCI-MSI-X enabled: IRQ 476 mpt3sas0-msix30: PCI-MSI-X enabled: IRQ 477 mpt3sas0-msix31: PCI-MSI-X enabled: IRQ 478 mpt3sas0-msix32: PCI-MSI-X enabled: IRQ 479 mpt3sas0-msix33: PCI-MSI-X enabled: IRQ 480 mpt3sas0-msix34: PCI-MSI-X enabled: IRQ 481 mpt3sas0-msix35: PCI-MSI-X enabled: IRQ 482 mpt3sas0-msix36: PCI-MSI-X enabled: IRQ 483 mpt3sas0-msix37: PCI-MSI-X enabled: IRQ 484 mpt3sas0-msix38: PCI-MSI-X enabled: IRQ 485 mpt3sas0-msix39: PCI-MSI-X enabled: IRQ 486 mpt3sas_cm0: iomem(0x00000000ac400000), mapped(0x00000000d9f45f61), size(65536) mpt3sas_cm0: ioport(0x0000000000006000), size(256) mpt3sas_cm0: CurrentHostPageSize is 0: Setting default host page size to 4k mpt3sas_cm0: scatter gather: sge_in_main_msg(1), sge_per_chain(7), sge_per_io(128), chains_per_io(19) mpt3sas_cm0: failure at drivers/scsi/mpt3sas/mpt3sas_scsih.c:12348/_scsih_probe()! We were able to bissect the changes (see https://bugs.debian.org/1088159#64) down to b1e6e80a1b42 ("xen/swiotlb: add alignment check for dma buffers") #regzbot introduced: b1e6e80a1b42 #regzbot link: https://bugs.debian.org/1088159 reverting the commit resolves the issue. Does that ring some bells? In fact we have two more bugs reported with similar symptoms but not yet confirmed they are the same, but I'm referencing them here as well in case we are able to cross-match to root cause: https://bugs.debian.org/1093371 (megaraid_sas didn't work anymore with Xen) and https://bugs.debian.org/1087807 (Unable to boot: i40e swiotlb buffer is full) (but again the these are yet not confirmed to have the same root cause). Thanks in advance, Regards, Salvatore

6 months, 1 week

5
10
0 0

[PATCH dlm/next 1/2] dlm: fix error if inactive rsb is not hashed

by Alexander Aring

If an inactive rsb is not hashed anymore and this could occur because we releases and acquired locks we need to signal the followed code that the lookup failed. Since the lookup was successful, but it isn't part of the rsb hash anymore we need to signal it by setting error to -EBADR as dlm_search_rsb_tree() does it. Cc: stable(a)vger.kernel.org Fixes: 01fdeca1cc2d ("dlm: use rcu to avoid an extra rsb struct lookup") Signed-off-by: Alexander Aring <aahringo(a)redhat.com> --- fs/dlm/lock.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index c8ff88f1cdcf..499fa999ae83 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -784,6 +784,7 @@ static int find_rsb_dir(struct dlm_ls *ls, const void *name, int len, } } else { write_unlock_bh(&ls->ls_rsbtbl_lock); + error = -EBADR; goto do_new; } -- 2.43.0

6 months, 1 week

1
1
0 0

[PATCH net-next v4 1/4] stmmac: loongson: Pass correct arg to PCI function

by Philipp Stanner

pcim_iomap_regions() should receive the driver's name as its third parameter, not the PCI device's name. Define the driver name with a macro and use it at the appropriate places, including pcim_iomap_regions(). Cc: stable(a)vger.kernel.org # v5.14+ Fixes: 30bba69d7db4 ("stmmac: pci: Add dwmac support for Loongson") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Reviewed-by: Yanteng Si <si.yanteng(a)linux.dev> Tested-by: Henry Chen <chenx97(a)aosc.io> --- drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c index bfe6e2d631bd..73a6715a93e6 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c @@ -11,6 +11,8 @@ #include "dwmac_dma.h" #include "dwmac1000.h" +#define DRIVER_NAME "dwmac-loongson-pci" + /* Normal Loongson Tx Summary */ #define DMA_INTR_ENA_NIE_TX_LOONGSON 0x00040000 /* Normal Loongson Rx Summary */ @@ -555,7 +557,7 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id for (i = 0; i < PCI_STD_NUM_BARS; i++) { if (pci_resource_len(pdev, i) == 0) continue; - ret = pcim_iomap_regions(pdev, BIT(0), pci_name(pdev)); + ret = pcim_iomap_regions(pdev, BIT(0), DRIVER_NAME); if (ret) goto err_disable_device; break; @@ -673,7 +675,7 @@ static const struct pci_device_id loongson_dwmac_id_table[] = { MODULE_DEVICE_TABLE(pci, loongson_dwmac_id_table); static struct pci_driver loongson_dwmac_driver = { - .name = "dwmac-loongson-pci", + .name = DRIVER_NAME, .id_table = loongson_dwmac_id_table, .probe = loongson_dwmac_probe, .remove = loongson_dwmac_remove, -- 2.48.1

6 months, 1 week

3
3
0 0

[PATCH] mm/damon: respect core layer filters' allowance decision on ops layer

by SeongJae Park

Filtering decisions are made in filters evaluation order. Once a decision is made by a filter, filters that scheduled to be evaluated after the decision-made filter should just respect it. This is the intended and documented behavior. Since core layer-handled filters are evaluated before operations layer-handled filters, decisions made on core layer should respected by ops layer. In case of reject filters, the decision is respected, since core layer-rejected regions are not passed to ops layer. But in case of allow filters, ops layer filters don't know if the region has passed to them because it was allowed by core filters or just because it didn't match to any core layer. The current wrong implementation assumes it was due to not matched by any core filters. As a reuslt, the decision is not respected. Pass the missing information to ops layer using a new filed in 'struct damos', and make the ops layer filters respect it. Fixes: 491fee286e56 ("mm/damon/core: support damos_filter->allow") Cc: <stable(a)vger.kernel.org> # 6.14.x Signed-off-by: SeongJae Park <sj(a)kernel.org> --- include/linux/damon.h | 5 +++++ mm/damon/core.c | 6 +++++- mm/damon/paddr.c | 3 +++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/include/linux/damon.h b/include/linux/damon.h index 795ca09b1107..242910b190c9 100644 --- a/include/linux/damon.h +++ b/include/linux/damon.h @@ -496,6 +496,11 @@ struct damos { unsigned long next_apply_sis; /* informs if ongoing DAMOS walk for this scheme is finished */ bool walk_completed; + /* + * If the current region in the filtering stage is allowed by core + * layer-handled filters. If true, operations layer allows it, too. + */ + bool core_filters_allowed; /* public: */ struct damos_quota quota; struct damos_watermarks wmarks; diff --git a/mm/damon/core.c b/mm/damon/core.c index cfa105ee9610..b1ce072b56f2 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -1433,9 +1433,13 @@ static bool damos_filter_out(struct damon_ctx *ctx, struct damon_target *t, { struct damos_filter *filter; + s->core_filters_allowed = false; damos_for_each_filter(filter, s) { - if (damos_filter_match(ctx, t, r, filter)) + if (damos_filter_match(ctx, t, r, filter)) { + if (filter->allow) + s->core_filters_allowed = true; return !filter->allow; + } } return false; } diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c index 25090230da17..d5db313ca717 100644 --- a/mm/damon/paddr.c +++ b/mm/damon/paddr.c @@ -253,6 +253,9 @@ static bool damos_pa_filter_out(struct damos *scheme, struct folio *folio) { struct damos_filter *filter; + if (scheme->core_filters_allowed) + return false; + damos_for_each_filter(filter, scheme) { if (damos_pa_filter_match(filter, folio)) return !filter->allow; base-commit: c8f5534db6574708eee17fcd416f0a3fb3b45dbd -- 2.39.5

6 months, 1 week

1
0
0 0

[PATCH] mm/damon/core: initialize damos->walk_completed in damon_new_scheme()

by SeongJae Park

The function for allocating and initialize a 'struct damos' object, damon_new_scheme(), is not initializing damos->walk_completed field. Only damos_walk_complete() is setting the field. Hence the field will be eventually set and used correctly from second damos_walk() call for the scheme. But the first damos_walk() could mistakenly not walk on the regions. Actually, a common usage of DAMOS for taking an access pattern snapshot is installing a monitoring-purpose DAMOS scheme, doing damos_walk() to retrieve the snapshot, and then removing the scheme. DAMON user-space tool (damo) also gets runtime snapshot in the way. Hence the problem can continuously happen in such use cases. Initialize it properly in the allocation function. Fixes: bf0eaba0ff9c ("mm/damon/core: implement damos_walk()") Cc: <stable(a)vger.kernel.org> # 6.14.x Signed-off-by: SeongJae Park <sj(a)kernel.org> --- mm/damon/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/damon/core.c b/mm/damon/core.c index 38f545fea585..cfa105ee9610 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -373,6 +373,7 @@ struct damos *damon_new_scheme(struct damos_access_pattern *pattern, * or damon_attrs are updated. */ scheme->next_apply_sis = 0; + scheme->walk_completed = false; INIT_LIST_HEAD(&scheme->filters); scheme->stat = (struct damos_stat){}; INIT_LIST_HEAD(&scheme->list); base-commit: 3880bbe477938a3b30ff7bf2ef316adf98876671 -- 2.39.5

6 months, 1 week

1
0
0 0

[REGRESSION][BISECTED][STABLE] MT7925 wifi throughput halved with 6.13.2

by Christian Heusel

Hello everyone, on the Arch Linux Bugtracker[1] Benjamin (also added in CC) reported that his MT7925 wifi card has halved it's throughput when updating from the v6.13.1 to the v6.13.2 stable kernel. The problem is still present in the 6.13.5 stable kernel. We have bisected this issue together and found the backporting of the following commit responsible for this issue: 4cf9f08632c0 ("wifi: mt76: mt7925: Update mt7925_mcu_uni_[tx,rx]_ba for MLO") We unfortunately didn't have a chance to test the mainline releases as the reporter uses the (out of tree) nvidia modules that were not compatible with mainline release at the time of testing. We will soon test against Mainline aswell. I have attached dmesg outputs of a good and a bad boot aswell as his other hardware specs and will be available to debug this further. Cheers, Christian [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/112

6 months, 1 week

3
2
0 0

[PATCH v4 1/1] xhci: Correctly handle last TRB of isoc TD on Etron xHCI host

by Kuangyi Chiang

Unplugging a USB3.0 webcam while streaming results in errors like this: [ 132.646387] xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 18 comp_code 13 [ 132.646446] xhci_hcd 0000:03:00.0: Looking for event-dma 000000002fdf8630 trb-start 000000002fdf8640 trb-end 000000002fdf8650 seg-start 000000002fdf8000 seg-end 000000002fdf8ff0 [ 132.646560] xhci_hcd 0000:03:00.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 18 comp_code 13 [ 132.646568] xhci_hcd 0000:03:00.0: Looking for event-dma 000000002fdf8660 trb-start 000000002fdf8670 trb-end 000000002fdf8670 seg-start 000000002fdf8000 seg-end 000000002fdf8ff0 If an error is detected while processing the last TRB of an isoc TD, the Etron xHC generates two transfer events for the TRB where the error was detected. The first event can be any sort of error (like USB Transaction or Babble Detected, etc), and the final event is Success. The xHCI driver will handle the TD after the first event and remove it from its internal list, and then print an "Transfer event TRB DMA ptr not part of current TD" error message after the final event. Commit 5372c65e1311 ("xhci: process isoc TD properly when there was a transaction error mid TD.") is designed to address isoc transaction errors, but unfortunately it doesn't account for this scenario. To work around this by reusing the logic that handles isoc transaction errors, but continuing to wait for the final event when this condition occurs. Sometimes we see the Stopped event after an error mid TD, this is a normal event for a pending TD and we can think of it as the final event we are waiting for. Check if the XHCI_ETRON_HOST quirk flag is set before invoking the workaround in process_isoc_td(). Fixes: 5372c65e1311 ("xhci: process isoc TD properly when there was a transaction error mid TD.") Cc: <stable(a)vger.kernel.org> Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> --- drivers/usb/host/xhci-ring.c | 29 +++++++++++++++++++++-------- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 965bffce301e..936fd9151ba8 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2452,8 +2452,10 @@ static void process_isoc_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, switch (trb_comp_code) { case COMP_SUCCESS: /* Don't overwrite status if TD had an error, see xHCI 4.9.1 */ - if (td->error_mid_td) + if (td->error_mid_td) { + td->error_mid_td = false; break; + } if (remaining) { frame->status = short_framestatus; sum_trbs_for_length = true; @@ -2468,25 +2470,36 @@ static void process_isoc_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, case COMP_BANDWIDTH_OVERRUN_ERROR: frame->status = -ECOMM; break; + case COMP_USB_TRANSACTION_ERROR: case COMP_BABBLE_DETECTED_ERROR: sum_trbs_for_length = true; fallthrough; case COMP_ISOCH_BUFFER_OVERRUN: frame->status = -EOVERFLOW; + if (trb_comp_code == COMP_USB_TRANSACTION_ERROR) + frame->status = -EPROTO; if (ep_trb != td->end_trb) td->error_mid_td = true; + else + td->error_mid_td = false; + + /* + * If an error is detected on the last TRB of the TD, + * wait for the final event. + */ + if ((xhci->quirks & XHCI_ETRON_HOST) && + td->urb->dev->speed >= USB_SPEED_SUPER && + ep_trb == td->end_trb) + td->error_mid_td = true; break; case COMP_INCOMPATIBLE_DEVICE_ERROR: case COMP_STALL_ERROR: frame->status = -EPROTO; break; - case COMP_USB_TRANSACTION_ERROR: - frame->status = -EPROTO; - sum_trbs_for_length = true; - if (ep_trb != td->end_trb) - td->error_mid_td = true; - break; case COMP_STOPPED: + /* Think of it as the final event if TD had an error */ + if (td->error_mid_td) + td->error_mid_td = false; sum_trbs_for_length = true; break; case COMP_STOPPED_SHORT_PACKET: @@ -2519,7 +2532,7 @@ static void process_isoc_td(struct xhci_hcd *xhci, struct xhci_virt_ep *ep, finish_td: /* Don't give back TD yet if we encountered an error mid TD */ - if (td->error_mid_td && ep_trb != td->end_trb) { + if (td->error_mid_td) { xhci_dbg(xhci, "Error mid isoc TD, wait for final completion event\n"); td->urb_length_set = true; return; -- 2.25.1

6 months, 1 week

5
19
0 0

[PATCH v2 0/2] leds: rgb: leds-qcom-lpg: Fixes for Hi-Res PWMs

by Abel Vesa

The PWM Hi-Res allow configuring the PWM resolution from 8 bits PWM values up to 15 bits values. The current implementation loops through all possible resolutions (PWM sizes) on top of the already existing process of determining the prediv, exponent and refclk. The first issue is that the maximum value used for capping is wrongly hardcoded. The second issue is that it uses the wrong maximum possible PWM value for determining the best matched period. Fix both. Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- Changes in v2: - Re-worded the commit to drop the details that are not important w.r.t. what the patch is fixing. - Added another patch which fixes the resolution used for determining best matched period and PWM config. - Link to v1: https://lore.kernel.org/r/20250220-leds-qcom-lpg-fix-max-pwm-on-hi-res-v1-1… --- Abel Vesa (2): leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs drivers/leds/rgb/leds-qcom-lpg.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- base-commit: 8433c776e1eb1371f5cd40b5fd3a61f9c7b7f3ad change-id: 20250220-leds-qcom-lpg-fix-max-pwm-on-hi-res-067e8782a79b Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

6 months, 1 week

3
4
0 0

[PATCH] f2fs: fix the missing write pointer correction

by Jaegeuk Kim

If checkpoint was disabled, we missed to fix the write pointers. Cc: <stable(a)vger.kernel.org> Fixes: 1015035609e4 ("f2fs: fix changing cursegs if recovery fails on zoned device") Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org> --- fs/f2fs/super.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index f5c69cc2de72..7a8fcc1e278c 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -4752,8 +4752,10 @@ static int f2fs_fill_super(struct super_block *sb, void *data, int silent) if (err) goto free_meta; - if (unlikely(is_set_ckpt_flags(sbi, CP_DISABLED_FLAG))) + if (unlikely(is_set_ckpt_flags(sbi, CP_DISABLED_FLAG))) { + skip_recovery = true; goto reset_checkpoint; + } /* recover fsynced data */ if (!test_opt(sbi, DISABLE_ROLL_FORWARD) && -- 2.48.1.711.g2feabab25a-goog

6 months, 1 week

3
2
0 0

Re: [PATCH v10 1/2] of: reserved_mem: Restruture how the reserved memory regions are processed

by Marco Felsch

Hi, On 24-10-08, Oreoluwa Babatunde wrote: > Reserved memory regions defined in the devicetree can be broken up into > two groups: > i) Statically-placed reserved memory regions > i.e. regions defined with a static start address and size using the > "reg" property. > ii) Dynamically-placed reserved memory regions. > i.e. regions defined by specifying an address range where they can be > placed in memory using the "alloc_ranges" and "size" properties. > > These regions are processed and set aside at boot time. > This is done in two stages as seen below: > > Stage 1: > At this stage, fdt_scan_reserved_mem() scans through the child nodes of > the reserved_memory node using the flattened devicetree and does the > following: > > 1) If the node represents a statically-placed reserved memory region, > i.e. if it is defined using the "reg" property: > - Call memblock_reserve() or memblock_mark_nomap() as needed. > - Add the information for that region into the reserved_mem array > using fdt_reserved_mem_save_node(). > i.e. fdt_reserved_mem_save_node(node, name, base, size). > > 2) If the node represents a dynamically-placed reserved memory region, > i.e. if it is defined using "alloc-ranges" and "size" properties: > - Add the information for that region to the reserved_mem array with > the starting address and size set to 0. > i.e. fdt_reserved_mem_save_node(node, name, 0, 0). > Note: This region is saved to the array with a starting address of 0 > because a starting address is not yet allocated for it. > > Stage 2: > After iterating through all the reserved memory nodes and storing their > relevant information in the reserved_mem array,fdt_init_reserved_mem() is > called and does the following: > > 1) For statically-placed reserved memory regions: > - Call the region specific init function using > __reserved_mem_init_node(). > 2) For dynamically-placed reserved memory regions: > - Call __reserved_mem_alloc_size() which is used to allocate memory > for each of these regions, and mark them as nomap if they have the > nomap property specified in the DT. > - Call the region specific init function. > > The current size of the resvered_mem array is 64 as is defined by > MAX_RESERVED_REGIONS. This means that there is a limitation of 64 for > how many reserved memory regions can be specified on a system. > As systems continue to grow more and more complex, the number of > reserved memory regions needed are also growing and are starting to hit > this 64 count limit, hence the need to make the reserved_mem array > dynamically sized (i.e. dynamically allocating memory for the > reserved_mem array using membock_alloc_*). > > On architectures such as arm64, memory allocated using memblock is > writable only after the page tables have been setup. This means that if > the reserved_mem array is going to be dynamically allocated, it needs to > happen after the page tables have been setup, not before. > > Since the reserved memory regions are currently being processed and > added to the array before the page tables are setup, there is a need to > change the order in which some of the processing is done to allow for > the reserved_mem array to be dynamically sized. > > It is possible to process the statically-placed reserved memory regions > without needing to store them in the reserved_mem array until after the > page tables have been setup because all the information stored in the > array is readily available in the devicetree and can be referenced at > any time. > Dynamically-placed reserved memory regions on the other hand get > assigned a start address only at runtime, and hence need a place to be > stored once they are allocated since there is no other referrence to the > start address for these regions. > > Hence this patch changes the processing order of the reserved memory > regions in the following ways: > > Step 1: > fdt_scan_reserved_mem() scans through the child nodes of > the reserved_memory node using the flattened devicetree and does the > following: > > 1) If the node represents a statically-placed reserved memory region, > i.e. if it is defined using the "reg" property: > - Call memblock_reserve() or memblock_mark_nomap() as needed. > > 2) If the node represents a dynamically-placed reserved memory region, > i.e. if it is defined using "alloc-ranges" and "size" properties: > - Call __reserved_mem_alloc_size() which will: > i) Allocate memory for the reserved region and call > memblock_mark_nomap() as needed. > ii) Call the region specific initialization function using > fdt_init_reserved_mem_node(). > iii) Save the region information in the reserved_mem array using > fdt_reserved_mem_save_node(). > > Step 2: > 1) This stage of the reserved memory processing is now only used to add > the statically-placed reserved memory regions into the reserved_mem > array using fdt_scan_reserved_mem_reg_nodes(), as well as call their > region specific initialization functions. > > 2) This step has also been moved to be after the page tables are > setup. Moving this will allow us to replace the reserved_mem > array with a dynamically sized array before storing the rest of > these regions. > > Signed-off-by: Oreoluwa Babatunde <quic_obabatun(a)quicinc.com> > --- > drivers/of/fdt.c | 5 +- > drivers/of/of_private.h | 3 +- > drivers/of/of_reserved_mem.c | 168 ++++++++++++++++++++++++----------- > 3 files changed, 122 insertions(+), 54 deletions(-) this patch got into stable kernel 6.12.13++ as part of Stable-dep-of. The stable kernel commit is: 9a0fe62f93ede02c27aaca81112af1e59c8c0979. With the patch applied I see that the cma area pool is misplaced which cause my 4G device to fail to activate the cma pool. Below are some logs: *** Good case (6.12) root@test:~# dmesg|grep -i cma [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] OF: reserved mem: 0x0000000044200000..0x00000000541fffff (262144 KiB) map reusable linux,cma [ 0.056915] Memory: 3695024K/4194304K available (15552K kernel code, 2510K rwdata, 5992K rodata, 6016K init, 489K bss, 231772K reserved, 262144K cma-reserved) *** Bad (6.12.16) root@test:~# dmesg|grep -i cma [ 0.000000] Reserved memory: created CMA memory pool at 0x00000000f2000000, size 256 MiB [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] OF: reserved mem: 0x00000000f2000000..0x0000000101ffffff (262144 KiB) map reusable linux,cma [ 0.056968] Memory: 3694896K/4194304K available (15616K kernel code, 2512K rwdata, 6012K rodata, 6080K init, 491K bss, 231900K reserved, 262144K cma-reserved) [ 0.116920] cma: CMA area linux,cma could not be activated *** Good (6.12.16, revert 9a0fe62f93ed) root@test:~# dmesg|grep -i cma [ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool [ 0.000000] OF: reserved mem: 0x0000000044200000..0x00000000541fffff (262144 KiB) map reusable linux,cma [ 0.060976] Memory: 3694896K/4194304K available (15616K kernel code, 2512K rwdata, 6012K rodata, 6080K init, 491K bss, 231900K reserved, 262144K cma-reserved) Below is our reserved-memory dts node: reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; linux,cma { compatible = "shared-dma-pool"; reusable; /* * The CMA area must be in the lower 32-bit address range. */ alloc-ranges = <0x0 0x42000000 0 0xc0000000>; size = <0x0 0x10000000>; alignment = <0 0x2000>; linux,cma-default; }; optee-core@40000000 { reg = <0 0x40000000 0 0x1e00000>; no-map; }; optee-shm@41e00000 { reg = <0 0x41e00000 0 0x200000>; no-map; }; m7_reserved: m7@80000000 { reg = <0 0x80000000 0 0x1000000>; no-map; }; vdev0vring0: vdev0vring0@55000000 { reg = <0 0x55000000 0 0x8000>; no-map; }; vdev0vring1: vdev0vring1@55008000 { reg = <0 0x55008000 0 0x8000>; no-map; }; rsc_table: rsc-table@550ff000 { reg = <0 0x550ff000 0 0x1000>; no-map; }; ram_console_buffer: ram-console-buffer@55100000 { reg = <0 0x55100000 0 0x1000>; no-map; }; vdev0buffer: vdev0buffer@55400000 { compatible = "shared-dma-pool"; reg = <0 0x55400000 0 0x100000>; no-map; }; }; My current workaround is to revert commit 9a0fe62f93ed and the dep-chain: 2d1d620ff27b444 8de4e5a92282. But I would like to get a proper solution without having revert commits in my downstream patchstack. Regards, Marco

6 months, 1 week

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025