* Re: [PATCH] spi: sun6i: Set SPI mode in prepare_message
From: Mark Brown @ 2026-04-22 19:50 UTC (permalink / raw)
To: Kevin Mehall
Cc: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Mirko Vogt,
Ralf Schlatterbeck, linux-spi, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <d199f72a-093b-41bb-b33e-b6685563f704@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
On Wed, Apr 22, 2026 at 01:01:11PM -0600, Kevin Mehall wrote:
> SS_LEVEL (aka SUN6I_TFR_CTL_CS_LEVEL) resets to 0x1 (CS high = inactive)
> and is also written in sun6i_spi_set_cs(), which is called in spi_setup() via
> spi_set_cs(). Thus it should be initialized before we get here the first time.
> Once SUN6I_TFR_CTL_CS_MANUAL is set, it is never cleared elsewhere in the
> driver, so in any case, this can only affect the first transfer.
I do see that the driver uses a reset controller over suspend, are you
sure that setup() will be called again on resume?
> However, what's not clear to me is why SUN6I_TFR_CTL_CS_MANUAL was in
> sun6i_spi_transfer_one() in the first place. sun6i_spi_set_cs() is writing to
> the same register, and it seems to me that setting that bit there would be a
> more logical place to do it, though I don't think there is any functional change
> vs what I have here. Let me know if you'd like me to move it to
> sun6i_spi_set_cs() instead and how that should be submitted (same patch?
> separate patch before the rest of this in a series? standalone patch to be
> applied after this one?).
Smaller patches are generally better so splitting is good. It does seem
sensible to group the chip select operations together, so long as we
ensure that everything else is stable before the chip select gets
asserted we should be good.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-22 19:47 UTC (permalink / raw)
To: Mark Rutland
Cc: Mathias Stearn, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Jinjie Ruan, Blake Oler
In-Reply-To: <aekPXvvuKHKlETjm@J2N7QTR9R3.cambridge.arm.com>
On Wed, Apr 22 2026 at 19:11, Mark Rutland wrote:
> On Wed, Apr 22, 2026 at 07:49:30PM +0200, Thomas Gleixner wrote:
> Conceptually we just need to use syscall_enter_from_user_mode() and
> irqentry_enter_from_user_mode() appropriately.
Right. I figured that out.
> In practice, I can't use those as-is without introducing the exception
> masking problems I just fixed up for irqentry_enter_from_kernel_mode(),
> so I'll need to do some similar refactoring first.
See below.
> I haven't paged everything in yet, so just to cehck, is there anything
> that would behave incorrectly if current->rseq.event.user_irq were set
> for syscall entry? IIUC it means we'll effectively do the slow path, and
> I was wondering if that might be acceptable as a one-line bodge for
> stable.
It might work, but it's trivial enough to avoid that. See below. That on
top of 6.19.y makes the selftests pass too.
Thanks,
tglx
---
arch/arm64/kernel/entry-common.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -58,6 +58,12 @@ static void noinstr exit_to_kernel_mode(
irqentry_exit(regs, state);
}
+static __always_inline void arm64_enter_from_user_mode_syscall(struct pt_regs *regs)
+{
+ enter_from_user_mode(regs);
+ mte_disable_tco_entry(current);
+}
+
/*
* Handle IRQ/context state management when entering from user mode.
* Before this function is called it is not safe to call regular kernel code,
@@ -65,8 +71,8 @@ static void noinstr exit_to_kernel_mode(
*/
static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs)
{
- enter_from_user_mode(regs);
- mte_disable_tco_entry(current);
+ arm64_enter_from_user_mode_syscall(regs);
+ rseq_note_user_irq_entry();
}
/*
@@ -717,7 +723,7 @@ static void noinstr el0_brk64(struct pt_
static void noinstr el0_svc(struct pt_regs *regs)
{
- arm64_enter_from_user_mode(regs);
+ arm64_enter_from_user_mode_syscall(regs);
cortex_a76_erratum_1463225_svc_handler();
fpsimd_syscall_enter();
local_daif_restore(DAIF_PROCCTX);
@@ -869,7 +875,7 @@ static void noinstr el0_cp15(struct pt_r
static void noinstr el0_svc_compat(struct pt_regs *regs)
{
- arm64_enter_from_user_mode(regs);
+ arm64_enter_from_user_mode_syscall(regs);
cortex_a76_erratum_1463225_svc_handler();
local_daif_restore(DAIF_PROCCTX);
do_el0_svc_compat(regs);
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-22 19:41 UTC (permalink / raw)
To: Mimi Zohar
Cc: 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: <aekXaU52fzvNYaUF@e129823.arm.com>
> Hi Mimi,
>
> > On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > > the TPM driver must be built as built-in and
> > > must be probed before the IMA subsystem is initialized.
> > >
> > > However, when the TPM device operates over the FF-A protocol using
> > > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > > the tpm_crb_ffa device — an FF-A device that provides the communication
> > > interface to the tpm_crb driver — has not yet been probed.
> > >
> > > To ensure the TPM device operating over the FF-A protocol with
> > > the CRB interface is probed before IMA initialization,
> > > the following conditions must be met:
> > >
> > > 1. The corresponding ffa_device must be registered,
> > > which is done via ffa_init().
> > >
> > > 2. The tpm_crb_driver must successfully probe this device via
> > > tpm_crb_ffa_init().
> > >
> > > 3. The tpm_crb driver using CRB over FF-A can then
> > > be probed successfully. (See crb_acpi_add() and
> > > tpm_crb_ffa_init() for reference.)
> > >
> > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > >
> > > When this occurs, probing the TPM device is deferred.
> > > However, the deferred probe can happen after the IMA subsystem
> > > has already been initialized, since IMA initialization is performed
> > > during late_initcall, and deferred_probe_initcall() is performed
> > > at the same level.
> > >
> > > To resolve this, call ima_init() again at late_inicall_sync level
> > > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > > log though TPM device presents in the system.
> > >
> > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> >
> > A lot of change for just detecting whether ima_init() is being called on
> > late_initcall or late_initcall_sync(), without any explanation for all the other
> > changes (e.g. ima_init_core).
> >
> > Please just limit the change to just calling ima_init() twice.
>
> My concern is that ima_update_policy_flags() will be called
> when ima_init() is deferred -- not initialised anything.
> though functionally, it might be okay however,
> I think ima_update_policy_flags() and notifier should work after ima_init()
> works logically.
>
> This change I think not much quite a lot. just wrapper ima_init() with
> ima_init_core() with some error handling.
>
> Am I missing something?
Also, if we handle in ima_init() only, but it failed with other reason,
we shouldn't call again ima_init() in the late_initcall_sync.
To handle this, It wouldn't do in the ima_init() but we need to handle
it by caller of ima_init().
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Sudeep Holla @ 2026-04-22 19:29 UTC (permalink / raw)
To: Sebastian Ene
Cc: Marc Zyngier, oupton, will, Sudeep Holla, ayrton, catalin.marinas,
joey.gouly, korneld, kvmarm, linux-arm-kernel, linux-kernel,
android-kvm, mrigendra.chaubey, perlarsen, suzuki.poulose,
yuzenghui, stable
In-Reply-To: <aejOu98q1lEZoFfW@google.com>
On Wed, Apr 22, 2026 at 01:35:55PM +0000, Sebastian Ene wrote:
> On Wed, Apr 22, 2026 at 01:24:02PM +0100, Marc Zyngier wrote:
> > On Wed, 22 Apr 2026 11:25:40 +0100,
> > Sebastian Ene <sebastianene@google.com> wrote:
> > >
> > > Prevent the pKVM hypervisor from making assumptions that the
> > > endpoint memory access descriptor (EMAD) comes right after the
> > > FF-A memory region header and enforce a strict placement for it
> > > when validating an FF-A memory lend/share transaction.
>
> Hello Marc,
>
> >
> > As I read this, you want to remove a bad assumption...
> >
> > >
> > > Prior to FF-A version 1.1 the header of the memory region
> > > didn't contain an offset to the endpoint memory access descriptor.
> > > The layout of a memory transaction looks like this:
> > >
> > > Field name | Offset
> > > -- 0
> > > [ Header (ffa_mem_region) |__ ep_mem_offset
> > > EMAD 1 (ffa_mem_region_attributes) |
> > > ]
> > >
> > > Reject the host from specifying a memory access descriptor offset
> > > that is different than the size of the memory region header.
> >
> > And yet you decide that you want to enforce this assumption. I don't
> > understand how you arrive to this conclusion.
> >
> > Looking at the spec, it appears that the offset is *designed* to allow
> > a gap between the header and the EMAD. Refusing to handle a it seems to be a
> > violation of the spec.
> >
> > What am I missing?
>
> While the spec allows the gap to be variable (since version 1.1), the
> arm ff-a driver places it at a fixed position in:
> ffa_mem_region_additional_setup()
> https://elixir.bootlin.com/linux/v7.0/source/drivers/firmware/arm_ffa/driver.c#L671
>
That's just the current choice in the driver and can be changed in the future.
> and makes use of the same assumption in: ffa_mem_desc_offset().
> https://elixir.bootlin.com/linux/v7.0/source/include/linux/arm_ffa.h#L448
Again this is just in the transmit path of the message the driver is
constructing and hence it is a simple choice rather than wrong assumption.
> The later one seems wrong IMO. because we should compute the offset
> based on the value stored in ep_mem_offset and not adding it up with
> sizeof(struct ffa_mem_region).
>
Sorry what am I missing as the driver is building these descriptors to
send it across to SPMC, we are populating the field and it will be 0
before it is initialised
> Maybe this should be the fix instead and not the one in pKVM ? What do
> you think ?
>
Can you share the diff you have in mind to understand your concern better
or are you referring to this patch itself.
> The current implementation in pKVM makes use of the
> ffa_mem_desc_offset() to validate the first EMAD. If a compromised host
> places an EMAD at a different offset than sizeof(struct ffa_mem_region),
> then pKVM will not validate that EMAD.
>
Calling the host as compromised if it chooses a different offset seems bit
of extreme here. I am no sure if I am missing to understand something here.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Validate the FF-A memory access descriptor placement
From: Sudeep Holla @ 2026-04-22 19:17 UTC (permalink / raw)
To: Marc Zyngier
Cc: Sebastian Ene, oupton, Sudeep Holla, will, ayrton,
catalin.marinas, joey.gouly, korneld, kvmarm, linux-arm-kernel,
linux-kernel, android-kvm, mrigendra.chaubey, perlarsen,
suzuki.poulose, yuzenghui, stable
In-Reply-To: <86bjfb18v1.wl-maz@kernel.org>
On Wed, Apr 22, 2026 at 01:24:02PM +0100, Marc Zyngier wrote:
> On Wed, 22 Apr 2026 11:25:40 +0100,
> Sebastian Ene <sebastianene@google.com> wrote:
> >
> > Prevent the pKVM hypervisor from making assumptions that the
> > endpoint memory access descriptor (EMAD) comes right after the
> > FF-A memory region header and enforce a strict placement for it
> > when validating an FF-A memory lend/share transaction.
>
> As I read this, you want to remove a bad assumption...
>
Indeed, it matches my understanding as well. I got confused with the
code change initially only to realise you want to restrict the choice
of offset.
> >
> > Prior to FF-A version 1.1 the header of the memory region
> > didn't contain an offset to the endpoint memory access descriptor.
> > The layout of a memory transaction looks like this:
> >
> > Field name | Offset
> > -- 0
> > [ Header (ffa_mem_region) |__ ep_mem_offset
> > EMAD 1 (ffa_mem_region_attributes) |
> > ]
> >
> > Reject the host from specifying a memory access descriptor offset
> > that is different than the size of the memory region header.
>
> And yet you decide that you want to enforce this assumption. I don't
> understand how you arrive to this conclusion.
>
> Looking at the spec, it appears that the offset is *designed* to allow
> a gap between the header and the EMAD. Refusing to handle a it seems to be a
> violation of the spec.
>
+1
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH] spi: sun6i: Set SPI mode in prepare_message
From: Kevin Mehall @ 2026-04-22 19:01 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: <66909301-ed23-4b36-8955-a69b64eed9a1@sirena.org.uk>
On Wed, Apr 22, 2026, at 8:57 AM, Mark Brown wrote:
> Might this cause the native chip select to get asserted, we didn't set
> up values so it'll have defaults if it wasn't previously configured?
Per the H616 datasheet, the SUN6I_TFR_CTL_CS_MANUAL bit (which it calls
SS_OWNER) is documented as:
> Usually, controller sends SS signal automatically with data together. When
this bit is set to 1, software must manually write SPI_CTL_REG.SS_LEVEL to 1 or
0 to control the level of SS signal.
SS_LEVEL (aka SUN6I_TFR_CTL_CS_LEVEL) resets to 0x1 (CS high = inactive)
and is also written in sun6i_spi_set_cs(), which is called in spi_setup() via
spi_set_cs(). Thus it should be initialized before we get here the first time.
Once SUN6I_TFR_CTL_CS_MANUAL is set, it is never cleared elsewhere in the
driver, so in any case, this can only affect the first transfer.
I believe this is actually a bugfix in that case: having SUN6I_TFR_CTL_CS_MANUAL
set earlier means that the write to SUN6I_TFR_CTL_CS_LEVEL in sun6i_spi_set_cs()
takes effect immediately, whereas previously that CS falling edge would have
been deferred until sun6i_spi_transfer_one() set SUN6I_TFR_CTL_CS_MANUAL. As any
configured cs_setup delay happens between those two steps, the configured delay
would have effectively been ignored on the very first transfer, and this change
makes the first transfer work like subsequent ones.
However, what's not clear to me is why SUN6I_TFR_CTL_CS_MANUAL was in
sun6i_spi_transfer_one() in the first place. sun6i_spi_set_cs() is writing to
the same register, and it seems to me that setting that bit there would be a
more logical place to do it, though I don't think there is any functional change
vs what I have here. Let me know if you'd like me to move it to
sun6i_spi_set_cs() instead and how that should be submitted (same patch?
separate patch before the rest of this in a series? standalone patch to be
applied after this one?).
^ permalink raw reply
* Re: [PATCH RFC 2/2] clk: scmi: Add support for two #clock-cells to pass rate rounding mode
From: Sudeep Holla @ 2026-04-22 18:51 UTC (permalink / raw)
To: Peng Fan
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Sudeep Holla,
Krzysztof Kozlowski, Conor Dooley, Cristian Marussi, linux-kernel,
linux-clk, devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <aejUd6L1AfbsflxR@shlinux89>
On Wed, Apr 22, 2026 at 10:00:23PM +0800, Peng Fan wrote:
> Hi Sudeep,
>
> Thanks for giving a look.
>
> On Wed, Apr 22, 2026 at 02:14:56PM +0100, Sudeep Holla wrote:
> >On Fri, Mar 06, 2026 at 02:20:13PM +0800, Peng Fan (OSS) wrote:
> >> From: Peng Fan <peng.fan@nxp.com>
> >>
> >> SCMI CLOCK_RATE_SET allows the caller to specify the rounding behaviour
> >> when setting a clock rate. The previously added dt-bindings header
> >> defines three modes:
> >>
> >> ROUND_DOWN / ROUND_UP / ROUND_AUTO
> >>
> >> To enable device tree clients to select a rounding mode, extend the
> >> SCMI clock provider to support "#clock-cells = <2>", where the second
> >> cell encodes the desired rounding mode. The default remains
> >> ROUND_DOWN for backwards compatibility with existing device trees.
> >>
> >
> >Where is the binding update documented ? It's not in 1/2.
>
> This was missed in this patchset, I will fix in new version, if this
> patchset does not have big design flaw.
>
> >
> >Also if it can be static in the device tree, why can't it be
> >autonomously handled in the platform firmware ? I think I know the
>
> Linux passes ROUND_DOWN, SCMI firmware uses round down for clk calculation.
>
> >answer for this but I want to make sure it is a valid use-case and
> >gets documented here as part of binding updates.
>
> Per info from our video software team.
> We have some video modes where the best pixel clock rate is slightly above the
> nominal rate, and the default round down rule (CLOCK_ROUND_RULE_CEILING in SM
> firmware) can cause the resulting clock rate to be much lower than expected.
>
> disp1pix = 96200000 Hz (desired pixel clock rate)
>
> The MIPI DPHY cannot hit the exact frequency of 288600000 Hz needed for this
> pixel clock rate, so the next best DPHY PLL frequency is 289000000 Hz. This
> corresponds to a pixel clock frequency of 96333333 Hz, which is slightly higher
> than the nominal rate of 96200000 Hz the video mode specifies.
>
> Setting the VIDEOPLL (disp1pix parent) to 289000000 Hz should divide down to
> the adjusted disp1pix frequency of 96333333 Hz, but here is what happens in the
> SM firmware:
>
> quotient = 289000000 / (96200000 + 1) = 3.004 => 3 (notice that the SM always
> receives the nominal clock rate, not the adjusted rate)
>
> If the rounding rule is round down (CLOCK_ROUND_RULE_CEILING),
> quotient = quotient + 1. Therefore, quotient becomes 4.
>
> disp1pix = 289000000 / 4 = 72250000, which is nowhere close to the target of
> 96333333.
>
I do not think this is the correct interpretation of `CLOCK_ROUND_DOWN/UP`.
`CLOCK_ROUND_DOWN/UP` should apply to the requested `disp1pix` rate itself,
not to the divider choice in a way that forces selection of the next integer
divisor and produces a much lower output clock.
Here, the requested `disp1pix` is `96,200,000 Hz`, and the parent rate is
`289,000,000 Hz`. The achievable child rates nearby are:
`289,000,000 / 3 = 96,333,333 Hz`
`289,000,000 / 4 = 72,250,000 Hz`
Given those options, the firmware should be able to round the request
autonomously to the nearest supported `disp1pix` rate, which is `96,333,333
Hz` (`289,000,000 / 3`).
Under that interpretation:
`CLOCK_ROUND_UP` would permit choosing `96,333,333`
`CLOCK_ROUND_AUTO` would also likely choose `96,333,333`
Choosing `/4` and ending up at `72,250,000` does not look like a meaningful
rounding of `96,200,000`
So the issue appears to be that the firmware is applying the rounding rule to
divider selection rather than to the resulting `disp1pix` frequency.
> However, if we can use `ROUND_AUTO` the SM firmware would select a quotient of 3
> in this case, and `disp1pix` would match our target: `289000000 / 3 = 96333333`.
Given the explanation above, I would not support this approach. `ROUND_AUTO`
should be sufficient for this case if the firmware is making a sensible
selection.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] security: ima: call ima_init() again at late_initcall_sync for defered TPM
From: Yeoreum Yun @ 2026-04-22 18:46 UTC (permalink / raw)
To: Mimi Zohar
Cc: 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: <6919248bdc85dac60277fa9d9c83d8bd258ca635.camel@linux.ibm.com>
Hi Mimi,
> On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> > To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> > the TPM driver must be built as built-in and
> > must be probed before the IMA subsystem is initialized.
> >
> > However, when the TPM device operates over the FF-A protocol using
> > the CRB interface, probing fails and returns -EPROBE_DEFER if
> > the tpm_crb_ffa device — an FF-A device that provides the communication
> > interface to the tpm_crb driver — has not yet been probed.
> >
> > To ensure the TPM device operating over the FF-A protocol with
> > the CRB interface is probed before IMA initialization,
> > the following conditions must be met:
> >
> > 1. The corresponding ffa_device must be registered,
> > which is done via ffa_init().
> >
> > 2. The tpm_crb_driver must successfully probe this device via
> > tpm_crb_ffa_init().
> >
> > 3. The tpm_crb driver using CRB over FF-A can then
> > be probed successfully. (See crb_acpi_add() and
> > tpm_crb_ffa_init() for reference.)
> >
> > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > all registered with device_initcall, which means crb_acpi_driver_init() may
> > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> >
> > When this occurs, probing the TPM device is deferred.
> > However, the deferred probe can happen after the IMA subsystem
> > has already been initialized, since IMA initialization is performed
> > during late_initcall, and deferred_probe_initcall() is performed
> > at the same level.
> >
> > To resolve this, call ima_init() again at late_inicall_sync level
> > so that let IMA not miss TPM PCR value when generating boot_aggregate
> > log though TPM device presents in the system.
> >
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
>
> A lot of change for just detecting whether ima_init() is being called on
> late_initcall or late_initcall_sync(), without any explanation for all the other
> changes (e.g. ima_init_core).
>
> Please just limit the change to just calling ima_init() twice.
My concern is that ima_update_policy_flags() will be called
when ima_init() is deferred -- not initialised anything.
though functionally, it might be okay however,
I think ima_update_policy_flags() and notifier should work after ima_init()
works logically.
This change I think not much quite a lot. just wrapper ima_init() with
ima_init_core() with some error handling.
Am I missing something?
>
>
> > ---
> > include/linux/lsm_hooks.h | 2 +
> > security/integrity/ima/ima.h | 4 +-
> > security/integrity/ima/ima_init.c | 10 +++-
> > security/integrity/ima/ima_main.c | 76 +++++++++++++++++++++++------
> > security/integrity/ima/ima_policy.c | 3 ++
> > security/lsm_init.c | 13 ++++-
> > 6 files changed, 87 insertions(+), 21 deletions(-)
> >
> > diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> > index d48bf0ad26f4..88fe105b7f00 100644
> > --- a/include/linux/lsm_hooks.h
> > +++ b/include/linux/lsm_hooks.h
> > @@ -166,6 +166,7 @@ enum lsm_order {
> > * @initcall_fs: LSM callback for fs_initcall setup, optional
> > * @initcall_device: LSM callback for device_initcall() setup, optional
> > * @initcall_late: LSM callback for late_initcall() setup, optional
> > + * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
> > */
> > struct lsm_info {
> > const struct lsm_id *id;
> > @@ -181,6 +182,7 @@ struct lsm_info {
> > int (*initcall_fs)(void);
> > int (*initcall_device)(void);
> > int (*initcall_late)(void);
> > + int (*initcall_late_sync)(void);
> > };
> >
> > #define DEFINE_LSM(lsm) \
> > diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> > index 89ebe98ffc5e..75ee7ad184d0 100644
> > --- a/security/integrity/ima/ima.h
> > +++ b/security/integrity/ima/ima.h
> > @@ -62,6 +62,8 @@ extern int ima_hash_algo_idx __ro_after_init;
> > extern int ima_extra_slots __ro_after_init;
> > extern struct ima_algo_desc *ima_algo_array __ro_after_init;
> >
> > +extern bool ima_initialised __ro_after_init;
> > +
> > extern int ima_appraise;
> > extern struct tpm_chip *ima_tpm_chip;
> > extern const char boot_aggregate_name[];
> > @@ -257,7 +259,7 @@ static inline void ima_measure_kexec_event(const char *event_name) {}
> > extern bool ima_canonical_fmt;
> >
> > /* Internal IMA function definitions */
> > -int ima_init(void);
> > +int ima_init(bool late);
> > int ima_fs_init(void);
> > int ima_add_template_entry(struct ima_template_entry *entry, int violation,
> > const char *op, struct inode *inode,
> > diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> > index a2f34f2d8ad7..c28c71090ad2 100644
> > --- a/security/integrity/ima/ima_init.c
> > +++ b/security/integrity/ima/ima_init.c
> > @@ -115,13 +115,19 @@ void __init ima_load_x509(void)
> > }
> > #endif
> >
> > -int __init ima_init(void)
> > +int __init ima_init(bool late)
> > {
> > int rc;
> >
> > ima_tpm_chip = tpm_default_chip();
> > - if (!ima_tpm_chip)
> > + if (!ima_tpm_chip) {
> > + if (!late) {
> > + pr_info("Defer initialisation to the late_initcall_sync stage.\n");
> > + return -EPROBE_DEFER;
> > + }
> > +
> > pr_info("No TPM chip found, activating TPM-bypass!\n");
> > + }
> >
> > rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
> > if (rc)
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index 1d6229b156fb..ac444ee600e2 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -38,6 +38,7 @@ int ima_appraise;
> > #endif
> >
> > int __ro_after_init ima_hash_algo = HASH_ALGO_SHA1;
> > +bool ima_initialised __ro_after_init = false;
> > static int hash_setup_done;
> > static int ima_disabled __ro_after_init;
> >
> > @@ -1237,6 +1238,35 @@ static int ima_kernel_module_request(char *kmod_name)
> >
> > #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
> >
> > +static int __init init_ima_core(bool late)
> > +{
> > + int err;
> > +
> > + if (ima_initialised)
> > + return 0;
> > +
> > + err = ima_init(late);
> > + if (err == -EPROBE_DEFER)
> > + return 0;
> > +
> > + if (err && strcmp(hash_algo_name[ima_hash_algo],
> > + CONFIG_IMA_DEFAULT_HASH) != 0) {
> > + pr_info("Allocating %s failed, going to use default hash algorithm %s\n",
> > + hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
> > + hash_setup_done = 0;
> > + hash_setup(CONFIG_IMA_DEFAULT_HASH);
> > + err = ima_init(late);
> > + }
> > +
> > + if (!err) {
> > + ima_update_policy_flags();
> > + ima_initialised = true;
> > + } else
> > + ima_disabled = 1;
> > +
> > + return err;
> > +}
> > +
> > static int __init init_ima(void)
> > {
> > int error;
> > @@ -1250,30 +1280,42 @@ static int __init init_ima(void)
> > ima_appraise_parse_cmdline();
> > ima_init_template_list();
> > hash_setup(CONFIG_IMA_DEFAULT_HASH);
> > - error = ima_init();
> > -
> > - if (error && strcmp(hash_algo_name[ima_hash_algo],
> > - CONFIG_IMA_DEFAULT_HASH) != 0) {
> > - pr_info("Allocating %s failed, going to use default hash algorithm %s\n",
> > - hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
> > - hash_setup_done = 0;
> > - hash_setup(CONFIG_IMA_DEFAULT_HASH);
> > - error = ima_init();
> > - }
> > -
> > - if (error)
> > - return error;
> >
> > error = register_blocking_lsm_notifier(&ima_lsm_policy_notifier);
> > - if (error)
> > + if (error) {
> > pr_warn("Couldn't register LSM notifier, error %d\n", error);
> > + goto disable_ima;
> > + }
> >
> > - if (!error)
> > - ima_update_policy_flags();
> > + error = init_ima_core(false);
> > + if (error) {
> > + unregister_blocking_lsm_notifier(&ima_lsm_policy_notifier);
> > + goto disable_ima;
> > + }
> > +
> > + return 0;
> >
> > +disable_ima:
> > + ima_disabled = 1;
> > return error;
> > }
> >
> > +static int __init late_init_ima(void)
> > +{
> > + int err;
> > +
> > + if (ima_disabled)
> > + return 0;
> > +
> > + err = init_ima_core(true);
> > + if (err) {
> > + unregister_blocking_lsm_notifier(&ima_lsm_policy_notifier);
> > + ima_disabled = 1;
> > + }
> > +
> > + return err;
> > +}
> > +
> > static struct security_hook_list ima_hooks[] __ro_after_init = {
> > LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
> > LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),
> > @@ -1321,4 +1363,6 @@ DEFINE_LSM(ima) = {
> > .blobs = &ima_blob_sizes,
> > /* Start IMA after the TPM is available */
> > .initcall_late = init_ima,
> > + /* Start IMA late in case of probing TPM is deferred. */
> > + .initcall_late_sync = late_init_ima,
> > };
> > diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> > index bf2d7ba4c14a..c3bcc3521c81 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > @@ -501,6 +501,9 @@ static void ima_lsm_update_rules(void)
> > int ima_lsm_policy_change(struct notifier_block *nb, unsigned long event,
> > void *lsm_data)
> > {
> > + if (!ima_initialised)
> > + return NOTIFY_DONE;
> > +
> > if (event != LSM_POLICY_CHANGE)
> > return NOTIFY_DONE;
> >
> > diff --git a/security/lsm_init.c b/security/lsm_init.c
> > index 573e2a7250c4..4e5c59beb82a 100644
> > --- a/security/lsm_init.c
> > +++ b/security/lsm_init.c
> > @@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
> > * security_initcall_late - Run the LSM late initcalls
> > */
> > static int __init security_initcall_late(void)
> > +{
> > + return lsm_initcall(late);
> > +}
> > +late_initcall(security_initcall_late);
> > +
> > +/**
> > + * security_initcall_late_sync - Run the LSM late initcalls sync
> > + */
> > +static int __init security_initcall_late_sync(void)
> > {
> > int rc;
> >
> > - rc = lsm_initcall(late);
> > + rc = lsm_initcall(late_sync);
> > lsm_pr_dbg("all enabled LSMs fully activated\n");
> > call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
> >
> > return rc;
> > }
> > -late_initcall(security_initcall_late);
> > +late_initcall_sync(security_initcall_late_sync);
> > --
> > LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Cristian Marussi @ 2026-04-22 18:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto, arm-scmi, linux-arm-kernel, linux-renesas-soc,
linux-clk, devicetree, linux-pm, linux-kernel
In-Reply-To: <72e2a0e7a5abda02fe36b3f5851842f7a77b2593.1776793163.git.geert+renesas@glider.be>
On Tue, Apr 21, 2026 at 08:11:38PM +0200, Geert Uytterhoeven wrote:
> Currently non-SCMI drivers cannot find out what the specific versions of
> each SCMI provider implementation on the running system are.
Hi Geert,
Thanks for your patches....this is not a proper full review of the series,
BUT this patch catched my eye..
Indeed, yes, it is deliberate that the SCMI version information is NOT
exposed out of the SCMI world, since being the SCMI an attempt to
standardize a common FW interface (as in [1] of course), you should not
know what runs inside the black-box, it should be irrelevant...
...indeed the versioning is used inside the SCMI stack to deal properly
with different protocol versions implemented by the server OR to apply
proper quirks when needed, but all the rest should be standard....
...you should NOT really behave differently based on the underneath
protocol or firmare implementation version...it is the SCMI stack that
should behave properly, transparently...
Having said that...I understand that at least it could be useful to be able
to query the SCMI stack to know, even from non-SCMI drivers, WHICH quirks
have been applied/activated at run time...but anything more than that it
seems to me dangerous and prone to a number of abuses of the SCMI stack
itself...
(Also...exposing the versions itself means also tracking that bit of info
in more than one place: the quirk framework and your drivers.)
>
> However, different versions may use different ABIs (e.g. different clock
> IDs), or behave different, requiring remapping or workarounds in other
> drivers.
...abuse like this indeed :P ... the SCMI server is supposed to be that
one entity remapping the IDs in the background if the same IDs happen to
be representing different physical resources across a number of distinct
platforms all supported by the same firmware blob...so as to present
a consistent set of contiguos IDs...
Also because this should be one of the selling point of the SCMI stack
in a virtualized environment: you can ship the same kernel drivers with
the same DT and you know that ID=<N> will always identify the specific
resource that is needed by your driver without worrying about the fact
that in reality in the backstage the effectively managed physical resource
could be different across different platforms, because that does not matter
if the SCMI platform server had properly remapped (at build time/run-time ?)
the resources to your expected ID...alternatively of course you can ship
with different DTs to describe different hardware...BUT remmapping stuff
in the drivers themselves guessing on the vendor/subvendor/impl_vers
seems a dangerous abuse...
I watched a bit of the LPC discussions around this (from Marek I think)
but sincerely most of those problems had one (not necessarily simple)
solution: fix your firmwares AND/OR apply quirks in the meantime...
Sorry, I am sure this not a welcomed answer :P ...thoughts ?
Thanks,
Cristian
[1]: https://xkcd.com/927/
^ permalink raw reply
* Re: [PATCH net v2] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Simon Horman @ 2026-04-22 18:23 UTC (permalink / raw)
To: Daniel Golle
Cc: Chester A. Unal, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, Russell King, Christian Marangi,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek,
Frank Wunderlich, John Crispin
In-Reply-To: <58aff8b5b1d691872342a6ffd3315f27854788a6.1776595131.git.daniel@makrotopia.org>
On Sun, Apr 19, 2026 at 11:43:05AM +0100, Daniel Golle wrote:
> The .get_stats64 callback runs in atomic context, but on
> MDIO-connected switches every register read acquires the MDIO bus
> mutex, which can sleep:
> [ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
> [ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
> [ 12.663377] preempt_count: 0, expected: 0
> [ 12.667410] RCU nest depth: 1, expected: 0
> [ 12.671511] INFO: lockdep is turned off.
> [ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
> [ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
> [ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
> [ 12.675459] Call trace:
> [ 12.675462] show_stack+0x14/0x1c (C)
> [ 12.675477] dump_stack_lvl+0x68/0x8c
> [ 12.675487] dump_stack+0x14/0x1c
> [ 12.675495] __might_resched+0x14c/0x220
> [ 12.675504] __might_sleep+0x44/0x80
> [ 12.675511] __mutex_lock+0x50/0xb10
> [ 12.675523] mutex_lock_nested+0x20/0x30
> [ 12.675532] mt7530_get_stats64+0x40/0x2ac
> [ 12.675542] dsa_user_get_stats64+0x2c/0x40
> [ 12.675553] dev_get_stats+0x44/0x1e0
> [ 12.675564] dev_seq_printf_stats+0x24/0xe0
> [ 12.675575] dev_seq_show+0x14/0x3c
> [ 12.675583] seq_read_iter+0x37c/0x480
> [ 12.675595] seq_read+0xd0/0xec
> [ 12.675605] proc_reg_read+0x94/0xe4
> [ 12.675615] vfs_read+0x98/0x29c
> [ 12.675625] ksys_read+0x54/0xdc
> [ 12.675633] __arm64_sys_read+0x18/0x20
> [ 12.675642] invoke_syscall.constprop.0+0x54/0xec
> [ 12.675653] do_el0_svc+0x3c/0xb4
> [ 12.675662] el0_svc+0x38/0x200
> [ 12.675670] el0t_64_sync_handler+0x98/0xdc
> [ 12.675679] el0t_64_sync+0x158/0x15c
>
> For MDIO-connected switches, poll MIB counters asynchronously using a
> delayed workqueue every second and let .get_stats64 return the cached
> values under a spinlock. A mod_delayed_work() call on each read
> triggers an immediate refresh so counters stay responsive when queried
> more frequently.
>
> MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
> because their regmap does not sleep, so they continue to read MIB
> counters directly in .get_stats64.
>
> Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> ---
> v2:
> * use spin_lock_bh()/spin_unlock_bh() to prevent potential deadlock
> * rate-limit mod_delayed_work() refresh to at most once per 100ms
> * move cancel_delayed_work_sync() after dsa_unregister_switch()
> * add mt753x_teardown() callback to cancel the stats work
> * fix commit message
FWIIW, I looked over the feedback generated by Sashiko for this patch,
and I believe the issues it flags are false positives.
^ permalink raw reply
* Re: [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Josh Law @ 2026-04-22 18:20 UTC (permalink / raw)
To: ardb+git
Cc: ardb, arnd, ebiggers, hch, linux-arm-kernel, linux-crypto,
linux-raid, linux
In-Reply-To: <20260422171655.3437334-17-ardb+git@google.com>
Hi ard.
Makes sense here
-#include <arm_neon.h>
+#include <asm/neon-intrinsics.h>
Reviewed-by: Josh Law <joshlaw48@gmail.com>
This series is a good (and deserved series)
That's me done! I've reviewed your lib patches for you, have a great day!
^ permalink raw reply
* Re: [PATCH 6/8] crypto: aegis128 - Use neon-intrinsics.h on ARM too
From: Josh Law @ 2026-04-22 18:19 UTC (permalink / raw)
To: ardb+git
Cc: ardb, arnd, ebiggers, hch, linux-arm-kernel, linux-crypto,
linux-raid, linux
In-Reply-To: <20260422171655.3437334-16-ardb+git@google.com>
Hi ard, this is a good cleanup!
Being able to drop <arm_neon.h> and just using
<asm/neon-intrinsics.h> across both architectures makes the C code much
cleaner.
-# Enable <arm_neon.h>
-CFLAGS_aegis128-neon-inner.o += -isystem $(shell $(CC) -print-file-name=include)
Getting rid of the isystem is good. iirc that was a hack anyway, feel free
to correct me on that
Reviewed-by: Josh Law <joshlaw48@gmail.com>
^ permalink raw reply
* Re: [PATCH 5/8] lib/crc: arm: Enable arm64's NEON intrinsics implementation of crc64
From: Josh Law @ 2026-04-22 18:16 UTC (permalink / raw)
To: ardb+git
Cc: ardb, arnd, ebiggers, hch, linux-arm-kernel, linux-crypto,
linux-raid, linux
In-Reply-To: <20260422171655.3437334-15-ardb+git@google.com>
Hi Ard,
Wow, 20x improvement is nuts.
I like how you handle this change *safely*
Like.
+static inline u64 crc64_nvme_arch(u64 crc, const u8 *p, size_t len)
+{
+ if (len >= 128 && static_branch_likely(&have_pmull) &&
+ likely(may_use_simd())) {
+ do {
+ size_t chunk = min_t(size_t, len & ~15, SZ_4K);
+
+ scoped_ksimd()
+ crc = crc64_nvme_neon(crc, p, chunk);
+
+ p += chunk;
+ len -= chunk;
+ } while (len >= 128);
+ }
chunking the SIMD work at SZ_4K to avoid hogging the CPU and allowing
softirqs/preemption to process is a great detail.
It’s easy to just wing it and throw
the entire buffer at the FPU, but respecting the kernel's latency
requirements is better!
Reviewed-by: Josh Law <joshlaw48@gmail.com>
Thanks!
^ permalink raw reply
* Re: [PATCH 4/8] lib/crc: Turn NEON intrinsics crc64 implementation into common code
From: Josh Law @ 2026-04-22 18:13 UTC (permalink / raw)
To: ardb+git
Cc: ardb, arnd, ebiggers, hch, linux-arm-kernel, linux-crypto,
linux-raid, linux
In-Reply-To: <20260422171655.3437334-14-ardb+git@google.com>
Hi ard.
diff --git a/lib/crc/arm64/crc64-neon.h b/lib/crc/arm64/crc64-neon.h
new file mode 100644
index 000000000000..fcd5b1e6f812
--- /dev/null
+++ b/lib/crc/arm64/crc64-neon.h
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+static inline uint64x2_t pmull64(uint64x2_t a, uint64x2_t b)
+{
return vreinterpretq_u64_p128(vmull_p64(vgetq_lane_u64(a, 0),
vgetq_lane_u64(b, 0)));
+}
+static inline uint64x2_t pmull64_high(uint64x2_t a, uint64x2_t b)
+{
poly64x2_t l = vreinterpretq_p64_u64(a);
poly64x2_t m = vreinterpretq_p64_u64(b);
return vreinterpretq_u64_p128(vmull_high_p64(l, m));
+}
Makes sense.
Moving these polynomial multiplication wrappers into their own header is
good.
Reviewed-by: Josh Law <joshlaw48@gmail.com>
Thanks!
^ permalink raw reply related
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Mark Rutland @ 2026-04-22 18:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Mathias Stearn, Mathieu Desnoyers, Catalin Marinas, Will Deacon,
Boqun Feng, Paul E. McKenney, Chris Kennelly, Dmitry Vyukov,
regressions, linux-kernel, linux-arm-kernel, Peter Zijlstra,
Ingo Molnar, Jinjie Ruan, Blake Oler
In-Reply-To: <87zf2u28d1.ffs@tglx>
On Wed, Apr 22, 2026 at 07:49:30PM +0200, Thomas Gleixner wrote:
> On Wed, Apr 22 2026 at 14:09, Mark Rutland wrote:
> > On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
> >> TL;DR: As of 6.19, rseq no longer provides the documented atomicity
> >> guarantees on arm64 by failing to abort the critical section on same-core
> >> preemption/resumption. Additionally, it breaks tcmalloc specifically by
> >> failing to overwrite the cpu_id_start field at points where it was relied
> >> on for correctness.
> >
> > Thanks for the report, and the test case.
> >
> > As a holding reply, I'm looking into this now from the arm64 side.
>
> I assume it's the partial conversion to the generic entry code which
> screws that up.
It's slightly more than that, but in a sense, yes. ;)
The fix is conceptually simple, but I'll need to do some refactoring.
Conceptually we just need to use syscall_enter_from_user_mode() and
irqentry_enter_from_user_mode() appropriately.
In practice, I can't use those as-is without introducing the exception
masking problems I just fixed up for irqentry_enter_from_kernel_mode(),
so I'll need to do some similar refactoring first.
That and I *think* a couple of of the current checks for CONFIG_GENERIC_ENTRY
should be checking CONFIG_GENERIC_IRQ_ENTRY, since all of the relevant
bits are in the generic irqentry code rather than the GENERIC_SYSCALL
code (and GENERIC_ENTRY is just GENERIC_IRQ_ENTRY + GENERIC_SYSCALL).
> The problem reproduces with rseq selftests nicely.
Ah; that's both good to know, and worrying that we've never had a report
from all the automated testing people are supposedly running. :/
> The patch below fixes it as it puts ARM64 back to the non-optimized code
> for now. Once ARM64 is fully converted it gets all the nice improvements.
Thanks; I'll give that a test tomorrow.
I haven't paged everything in yet, so just to cehck, is there anything
that would behave incorrectly if current->rseq.event.user_irq were set
for syscall entry? IIUC it means we'll effectively do the slow path, and
I was wondering if that might be acceptable as a one-line bodge for
stable.
As above, I'd like if the actual fix could make this work for
GENERIC_IRQ_ENTRY rather than GENERIC_ENTRY, since that way we can make
this work as it was supposed to *before* moving to GENERIC_SYSCALL
(which has a whole lot more ABI impact to worry about).
I think that just needs a small amount of refactoring that arm64 will
need regardless.
Mark.
>
> Thanks,
>
> tglx
> ---
> diff --git a/include/linux/rseq.h b/include/linux/rseq.h
> index 2266f4dc77b6..d55476e2a336 100644
> --- a/include/linux/rseq.h
> +++ b/include/linux/rseq.h
> @@ -30,7 +30,7 @@ void __rseq_signal_deliver(int sig, struct pt_regs *regs);
> */
> static inline void rseq_signal_deliver(struct ksignal *ksig, struct pt_regs *regs)
> {
> - if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
> + if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
> /* '&' is intentional to spare one conditional branch */
> if (current->rseq.event.has_rseq & current->rseq.event.user_irq)
> __rseq_signal_deliver(ksig->sig, regs);
> @@ -50,7 +50,7 @@ static __always_inline void rseq_sched_switch_event(struct task_struct *t)
> {
> struct rseq_event *ev = &t->rseq.event;
>
> - if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
> + if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
> /*
> * Avoid a boat load of conditionals by using simple logic
> * to determine whether NOTIFY_RESUME needs to be raised.
> diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
> index a36b472627de..8ccd464a108d 100644
> --- a/include/linux/rseq_entry.h
> +++ b/include/linux/rseq_entry.h
> @@ -80,7 +80,7 @@ bool rseq_debug_validate_ids(struct task_struct *t);
>
> static __always_inline void rseq_note_user_irq_entry(void)
> {
> - if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY))
> + if (IS_ENABLED(CONFIG_GENERIC_ENTRY))
> current->rseq.event.user_irq = true;
> }
>
> @@ -171,8 +171,8 @@ bool rseq_debug_update_user_cs(struct task_struct *t, struct pt_regs *regs,
> if (unlikely(usig != t->rseq.sig))
> goto die;
>
> - /* rseq_event.user_irq is only valid if CONFIG_GENERIC_IRQ_ENTRY=y */
> - if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
> + /* rseq_event.user_irq is only valid if CONFIG_GENERIC_ENTRY=y */
> + if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
> /* If not in interrupt from user context, let it die */
> if (unlikely(!t->rseq.event.user_irq))
> goto die;
> @@ -387,7 +387,7 @@ static rseq_inline bool rseq_update_usr(struct task_struct *t, struct pt_regs *r
> * allows to skip the critical section when the entry was not from
> * a user space interrupt, unless debug mode is enabled.
> */
> - if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
> + if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
> if (!static_branch_unlikely(&rseq_debug_enabled)) {
> if (likely(!t->rseq.event.user_irq))
> return true;
^ permalink raw reply
* Re: [PATCH 3/8] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
From: Josh Law @ 2026-04-22 18:11 UTC (permalink / raw)
To: ardb+git
Cc: ardb, arnd, ebiggers, hch, linux-arm-kernel, linux-crypto,
linux-raid, linux
In-Reply-To: <20260422171655.3437334-13-ardb+git@google.com>
Hi ard.
>+#ifdef CONFIG_ARM64
>+extern typeof(__xor_neon_2) >__xor_eor3_2 >__alias(__xor_neon_2);
>+#endif
Creative. A reduction of about 150 lines of duplicate code while
maintaining
the __alias for the 2 input case is great.
Reviewed-by: Josh Law <joshlaw48@gmail.com>
Thanks!
^ permalink raw reply
* Re: [PATCH 2/8] xor/arm: Replace vectorized implementation with arm64's intrinsics
From: Josh Law @ 2026-04-22 18:07 UTC (permalink / raw)
To: ardb+git
Cc: ardb, arnd, ebiggers, hch, linux-arm-kernel, linux-crypto,
linux-raid, linux
In-Reply-To: <20260422171655.3437334-12-ardb+git@google.com>
Hi ard.
I like this patch.
So, I'd be crazy not to say what I love here.
+ /* p1 ^= p2 */
+ v0 = veorq_u64(vld1q_u64(dp1 + 0), vld1q_u64(dp2 + 0));
+ v1 = veorq_u64(vld1q_u64(dp1 + 2), vld1q_u64(dp2 + 2));
+ v2 = veorq_u64(vld1q_u64(dp1 + 4), vld1q_u64(dp2 + 4));
+ v3 = veorq_u64(vld1q_u64(dp1 + 6), vld1q_u64(dp2 + 6));
+
+ /* p1 ^= p3 */
+ v0 = veorq_u64(v0, vld1q_u64(dp3 + 0));
+ v1 = veorq_u64(v1, vld1q_u64(dp3 + 2));
+ v2 = veorq_u64(v2, vld1q_u64(dp3 + 4));
+ v3 = veorq_u64(v3, vld1q_u64(dp3 + 6));
+
+ /* store */
+ vst1q_u64(dp1 + 0, v0);
+ vst1q_u64(dp1 + 2, v1);
+ vst1q_u64(dp1 + 4, v2);
+ vst1q_u64(dp1 + 6, v3);
+
+ dp1 += 8;
+ dp2 += 8;
+ dp3 += 8;
+ } while (--lines > 0);
+}
I really like how clean this is, I'm personally nodding my head here
Taking the "bad" guesswork of the compiler here is also amazing, it also
guarantees we won't get stupid regressions in the future.
Also, that performance boost is even better ;)
I'm not the biggest expert of this subdirectory, but I understand it well.
So well,
Reviewed-by: Josh Law <joshlaw48@gmail.com>
Thanks! (I will review your lib patches) :)
^ permalink raw reply
* Re: [PATCH v2] kselftest/arm64: Fix build failure with GCC-15
From: Mark Brown @ 2026-04-22 17:50 UTC (permalink / raw)
To: Leo Yan
Cc: Catalin Marinas, Will Deacon, Shuah Khan, Thiago Jung Bauermann,
linux-arm-kernel, linux-kselftest, linux-kernel
In-Reply-To: <20260422-selftests_arm64_gcc15-v2-1-c0134de8838a@arm.com>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Wed, Apr 22, 2026 at 06:42:54PM +0100, Leo Yan wrote:
> For GCC-15, NT_ARM_GCS is defined in the libc header, causing gcs-util.h
> to skip its fallback definition of struct user_gcs. This leads to the
> compiler error.
> Fix this by including <asm/ptrace.h> to provide the proper definition.
> +++ b/tools/testing/selftests/arm64/gcs/gcs-util.h
> @@ -7,6 +7,7 @@
> #define GCS_UTIL_H
>
> #include <stdbool.h>
> +#include <asm/ptrace.h>
>
> #ifndef __NR_map_shadow_stack
> #define __NR_map_shadow_stack 453
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rseq: refactoring in v6.19 broke everyone on arm64 and tcmalloc everywhere
From: Thomas Gleixner @ 2026-04-22 17:49 UTC (permalink / raw)
To: Mark Rutland, Mathias Stearn
Cc: Mathieu Desnoyers, Catalin Marinas, Will Deacon, Boqun Feng,
Paul E. McKenney, Chris Kennelly, Dmitry Vyukov, regressions,
linux-kernel, linux-arm-kernel, Peter Zijlstra, Ingo Molnar,
Jinjie Ruan, Blake Oler
In-Reply-To: <aejCaG6n9s7ak5TO@J2N7QTR9R3.cambridge.arm.com>
On Wed, Apr 22 2026 at 14:09, Mark Rutland wrote:
> On Wed, Apr 22, 2026 at 11:50:26AM +0200, Mathias Stearn wrote:
>> TL;DR: As of 6.19, rseq no longer provides the documented atomicity
>> guarantees on arm64 by failing to abort the critical section on same-core
>> preemption/resumption. Additionally, it breaks tcmalloc specifically by
>> failing to overwrite the cpu_id_start field at points where it was relied
>> on for correctness.
>
> Thanks for the report, and the test case.
>
> As a holding reply, I'm looking into this now from the arm64 side.
I assume it's the partial conversion to the generic entry code which
screws that up. The problem reproduces with rseq selftests nicely.
The patch below fixes it as it puts ARM64 back to the non-optimized code
for now. Once ARM64 is fully converted it gets all the nice improvements.
Thanks,
tglx
---
diff --git a/include/linux/rseq.h b/include/linux/rseq.h
index 2266f4dc77b6..d55476e2a336 100644
--- a/include/linux/rseq.h
+++ b/include/linux/rseq.h
@@ -30,7 +30,7 @@ void __rseq_signal_deliver(int sig, struct pt_regs *regs);
*/
static inline void rseq_signal_deliver(struct ksignal *ksig, struct pt_regs *regs)
{
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
+ if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
/* '&' is intentional to spare one conditional branch */
if (current->rseq.event.has_rseq & current->rseq.event.user_irq)
__rseq_signal_deliver(ksig->sig, regs);
@@ -50,7 +50,7 @@ static __always_inline void rseq_sched_switch_event(struct task_struct *t)
{
struct rseq_event *ev = &t->rseq.event;
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
+ if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
/*
* Avoid a boat load of conditionals by using simple logic
* to determine whether NOTIFY_RESUME needs to be raised.
diff --git a/include/linux/rseq_entry.h b/include/linux/rseq_entry.h
index a36b472627de..8ccd464a108d 100644
--- a/include/linux/rseq_entry.h
+++ b/include/linux/rseq_entry.h
@@ -80,7 +80,7 @@ bool rseq_debug_validate_ids(struct task_struct *t);
static __always_inline void rseq_note_user_irq_entry(void)
{
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY))
+ if (IS_ENABLED(CONFIG_GENERIC_ENTRY))
current->rseq.event.user_irq = true;
}
@@ -171,8 +171,8 @@ bool rseq_debug_update_user_cs(struct task_struct *t, struct pt_regs *regs,
if (unlikely(usig != t->rseq.sig))
goto die;
- /* rseq_event.user_irq is only valid if CONFIG_GENERIC_IRQ_ENTRY=y */
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
+ /* rseq_event.user_irq is only valid if CONFIG_GENERIC_ENTRY=y */
+ if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
/* If not in interrupt from user context, let it die */
if (unlikely(!t->rseq.event.user_irq))
goto die;
@@ -387,7 +387,7 @@ static rseq_inline bool rseq_update_usr(struct task_struct *t, struct pt_regs *r
* allows to skip the critical section when the entry was not from
* a user space interrupt, unless debug mode is enabled.
*/
- if (IS_ENABLED(CONFIG_GENERIC_IRQ_ENTRY)) {
+ if (IS_ENABLED(CONFIG_GENERIC_ENTRY)) {
if (!static_branch_unlikely(&rseq_debug_enabled)) {
if (likely(!t->rseq.event.user_irq))
return true;
^ permalink raw reply related
* [PATCH v2] kselftest/arm64: Fix build failure with GCC-15
From: Leo Yan @ 2026-04-22 17:42 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Shuah Khan, Mark Brown,
Thiago Jung Bauermann
Cc: linux-arm-kernel, linux-kselftest, linux-kernel, Leo Yan
Building on Debian sid with GCC 15 fails:
CC libc-gcs
libc-gcs.c: In function 'ptrace_read_write':
libc-gcs.c:142:25: error: storage size of 'child_gcs' isn't known
142 | struct user_gcs child_gcs;
| ^~~~~~~~~
libc-gcs.c:142:25: warning: unused variable 'child_gcs' [-Wunused-variable]
For GCC-15, NT_ARM_GCS is defined in the libc header, causing gcs-util.h
to skip its fallback definition of struct user_gcs. This leads to the
compiler error.
Fix this by including <asm/ptrace.h> to provide the proper definition.
Fixes: a505a52b4e29 ("kselftest/arm64: Add a GCS test program built with the system libc")
Signed-off-by: Leo Yan <leo.yan@arm.com>
---
Changes in v2:
- Refined commit log (Mark Brown).
- Moving header to gcs-util.h (Mark Brown).
- Link to v1: https://lore.kernel.org/r/20260422-selftests_arm64_gcc15-v1-1-0d919ea5ac5f@arm.com
---
tools/testing/selftests/arm64/gcs/gcs-util.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/arm64/gcs/gcs-util.h b/tools/testing/selftests/arm64/gcs/gcs-util.h
index c99a6b39ac147b4efbc9b5fbadb43daf4da2c85e..f583d4dbd0bfd964e08cf40b3951664c70bb031a 100644
--- a/tools/testing/selftests/arm64/gcs/gcs-util.h
+++ b/tools/testing/selftests/arm64/gcs/gcs-util.h
@@ -7,6 +7,7 @@
#define GCS_UTIL_H
#include <stdbool.h>
+#include <asm/ptrace.h>
#ifndef __NR_map_shadow_stack
#define __NR_map_shadow_stack 453
---
base-commit: 4ee64205ffaa587e8114d84a67ac721399ccb369
change-id: 20260421-selftests_arm64_gcc15-15f6f6d07dd8
Best regards,
--
Leo Yan <leo.yan@arm.com>
^ permalink raw reply related
* Re: [PATCH] kselftest/arm64: Fix build failure with GCC-15
From: Leo Yan @ 2026-04-22 17:41 UTC (permalink / raw)
To: Mark Brown
Cc: Catalin Marinas, Will Deacon, Shuah Khan, Thiago Jung Bauermann,
linux-arm-kernel, linux-kselftest, linux-kernel
In-Reply-To: <8690e67b-3637-45de-8956-e27486470866@sirena.org.uk>
On Wed, Apr 22, 2026 at 06:20:16PM +0100, Mark Brown wrote:
[...]
> > +++ b/tools/testing/selftests/arm64/gcs/libc-gcs.c
> > @@ -16,6 +16,7 @@
> >
> > #include <asm/hwcap.h>
> > #include <asm/mman.h>
> > +#include <asm/ptrace.h>
>
> Shouldn't this be in gcs-util.h where the local definition is?
Will update commit log and this one. Thanks for review!
Leo
^ 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-22 17:20 UTC (permalink / raw)
To: Yeoreum Yun, linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm
Cc: 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: <20260422162449.1814615-2-yeoreum.yun@arm.com>
On Wed, 2026-04-22 at 17:24 +0100, Yeoreum Yun wrote:
> To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
> the TPM driver must be built as built-in and
> must be probed before the IMA subsystem is initialized.
>
> However, when the TPM device operates over the FF-A protocol using
> the CRB interface, probing fails and returns -EPROBE_DEFER if
> the tpm_crb_ffa device — an FF-A device that provides the communication
> interface to the tpm_crb driver — has not yet been probed.
>
> To ensure the TPM device operating over the FF-A protocol with
> the CRB interface is probed before IMA initialization,
> the following conditions must be met:
>
> 1. The corresponding ffa_device must be registered,
> which is done via ffa_init().
>
> 2. The tpm_crb_driver must successfully probe this device via
> tpm_crb_ffa_init().
>
> 3. The tpm_crb driver using CRB over FF-A can then
> be probed successfully. (See crb_acpi_add() and
> tpm_crb_ffa_init() for reference.)
>
> Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> all registered with device_initcall, which means crb_acpi_driver_init() may
> be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
>
> When this occurs, probing the TPM device is deferred.
> However, the deferred probe can happen after the IMA subsystem
> has already been initialized, since IMA initialization is performed
> during late_initcall, and deferred_probe_initcall() is performed
> at the same level.
>
> To resolve this, call ima_init() again at late_inicall_sync level
> so that let IMA not miss TPM PCR value when generating boot_aggregate
> log though TPM device presents in the system.
>
> Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
A lot of change for just detecting whether ima_init() is being called on
late_initcall or late_initcall_sync(), without any explanation for all the other
changes (e.g. ima_init_core).
Please just limit the change to just calling ima_init() twice.
Mimi
> ---
> include/linux/lsm_hooks.h | 2 +
> security/integrity/ima/ima.h | 4 +-
> security/integrity/ima/ima_init.c | 10 +++-
> security/integrity/ima/ima_main.c | 76 +++++++++++++++++++++++------
> security/integrity/ima/ima_policy.c | 3 ++
> security/lsm_init.c | 13 ++++-
> 6 files changed, 87 insertions(+), 21 deletions(-)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index d48bf0ad26f4..88fe105b7f00 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -166,6 +166,7 @@ enum lsm_order {
> * @initcall_fs: LSM callback for fs_initcall setup, optional
> * @initcall_device: LSM callback for device_initcall() setup, optional
> * @initcall_late: LSM callback for late_initcall() setup, optional
> + * @initcall_late_sync: LSM callback for late_initcall_sync() setup, optional
> */
> struct lsm_info {
> const struct lsm_id *id;
> @@ -181,6 +182,7 @@ struct lsm_info {
> int (*initcall_fs)(void);
> int (*initcall_device)(void);
> int (*initcall_late)(void);
> + int (*initcall_late_sync)(void);
> };
>
> #define DEFINE_LSM(lsm) \
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 89ebe98ffc5e..75ee7ad184d0 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -62,6 +62,8 @@ extern int ima_hash_algo_idx __ro_after_init;
> extern int ima_extra_slots __ro_after_init;
> extern struct ima_algo_desc *ima_algo_array __ro_after_init;
>
> +extern bool ima_initialised __ro_after_init;
> +
> extern int ima_appraise;
> extern struct tpm_chip *ima_tpm_chip;
> extern const char boot_aggregate_name[];
> @@ -257,7 +259,7 @@ static inline void ima_measure_kexec_event(const char *event_name) {}
> extern bool ima_canonical_fmt;
>
> /* Internal IMA function definitions */
> -int ima_init(void);
> +int ima_init(bool late);
> int ima_fs_init(void);
> int ima_add_template_entry(struct ima_template_entry *entry, int violation,
> const char *op, struct inode *inode,
> diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> index a2f34f2d8ad7..c28c71090ad2 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -115,13 +115,19 @@ void __init ima_load_x509(void)
> }
> #endif
>
> -int __init ima_init(void)
> +int __init ima_init(bool late)
> {
> int rc;
>
> ima_tpm_chip = tpm_default_chip();
> - if (!ima_tpm_chip)
> + if (!ima_tpm_chip) {
> + if (!late) {
> + pr_info("Defer initialisation to the late_initcall_sync stage.\n");
> + return -EPROBE_DEFER;
> + }
> +
> pr_info("No TPM chip found, activating TPM-bypass!\n");
> + }
>
> rc = integrity_init_keyring(INTEGRITY_KEYRING_IMA);
> if (rc)
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 1d6229b156fb..ac444ee600e2 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -38,6 +38,7 @@ int ima_appraise;
> #endif
>
> int __ro_after_init ima_hash_algo = HASH_ALGO_SHA1;
> +bool ima_initialised __ro_after_init = false;
> static int hash_setup_done;
> static int ima_disabled __ro_after_init;
>
> @@ -1237,6 +1238,35 @@ static int ima_kernel_module_request(char *kmod_name)
>
> #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
>
> +static int __init init_ima_core(bool late)
> +{
> + int err;
> +
> + if (ima_initialised)
> + return 0;
> +
> + err = ima_init(late);
> + if (err == -EPROBE_DEFER)
> + return 0;
> +
> + if (err && strcmp(hash_algo_name[ima_hash_algo],
> + CONFIG_IMA_DEFAULT_HASH) != 0) {
> + pr_info("Allocating %s failed, going to use default hash algorithm %s\n",
> + hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
> + hash_setup_done = 0;
> + hash_setup(CONFIG_IMA_DEFAULT_HASH);
> + err = ima_init(late);
> + }
> +
> + if (!err) {
> + ima_update_policy_flags();
> + ima_initialised = true;
> + } else
> + ima_disabled = 1;
> +
> + return err;
> +}
> +
> static int __init init_ima(void)
> {
> int error;
> @@ -1250,30 +1280,42 @@ static int __init init_ima(void)
> ima_appraise_parse_cmdline();
> ima_init_template_list();
> hash_setup(CONFIG_IMA_DEFAULT_HASH);
> - error = ima_init();
> -
> - if (error && strcmp(hash_algo_name[ima_hash_algo],
> - CONFIG_IMA_DEFAULT_HASH) != 0) {
> - pr_info("Allocating %s failed, going to use default hash algorithm %s\n",
> - hash_algo_name[ima_hash_algo], CONFIG_IMA_DEFAULT_HASH);
> - hash_setup_done = 0;
> - hash_setup(CONFIG_IMA_DEFAULT_HASH);
> - error = ima_init();
> - }
> -
> - if (error)
> - return error;
>
> error = register_blocking_lsm_notifier(&ima_lsm_policy_notifier);
> - if (error)
> + if (error) {
> pr_warn("Couldn't register LSM notifier, error %d\n", error);
> + goto disable_ima;
> + }
>
> - if (!error)
> - ima_update_policy_flags();
> + error = init_ima_core(false);
> + if (error) {
> + unregister_blocking_lsm_notifier(&ima_lsm_policy_notifier);
> + goto disable_ima;
> + }
> +
> + return 0;
>
> +disable_ima:
> + ima_disabled = 1;
> return error;
> }
>
> +static int __init late_init_ima(void)
> +{
> + int err;
> +
> + if (ima_disabled)
> + return 0;
> +
> + err = init_ima_core(true);
> + if (err) {
> + unregister_blocking_lsm_notifier(&ima_lsm_policy_notifier);
> + ima_disabled = 1;
> + }
> +
> + return err;
> +}
> +
> static struct security_hook_list ima_hooks[] __ro_after_init = {
> LSM_HOOK_INIT(bprm_check_security, ima_bprm_check),
> LSM_HOOK_INIT(bprm_creds_for_exec, ima_bprm_creds_for_exec),
> @@ -1321,4 +1363,6 @@ DEFINE_LSM(ima) = {
> .blobs = &ima_blob_sizes,
> /* Start IMA after the TPM is available */
> .initcall_late = init_ima,
> + /* Start IMA late in case of probing TPM is deferred. */
> + .initcall_late_sync = late_init_ima,
> };
> diff --git a/security/integrity/ima/ima_policy.c b/security/integrity/ima/ima_policy.c
> index bf2d7ba4c14a..c3bcc3521c81 100644
> --- a/security/integrity/ima/ima_policy.c
> +++ b/security/integrity/ima/ima_policy.c
> @@ -501,6 +501,9 @@ static void ima_lsm_update_rules(void)
> int ima_lsm_policy_change(struct notifier_block *nb, unsigned long event,
> void *lsm_data)
> {
> + if (!ima_initialised)
> + return NOTIFY_DONE;
> +
> if (event != LSM_POLICY_CHANGE)
> return NOTIFY_DONE;
>
> diff --git a/security/lsm_init.c b/security/lsm_init.c
> index 573e2a7250c4..4e5c59beb82a 100644
> --- a/security/lsm_init.c
> +++ b/security/lsm_init.c
> @@ -547,13 +547,22 @@ device_initcall(security_initcall_device);
> * security_initcall_late - Run the LSM late initcalls
> */
> static int __init security_initcall_late(void)
> +{
> + return lsm_initcall(late);
> +}
> +late_initcall(security_initcall_late);
> +
> +/**
> + * security_initcall_late_sync - Run the LSM late initcalls sync
> + */
> +static int __init security_initcall_late_sync(void)
> {
> int rc;
>
> - rc = lsm_initcall(late);
> + rc = lsm_initcall(late_sync);
> lsm_pr_dbg("all enabled LSMs fully activated\n");
> call_blocking_lsm_notifier(LSM_STARTED_ALL, NULL);
>
> return rc;
> }
> -late_initcall(security_initcall_late);
> +late_initcall_sync(security_initcall_late_sync);
> --
> LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
^ permalink raw reply
* Re: [PATCH] kselftest/arm64: Fix build failure with GCC-15
From: Mark Brown @ 2026-04-22 17:20 UTC (permalink / raw)
To: Leo Yan
Cc: Catalin Marinas, Will Deacon, Shuah Khan, Thiago Jung Bauermann,
linux-arm-kernel, linux-kselftest, linux-kernel
In-Reply-To: <20260422-selftests_arm64_gcc15-v1-1-0d919ea5ac5f@arm.com>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Wed, Apr 22, 2026 at 06:01:39PM +0100, Leo Yan wrote:
> Building on Debian sid with GCC 15 fails:
> GCC-15 defines NT_ARM_GCS in the toolchain headers, causing gcs-util.h
> to skip its fallback definition of struct user_gcs. This leads to the
> compiler error.
Are you sure it's GCC and not libc? Anyway...
> tools/testing/selftests/arm64/gcs/libc-gcs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/testing/selftests/arm64/gcs/libc-gcs.c b/tools/testing/selftests/arm64/gcs/libc-gcs.c
> index 17b2fabfec386e523e788d8bcfcafa553c93bd9b..72e82bfbecc99e34da71d56cf5401c137d6e9a48 100644
> --- a/tools/testing/selftests/arm64/gcs/libc-gcs.c
> +++ b/tools/testing/selftests/arm64/gcs/libc-gcs.c
> @@ -16,6 +16,7 @@
>
> #include <asm/hwcap.h>
> #include <asm/mman.h>
> +#include <asm/ptrace.h>
Shouldn't this be in gcs-util.h where the local definition is?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 8/8] ARM: Remove hacked-up asm/types.h header
From: Ard Biesheuvel @ 2026-04-22 17:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-crypto, linux-raid, Ard Biesheuvel, Christoph Hellwig,
Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-10-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
ARM has a special version of asm/types.h which contains overrides for
certain #define's related to the C types used to back C99 types such as
uint32_t and uintptr_t.
This is only needed when pulling in system headers such as stdint.h
during the build, and this only happens when using NEON intrinsics,
for which there is now a dedicated header file.
So drop this header entirely, and revert to the asm-generic one.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm/include/uapi/asm/types.h | 41 --------------------
1 file changed, 41 deletions(-)
diff --git a/arch/arm/include/uapi/asm/types.h b/arch/arm/include/uapi/asm/types.h
deleted file mode 100644
index 1a667bc26510..000000000000
--- a/arch/arm/include/uapi/asm/types.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI_ASM_TYPES_H
-#define _UAPI_ASM_TYPES_H
-
-#include <asm-generic/int-ll64.h>
-
-/*
- * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
- * unambiguous on ARM as you would expect. For the types below, there is a
- * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
- * and the kernel itself, which results in build errors if you try to build with
- * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
- * in order to use NEON intrinsics)
- *
- * As the typedefs for these types in 'stdint.h' are based on builtin defines
- * supplied by GCC, we can tweak these to align with the kernel's idea of those
- * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
- * source file (provided that -ffreestanding is used).
- *
- * int32_t uint32_t uintptr_t
- * bare metal GCC long unsigned long unsigned int
- * glibc GCC int unsigned int unsigned int
- * kernel int unsigned int unsigned long
- */
-
-#ifdef __INT32_TYPE__
-#undef __INT32_TYPE__
-#define __INT32_TYPE__ int
-#endif
-
-#ifdef __UINT32_TYPE__
-#undef __UINT32_TYPE__
-#define __UINT32_TYPE__ unsigned int
-#endif
-
-#ifdef __UINTPTR_TYPE__
-#undef __UINTPTR_TYPE__
-#define __UINTPTR_TYPE__ unsigned long
-#endif
-
-#endif /* _UAPI_ASM_TYPES_H */
--
2.54.0.rc1.555.g9c883467ad-goog
^ permalink raw reply related
* [PATCH 7/8] lib/raid6: Include asm/neon-intrinsics.h rather than arm_neon.h
From: Ard Biesheuvel @ 2026-04-22 17:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-crypto, linux-raid, Ard Biesheuvel, Christoph Hellwig,
Russell King, Arnd Bergmann, Eric Biggers
In-Reply-To: <20260422171655.3437334-10-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
arm_neon.h is a compiler header which needs some scaffolding to work
correctly in the linux context, and so it is better not to include it
directly. Both ARM and arm64 now provide asm/neon-intrinsics.h which
takes care of this.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
lib/raid6/neon.uc | 2 +-
lib/raid6/recov_neon_inner.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/raid6/neon.uc b/lib/raid6/neon.uc
index 355270af0cd6..3dc20511103a 100644
--- a/lib/raid6/neon.uc
+++ b/lib/raid6/neon.uc
@@ -24,7 +24,7 @@
* This file is postprocessed using unroll.awk
*/
-#include <arm_neon.h>
+#include <asm/neon-intrinsics.h>
#include "neon.h"
typedef uint8x16_t unative_t;
diff --git a/lib/raid6/recov_neon_inner.c b/lib/raid6/recov_neon_inner.c
index f9e7e8f5a151..06b2967fb8b6 100644
--- a/lib/raid6/recov_neon_inner.c
+++ b/lib/raid6/recov_neon_inner.c
@@ -4,7 +4,7 @@
* Copyright (C) 2017 Linaro Ltd. <ard.biesheuvel@linaro.org>
*/
-#include <arm_neon.h>
+#include <asm/neon-intrinsics.h>
#include "neon.h"
#ifdef CONFIG_ARM
--
2.54.0.rc1.555.g9c883467ad-goog
^ 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