* Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature
From: Shah, Tanmay @ 2026-04-23 17:59 UTC (permalink / raw)
To: Krzysztof Kozlowski, tanmay.shah
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <eac0f387-c38a-44eb-aed4-6c4022f01777@kernel.org>
On 4/23/2026 12:26 PM, Krzysztof Kozlowski wrote:
> On 23/04/2026 17:14, Shah, Tanmay wrote:
>> Hello,
>>
>> Thanks for reviews. Please see my comments below.
>>
>> On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
>>> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>>>> Add auto-boot property to notify that remote processor is setup and
>>>> ready to boot. Linux can attempt to boot or attach to already running
>>>> remote processor. "firmware-name" property is used to mention default
>>>> firmware to boot when linux starts the remote processor.
>>>>
>>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>>> ---
>>>> .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> index ee63c03949c9..0d27260e3baa 100644
>>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>>> @@ -135,6 +135,14 @@ patternProperties:
>>>> - description: vring1
>>>> additionalItems: true
>>>>
>>>> + auto-boot:
>>>
>>> Last months, I have been asking AMD to follow writing-bindings doc or
>>> other DT guidelines way too many times.
>>>
>>> Or you just sent us downstream... Do you see anywhere such property?
>>> What properties do you see? How are they named?
>>>
>>
>> I should have put note about this. Current auto-boot properties are
>> named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
>> there. Can we have a common auto-boot property? Similar to
>> firmware-name? If we agree to it then what's the correct location? New
>> file remoteproc.yaml is okay?
>
> Common properties go to dtschema, so it would need to go there, but the
> point is that it's way too generic - every component with FW could be
> called "auto-boot". This should stay vendor property, IMO.
>
Ack, I will rename it to xlnx,auto-boot.
>>
>>>> + type: boolean
>>>> + description: remote core is either already running or ready to boot
>>>
>>> And why is this property of a board?
>>>
>>
>> Not sure what indicates it is? The property is under remoteproc child
>> device that is SOC level property. Remote core is on same SOC wher linux
>> core is running.
>
> So it is implied by SoC compatible? Please provide some arguments why it
> cannot be implied by the SoC compatible. I gave you one way out, but if
> you disagree then no problem.
>
So on some SoC, the bootloader supports loading and starting of the
remote processor. But it is totally user's choice. User can choose to
load & start one core of a cluster via bootloader and leave another core
powered-off.
That is why it is not possible to decide based on SoC compatible.
If we don't want to make it a device-tree property then I can implement
in a different way. New way will detect if the remote is running or not
via EMMI/SCMI call to the firmware, and take a decision based on that.
If this new way works, then I don't think we need auto-boot property at all.
Let me know your thoughts.
>>
>>>> +
>>>> + firmware-name:
>>>> + maxItems: 1
>>>> + description: default firmware to load
>>>
>>> Can you load non-default firmware later? IOW, why adding description
>>> here, what is special?
>>>
>>
>> The rootfs contains other firmware demos, and it is possible to stop the
>> default firmware, load other fw elf and re-run the remote core.
>> I don't have strong preference on the description part, I will remove it
>> if redundant.
>
> No, it's fine, I wanted to be sure that such use case makes sense.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mathieu Desnoyers @ 2026-04-23 17:47 UTC (permalink / raw)
To: Chris Kennelly, Thomas Gleixner
Cc: Mathias Stearn, Peter Zijlstra, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Dmitry Vyukov, regressions,
linux-kernel, linux-arm-kernel, Ingo Molnar, Mark Rutland,
Jinjie Ruan, Blake Oler, Linus Torvalds
In-Reply-To: <CAEE+yb=rZFxxOhCw+6wsUt5PE6=ebbKjEggQ_j_G3qSkMQZsfg@mail.gmail.com>
On 2026-04-23 13:38, Chris Kennelly wrote:
> On Thu, Apr 23, 2026 at 1:19 PM Thomas Gleixner <tglx@kernel.org> wrote:
[...]
>>
>> 3) The RO for userspace property has been enforced by RSEQ debugging
>> mode since day one. If such a debug enabled kernel detects user
>> space changing the field it kills the task/application.
>
> The optimization in TCMalloc that you're describing has been available
> since September 2023:
> https://github.com/google/tcmalloc/commit/aaa4fbf6fcdce1b7f86fcadd659874645c75ddb9
>
> I thought the RSEQ debug checks were added in December 2024:
> https://github.com/torvalds/linux/commit/7d5265ffcd8b41da5e09066360540d6e0716e9cd,
> but perhaps I misidentified the ones in question.
You are correct, I added the RSEQ field corruption validation under
debug config in Nov. 2024 when I noticed the world of pain we were
heading towards with incompatible tcmalloc vs glibc (and general) use
due to tcmalloc not respecting the ABI contract. RSEQ has been
upstreamed in 2018. So that's not exactly a day one enforcement.
The ABI contract was clear about this being an invalid use from
day one though.
[...]
>> 7) tcmalloc violates the ABI from day one and has since refused to
>> address the problem despite being offered a kernel side rseq
>> extension to solve it many years ago.
>
> I know there was some discussion around a preemption notification
> scheme, rseq_sched_state; but I thought the discussion moved in favor
> of the timeslice extension interface that recently landed. Timeslice
> extension solves some use cases, but I'm not sure it addresses this
> one.
I have actively engaged with the tcmalloc developers to
understand their needs and figure out a proper solution for the
past ~3-4 years, without success.
I have done a POC branch extending rseq with a "reset a linked list of
userspace areas on preemption" back in 2024 which would have solved
tcmalloc's issues cleanly. I never posted it publicly because the
tcmalloc devs told me they could not justify spending time even trying
this out to their managers.
I still have that feature branch gathering dust somewhere.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
^ permalink raw reply
* Re: [PATCH] spi: sun6i: Set SPI mode in prepare_message
From: Kevin Mehall @ 2026-04-23 17:46 UTC (permalink / raw)
To: Mark Brown
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Mirko Vogt,
Ralf Schlatterbeck, linux-spi, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <f93e1bc6-608b-4c75-8b1a-80f701ff37ce@sirena.org.uk>
I tested with `spi-cs-setup-delay-ns = <1000000>;` and a hardware CS in the
device tree, and confirmed the suspected second bug: without this patch, the
first transfer after autosuspend ignores the setup delay.
> I do see that the driver uses a reset controller over suspend, are you
> sure that setup() will be called again on resume?
SUN6I_TFR_CTL_REG is indeed being reset after autosuspend because the above bug
reoccurs after a few seconds of inactivity. I am not sure if setup() is running on
resume because the datasheet reset value of SUN6I_TFR_CTL_CS_LEVEL is the same
as what would be written. Either way, it's moot if we set all CS-related bits in
the same register write.
I've moved the line that sets SUN6I_TFR_CTL_CS_MANUAL into sun6i_spi_set_cs()
rather than into sun6i_spi_prepare_message() as a separated commit in a new patch
series:
https://lore.kernel.org/linux-spi/20260423174001.2797797-1-km@kevinmehall.net/
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-23 17:44 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB7252BD7967D2567AD6DA7A1D8B2F2@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]
On Mon, Apr 20, 2026 at 07:22:57AM +0000, Billy Tsai wrote:
> In particular, I'll split the constraints as follows:
>
> - For pinmux, the presence of `function` will require `groups`, and
> `pins` will not be allowed. This reflects the hardware design, where
> the groups are defined by the pins affected by a given mux expression
>
> - For pin configuration, exactly one of `groups` or `pins` will be
> required (using oneOf), so that configuration is applied either at
> group level or per-pin, but not both.
>
>
> - if:
> required:
> - function
> then:
> required:
> - groups
> not:
> required:
> - pins
> else:
I think this is a separate section under an allOf, rather than an else.
You can also simplify the condition above to just be
- if:
required:
- function
then:
required:
- groups
since the node will then always be tested against what you have below
> oneOf:
> - required:
> - groups
> not:
> required:
> - pins
> - required:
> - pins
> not:
> required:
> - groups
I think this here simplifies to
oneOf:
- required:
- groups
- required:
- pins
You'd also need to note that pin level config settings should take
precedence over group level ones.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Linus Torvalds @ 2026-04-23 17:41 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mathias Stearn, Peter Zijlstra, Mathieu Desnoyers,
Catalin Marinas, Will Deacon, Boqun Feng, Paul E. McKenney,
Chris Kennelly, Dmitry Vyukov, regressions, linux-kernel,
linux-arm-kernel, Ingo Molnar, Mark Rutland, Jinjie Ruan,
Blake Oler
In-Reply-To: <87cxzp1tn6.ffs@tglx>
On Thu, 23 Apr 2026 at 10:19, Thomas Gleixner <tglx@kernel.org> wrote:
>
> C) Declare that this is not a regression because the ABI guarantee is
> not violated and the RO property has been enforcable by RSEQ
> debugging since day one.
No, if this actually hits real users, that is not an option. If real
users never used RSEQ debugging options, those options are simply
irrelevant.
Regression rules have never been about "it wouldn't have worked in
some other configuration". That's like saying "that code would never
have worked on another architecture". It may be true, but it's
irrelevant for the people whose binaries no longer work.
We will have to fix this.
This is not some kind of gray area. It clearly violates our regression rules.
The only "ABI guarantee" is what people actually see and use, not some
debug option that wasn't enabled.
And I just checked - it's not enabled in at least the Fedora distro
kernels. Presumably other distros don't enable it either. So no actual
non-kernel developer would *ever* have hit it, and claiming it is
relevant is just garbage.
IOW, that debug option was always a complete no-op except for kernel developers.
In fact, that debug option is actively *hidden* - you have to enable
EXPERT to even see it. Soi it really is not a real option for normal
people AT ALL.
Christ, even *I* don't enable EXPERT except for build testing. It's
literally something that only embedded people doing odd things should
do.
If that rule was actually an important part of the ABI, it shouldn't
have been a debug thing.
So:
(a) the debug code in question needs to just be removed, since it's
now actively detrimental, and means that any kernel developer who
*does* enable it can't actually test this case any more. It's checking
for something that has been shown to not be true.
(b) we need to fix this (revert if it can't be fixed otherwise)
I see some patches flying around, but am not clear on whether there
was an actual patch that make this work again?
Linus
^ permalink raw reply
* [PATCH v2 2/2] spi: sun6i: Set SPI mode in prepare_message
From: Kevin Mehall @ 2026-04-23 17:40 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260423174001.2797797-1-km@kevinmehall.net>
With a GPIO chip select, CS is asserted before entering transfer_one.
The spi-sun6i driver previously configured the SPI mode (including clock
polarity) and enabled the bus in transfer_one, which can cause an
extraneous SCK transition with CS asserted, corrupting the transferred
data.
This patch moves the SPI mode configuration and bus enable to the
spi_prepare_message callback, ensuring that SCK is driven to the correct
level prior to asserting CS.
A previous fix for a related issue (0d7993b234c9f) was incomplete in
that it only delayed enabling the SCK output drive to prevent it from
being driven at the wrong level when resuming from autosuspend, but
didn't help if switching CPOL modes between chip selects while active,
or if SCK floats to the opposite level when suspended.
Fixes: 0d7993b234c9 ("spi: spi-sun6i: Fix chipselect/clock bug")
Signed-off-by: Kevin Mehall <km@kevinmehall.net>
---
drivers/spi/spi-sun6i.c | 67 +++++++++++++++++++++++++----------------
1 file changed, 41 insertions(+), 26 deletions(-)
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index fc228574ed38..983e791e3396 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -205,6 +205,44 @@ static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
return SUN6I_MAX_XFER_SIZE - 1;
}
+static int sun6i_spi_prepare_message(struct spi_controller *ctlr,
+ struct spi_message *msg)
+{
+ struct sun6i_spi *sspi = spi_controller_get_devdata(ctlr);
+ struct spi_device *spi = msg->spi;
+ u32 reg;
+
+ /* Set the mode bits in the transfer control register */
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
+ if (spi->mode & SPI_CPOL)
+ reg |= SUN6I_TFR_CTL_CPOL;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPOL;
+
+ if (spi->mode & SPI_CPHA)
+ reg |= SUN6I_TFR_CTL_CPHA;
+ else
+ reg &= ~SUN6I_TFR_CTL_CPHA;
+
+ if (spi->mode & SPI_LSB_FIRST)
+ reg |= SUN6I_TFR_CTL_FBS;
+ else
+ reg &= ~SUN6I_TFR_CTL_FBS;
+
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+
+ /*
+ * Now that the clock polarity is configured, enable the bus if the
+ * controller was previously suspended.
+ */
+ reg = sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG);
+ reg |= SUN6I_GBL_CTL_BUS_ENABLE;
+ sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, reg);
+
+ return 0;
+}
+
static void sun6i_spi_dma_rx_cb(void *param)
{
struct sun6i_spi *sspi = param;
@@ -336,31 +374,12 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG, reg);
- /*
- * Setup the transfer control register: Chip Select,
- * polarities, etc.
- */
- reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
-
- if (spi->mode & SPI_CPOL)
- reg |= SUN6I_TFR_CTL_CPOL;
- else
- reg &= ~SUN6I_TFR_CTL_CPOL;
-
- if (spi->mode & SPI_CPHA)
- reg |= SUN6I_TFR_CTL_CPHA;
- else
- reg &= ~SUN6I_TFR_CTL_CPHA;
-
- if (spi->mode & SPI_LSB_FIRST)
- reg |= SUN6I_TFR_CTL_FBS;
- else
- reg &= ~SUN6I_TFR_CTL_FBS;
-
/*
* If it's a TX only transfer, we don't want to fill the RX
* FIFO with bogus data
*/
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
if (sspi->rx_buf) {
reg &= ~SUN6I_TFR_CTL_DHB;
rx_len = tfr->len;
@@ -429,11 +448,6 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
}
- /* Finally enable the bus - doing so before might raise SCK to HIGH */
- reg = sun6i_spi_read(sspi, SUN6I_GBL_CTL_REG);
- reg |= SUN6I_GBL_CTL_BUS_ENABLE;
- sun6i_spi_write(sspi, SUN6I_GBL_CTL_REG, reg);
-
/* Setup the transfer now... */
if (sspi->tx_buf) {
tx_len = tfr->len;
@@ -668,6 +682,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
host->max_speed_hz = 100 * 1000 * 1000;
host->min_speed_hz = 3 * 1000;
host->use_gpio_descriptors = true;
+ host->prepare_message = sun6i_spi_prepare_message;
host->set_cs = sun6i_spi_set_cs;
host->transfer_one = sun6i_spi_transfer_one;
host->num_chipselect = 4;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] spi: sun6i: Honor CS setup delay on the first transfer with native CS
From: Kevin Mehall @ 2026-04-23 17:40 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260423174001.2797797-1-km@kevinmehall.net>
Move SUN6I_TFR_CTL_CS_MANUAL to sun6i_spi_set_cs.
The CS_MANUAL bit is required for CS_LEVEL to affect the CS pin state.
Set it in the same place as other CS bits to ensure that set_cs takes
effect immediately, and to make it easier to reason about CS behavior.
Previously, this bit was not set until the first transfer's
sun6i_spi_transfer_one. That meant that on the first transfer, set_cs
would have no immediate effect, and the CS falling edge was deferred
until the bit is set in transfer_one. As any configured cs_setup delay
happens between those two steps, the configured delay would have
effectively been ignored on the very first transfer. This change makes
the first transfer work like subsequent ones.
Link: https://lore.kernel.org/linux-spi/d199f72a-093b-41bb-b33e-b6685563f704@app.fastmail.com/
Fixes: 3558fe900e8a ("spi: sunxi: Add Allwinner A31 SPI controller driver")
Signed-off-by: Kevin Mehall <km@kevinmehall.net>
---
drivers/spi/spi-sun6i.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 240e46f84f7b..fc228574ed38 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -185,6 +185,10 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
u32 reg;
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
+ /* SUN6I_TFR_CTL_CS_LEVEL sets CS rather than the controller doing it automatically */
+ reg |= SUN6I_TFR_CTL_CS_MANUAL;
+
reg &= ~SUN6I_TFR_CTL_CS_MASK;
reg |= SUN6I_TFR_CTL_CS(spi_get_chipselect(spi, 0));
@@ -364,9 +368,6 @@ static int sun6i_spi_transfer_one(struct spi_controller *host,
reg |= SUN6I_TFR_CTL_DHB;
}
- /* We want to control the chip select manually */
- reg |= SUN6I_TFR_CTL_CS_MANUAL;
-
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
if (sspi->cfg->has_clk_ctl) {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] spi: sun6i: Fix chip select handling around autosuspend
From: Kevin Mehall @ 2026-04-23 17:39 UTC (permalink / raw)
To: Mark Brown, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Mirko Vogt, Ralf Schlatterbeck, linux-spi, linux-arm-kernel,
linux-sunxi, linux-kernel
Move the initialization of the SUN6I_TFR_CTL_REG bits out of
sun6i_spi_transfer_one() into earlier callbacks to fix two bugs:
- With a native chip select, the setup_delay is not correctly applied to
the first transfer after autosuspend.
- With a GPIO chip select, the CS is asserted before SCK is driven to the
correct initial level per the SPI mode. When the mode is set, it can
cause an extra SCK transition with CS low and corrupt the transfer.
Changes since the previous single patch:
- Move the line that sets `SUN6I_TFR_CTL_CS_MANUAL` into
`sun6i_spi_set_cs()` rather than into `sun6i_spi_prepare_message()`.
This change is now a separate commit.
Kevin Mehall (2):
spi: sun6i: Honor CS setup delay on the first transfer with native CS
spi: sun6i: Set SPI mode in prepare_message
drivers/spi/spi-sun6i.c | 74 +++++++++++++++++++++++++----------------
1 file changed, 45 insertions(+), 29 deletions(-)
base-commit: 028ef9c96e96197026887c0f092424679298aae8
--
2.53.0
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Chris Kennelly @ 2026-04-23 17:38 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mathias Stearn, Peter Zijlstra, Mathieu Desnoyers,
Catalin Marinas, Will Deacon, Boqun Feng, Paul E. McKenney,
Dmitry Vyukov, regressions, linux-kernel, linux-arm-kernel,
Ingo Molnar, Mark Rutland, Jinjie Ruan, Blake Oler,
Linus Torvalds
In-Reply-To: <87cxzp1tn6.ffs@tglx>
On Thu, Apr 23, 2026 at 1:19 PM Thomas Gleixner <tglx@kernel.org> wrote:
>
> On Thu, Apr 23 2026 at 14:11, Mathias Stearn wrote:
>
> Cc+ Linus
>
> > Of course, even if we make that change, it will only apply to _future_
> > binaries. That's why we prefer a kernel fix so that users will be able
> > to run our existing releases (or any containers that use them) on a
> > modern kernel.
>
> I understand that and as everyone else I would be happy to do that, but
> the price everyone pays for proliferating the tcmalloc insanity is not
> cheap either.
>
> So let me recap the whole situation and how we got there:
>
> 1) The original RSEQ implementation updates the rseq::cpu_id_start
> field in user space more or less unconditionally on every exit to
> user, whether the CPU/MMCID have been changed or not.
>
> That went unnoticed for years because nothing used rseq aside of
> google and tcmalloc. Once glibc registered rseq, this resulted in a
> up to 15% performance penalty for syscall heavy workloads.
>
> 2) The rseq::cpu_id_start field is documented as read only for user
> space in the ABI contract and guaranteed to be updated by the
> kernel when a task is migrated to a different CPU.
>
> 3) The RO for userspace property has been enforced by RSEQ debugging
> mode since day one. If such a debug enabled kernel detects user
> space changing the field it kills the task/application.
The optimization in TCMalloc that you're describing has been available
since September 2023:
https://github.com/google/tcmalloc/commit/aaa4fbf6fcdce1b7f86fcadd659874645c75ddb9
I thought the RSEQ debug checks were added in December 2024:
https://github.com/torvalds/linux/commit/7d5265ffcd8b41da5e09066360540d6e0716e9cd,
but perhaps I misidentified the ones in question.
>
> 4) tcmalloc abused the suboptimal implementation (see #1) and
> scribbled over rseq::cpu_id_start for their own nefarious purposes.
>
> 5) As a consequence of #4 tcmalloc cannot be used on a RSEQ debug
> enabled kernel. Which means a developer cannot validate his RSEQ
> code against a debug kernel when tcmalloc is in use on the system
> as that would crash the tcmalloc dependent applications due to #3.
>
> 6) As a consequence of #4 tcmalloc cannot be used together with any
> other facility/library which wants to utilize the ABI guaranteed
> properties of rseq::cpu_id_start in the same application.
>
> 7) tcmalloc violates the ABI from day one and has since refused to
> address the problem despite being offered a kernel side rseq
> extension to solve it many years ago.
I know there was some discussion around a preemption notification
scheme, rseq_sched_state; but I thought the discussion moved in favor
of the timeslice extension interface that recently landed. Timeslice
extension solves some use cases, but I'm not sure it addresses this
one.
>
> 8) When addressing the performance issues of RSEQ the unconditional
> update stopped to exist under the valid assumption that the kernel
> has only to satisfy the guaranteed ABI properties, especially when
> they are enforcable by RSEQ debug.
>
> As a consequence this exposed the tcmalloc ABI violation because
> the unconditional pointless overwriting of something which did not
> change stopped to happen.
>
> Due to #4 everyone is in a hard place and up a creek without a paddle.
>
> Here are the possible solutions:
>
> A) Mathias suggested to force overwrite rseq:cpu_id_start everytime
> the rseq::rseq_cs field is cleared by the kernel under the not yet
> validated theoretical assumption that this cures the problem for
> tcmalloc.
>
> If that's sufficient that would be harmless performance wise
> because the write would be inside the already existing STAC/CLAC
> section and just add some more noise to the rseq critical section
> operations.
>
> That would allow existing tcmalloc usage to continue, but
> obviously would neither solve #5 and #6 above nor provide an
> incentive for tcmalloc to actually fix their crap.
>
> B) If that's not sufficient then keeping tcmalloc alive would require
> to go back to the previous state and let everyone else pay the
> price in terms of performance overhead.
>
> C) Declare that this is not a regression because the ABI guarantee is
> not violated and the RO property has been enforcable by RSEQ
> debugging since day one.
>
> In my opinion #C is the right thing to do, but I can see a case being
> made for the lightweight fix Mathias suggested (#A) _if_ and only _if_
> that is sufficient. Picking #A would also mean that user space people
> have to take up the fight against tcmalloc when they want to use the
> RSEQ guaranteed ABI along with tcmalloc in the same application or use a
> RSEQ debug kernel to validate their own code.
>
> Going back to the full unconditional nightmare (#B) is not an option at
> all as anybody else has to take the massive performance hit.
>
> Oh well...
>
> Thanks,
>
> tglx
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: remoteproc: xlnx: add auto boot feature
From: Krzysztof Kozlowski @ 2026-04-23 17:26 UTC (permalink / raw)
To: tanmay.shah
Cc: andersson, mathieu.poirier, robh, krzk+dt, conor+dt, michal.simek,
ben.levinsky, linux-remoteproc, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <2351c698-cf08-4037-9777-0820448a14d8@amd.com>
On 23/04/2026 17:14, Shah, Tanmay wrote:
> Hello,
>
> Thanks for reviews. Please see my comments below.
>
> On 4/23/2026 4:09 AM, Krzysztof Kozlowski wrote:
>> On Wed, Apr 22, 2026 at 01:25:57PM -0700, Tanmay Shah wrote:
>>> Add auto-boot property to notify that remote processor is setup and
>>> ready to boot. Linux can attempt to boot or attach to already running
>>> remote processor. "firmware-name" property is used to mention default
>>> firmware to boot when linux starts the remote processor.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>> .../devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> index ee63c03949c9..0d27260e3baa 100644
>>> --- a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> +++ b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5fss.yaml
>>> @@ -135,6 +135,14 @@ patternProperties:
>>> - description: vring1
>>> additionalItems: true
>>>
>>> + auto-boot:
>>
>> Last months, I have been asking AMD to follow writing-bindings doc or
>> other DT guidelines way too many times.
>>
>> Or you just sent us downstream... Do you see anywhere such property?
>> What properties do you see? How are they named?
>>
>
> I should have put note about this. Current auto-boot properties are
> named like st,auto-boot fsl,auto-boot etc. but nothing vendor specific
> there. Can we have a common auto-boot property? Similar to
> firmware-name? If we agree to it then what's the correct location? New
> file remoteproc.yaml is okay?
Common properties go to dtschema, so it would need to go there, but the
point is that it's way too generic - every component with FW could be
called "auto-boot". This should stay vendor property, IMO.
>
>>> + type: boolean
>>> + description: remote core is either already running or ready to boot
>>
>> And why is this property of a board?
>>
>
> Not sure what indicates it is? The property is under remoteproc child
> device that is SOC level property. Remote core is on same SOC wher linux
> core is running.
So it is implied by SoC compatible? Please provide some arguments why it
cannot be implied by the SoC compatible. I gave you one way out, but if
you disagree then no problem.
>
>>> +
>>> + firmware-name:
>>> + maxItems: 1
>>> + description: default firmware to load
>>
>> Can you load non-default firmware later? IOW, why adding description
>> here, what is special?
>>
>
> The rootfs contains other firmware demos, and it is possible to stop the
> default firmware, load other fw elf and re-run the remote core.
> I don't have strong preference on the description part, I will remove it
> if redundant.
No, it's fine, I wanted to be sure that such use case makes sense.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 7/8] firmware: arm_ffa: Fix sched-recv callback partition lookup
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
ffa_sched_recv_cb_update() used list_for_each_entry_safe() to search for
a matching partition and then tested the iterator against NULL. That is
not a valid end-of-list check for circular lists and can fall through
with an invalid pointer. Use a normal iterator and detect the not-found
case correctly before touching the partition state.
Fixes: be61da938576 ("firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 4edb88079bac..40ade6edcf33 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1190,7 +1190,7 @@ static int
ffa_sched_recv_cb_update(struct ffa_device *dev, ffa_sched_recv_cb callback,
void *cb_data, bool is_registration)
{
- struct ffa_dev_part_info *partition = NULL, *tmp;
+ struct ffa_dev_part_info *partition = NULL;
struct list_head *phead;
bool cb_valid;
@@ -1203,11 +1203,11 @@ ffa_sched_recv_cb_update(struct ffa_device *dev, ffa_sched_recv_cb callback,
return -EINVAL;
}
- list_for_each_entry_safe(partition, tmp, phead, node)
+ list_for_each_entry(partition, phead, node)
if (partition->dev == dev)
break;
- if (!partition) {
+ if (&partition->node == phead) {
pr_err("%s: No such partition ID 0x%x\n", __func__, dev->vm_id);
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 8/8] firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
The register-based PARTITION_INFO_GET path trusted the firmware-provided
indices when copying partition descriptors into the caller buffer.
Reject inconsistent counts or index progressions so the copy loop cannot
write past the allocated array.
Fixes: ba85c644ac8d ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 40ade6edcf33..4bb86eb721cd 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -336,7 +336,7 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
do {
__le64 *regs;
- int idx;
+ int idx, nr_desc, buf_idx;
start_idx = prev_idx ? prev_idx + 1 : 0;
@@ -354,15 +354,25 @@ __ffa_partition_info_get_regs(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
count = PARTITION_COUNT(partition_info.a2);
if (!buffer || !num_parts) /* count only */
return count;
+ if (count > num_parts)
+ return -EINVAL;
cur_idx = CURRENT_INDEX(partition_info.a2);
+ if (cur_idx < start_idx || cur_idx >= count)
+ return -EINVAL;
+
+ nr_desc = cur_idx - start_idx + 1;
+ buf_idx = buf - buffer;
+ if (buf_idx + nr_desc > num_parts)
+ return -EINVAL;
+
tag = UUID_INFO_TAG(partition_info.a2);
buf_sz = PARTITION_INFO_SZ(partition_info.a2);
if (buf_sz > sizeof(*buffer))
buf_sz = sizeof(*buffer);
regs = (void *)&partition_info.a3;
- for (idx = 0; idx < cur_idx - start_idx + 1; idx++, buf++) {
+ for (idx = 0; idx < nr_desc; idx++, buf++) {
union {
uuid_t uuid;
u64 regs[2];
--
2.43.0
^ permalink raw reply related
* [PATCH 5/8] firmware: arm_ffa: Validate framework notification payload bounds
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
Framework notification callbacks copy an indirect message payload out of
the shared Rx buffer. Validate the reported offset and size before
kmemdup() so malformed firmware data cannot drive an out-of-bounds read
or an oversized allocation.
Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 764cb1226182..0e030f377985 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1469,6 +1469,7 @@ static void handle_fwk_notif_callbacks(u32 bitmap)
int notify_id = 0, target;
struct ffa_indirect_msg_hdr *msg;
struct notifier_cb_info *cb_info = NULL;
+ size_t min_offset = offsetof(struct ffa_indirect_msg_hdr, uuid);
/* Only one framework notification defined and supported for now */
if (!(bitmap & FRAMEWORK_NOTIFY_RX_BUFFER_FULL))
@@ -1476,6 +1477,13 @@ static void handle_fwk_notif_callbacks(u32 bitmap)
scoped_guard(mutex, &drv_info->rx_lock) {
msg = drv_info->rx_buffer;
+ if ((msg->offset != min_offset && msg->offset < sizeof(*msg)) ||
+ msg->offset > drv_info->rxtx_bufsz ||
+ msg->size > drv_info->rxtx_bufsz - msg->offset) {
+ pr_err("invalid framework notification message\n");
+ goto release_rx;
+ }
+
buf = kmemdup((void *)msg + msg->offset, msg->size, GFP_KERNEL);
if (!buf)
goto release_rx;
--
2.43.0
^ permalink raw reply related
* [PATCH 3/8] firmware: arm_ffa: Align RxTx buffer size before mapping
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Jens Wiklander, Sudeep Holla, Sebastian Ene
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
Commit 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during
RXTX_MAP") advertises PAGE_ALIGN(rxtx_bufsz) to firmware when mapping the
buffers but the driver continues to stores the minimum FF-A buffer size
in drv_info->rxtx_bufsz which is used elsewhere in the driver.
Align the size before storing it so that the allocation, validation and
FFA_RXTX_MAP all use the same buffer size.
Fixes: 83210251fd70 ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP")
Cc: Sebastian Ene <sebastianene@google.com>
Link: https://sashiko.dev/#/patchset/20260402113939.930221-1-sebastianene@google.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index e6a051b20cb7..4dec7ca52f8c 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2063,6 +2063,7 @@ static int __init ffa_init(void)
rxtx_bufsz = SZ_4K;
}
+ rxtx_bufsz = PAGE_ALIGN(rxtx_bufsz);
drv_info->rxtx_bufsz = rxtx_bufsz;
drv_info->rx_buffer = alloc_pages_exact(rxtx_bufsz, GFP_KERNEL);
if (!drv_info->rx_buffer) {
@@ -2078,7 +2079,7 @@ static int __init ffa_init(void)
ret = ffa_rxtx_map(virt_to_phys(drv_info->tx_buffer),
virt_to_phys(drv_info->rx_buffer),
- PAGE_ALIGN(rxtx_bufsz) / FFA_PAGE_SIZE);
+ rxtx_bufsz / FFA_PAGE_SIZE);
if (ret) {
pr_err("failed to register FFA RxTx buffers\n");
goto free_pages;
--
2.43.0
^ permalink raw reply related
* [PATCH 6/8] firmware: arm_ffa: Unregister v1.0 bus notifier on teardown
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
For FF-A v1.0 the driver registers a bus notifier to backfill UUID
matching, but the notifier was never unregistered on cleanup paths.
Track the registration state and unregister it during teardown and early
partition-setup failure.
Fixes: 9dd15934f60d ("firmware: arm_ffa: Move the FF-A v1.0 NULL UUID workaround to bus notifier")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 0e030f377985..4edb88079bac 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -100,6 +100,7 @@ struct ffa_drv_info {
bool mem_ops_native;
bool msg_direct_req2_supp;
bool bitmap_created;
+ bool bus_notifier_registered;
bool notif_enabled;
unsigned int sched_recv_irq;
unsigned int notif_pend_irq;
@@ -1638,6 +1639,15 @@ static struct notifier_block ffa_bus_nb = {
.notifier_call = ffa_bus_notifier,
};
+static void ffa_bus_notifier_unregister(void)
+{
+ if (!drv_info->bus_notifier_registered)
+ return;
+
+ bus_unregister_notifier(&ffa_bus_type, &ffa_bus_nb);
+ drv_info->bus_notifier_registered = false;
+}
+
static int ffa_xa_add_partition_info(struct ffa_device *dev)
{
struct ffa_dev_part_info *info;
@@ -1721,6 +1731,8 @@ static void ffa_partitions_cleanup(void)
struct list_head *phead;
unsigned long idx;
+ ffa_bus_notifier_unregister();
+
/* Clean up/free all registered devices */
ffa_devices_unregister();
@@ -1748,11 +1760,14 @@ static int ffa_setup_partitions(void)
ret = bus_register_notifier(&ffa_bus_type, &ffa_bus_nb);
if (ret)
pr_err("Failed to register FF-A bus notifiers\n");
+ else
+ drv_info->bus_notifier_registered = true;
}
count = ffa_partition_probe(&uuid_null, &pbuf);
if (count <= 0) {
pr_info("%s: No partitions found, error %d\n", __func__, count);
+ ffa_bus_notifier_unregister();
return -EINVAL;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 4/8] firmware: arm_ffa: Fix Rx buffer release in fwk notification handler
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
Refactor handle_fwk_notif_callbacks() so that all exit paths funnel
through a single FFA_RX_RELEASE call. While doing that, use scoped_guard()
for the Rx buffer lock and keep the message parsing under the lock scope.
This makes the Rx buffer release explicit for the kmemdup() failure path
and for the early exit when the framework notification bit is not set.
This will ensure the Rx buffer is always release in the framework
notification handler.
Fixes: 285a5ea0f542 ("firmware: arm_ffa: Add support for handling framework notifications")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 4dec7ca52f8c..764cb1226182 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1472,25 +1472,21 @@ static void handle_fwk_notif_callbacks(u32 bitmap)
/* Only one framework notification defined and supported for now */
if (!(bitmap & FRAMEWORK_NOTIFY_RX_BUFFER_FULL))
- return;
+ goto release_rx;
- mutex_lock(&drv_info->rx_lock);
+ scoped_guard(mutex, &drv_info->rx_lock) {
+ msg = drv_info->rx_buffer;
+ buf = kmemdup((void *)msg + msg->offset, msg->size, GFP_KERNEL);
+ if (!buf)
+ goto release_rx;
- msg = drv_info->rx_buffer;
- buf = kmemdup((void *)msg + msg->offset, msg->size, GFP_KERNEL);
- if (!buf) {
- mutex_unlock(&drv_info->rx_lock);
- return;
+ target = SENDER_ID(msg->send_recv_id);
+ if (msg->offset >= sizeof(*msg))
+ uuid_copy(&uuid, &msg->uuid);
+ else
+ uuid_copy(&uuid, &uuid_null);
}
- target = SENDER_ID(msg->send_recv_id);
- if (msg->offset >= sizeof(*msg))
- uuid_copy(&uuid, &msg->uuid);
- else
- uuid_copy(&uuid, &uuid_null);
-
- mutex_unlock(&drv_info->rx_lock);
-
ffa_rx_release();
read_lock(&drv_info->notify_lock);
@@ -1500,6 +1496,11 @@ static void handle_fwk_notif_callbacks(u32 bitmap)
if (cb_info && cb_info->fwk_cb)
cb_info->fwk_cb(notify_id, cb_info->cb_data, buf);
kfree(buf);
+
+ return;
+
+release_rx:
+ ffa_rx_release();
}
static void notif_get_and_handle(void *cb_data)
--
2.43.0
^ permalink raw reply related
* [PATCH 2/8] firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
If the RX buffer allocation fails in ffa_init(), the error path jumps to
free_pages even though no buffer has been allocated yet. Route that case
directly to free_drv_info so the cleanup path is only used after at
least one RX/TX buffer allocation has succeeded.
Fixes: 3bbfe9871005 ("firmware: arm_ffa: Add initial Arm FFA driver support")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index eb2782848283..e6a051b20cb7 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2067,7 +2067,7 @@ static int __init ffa_init(void)
drv_info->rx_buffer = alloc_pages_exact(rxtx_bufsz, GFP_KERNEL);
if (!drv_info->rx_buffer) {
ret = -ENOMEM;
- goto free_pages;
+ goto free_drv_info;
}
drv_info->tx_buffer = alloc_pages_exact(rxtx_bufsz, GFP_KERNEL);
--
2.43.0
^ permalink raw reply related
* [PATCH 1/8] firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: Jens Wiklander, Sudeep Holla
In-Reply-To: <20260423-ffa_fixes-v1-0-61189661affe@kernel.org>
The bus match callback assumes that every FF-A driver provides an
id_table and dereferences it unconditionally. Enforce that contract at
registration time so a buggy client driver cannot crash the bus during
match.
Fixes: e781858488b9 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration")
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
drivers/firmware/arm_ffa/bus.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/bus.c b/drivers/firmware/arm_ffa/bus.c
index 9576862d89c4..601c3418e0d9 100644
--- a/drivers/firmware/arm_ffa/bus.c
+++ b/drivers/firmware/arm_ffa/bus.c
@@ -26,6 +26,8 @@ static int ffa_device_match(struct device *dev, const struct device_driver *drv)
id_table = to_ffa_driver(drv)->id_table;
ffa_dev = to_ffa_dev(dev);
+ if (!id_table)
+ return 0;
while (!uuid_is_null(&id_table->uuid)) {
/*
@@ -123,7 +125,7 @@ int ffa_driver_register(struct ffa_driver *driver, struct module *owner,
{
int ret;
- if (!driver->probe)
+ if (!driver->probe || !driver->id_table)
return -EINVAL;
driver->driver.bus = &ffa_bus_type;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/8] firmware: arm_ffa: Fix cleanup, notification, and discovery paths
From: Sudeep Holla @ 2026-04-23 17:22 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: Jens Wiklander, Sudeep Holla, Sebastian Ene
Hi all,
This series fixes a set of issues in the FF-A driver around init
cleanup, framework notification handling, v1.0 notifier lifetime, and
partition discovery.
The fixes are all small and localized, but together they tighten a few
important paths:
- fix the early init unwind path when RX buffer allocation fails
- align the stored RX/TX buffer size with the size actually mapped to
firmware
- ensure the framework notification handler always releases the RX
buffer correctly
- validate framework notification payload bounds before copying data out
of the shared RX buffer
- fix the partition lookup used for sched-recv callback registration
- unregister the FF-A v1.0 bus notifier during teardown
- bound the register-based partition discovery copies against the caller
buffer
- reject FF-A driver registration without an ID table
This is the outcome of the self-initiated review of the entire driver
following the oversight of Sashiko’s review on one of the patches that
was merged.
https://sashiko.dev/#/patchset/20260402113939.930221-1-sebastianene@google.com
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
---
Sudeep Holla (8):
firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
firmware: arm_ffa: Align RxTx buffer size before mapping
firmware: arm_ffa: Fix Rx buffer release in fwk notification handler
firmware: arm_ffa: Validate framework notification payload bounds
firmware: arm_ffa: Unregister v1.0 bus notifier on teardown
firmware: arm_ffa: Fix sched-recv callback partition lookup
firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies
drivers/firmware/arm_ffa/bus.c | 4 +-
drivers/firmware/arm_ffa/driver.c | 79 ++++++++++++++++++++++++++++-----------
2 files changed, 60 insertions(+), 23 deletions(-)
---
base-commit: 2e68039281932e6dc37718a1ea7cbb8e2cda42e6
change-id: 20260423-ffa_fixes-4ad33f0ee250
--
Regards,
Sudeep
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-23 17:19 UTC (permalink / raw)
To: Mathias Stearn
Cc: Peter Zijlstra, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Ingo Molnar,
Mark Rutland, Jinjie Ruan, Blake Oler, Linus Torvalds
In-Reply-To: <CAHnCjA07ER=9xBqXq4jf5yn052W-E9ZXD86HxnRGtai6bpXbbQ@mail.gmail.com>
On Thu, Apr 23 2026 at 14:11, Mathias Stearn wrote:
Cc+ Linus
> Of course, even if we make that change, it will only apply to _future_
> binaries. That's why we prefer a kernel fix so that users will be able
> to run our existing releases (or any containers that use them) on a
> modern kernel.
I understand that and as everyone else I would be happy to do that, but
the price everyone pays for proliferating the tcmalloc insanity is not
cheap either.
So let me recap the whole situation and how we got there:
1) The original RSEQ implementation updates the rseq::cpu_id_start
field in user space more or less unconditionally on every exit to
user, whether the CPU/MMCID have been changed or not.
That went unnoticed for years because nothing used rseq aside of
google and tcmalloc. Once glibc registered rseq, this resulted in a
up to 15% performance penalty for syscall heavy workloads.
2) The rseq::cpu_id_start field is documented as read only for user
space in the ABI contract and guaranteed to be updated by the
kernel when a task is migrated to a different CPU.
3) The RO for userspace property has been enforced by RSEQ debugging
mode since day one. If such a debug enabled kernel detects user
space changing the field it kills the task/application.
4) tcmalloc abused the suboptimal implementation (see #1) and
scribbled over rseq::cpu_id_start for their own nefarious purposes.
5) As a consequence of #4 tcmalloc cannot be used on a RSEQ debug
enabled kernel. Which means a developer cannot validate his RSEQ
code against a debug kernel when tcmalloc is in use on the system
as that would crash the tcmalloc dependent applications due to #3.
6) As a consequence of #4 tcmalloc cannot be used together with any
other facility/library which wants to utilize the ABI guaranteed
properties of rseq::cpu_id_start in the same application.
7) tcmalloc violates the ABI from day one and has since refused to
address the problem despite being offered a kernel side rseq
extension to solve it many years ago.
8) When addressing the performance issues of RSEQ the unconditional
update stopped to exist under the valid assumption that the kernel
has only to satisfy the guaranteed ABI properties, especially when
they are enforcable by RSEQ debug.
As a consequence this exposed the tcmalloc ABI violation because
the unconditional pointless overwriting of something which did not
change stopped to happen.
Due to #4 everyone is in a hard place and up a creek without a paddle.
Here are the possible solutions:
A) Mathias suggested to force overwrite rseq:cpu_id_start everytime
the rseq::rseq_cs field is cleared by the kernel under the not yet
validated theoretical assumption that this cures the problem for
tcmalloc.
If that's sufficient that would be harmless performance wise
because the write would be inside the already existing STAC/CLAC
section and just add some more noise to the rseq critical section
operations.
That would allow existing tcmalloc usage to continue, but
obviously would neither solve #5 and #6 above nor provide an
incentive for tcmalloc to actually fix their crap.
B) If that's not sufficient then keeping tcmalloc alive would require
to go back to the previous state and let everyone else pay the
price in terms of performance overhead.
C) Declare that this is not a regression because the ABI guarantee is
not violated and the RO property has been enforcable by RSEQ
debugging since day one.
In my opinion #C is the right thing to do, but I can see a case being
made for the lightweight fix Mathias suggested (#A) _if_ and only _if_
that is sufficient. Picking #A would also mean that user space people
have to take up the fight against tcmalloc when they want to use the
RSEQ guaranteed ABI along with tcmalloc in the same application or use a
RSEQ debug kernel to validate their own code.
Going back to the full unconditional nightmare (#B) is not an option at
all as anybody else has to take the massive performance hit.
Oh well...
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v3 0/3] Add i.MX94 remoteproc support and reset vector handling improvements
From: Mathieu Poirier @ 2026-04-23 17:17 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260415-imx943-rproc-v3-0-9fa7528db8ca@nxp.com>
On Wed, Apr 15, 2026 at 03:50:37PM +0800, Peng Fan (OSS) wrote:
> This series adds remoteproc support for the i.MX94 family, including the
> CM70, CM71, and CM33S cores, and derive the hardware reset vector for
> Cortex‑M processors whose ELF entry point does not directly correspond to
> the actual reset address.
>
> Background:
> Cortex‑M processors fetch their initial SP and PC from a fixed reset vector
> table. While ELF images embed the entry point (e_entry), this value is
> not always aligned to the hardware reset address. On platforms such as
> i.MX94 CM33S, masking is required to compute the correct reset vector
> address before programming the SoC reset registers.
>
> Similarly, on i.MX95, the existing implementation always programs a reset
> vector of 0x0, which only works when executing entirely from TCM. When
> firmware is loaded into DDR, the driver must pass the correct reset vector
> to the SM CPU/LMM interfaces.
>
> Summary of patches:
> [1]dt-bindings: remoteproc: imx-rproc: Introduce fsl,reset-vector-mask
> Adds a new DT property allowing SoCs to specify a mask for deriving the
> hardware reset vector from the ELF entry point.
>
> [2]remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
> Ensures the correct reset vector is passed to SM APIs by introducing a
> helper (imx_rproc_sm_get_reset_vector()) that applies the reset‑vector
> mask.
>
> [3]remoteproc: imx_rproc: Add support for i.MX94 remoteproc
> Adds address translation tables and configuration data for CM70, CM71,
> and CM33S, enabling full remoteproc operation on i.MX94.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Changes in v3:
> - Patch 2:
> Drop R-b because of changes in V3
>
> Following suggestion from Mathieu that apply reset vector in
> scmi_imx_[cpu,lmm]_reset_vector_set(), not change the meaning of
> rproc->bootaddr, add helper imx_rproc_sm_get_reset_vector() to get reset
> vector and use the hlper in scmi_imx_[cpu,lmm]_reset_vector_set().
>
> Add reset-vector-mask for i.MX95 CM7 to avoid breaking i.MX95 CM7
> boot.
>
> - Link to v2: https://lore.kernel.org/r/20260327-imx943-rproc-v2-0-a547a3588730@nxp.com
>
> Changes in v2:
> - Drop fsl,reset-vector-mask by using fixed value in driver for per device
> - Add R-b for i.MX94 dt-binding
> - Update commit log to include dev addr and sys addr
> - Link to v1: https://lore.kernel.org/r/20260312-imx943-rproc-v1-0-3e66596592a8@nxp.com
>
> ---
> Peng Fan (3):
> dt-bindings: remoteproc: imx-rproc: Support i.MX94
> remoteproc: imx_rproc: Program non-zero SM CPU/LMM reset vector
> remoteproc: imx_rproc: Add support for i.MX94
>
> .../bindings/remoteproc/fsl,imx-rproc.yaml | 3 +
> drivers/remoteproc/imx_rproc.c | 98 +++++++++++++++++++++-
> drivers/remoteproc/imx_rproc.h | 2 +
> 3 files changed, 101 insertions(+), 2 deletions(-)
Much better - I'll pick this up when 7.1-rc1 comes out.
Thanks,
Mathieu
> ---
> base-commit: 724699d8d0523909da51fda8d1e10c1ff867b280
> change-id: 20260311-imx943-rproc-2050e00b65f7
>
> Best regards,
> --
> Peng Fan <peng.fan@nxp.com>
>
^ permalink raw reply
* Re: [PATCH v11 00/14] barrier: Add smp_cond_load_{relaxed,acquire}_timeout()
From: Andrew Morton @ 2026-04-23 17:16 UTC (permalink / raw)
To: Ankur Arora
Cc: linux-kernel, linux-arch, linux-arm-kernel, linux-pm, bpf, arnd,
catalin.marinas, will, peterz, mark.rutland, harisokn, cl, ast,
rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai, rdunlap,
david.laight.linux, joao.m.martins, boris.ostrovsky, konrad.wilk,
ashok.bhat
In-Reply-To: <20260408122538.3610871-1-ankur.a.arora@oracle.com>
On Wed, 8 Apr 2026 17:55:24 +0530 Ankur Arora <ankur.a.arora@oracle.com> wrote:
> The core kernel often uses smp_cond_load_{relaxed,acquire}() to spin
> on condition variables with architectural primitives used to avoid
> hammering the relevant cachelines.
>
> ...
>
> Accordingly add two interfaces (with their generic and arm64 specific
> implementations):
>
> smp_cond_load_relaxed_timeout(ptr, cond_expr, time_expr, timeout)
> smp_cond_load_acquire_timeout(ptr, cond_expr, time_expr, timeout)
>
> Also add tif_need_resched_relaxed_wait() which wraps the polling
> pattern and its scheduler specific details in poll_idle().
> In addition add atomic_cond_read_*_timeout(),
Thanks, I'll add this to mm.git's mm-new branch today.
This isn't am MM patchset, but mm-new isn't included in linux-next, and
linux-next isn't presently open for 7.1 material.
After -rc1 I'll move the series into mm.git's mm-nonmm-unstable branch,
where it will get linux-next exposure.
I see that further review/comment has been requested - hopefully this
will happen over the next couple of months, but please do continue to
chase this down if you feel the need.
> Haris Okanovic also saw improvement in real workloads due to the
> cpuidle changes: "observed 4-6% improvements in memcahed, cassandra,
> mysql, and postgresql under certain loads. Other applications likely
> benefit too." [12]
Those are significant improvements. Three years :(
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Mimi Zohar @ 2026-04-23 17:13 UTC (permalink / raw)
To: Jonathan McDowell
Cc: Yeoreum Yun, linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, paul, jmorris, serge, roberto.sassu,
dmitry.kasatkin, eric.snowberg, jarkko, jgg, sudeep.holla, maz,
oupton, joey.gouly, suzuki.poulose, yuzenghui, catalin.marinas,
will, noodles, sebastianene
In-Reply-To: <aepQwcY523aukAvw@earth.li>
On Thu, 2026-04-23 at 18:02 +0100, Jonathan McDowell wrote:
> > > > > >
> > > > > > I think what Mimi's proposing is:
> > > > > >
> > > > > > If we're in late_initcall, and the TPM isn't available, return
> > > > > > immediately with an error (the EPROBE_DEFER?), don't do any init.
> > > > > >
> > > > > > If we're in late_initcall_sync, either we're already initialised, so do
> > > > > > return and nothing, or run through the entire flow, even if the TPM
> > > > > > isn't unavailable.
> > > > > >
> > > > > > So ima_init() just needs to know a) if it's in the sync or non-sync mode
> > > > > > and b) for the sync mode, if we've already done the init at
> > > > > > non-sync.
> > > > >
> > > > > Thanks, Jonathan. That is exactly what I'm suggesting. Any other changes
> > > > > should not be included in this patch. Since Yeoreum is not hearing me, feel
> > > > > free to post a patch.
> > > >
> > > > I see. so what you need to is this only
> > > > If it looks good to you. I'll send it at v3.
> > >
> > > FWIW, I pulled the tpm_default_chip check out a level to account for the
> > > extra init you mentioned, and have the following (completely untested or
> > > compiled, but gives the approach):
> >
> > Thanks, Jonathan! It looks good. Similarly untested/compiled.
>
> FWIW, it does compile.
>
> > Emitting a message on failure to initialize IMA at late_initcall is good, but
> > the attestation service won't know. Could you somehow differentiate between the
> > late_initcall and late_initcall_sync boot_aggregate records?
>
> Are you thinking "boot_aggregate" and "boot_aggregate_late" or similar
> as the "filename" on the entries, just so it's clear when we did the
> init in the log, or something else?
Perfect!
Mimi
^ permalink raw reply
* [PATCH 1/4] ARM: OMAP2: use snprintf() in multiple check revision functions
From: Thorsten Blum @ 2026-04-23 17:10 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King
Cc: Thorsten Blum, linux-arm-kernel, linux-omap, linux-kernel
Replace unbounded sprintf() calls with the safer snprintf() in multiple
*_check_revision() functions.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/arm/mach-omap2/id.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index cf2bfb447ee2..44d7471666a8 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -192,8 +192,8 @@ void __init omap2xxx_check_revision(void)
j = i;
}
- sprintf(soc_name, "OMAP%04x", omap_rev() >> 16);
- sprintf(soc_rev, "ES%x", (omap_rev() >> 12) & 0xf);
+ snprintf(soc_name, sizeof(soc_name), "OMAP%04x", omap_rev() >> 16);
+ snprintf(soc_rev, sizeof(soc_rev), "ES%x", (omap_rev() >> 12) & 0xf);
pr_info("%s", soc_name);
if ((omap_rev() >> 8) & 0x0f)
@@ -519,7 +519,7 @@ void __init omap3xxx_check_revision(void)
pr_warn("Warning: unknown chip type: hawkeye %04x, assuming OMAP3630ES1.2\n",
hawkeye);
}
- sprintf(soc_rev, "ES%s", cpu_rev);
+ snprintf(soc_rev, sizeof(soc_rev), "ES%s", cpu_rev);
}
void __init omap4xxx_check_revision(void)
@@ -594,9 +594,9 @@ void __init omap4xxx_check_revision(void)
omap_revision = OMAP4430_REV_ES2_3;
}
- sprintf(soc_name, "OMAP%04x", omap_rev() >> 16);
- sprintf(soc_rev, "ES%d.%d", (omap_rev() >> 12) & 0xf,
- (omap_rev() >> 8) & 0xf);
+ snprintf(soc_name, sizeof(soc_name), "OMAP%04x", omap_rev() >> 16);
+ snprintf(soc_rev, sizeof(soc_rev), "ES%d.%d", (omap_rev() >> 12) & 0xf,
+ (omap_rev() >> 8) & 0xf);
pr_info("%s %s\n", soc_name, soc_rev);
}
@@ -637,8 +637,8 @@ void __init omap5xxx_check_revision(void)
omap_revision = OMAP5430_REV_ES2_0;
}
- sprintf(soc_name, "OMAP%04x", omap_rev() >> 16);
- sprintf(soc_rev, "ES%d.0", (omap_rev() >> 12) & 0xf);
+ snprintf(soc_name, sizeof(soc_name), "OMAP%04x", omap_rev() >> 16);
+ snprintf(soc_rev, sizeof(soc_rev), "ES%d.0", (omap_rev() >> 12) & 0xf);
pr_info("%s %s\n", soc_name, soc_rev);
}
@@ -712,9 +712,9 @@ void __init dra7xxx_check_revision(void)
omap_revision = DRA752_REV_ES2_0;
}
- sprintf(soc_name, "DRA%03x", omap_rev() >> 16);
- sprintf(soc_rev, "ES%d.%d", (omap_rev() >> 12) & 0xf,
- (omap_rev() >> 8) & 0xf);
+ snprintf(soc_name, sizeof(soc_name), "DRA%03x", omap_rev() >> 16);
+ snprintf(soc_rev, sizeof(soc_rev), "ES%d.%d", (omap_rev() >> 12) & 0xf,
+ (omap_rev() >> 8) & 0xf);
pr_info("%s %s\n", soc_name, soc_rev);
}
^ permalink raw reply related
* [PATCH 3/4] ARM: OMAP2: clean up string copying and formatting in omap3_cpuinfo
From: Thorsten Blum @ 2026-04-23 17:10 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King
Cc: Thorsten Blum, linux-arm-kernel, linux-omap, linux-kernel
In-Reply-To: <20260423171016.275157-5-thorsten.blum@linux.dev>
Replace scnprintf("%s") with the faster and more direct strscpy().
Remove unnecessary and inconsistent 'n' arithmetic when 'n = 0', and
when 'n' is no longer used at the end of the function.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/arm/mach-omap2/id.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 25ded74e4b01..126ffd87f572 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -255,7 +255,7 @@ static void __init omap3_cpuinfo(void)
strscpy(soc_name, cpu_name);
/* Print verbose information */
- n += scnprintf(buf, sizeof(buf) - n, "%s %s (", soc_name, soc_rev);
+ n += scnprintf(buf, sizeof(buf), "%s %s (", soc_name, soc_rev);
OMAP3_SHOW_FEATURE(l2cache);
OMAP3_SHOW_FEATURE(iva);
@@ -265,7 +265,7 @@ static void __init omap3_cpuinfo(void)
OMAP3_SHOW_FEATURE(192mhz_clk);
if (*(buf + n - 1) == ' ')
n--;
- n += scnprintf(buf + n, sizeof(buf) - n, ")\n");
+ scnprintf(buf + n, sizeof(buf) - n, ")\n");
pr_info("%s", buf);
}
^ 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