* Re: [PATCH v3] mmc: sdhci-of-dwcmshc: Disable clock before DLL configuration
From: Ulf Hansson @ 2026-04-09 15:53 UTC (permalink / raw)
To: Shawn Lin; +Cc: linux-mmc, linux-rockchip, Adrian Hunter, Stable
In-Reply-To: <1775632729-22841-1-git-send-email-shawn.lin@rock-chips.com>
On Wed, 8 Apr 2026 at 09:19, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>
> According to the ASIC design recommendations, the clock must be
> disabled before operating the DLL to prevent glitches that could
> affect the internal digital logic. In extreme cases, failing to
> do so may cause the controller to malfunction completely.
>
> Adds a step to disable the clock before DLL configuration and
> re-enables it at the end.
>
> Fixes: 08f3dff799d4 ("mmc: sdhci-of-dwcmshc: add rockchip platform support")
> Cc: <Stable@vger.kernel.org>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
It's getting too late for fixes (unless we get an rc8), so I decided
to apply this for next instead, thanks!
Kind regards
Uffe
> ---
>
> Changes in v3:
> - Fix compile error while amending the patch file by mistake
> - Add Adrian's tag
>
> Changes in v2:
> - Add a comment about why passing zero to sdhci_enable_clk()
>
> drivers/mmc/host/sdhci-of-dwcmshc.c | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-dwcmshc.c b/drivers/mmc/host/sdhci-of-dwcmshc.c
> index 6139516..0b2158a 100644
> --- a/drivers/mmc/host/sdhci-of-dwcmshc.c
> +++ b/drivers/mmc/host/sdhci-of-dwcmshc.c
> @@ -783,12 +783,15 @@ static void dwcmshc_rk3568_set_clock(struct sdhci_host *host, unsigned int clock
> extra |= BIT(4);
> sdhci_writel(host, extra, reg);
>
> + /* Disable clock while config DLL */
> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> if (clock <= 52000000) {
> if (host->mmc->ios.timing == MMC_TIMING_MMC_HS200 ||
> host->mmc->ios.timing == MMC_TIMING_MMC_HS400) {
> dev_err(mmc_dev(host->mmc),
> "Can't reduce the clock below 52MHz in HS200/HS400 mode");
> - return;
> + goto enable_clk;
> }
>
> /*
> @@ -808,7 +811,7 @@ static void dwcmshc_rk3568_set_clock(struct sdhci_host *host, unsigned int clock
> DLL_STRBIN_DELAY_NUM_SEL |
> DLL_STRBIN_DELAY_NUM_DEFAULT << DLL_STRBIN_DELAY_NUM_OFFSET;
> sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_STRBIN);
> - return;
> + goto enable_clk;
> }
>
> /* Reset DLL */
> @@ -835,7 +838,7 @@ static void dwcmshc_rk3568_set_clock(struct sdhci_host *host, unsigned int clock
> 500 * USEC_PER_MSEC);
> if (err) {
> dev_err(mmc_dev(host->mmc), "DLL lock timeout!\n");
> - return;
> + goto enable_clk;
> }
>
> extra = 0x1 << 16 | /* tune clock stop en */
> @@ -868,6 +871,16 @@ static void dwcmshc_rk3568_set_clock(struct sdhci_host *host, unsigned int clock
> DLL_STRBIN_TAPNUM_DEFAULT |
> DLL_STRBIN_TAPNUM_FROM_SW;
> sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_STRBIN);
> +
> +enable_clk:
> + /*
> + * The sdclk frequency select bits in SDHCI_CLOCK_CONTROL are not functional
> + * on Rockchip's SDHCI implementation. Instead, the clock frequency is fully
> + * controlled via external clk provider by calling clk_set_rate(). Consequently,
> + * passing 0 to sdhci_enable_clk() only re-enables the already-configured clock,
> + * which matches the hardware's actual behavior.
> + */
> + sdhci_enable_clk(host, 0);
> }
>
> static void rk35xx_sdhci_reset(struct sdhci_host *host, u8 mask)
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v3 2/5] media: qcom: camss: Fix RDI streaming for CSID 340
From: Vladimir Zapolskiy @ 2026-04-09 15:53 UTC (permalink / raw)
To: bod, Robert Foss, Todor Tomov, Bryan O'Donoghue,
Mauro Carvalho Chehab, Hans Verkuil, Loic Poulain, Hans Verkuil,
Gjorgji Rosikopulos, Milen Mitkov, Depeng Shao, Yongsheng Li
Cc: linux-media, linux-arm-msm, linux-kernel, stable
In-Reply-To: <20260407-camss-rdi-fix-v3-2-08f72d1f3442@kernel.org>
On 4/7/26 13:34, bod@kernel.org wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Fix streaming from CSIDn RDI1 and RDI2 to VFEn RDI1 and RDI2. A pattern we
> have replicated throughout CAMSS where we use the VC number to populate
> both the VC fields and port fields of the CSID means that in practice only
> VC = 0 on CSIDn:RDI0 to VFEn:RDI0 works.
>
> Fix that for CSID 340 by separating VC and port. Fix to VC zero as a bugfix
> we will look to properly populate the VC field with follow on patches
> later.
>
> Fixes: f0fc808a466a ("media: qcom: camss: Add CSID 340 support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 6.18 000/276] 6.18.22-rc2 review
From: Miguel Ojeda @ 2026-04-09 15:53 UTC (permalink / raw)
To: gregkh
Cc: achill, akpm, broonie, conor, f.fainelli, hargar, jonathanh,
linux-kernel, linux, lkft-triage, patches, patches, pavel,
rwarsow, shuah, sr, stable, sudipm.mukherjee, torvalds,
Miguel Ojeda
In-Reply-To: <20260409092720.599045151@linuxfoundation.org>
On Thu, 09 Apr 2026 11:27:43 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.18.22 release.
> There are 276 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 11 Apr 2026 09:26:30 +0000.
> Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested
for loongarch64:
Tested-by: Miguel Ojeda <ojeda@kernel.org>
(arm 32-bit seems to build-test fine as well. Same for UML x86_64 on
a non-debug configuration.)
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v3 1/5] media: qcom: camss: Fix RDI streaming for CSID 680
From: Vladimir Zapolskiy @ 2026-04-09 15:52 UTC (permalink / raw)
To: bod, Robert Foss, Todor Tomov, Bryan O'Donoghue,
Mauro Carvalho Chehab, Hans Verkuil, Loic Poulain, Hans Verkuil,
Gjorgji Rosikopulos, Milen Mitkov, Depeng Shao, Yongsheng Li
Cc: linux-media, linux-arm-msm, linux-kernel, stable
In-Reply-To: <20260407-camss-rdi-fix-v3-1-08f72d1f3442@kernel.org>
On 4/7/26 13:34, bod@kernel.org wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Fix streaming to RDI1 and RDI2. csid->phy.en_vc contains a bitmask of
> enabled CSID ports not virtual channels.
>
> We cycle through the number of available CSID ports and test this value
> against the vc_en bitmask.
>
> We then use the passed value both as an index to the port configuration
> macros and as a virtual channel index.
>
> This is a very broken pattern. Reviewing the initial introduction of VC
> support it states that you can only map one CSID to one VFE. This is true
> however each CSID has multiple sources which can sink inside of the VFE -
> for example there is a "pixel" path for bayer stats which sources @
> CSID(x):3 and sinks on VFE(x):pix.
>
> That is CSID port # 3 should drive VFE port #3. With our current setup only
> a sensor which drives virtual channel number #3 could possibly enable that
> setup.
>
> This is deeply wrong the virtual channel has no relevance to hooking CSID
> to VFE, a fact that is proven after this patch is applied allowing
> RDI0,RDI1 and RDI2 to function with VC0 whereas before only RDI1 worked.
>
> Another way the current model breaks is the DT field. A sensor driving
> different data-types on the same VC would not be able to separate the VC:DT
> pair to separate RDI outputs, thus breaking another feature of VCs in the
> MIPI data-stream.
>
> Default the VC back to zero. A follow on series will implement subdev
> streams to actually enable VCs without breaking CSID source to VFE sink.
>
> Fixes: 253314b20408 ("media: qcom: camss: Add CSID 680 support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v3 3/3] hwmon: (powerz) Fix use-after-free and signal handling on USB disconnect
From: Pradhan, Sanman @ 2026-04-09 15:50 UTC (permalink / raw)
To: linux@weissschuh.net
Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net,
cosmo.chou@quantatw.com, mail@carsten-spiess.de,
linux-kernel@vger.kernel.org, david.laight.linux@gmail.com,
stable@vger.kernel.org, Sanman Pradhan
In-Reply-To: <fa22e0b7-f962-409d-8738-e06df1fb4b92@t-8ch.de>
From: Sanman Pradhan <psanman@juniper.net>
On 2026-04-08 19:30+0000, Thomas Weißschuh wrote:
> > Fix several issues in the powerz driver related to USB disconnect
> > races and signal handling:
>
> Please split this into two patches.
> It has no downside and makes everything else easier.
Agreed, will split into two patches for v4.
> Also given that the series fixes completely different things in
> different drivers, they could be submitted without a series.
> This will reduce the spam to maintainers of unrelated drivers.
> Multiple patches to a single driver can stay in a series.
Makes sense. For v4 I will submit the powerz patches as a standalone
2-patch mini-series and send patches to other drivers separately.
> > 1. Use-after-free: When hwmon sysfs attributes are read concurrently
> > with USB disconnect, powerz_read() obtains a pointer to the
> > private data via usb_get_intfdata(), then powerz_disconnect() runs
> > and frees the URB while powerz_read_data() may still reference it.
>
> powerz_read_data() is executed with the mutex held. powerz_disconnect()
> will also take that mutex, so I don't see that race.
You are right, the mutex serializes concurrent access, so that
description was misleading.
The actual issue is that after powerz_disconnect() frees the URB and
releases the mutex, a subsequent powerz_read() can acquire the mutex
and call powerz_read_data(), which would then dereference the freed
URB pointer. Moving usb_set_intfdata() before registration and adding
priv->urb = NULL with the corresponding NULL check is sufficient to
prevent that. I will reword the commit message accordingly.
> I do see the value of the urb = NULL assignment and the associated
> check.
Ack.
> This also looks like it could be split into more patches.
I plan to keep the usb_set_intfdata() move together with the
priv->urb = NULL assignment and NULL check, since together they form
the disconnect-side fix.
> > 2. Signal handling: wait_for_completion_interruptible_timeout()
> > returns -ERESTARTSYS on signal, 0 on timeout, or positive on
> > completion. The original code tests !ret, which only catches
> > timeout. On signal delivery (-ERESTARTSYS), !ret is false so the
> > function skips usb_kill_urb() and falls through, accessing
> > potentially stale URB data. Capture the return value and handle
> > both the signal (negative) and timeout (zero) cases explicitly.
>
> What impact does the signal delivery have on URB validity?
My understanding is that on signal the URB may still be in flight: it
was submitted successfully, but the wait was interrupted before
completion was signaled.
In the original code, a negative return does not enter the timeout
path, so usb_kill_urb() is skipped and the code falls through to read
actual_length and transfer_buffer. It can also return with the URB
still pending. A subsequent powerz_read() then reinitializes the
completion and reuses transfer_buffer while the previous URB may still
reference it.
The URB may also complete later and signal the completion, which can
interfere with a subsequent read that reinitializes the same
completion structure.
Calling usb_kill_urb() in the signal case ensures the in-flight URB is
cancelled and its completion handler has finished before returning.
> > + ret = wait_for_completion_interruptible_timeout(&priv->completion,
> > + msecs_to_jiffies(5));
>
> Should use a long type.
Right, wait_for_completion_interruptible_timeout() returns long.
Will fix.
> > + if (ret <= 0) {
> > usb_kill_urb(priv->urb);
> > - return -EIO;
> > + return ret ? ret : -EIO;
> > }
>
> If these cases are to be handled differently I would just split this
> check into two parts.
Agreed, clearer that way. Will adopt:
if (ret < 0) {
usb_kill_urb(priv->urb);
return ret;
}
if (ret == 0) {
usb_kill_urb(priv->urb);
return -EIO;
}
> > + usb_set_intfdata(intf, priv);
>
> Ack.
> > if (IS_ERR(hwmon_dev)) {
> > + usb_set_intfdata(intf, NULL);
>
> Is this really necessary? If the probing fails I would expect the
> underlying subsystem to clean this up anyways.
You are right, disconnect is not called on probe failure. Will drop.
> > + usb_set_intfdata(intf, NULL);
>
> Why is this necessary? The intfdata is allocated to the parent device,
> so it should not become unavailable.
Agreed. The priv->urb = NULL check under the mutex is sufficient for
the post-disconnect case, so I will drop this as well.
Thanks Thomas for the thorough review.
Thank you.
Regards,
Sanman Pradhan
^ permalink raw reply
* Re: [PATCH v2] HID: ft260: validate report size and payload length in raw_event
From: Jiri Kosina @ 2026-04-09 15:50 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: michael.zaidman, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel, stable
In-Reply-To: <20260324201858.46591-1-sebasjosue84@gmail.com>
On Tue, 24 Mar 2026, Sebastian Josue Alba Vives wrote:
> ft260_raw_event() casts the raw data buffer to a
> ft260_i2c_input_report struct and accesses its fields without
> validating the size parameter. Since __hid_input_report() invokes
> the driver's raw_event callback before hid_report_raw_event()
> performs its own report-size validation, a device sending a
> truncated HID report can cause out-of-bounds heap reads.
>
> Additionally, even with a full-sized report, a corrupted
> xfer->length field can cause memcpy to read beyond the report
> buffer. The existing check only validates against the destination
> buffer size, not the source data available in the report.
>
> Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,
> and verify that xfer->length does not exceed the actual data
> available in the report. Log warnings to aid debugging.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
> ---
> drivers/hid/hid-ft260.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
> index 333341e80..68008a423 100644
> --- a/drivers/hid/hid-ft260.c
> +++ b/drivers/hid/hid-ft260.c
> @@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
> struct ft260_device *dev = hid_get_drvdata(hdev);
> struct ft260_i2c_input_report *xfer = (void *)data;
>
> + if (size < FT260_REPORT_MAX_LENGTH) {
> + hid_warn(hdev, "short report: %d\n", size);
> + return 0;
Michael, can you please confirm whether the device can never legitimately
send shorter than FT260_REPORT_MAX_LENGTH reports?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: apple: ensure the keyboard backlight is off if suspending
From: Jiri Kosina @ 2026-04-09 15:46 UTC (permalink / raw)
To: Aditya Garg
Cc: Benjamin Tissoires, linux-input, linux-kernel, stable,
André Eikmeyer
In-Reply-To: <MAUPR01MB115467C51E492BD620ED390B6B85FA@MAUPR01MB11546.INDPRD01.PROD.OUTLOOK.COM>
On Sat, 4 Apr 2026, Aditya Garg wrote:
> Some users reported that upon suspending their keyboard backlight
> remained on. Fix this by adding the missing LED_CORE_SUSPENDRESUME flag.
>
> Cc: stable@vger.kernel.org
> Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs")
> Fixes: 9018eacbe623 ("HID: apple: Add support for keyboard backlight on certain T2 Macs.")
> Reported-by: André Eikmeyer <andre.eikmeyer@gmail.com>
> Tested-by: André Eikmeyer <andre.eikmeyer@gmail.com>
> Signed-off-by: Aditya Garg <gargaditya08@live.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 6.6 000/160] 6.6.134-rc1 review
From: Miguel Ojeda @ 2026-04-09 15:44 UTC (permalink / raw)
To: gregkh
Cc: achill, akpm, broonie, conor, f.fainelli, hargar, jonathanh,
linux-kernel, linux, lkft-triage, patches, patches, pavel,
rwarsow, shuah, sr, stable, sudipm.mukherjee, torvalds,
Miguel Ojeda
In-Reply-To: <20260408175913.177092714@linuxfoundation.org>
On Wed, 08 Apr 2026 20:01:27 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.6.134 release.
> There are 160 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 10 Apr 2026 17:58:42 +0000.
> Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64:
Tested-by: Miguel Ojeda <ojeda@kernel.org>
(UML x86_64 builds fine too apart from the usual warnings.)
Thanks!
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 6.1 000/312] 6.1.168-rc1 review
From: Miguel Ojeda @ 2026-04-09 15:38 UTC (permalink / raw)
To: gregkh
Cc: achill, akpm, broonie, conor, f.fainelli, hargar, jonathanh,
linux-kernel, linux, lkft-triage, patches, patches, pavel,
rwarsow, shuah, sr, stable, sudipm.mukherjee, torvalds,
Miguel Ojeda
In-Reply-To: <20260408175933.715315542@linuxfoundation.org>
On Wed, 08 Apr 2026 19:58:37 +0200 Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 6.1.168 release.
> There are 312 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 10 Apr 2026 17:58:42 +0000.
> Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64:
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Thanks!
Cheers,
Miguel
^ permalink raw reply
* + mm-hugetlb-fix-early-boot-crash-on-parameters-without-=-separator.patch added to mm-unstable branch
From: Andrew Morton @ 2026-04-09 15:31 UTC (permalink / raw)
To: mm-commits, stable, osalvador, muchun.song, fvdl, david,
thorsten.blum, akpm
The patch titled
Subject: mm/hugetlb: fix early boot crash on parameters without '=' separator
has been added to the -mm mm-unstable branch. Its filename is
mm-hugetlb-fix-early-boot-crash-on-parameters-without-=-separator.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-hugetlb-fix-early-boot-crash-on-parameters-without-=-separator.patch
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 various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Thorsten Blum <thorsten.blum@linux.dev>
Subject: mm/hugetlb: fix early boot crash on parameters without '=' separator
Date: Thu, 9 Apr 2026 12:54:40 +0200
If hugepages, hugepagesz, or default_hugepagesz are specified on the
kernel command line without the '=' separator, early parameter parsing
passes NULL to hugetlb_add_param(), which dereferences it in strlen() and
can crash the system during early boot.
Reject NULL values in hugetlb_add_param() and return -EINVAL instead.
Link: https://lkml.kernel.org/r/20260409105437.108686-4-thorsten.blum@linux.dev
Fixes: 5b47c02967ab ("mm/hugetlb: convert cmdline parameters from setup to early")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Muchun Song <muchun.song@linux.dev>
Cc: David Hildenbrand <david@kernel.org>
Cc: Frank van der Linden <fvdl@google.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/hugetlb.c | 3 +++
1 file changed, 3 insertions(+)
--- a/mm/hugetlb.c~mm-hugetlb-fix-early-boot-crash-on-parameters-without-=-separator
+++ a/mm/hugetlb.c
@@ -4226,6 +4226,9 @@ static __init int hugetlb_add_param(char
size_t len;
char *p;
+ if (!s)
+ return -EINVAL;
+
if (hugetlb_param_index >= HUGE_MAX_CMDLINE_ARGS)
return -EINVAL;
_
Patches currently in -mm which might be from thorsten.blum@linux.dev are
mm-hugetlb-fix-early-boot-crash-on-parameters-without-=-separator.patch
^ permalink raw reply
* [PATCH] userfaultfd: preserve write protection across UFFDIO_MOVE
From: Gregory Price @ 2026-04-09 15:28 UTC (permalink / raw)
To: linux-mm
Cc: linux-kernel, kernel-team, akpm, rppt, peterx, surenb, aarcange,
stable
move_present_ptes() unconditionally makes the destination PTE writable,
dropping uffd-wp write-protection from the source PTE.
The original intent was to follow mremap() behavior, but mremap()'s
move_ptes() preserves the source write state unconditionally.
Modify uffd to preserve the source write state and check the uffd-wp
condition of the source before setting writable on the destination.
Fixes: adef440691ba ("userfaultfd: UFFDIO_MOVE uABI")
Cc: stable@vger.kernel.org
Signed-off-by: Gregory Price <gourry@gourry.net>
---
mm/userfaultfd.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index e6dfd5f28acd..783ca68aed88 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -1123,7 +1123,10 @@ static long move_present_ptes(struct mm_struct *mm,
orig_dst_pte = pte_mksoft_dirty(orig_dst_pte);
if (pte_dirty(orig_src_pte))
orig_dst_pte = pte_mkdirty(orig_dst_pte);
- orig_dst_pte = pte_mkwrite(orig_dst_pte, dst_vma);
+ if (pte_write(orig_src_pte))
+ orig_dst_pte = pte_mkwrite(orig_dst_pte, dst_vma);
+ if (pte_uffd_wp(orig_src_pte))
+ orig_dst_pte = pte_mkuffd_wp(orig_dst_pte);
set_pte_at(mm, dst_addr, dst_pte, orig_dst_pte);
src_addr += PAGE_SIZE;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Catalin Marinas @ 2026-04-09 15:20 UTC (permalink / raw)
To: Kevin Brodsky
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Suzuki K Poulose, Jinjiang Tu, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <567dff89-9f0f-40a0-ab10-22e061b4faaf@arm.com>
On Thu, Apr 09, 2026 at 11:53:41AM +0200, Kevin Brodsky wrote:
> On 07/04/2026 12:52, Catalin Marinas wrote:
> >> if we have forced pte mapping then the value of
> >> can_set_direct_map() is irrelevant - we will never need to split because we are
> >> already pte-mapped.
> >
> > can_set_direct_map() is used in other places, so its value is
> > relevant, e.g. sys_memfd_secret() is rejected if this function returns
> > false.
>
> Indeed, I have noticed this before: currently set_direct_map_*_noflush()
> and other functions will either fail or do nothing if none of the
> features (rodata=full, etc.) is enabled, even if we would be able to
> split the linear map using BBML2-noabort.
That's what I have been trying to say to Ryan ;), can_set_direct_map()
has different meanings depending on the caller: hint that it might split
or asking whether splitting is permitted. The latter is not captured.
Ignoring realms, if we have BBML2_NOABORT the kernel won't force pte
mappings under the assumption that split_kernel_leaf_mapping() is safe.
However set_direct_map_*_noflush() won't even reach the split function
because the "can" part says "no, you can't".
> What would make more sense to me is to enable the use of BBML2-noabort
> unconditionally if !force_pte_mapping(). We can then have
> can_set_direct_map() return true if we have BBML2-noabort, and we no
> longer need to check it in map_mem().
Indeed.
> This is a functional change that doesn't have anything to do with realms
> so it should probably be a separate series - happy to take care of it
> once the dust settles on the realm handling.
I think it can be done in parallel, it shouldn't interfere with realms.
The realm part should just affect force_pte_mapping() and
can_set_direct_map() should return just what's possible, not what may
need to set the direct map.
--
Catalin
^ permalink raw reply
* Re: [PATCH v2] Fixes a race in iopt_unmap_iova_range
From: Jason Gunthorpe @ 2026-04-09 15:15 UTC (permalink / raw)
To: Sina Hassani
Cc: kevin.tian, joro, will, robin.murphy, iommu, linux-kernel,
Aaron Wisner, stable
In-Reply-To: <CAAJpGJTNKxCfcZxgDj_sZYUozrOe=vxbWUUi4PVwdfvGx=WEfg@mail.gmail.com>
On Mon, Apr 06, 2026 at 06:40:05PM -0700, Sina Hassani wrote:
> On Mon, Apr 6, 2026 at 6:27 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Mon, Apr 06, 2026 at 06:17:24PM -0700, Sina Hassani wrote:
> > > On Mon, Apr 6, 2026 at 6:12 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > >
> > > > On Mon, Apr 06, 2026 at 04:07:01PM -0700, Sina Hassani wrote:
> > > >
> > > > > io_pagetable *iopt, unsigned long start,
> > > > > unmapped_bytes += area_last - area_first + 1;
> > > > >
> > > > > down_write(&iopt->iova_rwsem);
> > > > > +
> > > > > + /* Do not reconsider things already unmapped in case of
> > > > > + * concurrent allocation */
> > > > > + start = area_last + 1;
> > > >
> > > > area_last can be ULONG_MAX so this literally overflows to 0. It is why
> > > > I formed the suggestion I gave as I did
> > > >
> > > Yes, in which case the if (start < area_last) that follows will catch
> > > it. Are you suggesting I compare against ULONG_MAX instead?
> >
> > iommufd does not have any overflows to 0 and rely on it tricks like
> > this. You should just compare to the existing iteration last
> >
> Just to confirm that I understand correctly, like this?
>
> + if (area_last >= last) {
> + break;
> +. } else {
> +. start = area_last + 1;
> + }
Yeah that looks Ok
Jason
^ permalink raw reply
* Re: [PATCH] 9p: fix access mode flags being ORed instead of replaced
From: Christian Schoenebeck @ 2026-04-09 14:51 UTC (permalink / raw)
To: ericvh, lucho, asmadeus, Pierre Barre; +Cc: v9fs, linux-kernel, stable, sandeen
In-Reply-To: <0ddc72da-d196-4f01-8755-0086f670e779@app.fastmail.com>
On Thursday, 2 April 2026 12:03:12 CEST Pierre Barre wrote:
> Since commit 1f3e4142c0eb ("9p: convert to the new mount API"),
> v9fs_apply_options() applies parsed mount flags with |= onto flags
> already set by v9fs_session_init(). For 9P2000.L, session_init sets
> V9FS_ACCESS_CLIENT as the default, so when the user mounts with
> "access=user", both bits end up set. Access mode checks compare
> against exact values, so having both bits set matches neither mode.
>
> This causes v9fs_fid_lookup() to fall through to the default switch
> case, using INVALID_UID (nobody/65534) instead of current_fsuid()
> for all fid lookups. Root is then unable to chown or perform other
> privileged operations.
>
> Fix by clearing the access mask before applying the user's choice.
>
> Fixes: 1f3e4142c0eb ("9p: convert to the new mount API")
> Signed-off-by: Pierre Barre <pierre@barre.sh>
> ---
> fs/9p/v9fs.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
> index 057487efaaeb..05a5e1c4df35 100644
> --- a/fs/9p/v9fs.c
> +++ b/fs/9p/v9fs.c
> @@ -413,7 +413,11 @@ static void v9fs_apply_options(struct v9fs_session_info
> *v9ses, /*
> * Note that we must |= flags here as session_init already
> * set basic flags. This adds in flags from parsed options.
> + * Access flags are mutually exclusive, so clear any access
> + * bits set by session_init before applying the user's choice.
That phrase is a bit suboptimal, because V9FS_ACCESS_ANY is actually a bit
combination of single, user and client. But OK, I currently don't have a
better phrase for it since the access fields have to be replaced altogether.
As for the actual behaviour change; makes sense to me:
Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
> */
> + if (ctx->session_opts.flags & V9FS_ACCESS_MASK)
> + v9ses->flags &= ~V9FS_ACCESS_MASK;
> v9ses->flags |= ctx->session_opts.flags;
> #ifdef CONFIG_9P_FSCACHE
> v9ses->cachetag = ctx->session_opts.cachetag;
> --
> 2.51.0
^ permalink raw reply
* [PATCH 3/6] drm/amd/display: fix math_mod() using arg1 instead of arg2
From: Aurabindo Pillai @ 2026-04-09 15:03 UTC (permalink / raw)
To: amd-gfx
Cc: Harry Wentland, Leo Li, Aurabindo Pillai, Roman Li, Wayne Lin,
Tom Chung, Fangzhi Zuo, Dan Wheeler, Ray Wu, Ivan Lipski,
Alex Hung, Chuanyu Tseng, Wenjing Liu, Mario Limonciello,
Alex Deucher, stable, Dillon Varone
In-Reply-To: <20260409150413.34779-1-aurabindo.pillai@amd.com>
From: Wenjing Liu <wenjing.liu@amd.com>
[Why]
math_mod() multiplied by arg1 instead of arg2, returning a wrong
result for any non-trivial modulo operation.
[How]
Replace arg1 with arg2 in the subtraction term to correctly
implement fmod(arg1, arg2).
Cc: Mario Limonciello <mario.limonciello@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Dillon Varone <dillon.varone@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
---
.../dml2_0/dml21/src/dml2_standalone_libraries/lib_float_math.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_standalone_libraries/lib_float_math.c b/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_standalone_libraries/lib_float_math.c
index e17b5ceba447..dc5bc649f3ac 100644
--- a/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_standalone_libraries/lib_float_math.c
+++ b/drivers/gpu/drm/amd/display/dc/dml2_0/dml21/src/dml2_standalone_libraries/lib_float_math.c
@@ -23,7 +23,7 @@ double math_mod(const double arg1, const double arg2)
return arg2;
if (isNaN(arg2))
return arg1;
- return arg1 - arg1 * ((int)(arg1 / arg2));
+ return arg1 - arg2 * ((int)(arg1 / arg2));
}
double math_min2(const double arg1, const double arg2)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] nvme-apple: drop invalid put of admin queue reference count
From: Keith Busch @ 2026-04-09 14:47 UTC (permalink / raw)
To: Fedor Pchelkin
Cc: Christoph Hellwig, Jens Axboe, Sven Peter, Janne Grunau,
Neal Gompa, Sagi Grimberg, Hannes Reinecke, Ming Lei,
Chaitanya Kulkarni, Heyne, Maximilian, asahi, linux-arm-kernel,
linux-nvme, linux-kernel, lvc-project, stable
In-Reply-To: <20260408141815.375695-1-pchelkin@ispras.ru>
On Wed, Apr 08, 2026 at 05:18:14PM +0300, Fedor Pchelkin wrote:
> Commit 03b3bcd319b3 ("nvme: fix admin request_queue lifetime") moved the
> admin queue reference ->put call into nvme_free_ctrl() - a controller
> device release callback performed for every nvme driver doing
> nvme_init_ctrl().
Thanks, applied to nvme-7.1.
^ permalink raw reply
* Re: [PATCH] nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free
From: Keith Busch @ 2026-04-09 14:46 UTC (permalink / raw)
To: Chaitanya Kulkarni; +Cc: hch, sagi, roys, linux-nvme, stable
In-Reply-To: <20260409005647.112289-1-kch@nvidia.com>
On Wed, Apr 08, 2026 at 05:56:47PM -0700, Chaitanya Kulkarni wrote:
> nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the
> final controller reference through nvmet_cq_put(). If that triggers
> nvmet_ctrl_free(), the teardown path flushes ctrl->async_event_work on
> the same nvmet-wq.
Thanks, applied to nvme-7.1.
^ permalink raw reply
* Re: [PATCH v2] bpf: guard sock_ops rtt_min access with is_locked_tcp_sock
From: Alexei Starovoitov @ 2026-04-09 14:29 UTC (permalink / raw)
To: Werner Kasselman
Cc: Martin KaFai Lau, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, John Fastabend, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Shuah Khan, bpf@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260409061026.3926858-1-werner@verivus.com>
On Wed, Apr 8, 2026 at 11:10 PM Werner Kasselman <werner@verivus.ai> wrote:
>
> sock_ops_convert_ctx_access() emits guarded reads for tcp_sock-backed
> bpf_sock_ops fields such as snd_cwnd, srtt_us, snd_ssthresh, rcv_nxt,
> snd_nxt, snd_una, mss_cache, ecn_flags, rate_delivered, and
> rate_interval_us. Those accesses go through SOCK_OPS_GET_TCP_SOCK_FIELD(),
> which checks is_locked_tcp_sock before dereferencing sock_ops.sk.
>
> The rtt_min case is different. Because it reads a subfield of
> struct minmax, it uses a custom open-coded load sequence instead of the
> usual helper macro, and that sequence currently dereferences sock_ops.sk
> without checking is_locked_tcp_sock first.
>
> This is unsafe when sock_ops.sk points to a request_sock-backed object
> instead of a locked full tcp_sock. That is reachable not only from the
> SYNACK header option callbacks, but also from other request_sock-backed
> sock_ops callbacks such as BPF_SOCK_OPS_TIMEOUT_INIT,
> BPF_SOCK_OPS_RWND_INIT, and BPF_SOCK_OPS_NEEDS_ECN. In those cases,
> reading ctx->rtt_min makes the generated code treat a request_sock as a
> tcp_sock and read beyond the end of the request_sock allocation.
>
> Fix the rtt_min conversion by adding the same is_locked_tcp_sock guard
> used for the other tcp_sock field reads. Also make the accessed subfield
> explicit by using offsetof(struct minmax_sample, v).
>
> Add a selftest that verifies request_sock-backed sock_ops callbacks see
> ctx->rtt_min as zero after the fix.
>
> Found via AST-based call-graph analysis using sqry.
>
> Fixes: 44f0e43037d3 ("bpf: Add support for reading sk_state and more")
> Cc: stable@vger.kernel.org
> Signed-off-by: Werner Kasselman <werner@verivus.com>
> ---
> net/core/filter.c | 53 +++++++++++++++----
> .../selftests/bpf/prog_tests/tcpbpf_user.c | 9 ++++
> .../selftests/bpf/progs/test_tcpbpf_kern.c | 21 ++++++++
> tools/testing/selftests/bpf/test_tcpbpf.h | 6 +++
> 4 files changed, 79 insertions(+), 10 deletions(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 78b548158..5040bf7e4 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -10827,16 +10827,49 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type,
> case offsetof(struct bpf_sock_ops, rtt_min):
> BUILD_BUG_ON(sizeof_field(struct tcp_sock, rtt_min) !=
> sizeof(struct minmax));
> - BUILD_BUG_ON(sizeof(struct minmax) <
> - sizeof(struct minmax_sample));
> -
> - *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(
> - struct bpf_sock_ops_kern, sk),
> - si->dst_reg, si->src_reg,
> - offsetof(struct bpf_sock_ops_kern, sk));
> - *insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->dst_reg,
> - offsetof(struct tcp_sock, rtt_min) +
> - sizeof_field(struct minmax_sample, t));
> + BUILD_BUG_ON(sizeof_field(struct bpf_sock_ops, rtt_min) !=
> + sizeof_field(struct minmax_sample, v));
> + off = offsetof(struct tcp_sock, rtt_min) +
> + offsetof(struct minmax_sample, v);
> +
> + {
> + int fullsock_reg = si->dst_reg, reg = BPF_REG_9, jmp = 2;
> +
please de-claude your patches before posting.
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] nvmet-tcp: fix race between ICReq handling and queue teardown
From: Keith Busch @ 2026-04-09 14:21 UTC (permalink / raw)
To: Chaitanya Kulkarni; +Cc: skumar47, hch, sagi, linux-nvme, stable
In-Reply-To: <20260408075131.6221-1-kch@nvidia.com>
On Wed, Apr 08, 2026 at 12:51:31AM -0700, Chaitanya Kulkarni wrote:
> nvmet_tcp_handle_icreq() updates queue->state after sending an
> Initialization Connection Response (ICResp), but it does so without
> serializing against target-side queue teardown.
Thanks, applied to nvme-7.1 with the overly long line fixed up when
applying.
^ permalink raw reply
* Re: [PATCH v2] erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()
From: Gao Xiang @ 2026-04-09 14:21 UTC (permalink / raw)
To: Junrui Luo, linux-erofs
Cc: linux-kernel, Yuhao Jiang, stable, Gao Xiang, Chao Yu, Yue Hu,
Jeffle Xu, Sandeep Dhavale, Hongbo Li, Chunhai Guo
In-Reply-To: <SYBPR01MB788118F7F3CBCD0B894B5460AF582@SYBPR01MB7881.ausprd01.prod.outlook.com>
On 2026/4/9 21:59, Junrui Luo wrote:
> Some crafted images can have illegal (!partial_decoding &&
> m_llen < m_plen) extents, and the LZ4 inplace decompression path
> can be wrongly hit, but it cannot handle (outpages < inpages)
> properly: "outpages - inpages" wraps to a large value and
> the subsequent rq->out[] access reads past the decompressed_pages
> array.
>
> However, such crafted cases can correctly result in a corruption
> report in the normal LZ4 non-inplace path.
>
> Let's add an additional check to fix this for backporting.
>
> Reproducible image (base64-encoded gzipped blob):
>
> H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g
> dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i
> PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz
> 2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w
> ywAAAAAAAADwu14ATsEYtgBQAAA=
>
> $ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt
> $ dd if=/mnt/data of=/dev/null bs=4096 count=1
>
> Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Thanks for catching this:
Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Thanks,
Gao Xiang
^ permalink raw reply
* Re: [PATCH] RDMA: rxe: validate pad and ICRC before payload_size() in rxe_rcv
From: Jason Gunthorpe @ 2026-04-09 14:20 UTC (permalink / raw)
To: hkbinbin; +Cc: zyjzyj2000, leon, w, linux-rdma, linux-kernel, stable
In-Reply-To: <20260401121907.1468366-1-hkbinbinbin@gmail.com>
On Wed, Apr 01, 2026 at 12:19:07PM +0000, hkbinbin wrote:
> rxe_rcv() currently checks only that the incoming packet is at least
> header_size(pkt) bytes long before payload_size() is used.
>
> However, payload_size() subtracts both the attacker-controlled BTH pad
> field and RXE_ICRC_SIZE from pkt->paylen:
>
> payload_size = pkt->paylen - offset[RXE_PAYLOAD] - bth_pad(pkt)
> - RXE_ICRC_SIZE
>
> This means a short packet can still make payload_size() underflow even
> if it includes enough bytes for the fixed headers. Simply requiring
> header_size(pkt) + RXE_ICRC_SIZE is not sufficient either, because a
> packet with a forged non-zero BTH pad can still leave payload_size()
> negative and pass an underflowed value to later receive-path users.
>
> Fix this by validating pkt->paylen against the full minimum length
> required by payload_size(): header_size(pkt) + bth_pad(pkt) +
> RXE_ICRC_SIZE.
>
> Fixes: 8700e3e7c485 ("Soft RoCE driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: hkbinbin <hkbinbinbin@gmail.com>
> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev>
> ---
> drivers/infiniband/sw/rxe/rxe_recv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Suzuki K Poulose @ 2026-04-09 14:18 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <d1ecba64-898f-433b-93d4-7a33b9c3f378@arm.com>
On 09/04/2026 10:38, Suzuki K Poulose wrote:
> On 07/04/2026 18:21, Catalin Marinas wrote:
>> On Tue, Apr 07, 2026 at 10:57:35AM +0100, Suzuki K Poulose wrote:
>>> On 02/04/2026 21:43, Catalin Marinas wrote:
>>>> On Mon, Mar 30, 2026 at 05:17:02PM +0100, Ryan Roberts wrote:
>>>>> int split_kernel_leaf_mapping(unsigned long start, unsigned long
>>>>> end)
>>>>> {
>>>>> int ret;
>>>>> - /*
>>>>> - * !BBML2_NOABORT systems should not be trying to change
>>>>> permissions on
>>>>> - * anything that is not pte-mapped in the first place. Just
>>>>> return early
>>>>> - * and let the permission change code raise a warning if not
>>>>> already
>>>>> - * pte-mapped.
>>>>> - */
>>>>> - if (!system_supports_bbml2_noabort())
>>>>> - return 0;
>>>>> -
>>>>> /*
>>>>> * If the region is within a pte-mapped area, there is no
>>>>> need to try to
>>>>> * split. Additionally, CONFIG_DEBUG_PAGEALLOC and
>>>>> CONFIG_KFENCE may
>>>>> * change permissions from atomic context so for those cases
>>>>> (which are
>>>>> * always pte-mapped), we must not go any further because
>>>>> taking the
>>>>> - * mutex below may sleep.
>>>>> + * mutex below may sleep. Do not call force_pte_mapping() here
>>>>> because
>>>>> + * it could return a confusing result if called from a
>>>>> secondary cpu
>>>>> + * prior to finalizing caps. Instead,
>>>>> linear_map_requires_bbml2 gives us
>>>>> + * what we need.
>>>>> */
>>>>> - if (force_pte_mapping() || is_kfence_address((void *)start))
>>>>> + if (!linear_map_requires_bbml2 || is_kfence_address((void
>>>>> *)start))
>>>>> return 0;
>>>>> + if (!system_supports_bbml2_noabort()) {
>>>>> + /*
>>>>> + * !BBML2_NOABORT systems should not be trying to change
>>>>> + * permissions on anything that is not pte-mapped in the
>>>>> first
>>>>> + * place. Just return early and let the permission change
>>>>> code
>>>>> + * raise a warning if not already pte-mapped.
>>>>> + */
>>>>> + if (system_capabilities_finalized())
>>>>> + return 0;
>>>>> +
>>>>> + /*
>>>>> + * Boot-time: split_kernel_leaf_mapping_locked() allocates
>>>>> from
>>>>> + * page allocator. Can't split until it's available.
>>>>> + */
>>>>> + if (WARN_ON(!page_alloc_available))
>>>>> + return -EBUSY;
>>>>> +
>>>>> + /*
>>>>> + * Boot-time: Started secondary cpus but don't know if they
>>>>> + * support BBML2_NOABORT yet. Can't allow splitting in this
>>>>> + * window in case they don't.
>>>>> + */
>>>>> + if (WARN_ON(num_online_cpus() > 1))
>>>>> + return -EBUSY;
>>>>> + }
>>>>
>>>> I think sashiko is over cautions here
>>>> (https://sashiko.dev/#/patchset/20260330161705.3349825-1-
>>>> ryan.roberts@arm.com)
>>>> but it has a somewhat valid point from the perspective of
>>>> num_online_cpus() semantics. We have have num_online_cpus() == 1 while
>>>> having a secondary CPU just booted and with its MMU enabled. I don't
>>>> think we can have any asynchronous tasks running at that point to
>>>> trigger a spit though. Even async_init() is called after smp_init().
>>>>
>>>> An option may be to attempt cpus_read_trylock() as this lock is
>>>> taken by
>>>> _cpu_up(). If it fails, return -EBUSY, otherwise check
>>>> num_online_cpus()
>>>> and unlock (and return -EBUSY if secondaries already started).
>>>>
>>>> Another thing I couldn't get my head around - IIUC is_realm_world()
>>>> won't return true for map_mem() yet (if in a realm).
>>>
>>> That is correct. map_mem() comes from paginig_init(), which gets called
>>> before arm64_rsi_init(). Realm check was delayed until psci_xx_init().
>>> We had a version which parsed the DT for PSCI conduit early enough
>>> to be able to make the SMC calls to detect the Realm. But there
>>> were concerns around it.
>>
>> Ah, yes, I remember.
>>
>> Does it mean that commit 42be24a4178f ("arm64: Enable memory encrypt for
>> Realms") was broken without rodata=full w.r.t. the linear map? Commit
>
> Apparently, it looks like we missed this when we demoted the RSI
> detection later.
>
>> a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
>> introduced force_pte_mapping() but it just copied the logic in the
>> existing can_set_direct_map(). Looking at the linear_map_requires_bbml2
>> assignment, we get (!is_realm_world() && is_realm_world()) and it
>> cancels out, no effect on it but we don't get pte mappings either (even
>> if we don't have BBML2).
>
> Yep, that's right.
>>
>> I think we need at least some safety checks:
>>
>> 1. BBML2_NOABORT support on the boot CPU - continue with the existing
>> logic (as per Ryan's series)
>>
>> 2. !system_supports_bbml2_noabort() - split in
>> linear_map_maybe_split_to_ptes(). This does not currently happen
>> because linear_map_requires_bbml2 may be false in the absence of
>> rodata=full. Not sure how to fix this without some variable telling
>> us how the linear map was mapped. The requires_bbml2 flag doesn't
>>
>> 3. Panic in arm64_rsi_init() if !BBML2_NOABORT on the boot CPU _and_ we
>> have block mappings already. People can avoid it with rodata=full
>
> It looks like this will be a common case :-(
Having another look, by default, arm64 boots with rodata=full, and users
have to explicitly lower the bar by setting rodata=off or noalias. So
this has been keeping us running ;-).
With rodata=off, I get the following for a Realm boot:
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: arch/arm64/mm/pageattr.c:61 at
pageattr_pmd_entry+0x78/0xe0, CPU#0: swapper/0
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-rc1+
#1889 PREEMPT
[ 0.000000] Hardware name: linux,dummy-virt (DT)
[ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 0.000000] pc : pageattr_pmd_entry+0x78/0xe0
[ 0.000000] lr : walk_pgd_range+0x43c/0x970
[ 0.000000] sp : ffff800082343b70
[ 0.000000] x29: ffff800082343b70 x28: fff0000019600000 x27:
fff0000019580000
[ 0.000000] x26: ffff800082343c98 x25: fff000001d57ffff x24:
fff000001fffe000
[ 0.000000] x23: ffff8000810ae698 x22: fff000001fffd650 x21:
fff0000019780000
[ 0.000000] x20: fff000001d580000 x19: 0000000000000000 x18:
0000000000000030
[ 0.000000] x17: 0000000000004000 x16: 000000009fffc000 x15:
0000000000000020
[ 0.000000] x14: 0000000000003be4 x13: 0000000000000020 x12:
0000000000000000
[ 0.000000] x11: 0000000000000016 x10: 0000000000000015 x9 :
0000000000000013
[ 0.000000] x8 : 0000000000000015 x7 : 0000000080000000 x6 :
0000000000000000
[ 0.000000] x5 : 0078000099400405 x4 : fff000001fffd650 x3 :
ffff800082343c98
[ 0.000000] x2 : 0000000000080000 x1 : fff0000019580000 x0 :
0000000000000001
[ 0.000000] Call trace:
[ 0.000000] pageattr_pmd_entry+0x78/0xe0 (P)
[ 0.000000] walk_kernel_page_table_range_lockless+0x60/0xa0
[ 0.000000] update_range_prot+0x80/0x128
[ 0.000000] __set_memory_enc_dec.part.0+0x88/0x258
[ 0.000000] realm_set_memory_decrypted+0x54/0x98
[ 0.000000] set_memory_decrypted+0x38/0x58
[ 0.000000] swiotlb_update_mem_attributes+0x44/0x58
[ 0.000000] mem_init+0x24/0x38
[ 0.000000] mm_core_init+0x94/0x140
[ 0.000000] start_kernel+0x544/0xa18
[ 0.000000] __primary_switched+0x88/0x98
[ 0.000000] ---[ end trace 0000000000000000 ]---
Suzuki
>
>>
>> 4. If (3) is a common case, a better alternative is to rewrite the
>> linear map sometime after arm64_rsi_init() but before we call
>> split_kernel_leaf_mapping().
>
> We will explore this route.
>
> The other option is to move the RSI detection (and the PSCI probe)
> earlier to be able to make better decisions early on. I will play with
> that a bit too.
>
> Suzuki
>
>
>>
>
^ permalink raw reply
* Re: [PATCH 6.6 000/160] 6.6.134-rc1 review
From: Mark Brown @ 2026-04-09 14:16 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, achill, sr
In-Reply-To: <20260408175913.177092714@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Wed, Apr 08, 2026 at 08:01:27PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.6.134 release.
> There are 160 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Catalin Marinas @ 2026-04-09 14:09 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <d1ecba64-898f-433b-93d4-7a33b9c3f378@arm.com>
On Thu, Apr 09, 2026 at 10:38:03AM +0100, Suzuki K Poulose wrote:
> On 07/04/2026 18:21, Catalin Marinas wrote:
> > a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
> > introduced force_pte_mapping() but it just copied the logic in the
> > existing can_set_direct_map(). Looking at the linear_map_requires_bbml2
> > assignment, we get (!is_realm_world() && is_realm_world()) and it
> > cancels out, no effect on it but we don't get pte mappings either (even
> > if we don't have BBML2).
>
> Yep, that's right.
> >
> > I think we need at least some safety checks:
> >
> > 1. BBML2_NOABORT support on the boot CPU - continue with the existing
> > logic (as per Ryan's series)
> >
> > 2. !system_supports_bbml2_noabort() - split in
> > linear_map_maybe_split_to_ptes(). This does not currently happen
> > because linear_map_requires_bbml2 may be false in the absence of
> > rodata=full. Not sure how to fix this without some variable telling
> > us how the linear map was mapped. The requires_bbml2 flag doesn't
> >
> > 3. Panic in arm64_rsi_init() if !BBML2_NOABORT on the boot CPU _and_ we
> > have block mappings already. People can avoid it with rodata=full
>
> It looks like this will be a common case :-(
>
> >
> > 4. If (3) is a common case, a better alternative is to rewrite the
> > linear map sometime after arm64_rsi_init() but before we call
> > split_kernel_leaf_mapping().
>
> We will explore this route.
>
> The other option is to move the RSI detection (and the PSCI probe)
> earlier to be able to make better decisions early on. I will play with
> that a bit too.
I thought we could reuse linear_map_split_to_ptes() but this function
assumes that the primary CPU supports BBML2_NOABORT. To do this live,
we'd have to clone the active kernel pgtable hierarchy, switch to it and
then continue with the splitting. kasan_init_shadow() does a bit of this
but not fully as it only cares about the shadow mapping.
Hmm, maybe probing the RSI early is easier ;).
--
Catalin
^ permalink raw reply
* [PATCH v2] erofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()
From: Junrui Luo @ 2026-04-09 13:59 UTC (permalink / raw)
To: Gao Xiang, Chao Yu, Yue Hu, Jeffle Xu, Sandeep Dhavale, Hongbo Li,
Chunhai Guo
Cc: linux-erofs, linux-kernel, Yuhao Jiang, stable, Junrui Luo
Some crafted images can have illegal (!partial_decoding &&
m_llen < m_plen) extents, and the LZ4 inplace decompression path
can be wrongly hit, but it cannot handle (outpages < inpages)
properly: "outpages - inpages" wraps to a large value and
the subsequent rq->out[] access reads past the decompressed_pages
array.
However, such crafted cases can correctly result in a corruption
report in the normal LZ4 non-inplace path.
Let's add an additional check to fix this for backporting.
Reproducible image (base64-encoded gzipped blob):
H4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g
dilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i
PNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz
2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w
ywAAAAAAAADwu14ATsEYtgBQAAA=
$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt
$ dd if=/mnt/data of=/dev/null bs=4096 count=1
Fixes: 598162d05080 ("erofs: support decompress big pcluster for lz4 backend")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
Changes in v2:
- Change commit message suggested by Gao Xiang
- Link to v1: https://lore.kernel.org/all/SYBPR01MB78811E3B3E935EFCD5D63334AF582@SYBPR01MB7881.ausprd01.prod.outlook.com/
---
fs/erofs/decompressor.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
index 3c54e95964c9..2b065f8c3f71 100644
--- a/fs/erofs/decompressor.c
+++ b/fs/erofs/decompressor.c
@@ -145,6 +145,7 @@ static void *z_erofs_lz4_handle_overlap(const struct z_erofs_decompress_req *rq,
oend = rq->pageofs_out + rq->outputsize;
omargin = PAGE_ALIGN(oend) - oend;
if (!rq->partial_decoding && may_inplace &&
+ rq->outpages >= rq->inpages &&
omargin >= LZ4_DECOMPRESS_INPLACE_MARGIN(rq->inputsize)) {
for (i = 0; i < rq->inpages; ++i)
if (rq->out[rq->outpages - rq->inpages + i] !=
---
base-commit: 7aaa8047eafd0bd628065b15757d9b48c5f9c07d
change-id: 20260409-fixes-e53fcaec5dad
Best regards,
--
Junrui Luo <moonafterrain@outlook.com>
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox