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

[PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

by Christopher Obbard

This reverts commit b3b274bc9d3d7307308aeaf75f70731765ac999a. On the DragonBoard 820c (which uses APQ8096/MSM8996) this change causes the CPUs to downclock to roughly half speed under sustained load. The regression is visible both during boot and when running CPU stress workloads such as stress-ng: the CPUs initially ramp up to the expected frequency, then drop to a lower OPP even though the system is clearly CPU-bound. Bisecting points to this commit and reverting it restores the expected behaviour on the DragonBoard 820c - the CPUs track the cpufreq policy and run at full performance under load. The exact interaction with the ACD is not yet fully understood and we would like to keep ACD in use to avoid possible SoC reliability issues. Until we have a better fix that preserves ACD while avoiding this performance regression, revert the bisected patch to restore the previous behaviour. Fixes: b3b274bc9d3d ("clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb") Cc: stable(a)vger.kernel.org # v6.3+ Link: https://lore.kernel.org/linux-arm-msm/20230113120544.59320-8-dmitry.baryshk… Cc: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> Signed-off-by: Christopher Obbard <christopher.obbard(a)linaro.org> --- Hi all, This series contains a single revert for a regression affecting the APQ8096/MSM8996 (DragonBoard 820c). The commit being reverted, b3b274bc9d3d ("clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"), introduces a significant performance issue where the CPUs downclock to ~50% of their expected frequency under sustained load. The problem is reproducible both at boot and when running CPU-bound workloads such as stress-ng. Bisecting the issue pointed directly to this commit and reverting it restores correct cpufreq behaviour. The root cause appears to be related to the interaction between the simplified notifier callback and ACD (Adaptive Clock Distribution). Since we would prefer to keep ACD enabled for SoC reliability reasons, a revert is the safest option until a proper fix is identified. Full details are included in the commit message. Feedback & suggestions welcome. Cheers! Christopher Obbard --- drivers/clk/qcom/clk-cpu-8996.c | 30 +++++++++++------------------- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/drivers/clk/qcom/clk-cpu-8996.c b/drivers/clk/qcom/clk-cpu-8996.c index 21d13c0841ed..028476931747 100644 --- a/drivers/clk/qcom/clk-cpu-8996.c +++ b/drivers/clk/qcom/clk-cpu-8996.c @@ -547,35 +547,27 @@ static int cpu_clk_notifier_cb(struct notifier_block *nb, unsigned long event, { struct clk_cpu_8996_pmux *cpuclk = to_clk_cpu_8996_pmux_nb(nb); struct clk_notifier_data *cnd = data; + int ret; switch (event) { case PRE_RATE_CHANGE: + ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, ALT_INDEX); qcom_cpu_clk_msm8996_acd_init(cpuclk->clkr.regmap); - - /* - * Avoid overvolting. clk_core_set_rate_nolock() walks from top - * to bottom, so it will change the rate of the PLL before - * chaging the parent of PMUX. This can result in pmux getting - * clocked twice the expected rate. - * - * Manually switch to PLL/2 here. - */ - if (cnd->new_rate < DIV_2_THRESHOLD && - cnd->old_rate > DIV_2_THRESHOLD) - clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, SMUX_INDEX); - break; - case ABORT_RATE_CHANGE: - /* Revert manual change */ - if (cnd->new_rate < DIV_2_THRESHOLD && - cnd->old_rate > DIV_2_THRESHOLD) - clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, ACD_INDEX); + case POST_RATE_CHANGE: + if (cnd->new_rate < DIV_2_THRESHOLD) + ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, + SMUX_INDEX); + else + ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, + ACD_INDEX); break; default: + ret = 0; break; } - return NOTIFY_OK; + return notifier_from_errno(ret); }; static int qcom_cpu_clk_msm8996_driver_probe(struct platform_device *pdev) --- base-commit: c17e270dfb342a782d69c4a7c4c32980455afd9c change-id: 20251202-wip-obbardc-qcom-msm8096-clk-cpu-fix-downclock-b7561da4cb95 Best regards, -- Christopher Obbard <christopher.obbard(a)linaro.org>

6 days, 7 hours

3
9
0 0

[PATCH] block: fix partial IOVA mapping cleanup in blk_rq_dma_map_iova

by Chaitanya Kulkarni

When dma_iova_link() fails partway through mapping a request's bvec list, the function breaks out of the loop without cleaning up the already-mapped portions. Similarly, if dma_iova_sync() fails after all segments are linked, no cleanup is performed. This leaves the IOVA state partially mapped. The completion path (via dma_iova_destroy() or nvme_unmap_data()) then attempts to unmap the full expected size, but only a partial size was actually mapped. Fix by adding an out_unlink error path that calls dma_iova_destroy() to clean up any partial mapping before returning failure. The dma_iova_destroy() function handles both partial unlink and IOVA space freeing, and correctly handles the case where mapped_len is zero (first dma_iova_link() failed) by just freeing the IOVA allocation. This ensures that when an error occurs: 1. All partially-mapped IOVA ranges are properly unmapped 2. The IOVA address space is freed 3. The completion path won't attempt to unmap non-existent mappings Fixes: 858299dc6160 ("block: add scatterlist-less DMA mapping helpers") Cc: stable(a)vger.kernel.org Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux(a)gmail.com> --- Hi Leon, Your last email is not accessible to me. Updated the patch description to explain dma_iova_destroy(). Please let me know for any issues you want me to fix before I send. -ck --- block/blk-mq-dma.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c index fb018fffffdc..feead1934301 100644 --- a/block/blk-mq-dma.c +++ b/block/blk-mq-dma.c @@ -126,17 +126,20 @@ static bool blk_rq_dma_map_iova(struct request *req, struct device *dma_dev, error = dma_iova_link(dma_dev, state, vec->paddr, mapped, vec->len, dir, attrs); if (error) - break; + goto out_unlink; mapped += vec->len; } while (blk_map_iter_next(req, &iter->iter, vec)); error = dma_iova_sync(dma_dev, state, 0, mapped); - if (error) { - iter->status = errno_to_blk_status(error); - return false; - } + if (error) + goto out_unlink; return true; + +out_unlink: + dma_iova_destroy(dma_dev, state, mapped, dir, attrs); + iter->status = errno_to_blk_status(error); + return false; } static inline void blk_rq_map_iter_init(struct request *rq, -- 2.40.0

6 days, 8 hours

1
0
0 0

[PATCH] parisc: kernel: replace kfree() with put_device() in create_tree_node()

by Haoxiang Li

If device_register() fails, put_device() is the correct way to drop the device reference. Found by code review. Fixes: 1070c9655b90 ("[PA-RISC] Fix must_check warnings in drivers.c") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- arch/parisc/kernel/drivers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/kernel/drivers.c b/arch/parisc/kernel/drivers.c index 8d23fe42b0ce..809e3c171ad5 100644 --- a/arch/parisc/kernel/drivers.c +++ b/arch/parisc/kernel/drivers.c @@ -435,7 +435,7 @@ static struct parisc_device * __init create_tree_node(char id, dev->dev.dma_mask = &dev->dma_mask; dev->dev.coherent_dma_mask = dev->dma_mask; if (device_register(&dev->dev)) { - kfree(dev); + put_device(&dev->dev); return NULL; } -- 2.25.1

6 days, 10 hours

2
1
0 0

[PATCH 1/2] drm/nouveau/disp/nv50-: Set lock_core in curs507a_prepare

by Lyude Paul

For a while, I've been seeing a strange issue where some (usually not all) of the display DMA channels will suddenly hang, particularly when there is a visible cursor on the screen that is being frequently updated, and especially when said cursor happens to go between two screens. While this brings back lovely memories of fixing Intel Skylake bugs, I would quite like to fix it :). It turns out the problem that's happening here is that we're managing to reach nv50_head_flush_set() in our atomic commit path without actually holding nv50_disp->mutex. This means that cursor updates happening in parallel (along with any other atomic updates that need to use the core channel) will race with eachother, which eventually causes us to corrupt the pushbuffer - leading to a plethora of various GSP errors, usually: nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 00000218 00102680 00000004 00800003 nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 0000021c 00040509 00000004 00000001 nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 00000000 00000000 00000001 00000001 The reason this is happening is because generally we check whether we need to set nv50_atom->lock_core at the end of nv50_head_atomic_check(). However, curs507a_prepare is called from the fb_prepare callback, which happens after the atomic check phase. As a result, this can lead to commits that both touch the core channel but also don't grab nv50_disp->mutex. So, fix this by making sure that we set nv50_atom->lock_core in cus507a_prepare(). Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files") Cc: <stable(a)vger.kernel.org> # v4.18+ --- drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c index a95ee5dcc2e39..1a889139cb053 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c +++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c @@ -84,6 +84,7 @@ curs507a_prepare(struct nv50_wndw *wndw, struct nv50_head_atom *asyh, asyh->curs.handle = handle; asyh->curs.offset = offset; asyh->set.curs = asyh->curs.visible; + nv50_atom(asyh->state.state)->lock_core = true; } } -- 2.52.0

6 days, 10 hours

1
0
0 0

[PATCH] media: imagination: Fix value clamping in calculate_qp_tables

by Thorsten Blum

The local variable 'val' was never clamped to 1 or 255 because the return value of clamp() was not used. Fix this by assigning the clamped value back to 'val'. Cc: stable(a)vger.kernel.org Fixes: a1e294045885 ("media: imagination: Add E5010 JPEG Encoder driver") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/media/platform/imagination/e5010-jpeg-enc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/imagination/e5010-jpeg-enc.c b/drivers/media/platform/imagination/e5010-jpeg-enc.c index c4e0097cb8b7..a36a2acc896c 100644 --- a/drivers/media/platform/imagination/e5010-jpeg-enc.c +++ b/drivers/media/platform/imagination/e5010-jpeg-enc.c @@ -175,12 +175,12 @@ static void calculate_qp_tables(struct e5010_context *ctx) long long delta = v4l2_jpeg_ref_table_chroma_qt[i] * contrast + luminosity; int val = (int)(v4l2_jpeg_ref_table_chroma_qt[i] + delta); - clamp(val, 1, 255); + val = clamp(val, 1, 255); ctx->chroma_qp[i] = quality == -50 ? 1 : val; delta = v4l2_jpeg_ref_table_luma_qt[i] * contrast + luminosity; val = (int)(v4l2_jpeg_ref_table_luma_qt[i] + delta); - clamp(val, 1, 255); + val = clamp(val, 1, 255); ctx->luma_qp[i] = quality == -50 ? 1 : val; } -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

6 days, 11 hours

1
1
0 0

[PATCH v2] mm/memory-failure: fix missing ->mf_stats count in hugetlb poison

by Jane Chu

When a newly poisoned subpage ends up in an already poisoned hugetlb folio, 'num_poisoned_pages' is incremented, but the per node ->mf_stats is not. Fix the inconsistency by designating action_result() to update them both. While at it, define __get_huge_page_for_hwpoison() return values in terms of symbol names for better readibility. Also rename folio_set_hugetlb_hwpoison() to hugetlb_update_hwpoison() since the function does more than the conventional bit setting and the fact three possible return values are expected. Fixes: 18f41fa616ee4 ("mm: memory-failure: bump memory failure stats to pglist_data") Cc: <stable(a)vger.kernel.org> Signed-off-by: Jane Chu <jane.chu(a)oracle.com> --- v1 -> v2: adapted David and Liam's comment, define __get_huge_page_for_hwpoison() return values in terms of symbol names instead of naked integers for better readibility. #define instead of enum is used since the function has footprint outside MF, just try to limit the MF specifics local. also renamed folio_set_hugetlb_hwpoison() to hugetlb_update_hwpoison() since the function does more than the conventional bit setting and the fact three possible return values are expected. --- mm/memory-failure.c | 56 ++++++++++++++++++++++++++------------------- 1 file changed, 33 insertions(+), 23 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 3edebb0cda30..3eb9d23a4ad0 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1873,12 +1873,18 @@ static unsigned long __folio_free_raw_hwp(struct folio *folio, bool move_flag) return count; } -static int folio_set_hugetlb_hwpoison(struct folio *folio, struct page *page) +#define MF_HUGETLB_ALREADY_POISONED 3 /* already poisoned */ +#define MF_HUGETLB_ACC_EXISTING_POISON 4 /* accessed existing poisoned page */ +/* + * Set hugetlb folio as hwpoisoned, update folio private raw hwpoison list + * to keep track of the poisoned pages. + */ +static int hugetlb_update_hwpoison(struct folio *folio, struct page *page) { struct llist_head *head; struct raw_hwp_page *raw_hwp; struct raw_hwp_page *p; - int ret = folio_test_set_hwpoison(folio) ? -EHWPOISON : 0; + int ret = folio_test_set_hwpoison(folio) ? MF_HUGETLB_ALREADY_POISONED : 0; /* * Once the hwpoison hugepage has lost reliable raw error info, @@ -1886,20 +1892,18 @@ static int folio_set_hugetlb_hwpoison(struct folio *folio, struct page *page) * so skip to add additional raw error info. */ if (folio_test_hugetlb_raw_hwp_unreliable(folio)) - return -EHWPOISON; + return MF_HUGETLB_ALREADY_POISONED; + head = raw_hwp_list_head(folio); llist_for_each_entry(p, head->first, node) { if (p->page == page) - return -EHWPOISON; + return MF_HUGETLB_ACC_EXISTING_POISON; } raw_hwp = kmalloc(sizeof(struct raw_hwp_page), GFP_ATOMIC); if (raw_hwp) { raw_hwp->page = page; llist_add(&raw_hwp->node, head); - /* the first error event will be counted in action_result(). */ - if (ret) - num_poisoned_pages_inc(page_to_pfn(page)); } else { /* * Failed to save raw error info. We no longer trace all @@ -1945,32 +1949,30 @@ void folio_clear_hugetlb_hwpoison(struct folio *folio) folio_free_raw_hwp(folio, true); } +#define MF_HUGETLB_FREED 0 /* freed hugepage */ +#define MF_HUGETLB_IN_USED 1 /* in-use hugepage */ +#define MF_NOT_HUGETLB 2 /* not a hugepage */ + /* * Called from hugetlb code with hugetlb_lock held. - * - * Return values: - * 0 - free hugepage - * 1 - in-use hugepage - * 2 - not a hugepage - * -EBUSY - the hugepage is busy (try to retry) - * -EHWPOISON - the hugepage is already hwpoisoned */ int __get_huge_page_for_hwpoison(unsigned long pfn, int flags, bool *migratable_cleared) { struct page *page = pfn_to_page(pfn); struct folio *folio = page_folio(page); - int ret = 2; /* fallback to normal page handling */ + int ret = MF_NOT_HUGETLB; bool count_increased = false; + int rc; if (!folio_test_hugetlb(folio)) goto out; if (flags & MF_COUNT_INCREASED) { - ret = 1; + ret = MF_HUGETLB_IN_USED; count_increased = true; } else if (folio_test_hugetlb_freed(folio)) { - ret = 0; + ret = MF_HUGETLB_FREED; } else if (folio_test_hugetlb_migratable(folio)) { ret = folio_try_get(folio); if (ret) @@ -1981,8 +1983,9 @@ int __get_huge_page_for_hwpoison(unsigned long pfn, int flags, goto out; } - if (folio_set_hugetlb_hwpoison(folio, page)) { - ret = -EHWPOISON; + rc = hugetlb_update_hwpoison(folio, page); + if (rc >= MF_HUGETLB_ALREADY_POISONED) { + ret = rc; goto out; } @@ -2019,22 +2022,29 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb *hugetlb = 1; retry: res = get_huge_page_for_hwpoison(pfn, flags, &migratable_cleared); - if (res == 2) { /* fallback to normal page handling */ + switch (res) { + case MF_NOT_HUGETLB: /* fallback to normal page handling */ *hugetlb = 0; return 0; - } else if (res == -EHWPOISON) { + case MF_HUGETLB_ALREADY_POISONED: + case MF_HUGETLB_ACC_EXISTING_POISON: if (flags & MF_ACTION_REQUIRED) { folio = page_folio(p); res = kill_accessing_process(current, folio_pfn(folio), flags); } - action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); + if (res == MF_HUGETLB_ALREADY_POISONED) + action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); + else + action_result(pfn, MF_MSG_HUGE, MF_FAILED); return res; - } else if (res == -EBUSY) { + case -EBUSY: if (!(flags & MF_NO_RETRY)) { flags |= MF_NO_RETRY; goto retry; } return action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED); + default: + break; } folio = page_folio(p); -- 2.43.5

6 days, 13 hours

1
0
0 0

[PATCH 02/23] PCI: Rewrite bridge window head alignment function

by Ilpo Järvinen

The calculation of bridge window head alignment is done by calculate_mem_align() [*]. With the default bridge window alignment, it is used for both head and tail alignment. The selected head alignment does not always result in tight-fitting resources (gap at d4f00000-d4ffffff): d4800000-dbffffff : PCI Bus 0000:06 d4800000-d48fffff : PCI Bus 0000:07 d4800000-d4803fff : 0000:07:00.0 d4800000-d4803fff : nvme d4900000-d49fffff : PCI Bus 0000:0a d4900000-d490ffff : 0000:0a:00.0 d4900000-d490ffff : r8169 d4910000-d4913fff : 0000:0a:00.0 d4a00000-d4cfffff : PCI Bus 0000:0b d4a00000-d4bfffff : 0000:0b:00.0 d4a00000-d4bfffff : 0000:0b:00.0 d4c00000-d4c07fff : 0000:0b:00.0 d4d00000-d4dfffff : PCI Bus 0000:15 d4d00000-d4d07fff : 0000:15:00.0 d4d00000-d4d07fff : xhci-hcd d4e00000-d4efffff : PCI Bus 0000:16 d4e00000-d4e7ffff : 0000:16:00.0 d4e80000-d4e803ff : 0000:16:00.0 d4e80000-d4e803ff : ahci d5000000-dbffffff : PCI Bus 0000:0c This has not been caused problems (for years) with the default bridge window tail alignment that grossly over-estimates the required tail alignment leaving more tail room than necessary. With the introduction of relaxed tail alignment that leaves no extra tail room whatsoever, any gaps will immediately turn into assignment failures. Introduce head alignment calculation that ensures no gaps are left and apply the new approach when using relaxed alignment. We may want to consider using it for the normal alignment eventually, but as the first step, solve only the problem with the relaxed tail alignment. ([*] I don't understand the algorithm in calculate_mem_align().) Fixes: 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220775 Reported-by: Malte Schröder <malte+lkml(a)tnxip.de> Tested-by: Malte Schröder <malte+lkml(a)tnxip.de> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- Little annoyingly, there's difference in what aligns array contains between the legacy alignment approach (which I dare not to touch as I really don't understand what the algorithm tries to do) and this new head aligment algorithm, both consuming stack space. After making the new approach the only available approach in the follow-up patch, only one array remains (however, that follow-up change is also somewhat riskier when it comes to regressions). That being said, the new head alignment could work with the same aligns array as the legacy approach, it just won't necessarily produce an optimal (the smallest possible) head alignment when if (r_size <= align) condition is used. Just let me know if that approach is preferred (to save some stack space). --- drivers/pci/setup-bus.c | 53 ++++++++++++++++++++++++++++++++++------- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 4b918ff4d2d8..80e5a8fc62e7 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1228,6 +1228,45 @@ static inline resource_size_t calculate_mem_align(resource_size_t *aligns, return min_align; } +/* + * Calculate bridge window head alignment that leaves no gaps in between + * resources. + */ +static resource_size_t calculate_head_align(resource_size_t *aligns, + int max_order) +{ + resource_size_t head_align = 1; + resource_size_t remainder = 0; + int order; + + /* Take the largest alignment as the starting point. */ + head_align <<= max_order + __ffs(SZ_1M); + + for (order = max_order - 1; order >= 0; order--) { + resource_size_t align1 = 1; + + align1 <<= order + __ffs(SZ_1M); + + /* + * Account smaller resources with alignment < max_order that + * could be used to fill head room if alignment less than + * max_order is used. + */ + remainder += aligns[order]; + + /* + * Test if head fill is enough to satisfy the alignment of + * the larger resources after reducing the alignment. + */ + while ((head_align > align1) && (remainder >= head_align / 2)) { + head_align /= 2; + remainder -= head_align; + } + } + + return head_align; +} + /** * pbus_upstream_space_available - Check no upstream resource limits allocation * @bus: The bus @@ -1315,13 +1354,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, { struct pci_dev *dev; resource_size_t min_align, win_align, align, size, size0, size1 = 0; - resource_size_t aligns[28]; /* Alignments from 1MB to 128TB */ + resource_size_t aligns[28] = {}; /* Alignments from 1MB to 128TB */ + resource_size_t aligns2[28] = {};/* Alignments from 1MB to 128TB */ int order, max_order; struct resource *b_res = pbus_select_window_for_type(bus, type); resource_size_t children_add_size = 0; resource_size_t children_add_align = 0; resource_size_t add_align = 0; - resource_size_t relaxed_align; resource_size_t old_size; if (!b_res) @@ -1331,7 +1370,6 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (b_res->parent) return; - memset(aligns, 0, sizeof(aligns)); max_order = 0; size = 0; @@ -1382,6 +1420,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, */ if (r_size <= align) aligns[order] += align; + aligns2[order] += align; if (order > max_order) max_order = order; @@ -1406,9 +1445,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (bus->self && size0 && !pbus_upstream_space_available(bus, b_res, size0, min_align)) { - relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align = max(relaxed_align, win_align); - min_align = min(min_align, relaxed_align); + min_align = calculate_head_align(aligns2, max_order); size0 = calculate_memsize(size, min_size, 0, 0, old_size, win_align); resource_set_range(b_res, min_align, size0); pci_info(bus->self, "bridge window %pR to %pR requires relaxed alignment rules\n", @@ -1422,9 +1459,7 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, if (bus->self && size1 && !pbus_upstream_space_available(bus, b_res, size1, add_align)) { - relaxed_align = 1ULL << (max_order + __ffs(SZ_1M)); - relaxed_align = max(relaxed_align, win_align); - min_align = min(min_align, relaxed_align); + min_align = calculate_head_align(aligns2, max_order); size1 = calculate_memsize(size, min_size, add_size, children_add_size, old_size, win_align); pci_info(bus->self, -- 2.39.5

6 days, 15 hours

1
0
0 0

[PATCH 01/23] PCI: Fix bridge window alignment with optional resources

by Ilpo Järvinen

pbus_size_mem() has two alignments, one for required resources in min_align and another in add_align that takes account optional resources. The add_align is applied to the bridge window through the realloc_head list. It can happen, however, that add_align is larger than min_align but calculated size1 and size0 are equal due to extra tailroom (e.g., hotplug reservation, tail alignment), and therefore no entry is created to the realloc_head list. Without the bridge appearing in the realloc head, add_align is lost when pbus_size_mem() returns. The problem is visible in this log for 0000:05:00.0 which lacks add_size ... add_align ... line that would indicate it was added into the realloc_head list: pci 0000:05:00.0: PCI bridge to [bus 06-16] ... pci 0000:06:00.0: bridge window [mem 0x00100000-0x001fffff] to [bus 07] requires relaxed alignment rules pci 0000:06:06.0: bridge window [mem 0x00100000-0x001fffff] to [bus 0a] requires relaxed alignment rules pci 0000:06:07.0: bridge window [mem 0x00100000-0x003fffff] to [bus 0b] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x00800000-0x00ffffff 64bit pref] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] requires relaxed alignment rules pci 0000:06:08.0: bridge window [mem 0x01000000-0x057fffff] to [bus 0c-14] add_size 100000 add_align 1000000 pci 0000:06:0c.0: bridge window [mem 0x00100000-0x001fffff] to [bus 15] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:06:0d.0: bridge window [mem 0x00100000-0x001fffff] to [bus 16] requires relaxed alignment rules pci 0000:05:00.0: bridge window [mem 0xd4800000-0xd97fffff]: assigned pci 0000:05:00.0: bridge window [mem 0x1060000000-0x10607fffff 64bit pref]: assigned pci 0000:06:08.0: bridge window [mem size 0x04900000]: can't assign; no space pci 0000:06:08.0: bridge window [mem size 0x04900000]: failed to assign While this bug itself seems old, it has likely become more visible after the relaxed tail alignment that does not grossly overestimate the size needed for the bridge window. Make sure add_align > min_align too results in adding an entry into the realloc head list. In addition, add handling to the cases where add_size is zero while only alignment differs. Fixes: d74b9027a4da ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning") Reported-by: Malte Schröder <malte+lkml(a)tnxip.de> Tested-by: Malte Schröder <malte+lkml(a)tnxip.de> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/pci/setup-bus.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 6e90f46f52af..4b918ff4d2d8 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -14,6 +14,7 @@ * tighter packing. Prefetchable range support. */ +#include <linux/align.h> #include <linux/bitops.h> #include <linux/bug.h> #include <linux/init.h> @@ -456,7 +457,7 @@ static void reassign_resources_sorted(struct list_head *realloc_head, "%s %pR: ignoring failure in optional allocation\n", res_name, res); } - } else if (add_size > 0) { + } else if (add_size > 0 || !IS_ALIGNED(res->start, align)) { res->flags |= add_res->flags & (IORESOURCE_STARTALIGN|IORESOURCE_SIZEALIGN); if (pci_reassign_resource(dev, idx, add_size, align)) @@ -1442,12 +1443,13 @@ static void pbus_size_mem(struct pci_bus *bus, unsigned long type, resource_set_range(b_res, min_align, size0); b_res->flags |= IORESOURCE_STARTALIGN; - if (bus->self && size1 > size0 && realloc_head) { + if (bus->self && realloc_head && (size1 > size0 || add_align > min_align)) { b_res->flags &= ~IORESOURCE_DISABLED; - add_to_list(realloc_head, bus->self, b_res, size1-size0, add_align); + add_size = size1 > size0 ? size1 - size0 : 0; + add_to_list(realloc_head, bus->self, b_res, add_size, add_align); pci_info(bus->self, "bridge window %pR to %pR add_size %llx add_align %llx\n", b_res, &bus->busn_res, - (unsigned long long) (size1 - size0), + (unsigned long long) add_size, (unsigned long long) add_align); } } -- 2.39.5

6 days, 15 hours

1
0
0 0

[regression 5.10.y] Libvirt can no longer delete macvtap devices after backport of a6cec0bcd342 ("net: rtnetlink: add bulk delete support flag") to 5.10.y series (Debian 11)

by Salvatore Bonaccorso

Hi all, Roland Schwarzkopf reported to the Debian mailing list a problem which he encountered once updating in Debian from 5.10.244 to 5.10.247. The report is quoted below and found in https://lists.debian.org/debian-kernel/2025/12/msg00223.html Roland did bisect the changes between 5.10.244 to 5.10.247 and found that the issue is introduced with 1550f3673972 ("net: rtnetlink: add bulk delete support flag") which is the backport to the 5.10.y series. On Thu, Dec 18, 2025 at 02:59:55PM +0100, Roland Schwarzkopf wrote: > Hi Salvatore, > > On 12/17/25 20:28, Salvatore Bonaccorso wrote: > > Hi Roland, > > > > I'm CC'ing Ben Hutchings directly as well as he takes care of the > > Debian LTS kernel updates. Idellly we make this as well a proper bug > > for easier tracking. > > > > On Wed, Dec 17, 2025 at 01:35:54PM +0100, Roland Schwarzkopf wrote: > > > Hi there, > > > > > > after upgrading to the latest kernel on Debian 11 > > > (linux-image-5.10.0-37-amd64) I have an issue using libvirt with qemu/kvm > > > virtual machines and macvtap networking. When a machine is shut down, > > > libvirt can not delete the corresponding macvtap device. Thus, starting the > > > machine again is not possible. After manually removing the macvtap device > > > using `ip link delete` the vm can be started again. > > > > > > In the journal the following message is shown: > > > > > > Dec 17 13:19:27 iblis libvirtd[535]: error destroying network device macvtap0: Operation not supported > > > > > > After downgrading the kernel to linux-image-5.10.0-36-amd64, the problem > > > disappears. I tested this on a fresh minimal install of Debian 11 - to > > > exclude that anything else on my production machines is causing this issue. > > > > > > Since the older kernel does not have this issue, I assume this is related to > > > the kernel and not to libvirt? > > > > > > I tried to check for bug reports of the kernel package, but the bug tracker > > > finds no reports and even states that the package does not exist (I used the > > > "Bug reports" link on > > > https://packages.debian.org/bullseye/linux-image-5.10.0-37-amd64). This left > > > me a bit puzzled. Since I don't have experience with the debian bug > > > reporting process, I had no other idea than writing to this list. > > You would need to search for inhttps://bugs.debian.org/src:linux , > > but that said I'm not aware of any bug reports in that direction. > > > > Would you be in the position of bisecting the problem as you can say > > that 5.10.244 is good and 5.10.247 is bad and regressed? If you can do > > that that would involve compiling a couple of kernels to narrow down > > where the problem is introduced: > > > > git clone --single-branch -b linux-5.10.yhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-st… > > cd linux-stable > > git checkout v5.10.244 > > cp /boot/config-$(uname -r) .config > > yes '' | make localmodconfig > > make savedefconfig > > mv defconfig arch/x86/configs/my_defconfig > > > > # test 5.10.244 to ensure this is "good" > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install the resulting .deb package and confirm it successfully boots / problem does not exist > > > > # test 5.10.247 to ensure this is "bad" > > git checkout v5.10.247 > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install the resulting .deb package and confirm it fails to boot / problem exists > > > > With that confirmed, the bisection can start: > > > > git bisect start > > git bisect good v5.10.244 > > git bisect bad v5.10.247 > > > > In each bisection step git checks out a state between the oldest > > known-bad and the newest known-good commit. In each step test using: > > > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install, try to boot / verify if problem exists > > > > and if the problem is hit run: > > > > git bisect bad > > > > and if the problem doesn't trigger run: > > > > git bisect good > > > > . Please pay attention to always select the just built kernel for > > booting, it won't always be the default kernel picked up by grub. > > > > Iterate until git announces to have identified the first bad commit. > > > > Then provide the output of > > > > git bisect log > > > > In the course of the bisection you might have to uninstall previous > > kernels again to not exhaust the disk space in /boot. Also in the end > > uninstall all self-built kernels again. > > I just did my first bisection \o/ (sorry) > > Here are the results: > > git bisect start > # bad: [f964b940099f9982d723d4c77988d4b0dda9c165] Linux 5.10.247 > git bisect bad f964b940099f9982d723d4c77988d4b0dda9c165 > # good: [863b76df7d1e327979946a2d3893479c3275bfa4] Linux 5.10.244 > git bisect good f52ee6ea810273e527a5d319e5f400be8c8424c1 > # good: [dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1] net: usb: lan78xx: Add error handling to lan78xx_init_mac_address > git bisect good dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1 > # bad: [2272d5757ce5d3fb416d9f2497b015678eb85c0d] phy: cadence: cdns-dphy: Enable lower resolutions in dphy > git bisect bad 2272d5757ce5d3fb416d9f2497b015678eb85c0d > # bad: [547539f08b9e3629ce68479889813e58c8087e70] ALSA: usb-audio: fix control pipe direction > git bisect bad 547539f08b9e3629ce68479889813e58c8087e70 > # bad: [3509c748e79435d09e730673c8c100b7f0ebc87c] most: usb: hdm_probe: Fix calling put_device() before device initialization > git bisect bad 3509c748e79435d09e730673c8c100b7f0ebc87c > # bad: [a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0] net: add ndo_fdb_del_bulk > git bisect bad a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0 > # good: [b8a72692aa42b7dcd179a96b90bc2763ac74576a] hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() > git bisect good b8a72692aa42b7dcd179a96b90bc2763ac74576a > # good: [2b42a595863556b394bd702d46f4a9d0d2985aaa] m68k: bitops: Fix find_*_bit() signatures > git bisect good 2b42a595863556b394bd702d46f4a9d0d2985aaa > # good: [9d9f7d71d46cff3491a443a3cf452cecf87d51ef] net: rtnetlink: use BIT for flag values > git bisect good 9d9f7d71d46cff3491a443a3cf452cecf87d51ef > # bad: [1550f3673972c5cfba714135f8bf26784e6f2b0f] net: rtnetlink: add bulk delete support flag > git bisect bad 1550f3673972c5cfba714135f8bf26784e6f2b0f > # good: [c8879afa24169e504f78c9ca43a4d0d7397049eb] net: netlink: add NLM_F_BULK delete request modifier > git bisect good c8879afa24169e504f78c9ca43a4d0d7397049eb > # first bad commit: [1550f3673972c5cfba714135f8bf26784e6f2b0f] net: rtnetlink: add bulk delete support flag > > Is there anything else I can do to help? Is there soemthing missing? Roland I think it would be helpful if you can test as well more recent stable series versions to confirm if the issue is present there as well or not, which might indicate a 5.10.y specific backporting problem. #regzbot introduced: 1550f3673972c5cfba714135f8bf26784e6f2b0f Regards, Salvatore

6 days, 15 hours

3
2
0 0

[PATCH] drm/fsl-dcu: fix clock reference leak in fsl_tcon_init error path

by Miaoqian Lin

In fsl_tcon_init(), when of_clk_get_by_name() succeeds but clk_prepare_enable() fails, the function jumps to err_node_put label without releasing the clock reference obtained. This causes a clock reference leak. Fix by calling clk_put() that properly releases the clock reference. Found via static analysis and code review. Fixes: fb127b7943c9 ("drm/fsl-dcu: add TCON driver") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c index 49bbd00c77ae..b7ba90814b0e 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c @@ -86,7 +86,7 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev) ret = clk_prepare_enable(tcon->ipg_clk); if (ret) { dev_err(dev, "Couldn't enable the TCON clock\n"); - goto err_node_put; + goto err_clk_put; } of_node_put(np); @@ -94,6 +94,8 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev) return tcon; +err_clk_put: + clk_put(tcon->ipg_clk); err_node_put: of_node_put(np); return NULL; -- 2.25.1

6 days, 17 hours

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror