March 2025 - Linux-stable-mirror

+ 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

9 months, 1 week

1
0
0 0

+ mm-mremap-correctly-handle-partial-mremap-of-vma-starting-at-0.patch added to mm-unstable branch

by Andrew Morton

The patch titled Subject: mm/mremap: correctly handle partial mremap() of VMA starting at 0 has been added to the -mm mm-unstable branch. Its filename is mm-mremap-correctly-handle-partial-mremap-of-vma-starting-at-0.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-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: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Subject: mm/mremap: correctly handle partial mremap() of VMA starting at 0 Date: Mon, 10 Mar 2025 20:50:34 +0000 Patch series "refactor mremap and fix bug", v3. The existing mremap() logic has grown organically over a very long period of time, resulting in code that is in many parts, very difficult to follow and full of subtleties and sources of confusion. In addition, it is difficult to thread state through the operation correctly, as function arguments have expanded, some parameters are expected to be temporarily altered during the operation, others are intended to remain static and some can be overridden. This series completely refactors the mremap implementation, sensibly separating functions, adding comments to explain the more subtle aspects of the implementation and making use of small structs to thread state through everything. The reason for doing so is to lay the groundwork for planned future changes to the mremap logic, changes which require the ability to easily pass around state. Additionally, it would be unhelpful to add yet more logic to code that is already difficult to follow without first refactoring it like this. The first patch in this series additionally fixes a bug when a VMA with start address zero is partially remapped. Tested on real hardware under heavy workload and all self tests are passing. This patch (of 3): Consider the case of a partial mremap() (that results in a VMA split) of an accountable VMA (i.e. which has the VM_ACCOUNT flag set) whose start address is zero, with the MREMAP_MAYMOVE flag specified and a scenario where a move does in fact occur: addr end | | v v |-------------| | vma | |-------------| 0 This move is affected by unmapping the range [addr, end). In order to prevent an incorrect decrement of accounted memory which has already been determined, the mremap() code in move_vma() clears VM_ACCOUNT from the VMA prior to doing so, before reestablishing it in each of the VMAs post-split: addr end | | v v |---| |---| | A | | B | |---| |---| Commit 6b73cff239e5 ("mm: change munmap splitting order and move_vma()") changed this logic such as to determine whether there is a need to do so by establishing account_start and account_end and, in the instance where such an operation is required, assigning them to vma->vm_start and vma->vm_end. Later the code checks if the operation is required for 'A' referenced above thusly: if (account_start) { ... } However, if the VMA described above has vma->vm_start == 0, which is now assigned to account_start, this branch will not be executed. As a result, the VMA 'A' above will remain stripped of its VM_ACCOUNT flag, incorrectly. The fix is to simply convert these variables to booleans and set them as required. Link: https://lkml.kernel.org/r/cover.1741639347.git.lorenzo.stoakes@oracle.com Link: https://lkml.kernel.org/r/dc55cb6db25d97c3d9e460de4986a323fa959676.17416393… Fixes: 6b73cff239e5 ("mm: change munmap splitting order and move_vma()") Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reviewed-by: Harry Yoo <harry.yoo(a)oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mremap.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/mm/mremap.c~mm-mremap-correctly-handle-partial-mremap-of-vma-starting-at-0 +++ a/mm/mremap.c @@ -705,8 +705,8 @@ static unsigned long move_vma(struct vm_ unsigned long vm_flags = vma->vm_flags; unsigned long new_pgoff; unsigned long moved_len; - unsigned long account_start = 0; - unsigned long account_end = 0; + bool account_start = false; + bool account_end = false; unsigned long hiwater_vm; int err = 0; bool need_rmap_locks; @@ -790,9 +790,9 @@ static unsigned long move_vma(struct vm_ if (vm_flags & VM_ACCOUNT && !(flags & MREMAP_DONTUNMAP)) { vm_flags_clear(vma, VM_ACCOUNT); if (vma->vm_start < old_addr) - account_start = vma->vm_start; + account_start = true; if (vma->vm_end > old_addr + old_len) - account_end = vma->vm_end; + account_end = true; } /* @@ -832,7 +832,7 @@ static unsigned long move_vma(struct vm_ /* OOM: unable to split vma, just get accounts right */ if (vm_flags & VM_ACCOUNT && !(flags & MREMAP_DONTUNMAP)) vm_acct_memory(old_len >> PAGE_SHIFT); - account_start = account_end = 0; + account_start = account_end = false; } if (vm_flags & VM_LOCKED) { _ Patches currently in -mm which might be from lorenzo.stoakes(a)oracle.com are mm-simplify-vma-merge-structure-and-expand-comments.patch mm-further-refactor-commit_merge.patch mm-eliminate-adj_start-parameter-from-commit_merge.patch mm-make-vmg-target-consistent-and-further-simplify-commit_merge.patch mm-completely-abstract-unnecessary-adj_start-calculation.patch mm-madvise-split-out-mmap-locking-operations-for-madvise-fix.patch mm-use-read-write_once-for-vma-vm_flags-on-migrate-mprotect.patch mm-refactor-rmap_walk_file-to-separate-out-traversal-logic.patch mm-provide-mapping_wrprotect_range-function.patch fb_defio-do-not-use-deprecated-page-mapping-index-fields.patch fb_defio-do-not-use-deprecated-page-mapping-index-fields-fix.patch mm-allow-guard-regions-in-file-backed-and-read-only-mappings.patch selftests-mm-rename-guard-pages-to-guard-regions.patch selftests-mm-rename-guard-pages-to-guard-regions-fix.patch tools-selftests-expand-all-guard-region-tests-to-file-backed.patch tools-selftests-add-file-shmem-backed-mapping-guard-region-tests.patch fs-proc-task_mmu-add-guard-region-bit-to-pagemap.patch tools-selftests-add-guard-region-test-for-proc-pid-pagemap.patch tools-selftests-add-guard-region-test-for-proc-pid-pagemap-fix.patch mm-mremap-correctly-handle-partial-mremap-of-vma-starting-at-0.patch mm-mremap-refactor-mremap-system-call-implementation.patch mm-mremap-introduce-and-use-vma_remap_struct-threaded-state.patch mm-mremap-initial-refactor-of-move_vma.patch mm-mremap-complete-refactor-of-move_vma.patch mm-mremap-refactor-move_page_tables-abstracting-state.patch mm-mremap-thread-state-through-move-page-table-operation.patch

9 months, 1 week

1
0
0 0

[PATCH] drm/dp_mst: Fix locking when skipping CSN before topology probing

by Imre Deak

The handling of the MST Connection Status Notify message is skipped if the probing of the topology is still pending. Acquiring the drm_dp_mst_topology_mgr::probe_lock for this in drm_dp_mst_handle_up_req() is problematic: the task/work this function is called from is also responsible for handling MST down-request replies (in drm_dp_mst_handle_down_rep()). Thus drm_dp_mst_link_probe_work() - holding already probe_lock - could be blocked waiting for an MST down-request reply while drm_dp_mst_handle_up_req() is waiting for probe_lock while processing a CSN message. This leads to the probe work's down-request message timing out. A scenario similar to the above leading to a down-request timeout is handling a CSN message in drm_dp_mst_handle_conn_stat(), holding the probe_lock and sending down-request messages while a second CSN message sent by the sink subsequently is handled by drm_dp_mst_handle_up_req(). Fix the above by moving the logic to skip the CSN handling to drm_dp_mst_process_up_req(). This function is called from a work (separate from the task/work handling new up/down messages), already holding probe_lock. This solves the above timeout issue, since handling of down-request replies won't be blocked by probe_lock. Fixes: ddf983488c3e ("drm/dp_mst: Skip CSN if topology probing is not done yet") Cc: Wayne Lin <Wayne.Lin(a)amd.com> Cc: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org # v6.6+ Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 40 +++++++++++-------- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index 8b68bb3fbffb0..3a1f1ffc7b552 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -4036,6 +4036,22 @@ static int drm_dp_mst_handle_down_rep(struct drm_dp_mst_topology_mgr *mgr) return 0; } +static bool primary_mstb_probing_is_done(struct drm_dp_mst_topology_mgr *mgr) +{ + bool probing_done = false; + + mutex_lock(&mgr->lock); + + if (mgr->mst_primary && drm_dp_mst_topology_try_get_mstb(mgr->mst_primary)) { + probing_done = mgr->mst_primary->link_address_sent; + drm_dp_mst_topology_put_mstb(mgr->mst_primary); + } + + mutex_unlock(&mgr->lock); + + return probing_done; +} + static inline bool drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_pending_up_req *up_req) @@ -4066,8 +4082,12 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr *mgr, /* TODO: Add missing handler for DP_RESOURCE_STATUS_NOTIFY events */ if (msg->req_type == DP_CONNECTION_STATUS_NOTIFY) { - dowork = drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat); - hotplug = true; + if (!primary_mstb_probing_is_done(mgr)) { + drm_dbg_kms(mgr->dev, "Got CSN before finish topology probing. Skip it.\n"); + } else { + dowork = drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat); + hotplug = true; + } } drm_dp_mst_topology_put_mstb(mstb); @@ -4149,10 +4169,11 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) drm_dp_send_up_ack_reply(mgr, mst_primary, up_req->msg.req_type, false); + drm_dp_mst_topology_put_mstb(mst_primary); + if (up_req->msg.req_type == DP_CONNECTION_STATUS_NOTIFY) { const struct drm_dp_connection_status_notify *conn_stat = &up_req->msg.u.conn_stat; - bool handle_csn; drm_dbg_kms(mgr->dev, "Got CSN: pn: %d ldps:%d ddps: %d mcs: %d ip: %d pdt: %d\n", conn_stat->port_number, @@ -4161,16 +4182,6 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) conn_stat->message_capability_status, conn_stat->input_port, conn_stat->peer_device_type); - - mutex_lock(&mgr->probe_lock); - handle_csn = mst_primary->link_address_sent; - mutex_unlock(&mgr->probe_lock); - - if (!handle_csn) { - drm_dbg_kms(mgr->dev, "Got CSN before finish topology probing. Skip it."); - kfree(up_req); - goto out_put_primary; - } } else if (up_req->msg.req_type == DP_RESOURCE_STATUS_NOTIFY) { const struct drm_dp_resource_status_notify *res_stat = &up_req->msg.u.resource_stat; @@ -4185,9 +4196,6 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) list_add_tail(&up_req->next, &mgr->up_req_list); mutex_unlock(&mgr->up_req_lock); queue_work(system_long_wq, &mgr->up_req_work); - -out_put_primary: - drm_dp_mst_topology_put_mstb(mst_primary); out_clear_reply: reset_msg_rx_state(&mgr->up_req_recv); return ret; -- 2.44.2

9 months, 1 week

3
5
0 0

[5.4/5.10/5.15/6.1/6.6] spi-mxs: Fix chipselect glitch

by Stefan Wahren

Dear stable team, I noticed that ceeeb99cd821 ("dmaengine: mxs: rename custom flag") got backported, but the additional fix 269e31aecdd0 ("spi-mxs: Fix chipselect glitch") hasn't. I think was caused by the lack of Cc to stable. Without the latter patch the SPI is causing glitches on MXS platform. Please backport it from 5.4 to 6.6. Thanks Stefan

9 months, 1 week

2
2
0 0

[PATCH 1/2] regulator: dummy: force synchronous probing

by Christian Eggers

Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack: anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get() By placing some extra BUG_ON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL). In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously. Cc: stable(a)vger.kernel.org Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by: Christian Eggers <ceggers(a)arri.de> --- drivers/regulator/dummy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/dummy.c b/drivers/regulator/dummy.c index 5b9b9e4e762d..9f59889129ab 100644 --- a/drivers/regulator/dummy.c +++ b/drivers/regulator/dummy.c @@ -60,7 +60,7 @@ static struct platform_driver dummy_regulator_driver = { .probe = dummy_regulator_probe, .driver = { .name = "reg-dummy", - .probe_type = PROBE_PREFER_ASYNCHRONOUS, + .probe_type = PROBE_FORCE_SYNCHRONOUS, }, }; -- 2.43.0

9 months, 1 week

3
4
0 0

[PATCH 2/3] usb: chipidea: ci_hdrc_imx: disable regulator on error path in probe

by Fedor Pchelkin

Upon encountering errors during the HSIC pinctrl handling section the regulator should be disabled. After the above-stated changes it is possible to jump onto "disable_hsic_regulator" label without having added the CPU latency QoS request previously. This would result in cpu_latency_qos_remove_request() yielding a WARNING. So rearrange the error handling path to follow the reverse order of different probing phases. Found by Linux Verification Center (linuxtesting.org). Fixes: 4d6141288c33 ("usb: chipidea: imx: pinctrl for HSIC is optional") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- drivers/usb/chipidea/ci_hdrc_imx.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index 619779eef333..3f11ae071c7f 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -407,13 +407,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) "pinctrl_hsic_idle lookup failed, err=%ld\n", PTR_ERR(pinctrl_hsic_idle)); ret = PTR_ERR(pinctrl_hsic_idle); - goto err_put; + goto disable_hsic_regulator; } ret = pinctrl_select_state(data->pinctrl, pinctrl_hsic_idle); if (ret) { dev_err(dev, "hsic_idle select failed, err=%d\n", ret); - goto err_put; + goto disable_hsic_regulator; } data->pinctrl_hsic_active = pinctrl_lookup_state(data->pinctrl, @@ -423,7 +423,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) "pinctrl_hsic_active lookup failed, err=%ld\n", PTR_ERR(data->pinctrl_hsic_active)); ret = PTR_ERR(data->pinctrl_hsic_active); - goto err_put; + goto disable_hsic_regulator; } } @@ -432,11 +432,11 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) ret = imx_get_clks(dev); if (ret) - goto disable_hsic_regulator; + goto qos_remove_request; ret = imx_prepare_enable_clks(dev); if (ret) - goto disable_hsic_regulator; + goto qos_remove_request; ret = clk_prepare_enable(data->clk_wakeup); if (ret) @@ -526,12 +526,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) clk_disable_unprepare(data->clk_wakeup); err_wakeup_clk: imx_disable_unprepare_clks(dev); +qos_remove_request: + if (pdata.flags & CI_HDRC_PMQOS) + cpu_latency_qos_remove_request(&data->pm_qos_req); disable_hsic_regulator: if (data->hsic_pad_regulator) /* don't overwrite original ret (cf. EPROBE_DEFER) */ regulator_disable(data->hsic_pad_regulator); - if (pdata.flags & CI_HDRC_PMQOS) - cpu_latency_qos_remove_request(&data->pm_qos_req); data->ci_pdev = NULL; err_put: if (data->usbmisc_data) -- 2.48.1

9 months, 1 week

2
2
0 0

[PATCH 6.1.y] KVM: selftests: Fix build error due to assert in dirty_log_test

by Andrey Kalachev

Hi all. Please apply that forgotten patch to fix v6.1 KVM selftests broken build. Origin of the patch can be founded here [1] Regards, AK [1] https://lore.kernel.org/stable/20240403164230.1722018-1-rananta@google.com/ -- 2.30.2

9 months, 1 week

1
1
0 0

Re: Patch "drm/i915: Plumb 'dsb' all way to the plane hooks" has been added to the 6.12-stable tree

by Ville Syrjälä

On Sun, Mar 09, 2025 at 03:45:57PM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/i915: Plumb 'dsb' all way to the plane hooks > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-i915-plumb-dsb-all-way-to-the-plane-hooks.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit f03e7cca22f4bb50cae98840f91fcf1e6d780a54 > Author: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > Date: Mon Sep 30 20:04:13 2024 +0300 > > drm/i915: Plumb 'dsb' all way to the plane hooks > > [ Upstream commit 01389846f7d61d262cc92d42ad4d1a25730e3eff ] It would help if you actually mentioned *why* you need to backport this? -- Ville Syrjälä Intel

9 months, 1 week

2
2
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) +arch/x86/events/amd/../perf_event.h:855:21: error: invalid output...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- +arch/x86/events/amd/../perf_event.h:855:21: error: invalid output size for constraint '=q' in arch/x86/events/amd/core.o (arch/x86/events/amd/core.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/issue/maestro:d36536187d181e0823b2aa631ebf9936dd657c… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 888d41479bea1f83b835311f71a91f5e08f6c4d7 Log excerpt: ===================================================== In file included from arch/x86/events/amd/core.c:12: +arch/x86/events/amd/../perf_event.h:855:21: error: invalid output size for constraint '=q' ./include/linux/percpu-defs.h:446:2: note: expanded from macro '__this_cpu_read' 446 | raw_cpu_read(pcp); \ | ^ ./include/linux/percpu-defs.h:420:28:.. note: expanded from macro 'raw_cpu_read' 420 | #define raw_cpu_read(pcp) __pcpu_size_call_return(raw_cpu_read_, pcp) | ^ ./include/linux/percpu-defs.h:323:23: note: expanded from macro '__pcpu_size_call_return' 323 | case 4: pscr_ret__ = stem##4(variable); break; \ | ^ <scratch space>:85:1: note: expanded from here 85 | raw_cpu_read_4 | ^ ./arch/x86/include/asm/percpu.h:396:30: note: expanded from macro 'raw_cpu_read_4' 396 | #define raw_cpu_read_4(pcp) percpu_from_op(, "mov", pcp) | ^ ./arch/x86/include/asm/percpu.h:189:15: note: expanded from macro 'percpu_from_op' 189 | : "=q" (pfo_ret__) \ | ^ ....+. HDRTEST usr/include/sound/sof/tokens.h . AR init/built-in.a ..........6 errors generated. ....+..... ===================================================== # Builds where the incident occurred: ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:67ceff2318018371957eaf29 #kernelci issue maestro:d36536187d181e0823b2aa631ebf9936dd657c55 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

9 months, 1 week

1
0
0 0

[REGRESSION] stable-rc/linux-6.6.y: (build) ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this functio...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.6.y: --- ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this function); did you mean ‘RISCV_ISA_EXT_ZIFENCEI’? in arch/riscv/kernel/suspend.o (arch/riscv/kernel/suspend.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/issue/maestro:f277022d07efdd2a5858eb44b3c3dab79cca84… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: b49d45c66a5e8cc1c82591049bfc0d04daa1e77c Log excerpt: ===================================================== arch/riscv/kernel/suspend.c:14:66: error: ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this function); did you mean ‘RISCV_ISA_EXT_ZIFENCEI’? 14 | if (riscv_cpu_has_extension_unlikely(smp_processor_id(), RISCV_ISA_EXT_XLINUXENVCFG)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | RISCV_ISA_EXT_ZIFENCEI arch/riscv/kernel/suspend.c:14:66: note: each undeclared identifier is reported only once for each function it appears in CC fs/proc/cpuinfo.o arch/riscv/kernel/suspend.c: In function ‘suspend_restore_csrs’: arch/riscv/kernel/suspend.c:37:66: error: ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this function); did you mean ‘RISCV_ISA_EXT_ZIFENCEI’? 37 | if (riscv_cpu_has_extension_unlikely(smp_processor_id(), RISCV_ISA_EXT_XLINUXENVCFG)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | RISCV_ISA_EXT_ZIFENCEI ===================================================== # Builds where the incident occurred: ## defconfig on (riscv): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:67cf00ee18018371957ec83e #kernelci issue maestro:f277022d07efdd2a5858eb44b3c3dab79cca847e Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

9 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025