* Re: [PATCH v2] powerpc/64s: Clarify copy_and_flush() cache sync loop comment
From: Aditya Gupta @ 2026-07-17 6:40 UTC (permalink / raw)
To: Nikhil Kumar Singh, linuxppc-dev, mkchauras
Cc: linux-kernel, maddy, mpe, npiggin, chleroy, mahesh
In-Reply-To: <20260706082708.43918-1-nikhilks@linux.ibm.com>
On 06/07/26 13:57, Nikhil Kumar Singh wrote:
> The value loaded into r0 in copy_and_flush() represents the number of
> 8-byte words processed between cache synchronization operations.
>
> The existing comment refers to cache line size, which can make it appear
> that the value is a cache line size in bytes rather than a loop count.
> Clarify the comment to explain that the loop processes 8 words (64 bytes)
> per cache synchronization iteration, and that increasing the value would
> skip cache maintenance for intermediate cache lines.
>
> This is a comment-only change with no functional impact.
>
> Signed-off-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
> ---
> arch/powerpc/kernel/head_64.S | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 63432a33ec49..a54f6f979173 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -713,14 +713,18 @@ p_end: .8byte _end - copy_to_here
> _GLOBAL(copy_and_flush)
> addi r5,r5,-8
> addi r6,r6,-8
> -4: li r0,8 /* Use the smallest common */
> - /* denominator cache line */
> - /* size. This results in */
> - /* extra cache line flushes */
> - /* but operation is correct. */
> - /* Can't get cache line size */
> - /* from NACA as it is being */
> - /* moved too. */
> +4: li r0,8 /* r0 is the number of 8-byte words */
> + /* to copy per cache sync iteration. */
> + /* 8 words * 8 bytes = 64 bytes. 64B is */
> + /* the current default cache line size. */
> + /* This is a loop count, not a byte */
> + /* count. Increasing it may skip */
> + /* dcbst/icbi for lines in between and */
> + /* leave stale instructions in icache. */
> + /* This results in extra cache line */
> + /* flushes but operation is correct. */
> + /* Can't get cache line size from NACA */
> + /* as it is being moved too. */
>
> mtctr r0 /* put # words/line in ctr */
> 3: addi r6,r6,8 /* copy a cache line */
Makes sense. Feel free to keep the rb.
Reviewed-by: Aditya Gupta <adityag@linux.ibm.com>
Thanks,
- Aditya G
^ permalink raw reply
* Re: [PATCH] crypto: powerpc/aes - use bool for encryption/decryption flag
From: Herbert Xu @ 2026-07-17 8:17 UTC (permalink / raw)
To: Thorsten Blum
Cc: Breno Leitão, Nayna Jain, Paulo Flabiano Smorigo,
David S. Miller, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), linux-crypto,
linuxppc-dev, linux-kernel
In-Reply-To: <20260711145216.747128-3-thorsten.blum@linux.dev>
On Sat, Jul 11, 2026 at 04:52:17PM +0200, Thorsten Blum wrote:
> Use bool for the CBC encryption/decryption flag passed through
> p8_aes_cbc_crypt() to aes_p8_cbc_encrypt().
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> arch/powerpc/crypto/aes_cbc.c | 6 +++---
> include/crypto/aes.h | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] powerpc/64s: Clarify copy_and_flush() cache sync loop comment
From: Amit Machhiwal @ 2026-07-17 11:55 UTC (permalink / raw)
To: Nikhil Kumar Singh
Cc: Mukesh Kumar Chaurasiya, linuxppc-dev, linux-kernel, maddy, mpe,
npiggin, chleroy, adityag, mahesh
In-Reply-To: <b5f97f5b-4a17-46f7-8830-a9c4c121f0c4@linux.ibm.com>
On 2026/07/09 11:40 AM, Nikhil Kumar Singh wrote:
> Hi Mukesh,
>
> Ideally, checkpatch should take care of this, I see no checkpatch errors.
That is because the default $max_line_length is set to 100 columns in
checkpatch.pl scripts. The kernel coding style document recommends 80,
but checkpatch enforces 100 unless you pass --max-line-length=80
explicitly.
my $max_line_length = 100;
You will see the warnings being reported when you run the script as:
❯ scripts/checkpatch.pl ./v2_20260706_nikhilks_powerpc_64s_clarify_copy_and_flush_cache_sync_loop_comment.mbx --max-line-length=80
WARNING: line length of 82 exceeds 80 columns
#44: FILE: arch/powerpc/kernel/head_64.S:716:
+4: li r0,8 /* r0 is the number of 8-byte words */
[...]
total: 0 errors, 12 warnings, 26 lines checked
I agree with Mukesh here and I think the comment should be fixed to fit
within 80 column width limit as staying within 80 columns is certainly
still preferred.
Thanks,
Amit
>
> ```
> ./scripts/checkpatch.pl
> v2-0001-powerpc-64s-Clarify-copy_and_flush-cache-sync-loo.patch
> total: 0 errors, 0 warnings, 26 lines checked
>
> v2-0001-powerpc-64s-Clarify-copy_and_flush-cache-sync-loo.patch has no
> obvious style problems and is ready for submission.
> ```
>
> Thanks
> ~ Nikhil
>
> On 07/07/26 12:48, Nikhil Kumar Singh wrote:
> > Hi Mukesh,
> >
> > Thanks for reviewing the patch and for the suggestion.
> > I'd prefer to keep the current alignment as I find it a bit more
> > readable.
> >
> > Thanks,
> > ~ Nikhil
> >
> > On 07/07/26 11:08, Mukesh Kumar Chaurasiya wrote:
> > > On Mon, Jul 06, 2026 at 01:57:08PM +0530, Nikhil Kumar Singh wrote:
> > > > The value loaded into r0 in copy_and_flush() represents the number of
> > > > 8-byte words processed between cache synchronization operations.
> > > >
> > > > The existing comment refers to cache line size, which can make
> > > > it appear
> > > > that the value is a cache line size in bytes rather than a loop count.
> > > > Clarify the comment to explain that the loop processes 8 words
> > > > (64 bytes)
> > > > per cache synchronization iteration, and that increasing the
> > > > value would
> > > > skip cache maintenance for intermediate cache lines.
> > > >
> > > > This is a comment-only change with no functional impact.
> > > >
> > > > Signed-off-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
> > > > ---
> > > > arch/powerpc/kernel/head_64.S | 20 ++++++++++++--------
> > > > 1 file changed, 12 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/arch/powerpc/kernel/head_64.S
> > > > b/arch/powerpc/kernel/head_64.S
> > > > index 63432a33ec49..a54f6f979173 100644
> > > > --- a/arch/powerpc/kernel/head_64.S
> > > > +++ b/arch/powerpc/kernel/head_64.S
> > > > @@ -713,14 +713,18 @@ p_end: .8byte _end - copy_to_here
> > > > _GLOBAL(copy_and_flush)
> > > > addi r5,r5,-8
> > > > addi r6,r6,-8
> > > > -4: li r0,8 /* Use the smallest common */
> > > > - /* denominator cache line */
> > > > - /* size. This results in */
> > > > - /* extra cache line flushes */
> > > > - /* but operation is correct. */
> > > > - /* Can't get cache line size */
> > > > - /* from NACA as it is being */
> > > > - /* moved too. */
> > > > +4: li r0,8 /* r0 is the number of 8-byte words */
> > > > + /* to copy per cache sync iteration. */
> > > > + /* 8 words * 8 bytes = 64 bytes. 64B is */
> > > > + /* the current default cache line size. */
> > > > + /* This is a loop count, not a byte */
> > > > + /* count. Increasing it may skip */
> > > > + /* dcbst/icbi for lines in between and */
> > > > + /* leave stale instructions in icache. */
> > > > + /* This results in extra cache line */
> > > > + /* flushes but operation is correct. */
> > > > + /* Can't get cache line size from NACA */
> > > > + /* as it is being moved too. */
> > > The comment looks fine. But the alignement of the comment is still
> > > different from earlier. Keep the alignment same as earlier, it looks a
> > > little nicer.
> > >
> > > Regards,
> > > Mukesh
> > > > mtctr r0 /* put # words/line in ctr */
> > > > 3: addi r6,r6,8 /* copy a cache line */
> > > > --
> > > > 2.43.5
> > > >
^ permalink raw reply
* [PATCH] char: powernv-op-panel: remove unnecessary reset of position pointer
From: Fernando Fernandez Mancera @ 2026-07-17 9:45 UTC (permalink / raw)
To: linuxppc-dev
Cc: linux-kernel, chleroy, npiggin, mpe, maddy, gregkh, arnd,
sjitindarsingh, Fernando Fernandez Mancera
The position pointer is only advanced if the return value of the write
operation is positive at ksys_write(). Therefore no need to manually
reset it when doing error handling.
Assisted-by: coccinelle # to find it
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
Note: i found this while fixing the same pattern in ipv6/ipv4 sysctl
proc handlers. This is not my area of expertise but I thought it was
worth contributing it :-)
---
drivers/char/powernv-op-panel.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/char/powernv-op-panel.c b/drivers/char/powernv-op-panel.c
index 63175b765c90..a98acb199805 100644
--- a/drivers/char/powernv-op-panel.c
+++ b/drivers/char/powernv-op-panel.c
@@ -89,7 +89,6 @@ static int __op_panel_update_display(void)
static ssize_t oppanel_write(struct file *filp, const char __user *userbuf,
size_t len, loff_t *f_pos)
{
- loff_t f_pos_prev = *f_pos;
ssize_t ret;
int rc;
@@ -105,7 +104,6 @@ static ssize_t oppanel_write(struct file *filp, const char __user *userbuf,
if (rc != OPAL_SUCCESS) {
pr_err_ratelimited("OPAL call failed to write to op panel display [rc=%d]\n",
rc);
- *f_pos = f_pos_prev;
return -EIO;
}
}
--
2.55.0
^ permalink raw reply related
* Re: [PATCH 35/60] kvm: Add VCPU plane-scheduling state and helpers
From: Saenz Julienne, Nicolas @ 2026-07-17 13:48 UTC (permalink / raw)
To: Jörg Rödel, Paolo Bonzini
Cc: Sean Christopherson, Tom Lendacky, ashish.kalra@amd.com,
michael.roth@amd.com, Saenz Julienne, Nicolas, Orazgaliyeva, Anel,
James.Bottomley@hansenpartnership.com, Melody Wang,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
kvmarm@lists.linux.dev, loongarch@lists.linux.dev,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm-riscv@lists.infradead.org, x86@kernel.org,
coconut-svsm@lists.linux.dev, joerg.roedel@amd.com
In-Reply-To: <aigE2EvJyZlYDz0V@8bytes.org>
Hi Joerg, I'm a bit late to the discussion hope it helps nonetheless,
On Tue Jun 9, 2026 at 2:37 PM CEST, Jörg Rödel wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>> The idea of the userspace scheduling was that you're not forced to use
>> it - the kernel can always choose to override it if it's using an
>> accelerated implementation of planes (and of plane switching). But it
>> also leaves some leeway to different accelerated implementations, each
>> of which can pick their own algorithm.
>>
>> Conceptually I'd rather keep the possibility of userspace scheduling.
>> But maybe it doesn't add much.
>
> My preference is to keep plane scheduling at one place (in the kernel) to keep
> it simple. But if you see a need for user-mode to interact there as well (only
> really works for VSM), then I can add it.
The responsibility split we had in mind when we built a VSM emulation
prototype [1] was to keep all VTL policing in user-space. This includes
VTL switching, Cross VTL IPIs, Intercepts (Memory, MSRs, Insns, CPU
regs), VTL aware SMP bring-up, etc. Even with KVM Planes in place, my
thinking was to keep it as such. While all this could be implemented in
the kernel, in practical terms, I think it'll be easier to get VSM
support upstream the more we move the implementation into user-space.
More importantly, I think the area of Virtualization Based Security
would benefit from a versatile Planes implementation. Forcing specific
plane switching semantics might prevent the introduction VSM
alternatives or extensions. Heki and lVBS come to mind here.
> I read a bit more about VSM and it seems their prioritization of VTLs is a bit
> more complicated. VTL0 has the least privileges but boots first, then sets up
> VTL1. But VTL1 is only higher-privileged once it is locked by VTL0. Another way
> to look at it is that VTL0 de-prioritizes itself.
>
> The patches here are built around the assumption that plane0 is the highest
> privileged one and is always runnable. Running any lower-privilege plane must
> be triggered by the guest. This is clearly not sufficient for VSM, the question
> is how to solve that.
I'd suggest inverting the priorities, with higher planes being more
privileged. It'll make introducing higher privilege levels easier. This
is especially useful with VSM, where it's not possible to know how many
levels will be enabled before launching the VM.
> The answer depends on how IRQ delivery affects VTL scheduling in VSM. If a
> VM has VTL0 (currently running), VTL1, and VTL2 (highest privilege), and an IRQ
> becomed pending for VTL1, does Hyper-V schedule VTL1 directly or does it switch
> to VTL2 (highest privilege) first to let it schedule VTL1?
The hypervisor can trigger a 0->1 switch directly with "interrupt" as
the entry reason.
Nicolas
[1] See the repositories and branches referred to here:
https://github.com/vianpl/qemu-kvm-dev-env
^ permalink raw reply
* Re: [PATCH 35/60] kvm: Add VCPU plane-scheduling state and helpers
From: James Bottomley @ 2026-07-17 14:35 UTC (permalink / raw)
To: Jörg Rödel, Paolo Bonzini
Cc: Sean Christopherson, Tom Lendacky, ashish.kalra, michael.roth,
nsaenz, anelkz, Melody Wang, kvm, linux-kernel, kvmarm, loongarch,
linux-mips, linuxppc-dev, kvm-riscv, x86, coconut-svsm,
joerg.roedel
In-Reply-To: <aigE2EvJyZlYDz0V@8bytes.org>
On Tue, 2026-06-09 at 14:37 +0200, Jörg Rödel wrote:
> I read a bit more about VSM and it seems their prioritization of VTLs
> is a bit more complicated. VTL0 has the least privileges but boots
> first, then sets up VTL1. But VTL1 is only higher-privileged once it
> is locked by VTL0. Another way to look at it is that VTL0 de-
> prioritizes itself.
Actually, I don't think we have to follow the VSM model. All we at
Microsoft care about is that we can emulate VSM with the planes
primitives provided.
There's a definite reason not to do strict VTL privilege in that one
can see two mutually distrusting planes sharing a common communication
area. This is definitely possible with TDX and so planes shouldn't
disallow it.
> The patches here are built around the assumption that plane0 is the
> highest privileged one and is always runnable. Running any lower-
> privilege plane must be triggered by the guest. This is clearly not
> sufficient for VSM, the question is how to solve that.
So this all depends how the planes are started. If you're starting
them from an IGVM file that loads the most privileged code and then
runs the guest in a different plane, absolutely, it can work as you
describe. However, the common use case for serviceable security
enclaves is you start the kernel first (necessarily in plane 0) and
then bring up the enclaves later which means the planes > 0 are
technically higher privilege since they're running hidden security
code. HOWEVER, there's no reason at all to trust a security enclave
that's doing something like guarding private keys to be able to poke
anywhere it wants in the guest ... that's a security breach waiting to
happen, so it would really be better if the model were not
hierarchical, but more akin to the ability to seal planes off from each
other, so the kernel can start the enclave, which would then set itself
and the communication area up, but then the plane 0 kernel would remove
access to most memory from the enclave.
In this sealing model, there's no absolute privilege levels; each plane
would decide what the other planes can see of its memory space and, on
security grounds, we'd likely configure the enclaves to have the least
possible privilege.
Now, Windows applications expect VSM to be strictly hierarchical in
terms of privilege, but if we create a sealing primitive as described
above, we can get it to build the strict VSM privilege hierarchy in the
hyper-v driver.
Regards,
James
^ permalink raw reply
* [PATCH v2 00/12] misc: Improvements around *_device_id defintions
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-17 14:50 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman
Cc: linux-kernel, Danilo Krummrich, Bjorn Helgaas, Takashi Sakamoto,
Frank Haverkamp, Kees Cook, Eric Piel, Akshay Gupta,
Naveen Krishna Chatradhi, Alexander Usyskin, Brad Warrum,
Ritu Agarwal, Srinivas Kandagatla, Ekansh Gupta, John Stultz,
Romain Gantois, linux-arm-msm, dri-devel, Scott Branden,
Broadcom internal kernel review list, Michał Mirosław,
Keng-Yu Lin, Vaibhaav Ram T.L, Kumaravel Thiagarajan,
Vamsi Attunuru, Alexander Graf, The AWS Nitro Enclaves Team,
Mahesh J Salgaonkar, Andrew Donnellan, Manivannan Sadhasivam,
Krzysztof Wilczyński, Kishon Vijay Abraham I, Frank Li,
Jiri Slaby, Andrea della Porta, Bryan Tan, Vishnu Dasa,
linux-gpio, linuxppc-dev, linux-pci
Hello,
the main motivation for this series are the patches that introduce named
initializers to these arrays. The reason I want these is that I plan to
make .driver_data a union, see
https://lore.kernel.org/all/cover.1780048925.git.u.kleine-koenig@baylibre.com/
for more details about this quest.
This series superseds a patch that only handled i2c_device_id, which is
available at
https://lore.kernel.org/all/20260515162734.469327-2-u.kleine-koenig@baylibre.com/.
Changes since then:
- Also handle all the other *_device_id to ideally only have to bother
about drivers/misc once for all the similar quests
- split drivers/misc/eeprom in separate patches
- rebased to yeserday's next
Best regards
Uwe
Uwe Kleine-König (The Capable Hub) (12):
misc: Drop unused assignment of spi_device_id driver data
misc/pvpanic: Drop unused assignment of acpi_device_id driver data
misc: genwqe: Drop unused assignment of pci_device_id driver data
misc: eeprom: Use named initializers for arrays of i2c_device_data
misc: Use named initializers for arrays of i2c_device_data
misc: Use named initializers for arrays of spi_device_data
misc: mei: Use named initializers for acpi_device_id array
misc: mei: Use named initializer for platform_device_id array
misc: ibmvmc: Use named initializers for vio_device_id array
misc: eeprom: idt_89hpesx: Unify style of of_device_id array
misc: Unify style of of_device_id arrays
misc: Unify code style for various *_device_id arrays
drivers/misc/ad525x_dpot-i2c.c | 52 ++---
drivers/misc/ad525x_dpot-spi.c | 58 ++---
drivers/misc/amd-sbi/rmi-i2c.c | 6 +-
drivers/misc/apds9802als.c | 2 +-
drivers/misc/bcm-vk/bcm_vk_dev.c | 2 +-
drivers/misc/bh1770glc.c | 6 +-
drivers/misc/cardreader/alcor_pci.c | 2 +-
drivers/misc/cb710/core.c | 5 +-
drivers/misc/ds1682.c | 6 +-
drivers/misc/eeprom/idt_89hpesx.c | 202 +++++++++---------
drivers/misc/eeprom/max6875.c | 2 +-
drivers/misc/fastrpc.c | 6 +-
drivers/misc/gehc-achc.c | 4 +-
drivers/misc/genwqe/card_base.c | 88 +++-----
drivers/misc/hi6421v600-irq.c | 2 +-
drivers/misc/hisi_hikey_usb.c | 2 +-
drivers/misc/hmc6352.c | 2 +-
drivers/misc/hpilo.c | 6 +-
drivers/misc/ibmasm/module.c | 2 +-
drivers/misc/ibmvmc.c | 4 +-
drivers/misc/ics932s401.c | 2 +-
drivers/misc/isl29003.c | 4 +-
drivers/misc/isl29020.c | 2 +-
drivers/misc/keba/lan9252.c | 4 +-
drivers/misc/lattice-ecp3-config.c | 4 +-
drivers/misc/lis3lv02d/lis3lv02d_i2c.c | 8 +-
drivers/misc/lis3lv02d/lis3lv02d_spi.c | 2 +-
drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c | 2 +-
.../misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.c | 4 +-
.../misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c | 4 +-
drivers/misc/mei/pci-csc.c | 2 +-
drivers/misc/mei/pci-me.c | 166 +++++++-------
drivers/misc/mei/pci-txe.c | 6 +-
drivers/misc/mei/platform-vsc.c | 2 +-
drivers/misc/mei/vsc-tp.c | 10 +-
drivers/misc/mrvl_cn10k_dpi.c | 2 +-
drivers/misc/nsm.c | 2 +-
drivers/misc/ocxl/pci.c | 2 +-
drivers/misc/open-dice.c | 2 +-
drivers/misc/pci_endpoint_test.c | 16 +-
drivers/misc/phantom.c | 6 +-
drivers/misc/pvpanic/pvpanic-mmio.c | 8 +-
drivers/misc/pvpanic/pvpanic-pci.c | 4 +-
drivers/misc/qcom-coincell.c | 4 +-
drivers/misc/rp1/rp1_pci.c | 2 +-
drivers/misc/sram.c | 2 +-
drivers/misc/ti_fpc202.c | 2 +-
drivers/misc/tsl2550.c | 2 +-
drivers/misc/vcpu_stall_detector.c | 4 +-
drivers/misc/vmw_vmci/vmci_guest.c | 4 +-
50 files changed, 362 insertions(+), 381 deletions(-)
base-commit: 1a1757b76427f6201bfe0bf1bea9f7574f332a93
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply
* [PATCH v2 12/12] misc: Unify code style for various *_device_id arrays
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-17 14:50 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman
Cc: Scott Branden, Broadcom internal kernel review list,
Michał Mirosław, Keng-Yu Lin, Vaibhaav Ram T.L,
Kumaravel Thiagarajan, Alexander Usyskin, Vamsi Attunuru,
Alexander Graf, The AWS Nitro Enclaves Team, Mahesh J Salgaonkar,
Andrew Donnellan, Manivannan Sadhasivam,
Krzysztof Wilczyński, Kishon Vijay Abraham I, Frank Li,
Jiri Slaby, Andrea della Porta, Bryan Tan, Vishnu Dasa,
Naveen Krishna Chatradhi, Akshay Gupta, Kees Cook, linux-kernel,
linux-gpio, linuxppc-dev, linux-pci
In-Reply-To: <cover.1784299069.git.u.kleine-koenig@baylibre.com>
- Add a trailing comma for initializers unless the closing brace is on
the same line and for the list terminator;
- Use a single space in the list terminator;
- A space after an opening { and before a closing };
- Use the PCI_DEVICE* macro in two drivers for pci_device_id entry
which is usual for these arrays
- No explicit zeros in the list terminator;
None of these changes introduces changes to the compiled result.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
drivers/misc/amd-sbi/rmi-i2c.c | 2 +-
drivers/misc/bcm-vk/bcm_vk_dev.c | 2 +-
drivers/misc/cardreader/alcor_pci.c | 2 +-
drivers/misc/cb710/core.c | 5 +-
drivers/misc/hi6421v600-irq.c | 2 +-
drivers/misc/hpilo.c | 6 +-
drivers/misc/ibmasm/module.c | 2 +-
drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c | 2 +-
.../misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.c | 4 +-
.../misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c | 4 +-
drivers/misc/mei/pci-csc.c | 2 +-
drivers/misc/mei/pci-me.c | 166 +++++++++---------
drivers/misc/mei/pci-txe.c | 6 +-
drivers/misc/mrvl_cn10k_dpi.c | 2 +-
drivers/misc/nsm.c | 2 +-
drivers/misc/ocxl/pci.c | 2 +-
drivers/misc/pci_endpoint_test.c | 16 +-
drivers/misc/phantom.c | 6 +-
drivers/misc/pvpanic/pvpanic-pci.c | 4 +-
drivers/misc/rp1/rp1_pci.c | 2 +-
drivers/misc/vmw_vmci/vmci_guest.c | 4 +-
21 files changed, 121 insertions(+), 122 deletions(-)
diff --git a/drivers/misc/amd-sbi/rmi-i2c.c b/drivers/misc/amd-sbi/rmi-i2c.c
index bbc0d14d1cfc..463a9a757464 100644
--- a/drivers/misc/amd-sbi/rmi-i2c.c
+++ b/drivers/misc/amd-sbi/rmi-i2c.c
@@ -226,7 +226,7 @@ static const struct i3c_device_id sbrmi_i3c_id[] = {
I3C_DEVICE_EXTRA_INFO(0x0, 0x100, 0x118, NULL), /* Socket:1, Venice */
I3C_DEVICE_EXTRA_INFO(0x112, 0x0, 0x119, NULL), /* Socket:0, Venice */
I3C_DEVICE_EXTRA_INFO(0x112, 0x100, 0x119, NULL), /* Socket:1, Venice */
- {}
+ { }
};
MODULE_DEVICE_TABLE(i3c, sbrmi_i3c_id);
diff --git a/drivers/misc/bcm-vk/bcm_vk_dev.c b/drivers/misc/bcm-vk/bcm_vk_dev.c
index 5773ffb46f0f..7aa818a7717a 100644
--- a/drivers/misc/bcm-vk/bcm_vk_dev.c
+++ b/drivers/misc/bcm-vk/bcm_vk_dev.c
@@ -1632,7 +1632,7 @@ static void bcm_vk_shutdown(struct pci_dev *pdev)
}
static const struct pci_device_id bcm_vk_ids[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_VALKYRIE), },
+ { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, PCI_DEVICE_ID_VALKYRIE) },
{ }
};
MODULE_DEVICE_TABLE(pci, bcm_vk_ids);
diff --git a/drivers/misc/cardreader/alcor_pci.c b/drivers/misc/cardreader/alcor_pci.c
index 8e7ea2c9142d..9e0f4f91763e 100644
--- a/drivers/misc/cardreader/alcor_pci.c
+++ b/drivers/misc/cardreader/alcor_pci.c
@@ -47,7 +47,7 @@ static const struct pci_device_id pci_ids[] = {
.driver_data = (kernel_ulong_t)&au6621_cfg },
{ PCI_DEVICE(PCI_ID_ALCOR_MICRO, PCI_ID_AU6625),
.driver_data = (kernel_ulong_t)&au6625_cfg },
- {},
+ { }
};
MODULE_DEVICE_TABLE(pci, pci_ids);
diff --git a/drivers/misc/cb710/core.c b/drivers/misc/cb710/core.c
index 2dd212f04fed..8e0d11e59c4e 100644
--- a/drivers/misc/cb710/core.c
+++ b/drivers/misc/cb710/core.c
@@ -292,9 +292,8 @@ static void cb710_remove_one(struct pci_dev *pdev)
}
static const struct pci_device_id cb710_pci_tbl[] = {
- { PCI_VENDOR_ID_ENE, PCI_DEVICE_ID_ENE_CB710_FLASH,
- PCI_ANY_ID, PCI_ANY_ID, },
- { 0, }
+ { PCI_DEVICE(PCI_VENDOR_ID_ENE, PCI_DEVICE_ID_ENE_CB710_FLASH) },
+ { }
};
static SIMPLE_DEV_PM_OPS(cb710_pm_ops, cb710_suspend, cb710_resume);
diff --git a/drivers/misc/hi6421v600-irq.c b/drivers/misc/hi6421v600-irq.c
index 5ba40222eb12..143f2ffa846f 100644
--- a/drivers/misc/hi6421v600-irq.c
+++ b/drivers/misc/hi6421v600-irq.c
@@ -285,7 +285,7 @@ static int hi6421v600_irq_probe(struct platform_device *pdev)
static const struct platform_device_id hi6421v600_irq_table[] = {
{ .name = "hi6421v600-irq" },
- {},
+ { }
};
MODULE_DEVICE_TABLE(platform, hi6421v600_irq_table);
diff --git a/drivers/misc/hpilo.c b/drivers/misc/hpilo.c
index ff3f03ea577e..40e96d15164a 100644
--- a/drivers/misc/hpilo.c
+++ b/drivers/misc/hpilo.c
@@ -33,10 +33,10 @@ static unsigned int max_ccb = 16;
static char ilo_hwdev[MAX_ILO_DEV];
static const struct pci_device_id ilo_blacklist[] = {
/* auxiliary iLO */
- {PCI_DEVICE_SUB(PCI_VENDOR_ID_HP, 0x3307, PCI_VENDOR_ID_HP, 0x1979)},
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_HP, 0x3307, PCI_VENDOR_ID_HP, 0x1979) },
/* CL */
- {PCI_DEVICE_SUB(PCI_VENDOR_ID_HP, 0x3307, PCI_VENDOR_ID_HP_3PAR, 0x0289)},
- {}
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_HP, 0x3307, PCI_VENDOR_ID_HP_3PAR, 0x0289) },
+ { }
};
static inline int get_entry_id(int entry)
diff --git a/drivers/misc/ibmasm/module.c b/drivers/misc/ibmasm/module.c
index 4509c15a76a8..97f661f54b31 100644
--- a/drivers/misc/ibmasm/module.c
+++ b/drivers/misc/ibmasm/module.c
@@ -178,7 +178,7 @@ static void ibmasm_remove_one(struct pci_dev *pdev)
static struct pci_device_id ibmasm_pci_table[] =
{
{ PCI_DEVICE(VENDORID_IBM, DEVICEID_RSA) },
- {},
+ { }
};
static struct pci_driver ibmasm_driver = {
diff --git a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c
index 48bea1117771..b0b678e6b28d 100644
--- a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c
+++ b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gp.c
@@ -150,7 +150,7 @@ static const struct pci_device_id pci1xxxx_tbl[] = {
{ PCI_DEVICE(0x1055, 0xA035) },
{ PCI_DEVICE(0x1055, 0xA045) },
{ PCI_DEVICE(0x1055, 0xA055) },
- {0,}
+ { }
};
MODULE_DEVICE_TABLE(pci, pci1xxxx_tbl);
diff --git a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.c b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.c
index 8eddbaa1fccd..82635db04dc5 100644
--- a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.c
+++ b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_gpio.c
@@ -513,8 +513,8 @@ static int pci1xxxx_gpio_probe(struct auxiliary_device *aux_dev,
static DEFINE_SIMPLE_DEV_PM_OPS(pci1xxxx_gpio_pm_ops, pci1xxxx_gpio_suspend, pci1xxxx_gpio_resume);
static const struct auxiliary_device_id pci1xxxx_gpio_auxiliary_id_table[] = {
- {.name = "mchp_pci1xxxx_gp.gp_gpio"},
- {}
+ { .name = "mchp_pci1xxxx_gp.gp_gpio" },
+ { }
};
MODULE_DEVICE_TABLE(auxiliary, pci1xxxx_gpio_auxiliary_id_table);
diff --git a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c
index a2ed477e0370..09841c4f1a06 100644
--- a/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c
+++ b/drivers/misc/mchp_pci1xxxx/mchp_pci1xxxx_otpe2p.c
@@ -419,8 +419,8 @@ static void pci1xxxx_otp_eeprom_remove(struct auxiliary_device *aux_dev)
}
static const struct auxiliary_device_id pci1xxxx_otp_eeprom_auxiliary_id_table[] = {
- {.name = "mchp_pci1xxxx_gp.gp_otp_e2p"},
- {},
+ { .name = "mchp_pci1xxxx_gp.gp_otp_e2p" },
+ { }
};
MODULE_DEVICE_TABLE(auxiliary, pci1xxxx_otp_eeprom_auxiliary_id_table);
diff --git a/drivers/misc/mei/pci-csc.c b/drivers/misc/mei/pci-csc.c
index 70792bf9b3c0..6e1e8008f267 100644
--- a/drivers/misc/mei/pci-csc.c
+++ b/drivers/misc/mei/pci-csc.c
@@ -240,7 +240,7 @@ static const struct dev_pm_ops mei_csc_pm_ops = {
static const struct pci_device_id mei_csc_pci_tbl[] = {
{ PCI_DEVICE_DATA(INTEL, MEI_CRI, MEI_ME_CSC_CFG) },
- {}
+ { }
};
MODULE_DEVICE_TABLE(pci, mei_csc_pci_tbl);
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 55e0b8a98827..790a4647811b 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -27,114 +27,114 @@
/* mei_pci_tbl - PCI Device ID Table */
static const struct pci_device_id mei_me_pci_tbl[] = {
- {PCI_DEVICE_DATA(INTEL, MEI_82946GZ, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_82G35, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_82Q965, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_82G965, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_82GM965, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_82GME965, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_82Q35, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_82G33, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_82Q33, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_82X38, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_3200, MEI_ME_ICH_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_82946GZ, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_82G35, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_82Q965, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_82G965, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_82GM965, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_82GME965, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_82Q35, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_82G33, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_82Q33, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_82X38, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_3200, MEI_ME_ICH_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_6, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_7, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_8, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_9, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9_10, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9M_1, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9M_2, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9M_3, MEI_ME_ICH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH9M_4, MEI_ME_ICH_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_6, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_7, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_8, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_9, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9_10, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9M_1, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9M_2, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9M_3, MEI_ME_ICH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH9M_4, MEI_ME_ICH_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_ICH10_1, MEI_ME_ICH10_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH10_2, MEI_ME_ICH10_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH10_3, MEI_ME_ICH10_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICH10_4, MEI_ME_ICH10_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH10_1, MEI_ME_ICH10_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH10_2, MEI_ME_ICH10_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH10_3, MEI_ME_ICH10_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICH10_4, MEI_ME_ICH10_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_IBXPK_1, MEI_ME_PCH6_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_IBXPK_2, MEI_ME_PCH6_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CPT_1, MEI_ME_PCH_CPT_PBG_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_PBG_1, MEI_ME_PCH_CPT_PBG_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_PPT_1, MEI_ME_PCH7_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_PPT_2, MEI_ME_PCH7_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_PPT_3, MEI_ME_PCH7_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_LPT_H, MEI_ME_PCH8_SPS_4_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_LPT_W, MEI_ME_PCH8_SPS_4_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_LPT_LP, MEI_ME_PCH8_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_LPT_HR, MEI_ME_PCH8_SPS_4_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_WPT_LP, MEI_ME_PCH8_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_WPT_LP_2, MEI_ME_PCH8_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_IBXPK_1, MEI_ME_PCH6_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_IBXPK_2, MEI_ME_PCH6_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CPT_1, MEI_ME_PCH_CPT_PBG_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_PBG_1, MEI_ME_PCH_CPT_PBG_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_PPT_1, MEI_ME_PCH7_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_PPT_2, MEI_ME_PCH7_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_PPT_3, MEI_ME_PCH7_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_LPT_H, MEI_ME_PCH8_SPS_4_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_LPT_W, MEI_ME_PCH8_SPS_4_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_LPT_LP, MEI_ME_PCH8_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_LPT_HR, MEI_ME_PCH8_SPS_4_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_WPT_LP, MEI_ME_PCH8_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_WPT_LP_2, MEI_ME_PCH8_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_SPT, MEI_ME_PCH8_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_SPT_2, MEI_ME_PCH8_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_SPT_3, MEI_ME_PCH8_ITOUCH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_SPT_H, MEI_ME_PCH8_SPS_4_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_SPT_H_2, MEI_ME_PCH8_SPS_4_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_LBG, MEI_ME_PCH12_SPS_4_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_SPT, MEI_ME_PCH8_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_SPT_2, MEI_ME_PCH8_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_SPT_3, MEI_ME_PCH8_ITOUCH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_SPT_H, MEI_ME_PCH8_SPS_4_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_SPT_H_2, MEI_ME_PCH8_SPS_4_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_LBG, MEI_ME_PCH12_SPS_4_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_BXT_M, MEI_ME_PCH8_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_APL_I, MEI_ME_PCH8_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_BXT_M, MEI_ME_PCH8_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_APL_I, MEI_ME_PCH8_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_DNV_IE, MEI_ME_PCH8_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_DNV_IE, MEI_ME_PCH8_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_GLK, MEI_ME_PCH8_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_GLK, MEI_ME_PCH8_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_KBP, MEI_ME_PCH8_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_KBP_2, MEI_ME_PCH8_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_KBP_3, MEI_ME_PCH8_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_KBP, MEI_ME_PCH8_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_KBP_2, MEI_ME_PCH8_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_KBP_3, MEI_ME_PCH8_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_CNP_LP, MEI_ME_PCH12_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CNP_LP_3, MEI_ME_PCH8_ITOUCH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CNP_H, MEI_ME_PCH12_SPS_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CNP_H_3, MEI_ME_PCH12_SPS_ITOUCH_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_CNP_LP, MEI_ME_PCH12_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CNP_LP_3, MEI_ME_PCH8_ITOUCH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CNP_H, MEI_ME_PCH12_SPS_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CNP_H_3, MEI_ME_PCH12_SPS_ITOUCH_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_CMP_LP, MEI_ME_PCH12_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CMP_LP_3, MEI_ME_PCH8_ITOUCH_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CMP_V, MEI_ME_PCH12_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CMP_H, MEI_ME_PCH12_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_CMP_H_3, MEI_ME_PCH8_ITOUCH_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_CMP_LP, MEI_ME_PCH12_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CMP_LP_3, MEI_ME_PCH8_ITOUCH_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CMP_V, MEI_ME_PCH12_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CMP_H, MEI_ME_PCH12_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_CMP_H_3, MEI_ME_PCH8_ITOUCH_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_ICP_LP, MEI_ME_PCH12_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ICP_N, MEI_ME_PCH12_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_ICP_LP, MEI_ME_PCH12_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ICP_N, MEI_ME_PCH12_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_TGP_LP, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_TGP_H, MEI_ME_PCH15_SPS_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_TGP_LP, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_TGP_H, MEI_ME_PCH15_SPS_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_JSP_N, MEI_ME_PCH15_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_JSP_N, MEI_ME_PCH15_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_MCC, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_MCC_4, MEI_ME_PCH8_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_MCC, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_MCC_4, MEI_ME_PCH8_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_CDF, MEI_ME_PCH8_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_CDF, MEI_ME_PCH8_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_EBG, MEI_ME_PCH15_SPS_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_EBG, MEI_ME_PCH15_SPS_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_ADP_S, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ADP_LP, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ADP_P, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ADP_N, MEI_ME_PCH15_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_ADP_S, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ADP_LP, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ADP_P, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ADP_N, MEI_ME_PCH15_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_RPL_S, MEI_ME_PCH15_SPS_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_RPL_S, MEI_ME_PCH15_SPS_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_MTL_M, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ARL_S, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_ARL_H, MEI_ME_PCH15_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_MTL_M, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ARL_S, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_ARL_H, MEI_ME_PCH15_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_LNL_M, MEI_ME_PCH15_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_LNL_M, MEI_ME_PCH15_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_PTL_H, MEI_ME_PCH15_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_PTL_P, MEI_ME_PCH15_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_PTL_H, MEI_ME_PCH15_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_PTL_P, MEI_ME_PCH15_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_WCL_P, MEI_ME_PCH15_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_WCL_P, MEI_ME_PCH15_CFG) },
- {PCI_DEVICE_DATA(INTEL, MEI_NVL_S, MEI_ME_PCH22_IOE_CFG)},
- {PCI_DEVICE_DATA(INTEL, MEI_NVL_H, MEI_ME_PCH15_CFG)},
+ { PCI_DEVICE_DATA(INTEL, MEI_NVL_S, MEI_ME_PCH22_IOE_CFG) },
+ { PCI_DEVICE_DATA(INTEL, MEI_NVL_H, MEI_ME_PCH15_CFG) },
/* required last entry */
- {0, }
+ { }
};
MODULE_DEVICE_TABLE(pci, mei_me_pci_tbl);
diff --git a/drivers/misc/mei/pci-txe.c b/drivers/misc/mei/pci-txe.c
index f5441bc5efe2..815ca72877ce 100644
--- a/drivers/misc/mei/pci-txe.c
+++ b/drivers/misc/mei/pci-txe.c
@@ -24,10 +24,10 @@
#include "hw-txe.h"
static const struct pci_device_id mei_txe_pci_tbl[] = {
- {PCI_VDEVICE(INTEL, 0x0F18)}, /* Baytrail */
- {PCI_VDEVICE(INTEL, 0x2298)}, /* Cherrytrail */
+ { PCI_VDEVICE(INTEL, 0x0F18) }, /* Baytrail */
+ { PCI_VDEVICE(INTEL, 0x2298) }, /* Cherrytrail */
- {0, }
+ { }
};
MODULE_DEVICE_TABLE(pci, mei_txe_pci_tbl);
diff --git a/drivers/misc/mrvl_cn10k_dpi.c b/drivers/misc/mrvl_cn10k_dpi.c
index 7d5433121ff6..29b7a4110300 100644
--- a/drivers/misc/mrvl_cn10k_dpi.c
+++ b/drivers/misc/mrvl_cn10k_dpi.c
@@ -658,7 +658,7 @@ static void dpi_remove(struct pci_dev *pdev)
static const struct pci_device_id dpi_id_table[] = {
{ PCI_DEVICE_SUB(PCI_VENDOR_ID_CAVIUM, PCI_DEVID_MRVL_CN10K_DPI_PF,
PCI_VENDOR_ID_CAVIUM, PCI_SUBDEVID_MRVL_CN10K_DPI_PF) },
- { 0, } /* end of table */
+ { } /* end of table */
};
static struct pci_driver dpi_driver = {
diff --git a/drivers/misc/nsm.c b/drivers/misc/nsm.c
index ef7b32742340..7940e80979a9 100644
--- a/drivers/misc/nsm.c
+++ b/drivers/misc/nsm.c
@@ -61,7 +61,7 @@ struct nsm {
/* NSM device ID */
static const struct virtio_device_id id_table[] = {
{ VIRTIO_ID_NITRO_SEC_MOD, VIRTIO_DEV_ANY_ID },
- { 0 },
+ { }
};
static struct nsm *file_to_nsm(struct file *file)
diff --git a/drivers/misc/ocxl/pci.c b/drivers/misc/ocxl/pci.c
index cb920aa88d3a..0cf38bd482a9 100644
--- a/drivers/misc/ocxl/pci.c
+++ b/drivers/misc/ocxl/pci.c
@@ -9,7 +9,7 @@
* vendor/device ID to help differentiate devices.
*/
static const struct pci_device_id ocxl_pci_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_IBM, 0x062B), },
+ { PCI_DEVICE(PCI_VENDOR_ID_IBM, 0x062B) },
{ }
};
MODULE_DEVICE_TABLE(pci, ocxl_pci_tbl);
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 3635741c3e7a..a10fce77e0b4 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -1416,18 +1416,18 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0),
.driver_data = (kernel_ulong_t)&default_data,
},
- { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_IMX8),},
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_IMX8) },
{ PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_LS1088A),
.driver_data = (kernel_ulong_t)&default_data,
},
{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
- .driver_data = (kernel_ulong_t)&am654_data
+ .driver_data = (kernel_ulong_t)&am654_data,
},
- { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774A1),},
- { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774B1),},
- { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774C0),},
- { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774E1),},
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774A1) },
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774B1) },
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774C0) },
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774E1) },
{ PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A779F0),
.driver_data = (kernel_ulong_t)&default_data,
},
@@ -1446,8 +1446,8 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_ROCKCHIP, PCI_DEVICE_ID_ROCKCHIP_RK3588),
.driver_data = (kernel_ulong_t)&rk3588_data,
},
- { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_TEGRA194_EP),},
- { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_TEGRA234_EP),},
+ { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_TEGRA194_EP) },
+ { PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_TEGRA234_EP) },
{ }
};
MODULE_DEVICE_TABLE(pci, pci_endpoint_test_tbl);
diff --git a/drivers/misc/phantom.c b/drivers/misc/phantom.c
index 34a5054a6b40..331cae539290 100644
--- a/drivers/misc/phantom.c
+++ b/drivers/misc/phantom.c
@@ -481,10 +481,10 @@ static int __maybe_unused phantom_resume(struct device *dev_d)
}
static struct pci_device_id phantom_pci_tbl[] = {
- { .vendor = PCI_VENDOR_ID_PLX, .device = PCI_DEVICE_ID_PLX_9050,
- .subvendor = PCI_VENDOR_ID_PLX, .subdevice = PCI_DEVICE_ID_PLX_9050,
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050,
+ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050),
.class = PCI_CLASS_BRIDGE_OTHER << 8, .class_mask = 0xffff00 },
- { 0, }
+ { }
};
MODULE_DEVICE_TABLE(pci, phantom_pci_tbl);
diff --git a/drivers/misc/pvpanic/pvpanic-pci.c b/drivers/misc/pvpanic/pvpanic-pci.c
index b21598a18f6d..572c6148a297 100644
--- a/drivers/misc/pvpanic/pvpanic-pci.c
+++ b/drivers/misc/pvpanic/pvpanic-pci.c
@@ -35,8 +35,8 @@ static int pvpanic_pci_probe(struct pci_dev *pdev, const struct pci_device_id *e
}
static const struct pci_device_id pvpanic_pci_id_tbl[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PVPANIC)},
- {}
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PVPANIC) },
+ { }
};
MODULE_DEVICE_TABLE(pci, pvpanic_pci_id_tbl);
diff --git a/drivers/misc/rp1/rp1_pci.c b/drivers/misc/rp1/rp1_pci.c
index 81685e3f3296..f5cdf05ae4ec 100644
--- a/drivers/misc/rp1/rp1_pci.c
+++ b/drivers/misc/rp1/rp1_pci.c
@@ -288,7 +288,7 @@ static void rp1_remove(struct pci_dev *pdev)
}
static const struct pci_device_id dev_id_table[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_RPI, PCI_DEVICE_ID_RPI_RP1_C0), },
+ { PCI_DEVICE(PCI_VENDOR_ID_RPI, PCI_DEVICE_ID_RPI_RP1_C0) },
{ }
};
MODULE_DEVICE_TABLE(pci, dev_id_table);
diff --git a/drivers/misc/vmw_vmci/vmci_guest.c b/drivers/misc/vmw_vmci/vmci_guest.c
index 476af89e751b..83355c0ec1d2 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -960,8 +960,8 @@ static void vmci_guest_remove_device(struct pci_dev *pdev)
}
static const struct pci_device_id vmci_ids[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_VMWARE, PCI_DEVICE_ID_VMWARE_VMCI), },
- { 0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_VMWARE, PCI_DEVICE_ID_VMWARE_VMCI) },
+ { }
};
MODULE_DEVICE_TABLE(pci, vmci_ids);
--
2.55.0.11.g153666a7d9bb
^ permalink raw reply related
* Re: [PATCH v2] powerpc/64s: Clarify copy_and_flush() cache sync loop comment
From: Mahesh J Salgaonkar @ 2026-07-17 14:52 UTC (permalink / raw)
To: Nikhil Kumar Singh
Cc: linuxppc-dev, mkchauras, linux-kernel, maddy, mpe, npiggin,
chleroy, adityag
In-Reply-To: <20260706082708.43918-1-nikhilks@linux.ibm.com>
On 2026-07-06 13:57:08 Mon, Nikhil Kumar Singh wrote:
> The value loaded into r0 in copy_and_flush() represents the number of
> 8-byte words processed between cache synchronization operations.
>
> The existing comment refers to cache line size, which can make it appear
> that the value is a cache line size in bytes rather than a loop count.
> Clarify the comment to explain that the loop processes 8 words (64 bytes)
> per cache synchronization iteration, and that increasing the value would
> skip cache maintenance for intermediate cache lines.
>
> This is a comment-only change with no functional impact.
>
> Signed-off-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
> ---
> arch/powerpc/kernel/head_64.S | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 63432a33ec49..a54f6f979173 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -713,14 +713,18 @@ p_end: .8byte _end - copy_to_here
> _GLOBAL(copy_and_flush)
> addi r5,r5,-8
> addi r6,r6,-8
> -4: li r0,8 /* Use the smallest common */
> - /* denominator cache line */
> - /* size. This results in */
> - /* extra cache line flushes */
> - /* but operation is correct. */
> - /* Can't get cache line size */
> - /* from NACA as it is being */
> - /* moved too. */
> +4: li r0,8 /* r0 is the number of 8-byte words */
> + /* to copy per cache sync iteration. */
> + /* 8 words * 8 bytes = 64 bytes. 64B is */
> + /* the current default cache line size. */
> + /* This is a loop count, not a byte */
> + /* count. Increasing it may skip */
> + /* dcbst/icbi for lines in between and */
> + /* leave stale instructions in icache. */
> + /* This results in extra cache line */
> + /* flushes but operation is correct. */
> + /* Can't get cache line size from NACA */
> + /* as it is being moved too. */
Looks good to me. The previous comment was misleading which makes one to
think r0 as cache line size which is not the case.
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Thanks,
-Mahesh.
^ permalink raw reply
* Re: [PATCH] KVM: Use vma_lookup() in kvm_host_page_size()
From: Gautam Menghani @ 2026-07-17 15:04 UTC (permalink / raw)
To: David Woodhouse
Cc: Paolo Bonzini, kvm, linux-kernel, Madhavan Srinivasan,
Nicholas Piggin, Michael Ellerman, Christophe Leroy (CS GROUP),
linuxppc-dev
In-Reply-To: <71775f561c4b7fb23b7af0725c6ce232a4b27b20.camel@infradead.org>
On Sun, Jul 05, 2026 at 09:38:17AM +0100, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
>
> kvm_host_page_size() uses find_vma() to determine the host page size
> backing a guest page. find_vma() returns the next VMA when the address
> falls in an unmapped hole, which means an unmapped address inherits the
> page size of a completely unrelated VMA at a higher address. This is
> never a meaningful result.
>
> Replace find_vma() with vma_lookup() so that a hole address returns
> NULL, causing the function to return PAGE_SIZE (the safe default)
> rather than an unrelated VMA's page size.
>
> This is currently only cosmetic, as the only caller is in PPC book3s
> support (kvmppc_xive_native_set_queue_config()) and subsequently returns
> failure if !gfn_to_page() anyway.
>
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
> virt/kvm/kvm_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 89489996fbc1..d33761123459 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2693,7 +2693,7 @@ unsigned long kvm_host_page_size(struct kvm_vcpu *vcpu, gfn_t gfn)
> return PAGE_SIZE;
>
> mmap_read_lock(current->mm);
> - vma = find_vma(current->mm, addr);
> + vma = vma_lookup(current->mm, addr);
> if (!vma)
> goto out;
>
> --
> 2.43.0
>
LGTM, thanks for the patch.
I did some sanity testing for this with KVM on PowerNV system.
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH 01/42] of: reserved_mem: Introduce devres-managed initialization functions
From: Mukesh Ojha @ 2026-07-17 15:37 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, Konrad Dybcio, Liviu Dudau, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Joel Stanley, Andrew Jeffery, Paul Cercueil, Anitha Chrisanthus,
Paul Kocialkowski, Linus Walleij, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Alexey Brodkin, Laurent Pinchart, Tomi Valkeinen,
Michal Simek, Daniel Scally, Jacopo Mondi, Mauro Carvalho Chehab,
Eddie James, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Minghsiu Tsai, Houlong Wei, Matthias Brugger,
AngeloGioacchino Del Regno, Joseph Liu, Marvin Lin,
Dmitry Osipenko, Krzysztof Kozlowski, Thierry Reding,
Jonathan Hunter, Srinivas Kandagatla, Arnd Bergmann,
Greg Kroah-Hartman, Ge Gordon, Adrian Hunter, Ulf Hansson,
Saravana Kannan, Mathieu Poirier, Jaroslav Kysela, Takashi Iwai,
Shengjiu Wang, Xiubo Li, Liam Girdwood, Mark Brown, Frank Li,
Sascha Hauer, Peter Ujfalusi, Bard Liao, Daniel Baluta,
Orson Zhai, Baolin Wang, Peter Chen, Fugang Duan, Ekansh Gupta,
BST Linux Kernel Upstream Group, Fabio Estevam, Nicolin Chen,
Pengutronix Kernel Team, Kai Vehmanen, Pierre-Louis Bossart,
Vijendar Mukunda, Chunyan Zhang, CIX Linux Kernel Upstream Group,
linux-arm-msm, linux-kernel, dri-devel, linux-aspeed,
linux-arm-kernel, linux-mips, linux-sunxi, linux-media, openbmc,
linux-mediatek, kernel, linux-tegra, linux-mmc, devicetree,
linux-remoteproc, linux-staging, linux-sound, linuxppc-dev, imx,
sound-open-firmware, Konrad Dybcio
In-Reply-To: <20260716200048.GA1183026-robh@kernel.org>
On Thu, Jul 16, 2026 at 03:00:48PM -0500, Rob Herring wrote:
> On Sat, Jul 04, 2026 at 01:08:14AM +0530, Mukesh Ojha wrote:
> > From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> >
> > Introduce devres-based helpers for of_reserved_mem_device_init(_by_idx)
> > to help fight dangling references and ever so slightly reduce the
> > number of boilerplate deinitialization calls.
> >
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
> > drivers/of/of_reserved_mem.c | 41 +++++++++++++++++++++++++++++++++
> > include/linux/of_reserved_mem.h | 25 ++++++++++++++++++++
> > 2 files changed, 66 insertions(+)
> >
> > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > index 82222bd45ac6..b35541e9fbe8 100644
> > --- a/drivers/of/of_reserved_mem.c
> > +++ b/drivers/of/of_reserved_mem.c
> > @@ -787,6 +787,47 @@ void of_reserved_mem_device_release(struct device *dev)
> > }
> > EXPORT_SYMBOL_GPL(of_reserved_mem_device_release);
> >
> > +static void devm_of_reserved_mem_device_release(struct device *dev, void *res)
> > +{
> > + of_reserved_mem_device_release(*(struct device **)res);
> > +}
> > +
> > +/**
> > + * devm_of_reserved_mem_device_init_by_idx() - Resource managed of_reserved_mem_device_init_by_idx()
> > + * @dev: Pointer to the device to configure
> > + * @np: Pointer to the device node with 'memory-region' property
> > + * @idx: Index of selected region
> > + *
> > + * This is a resource managed version of of_reserved_mem_device_init_by_idx().
> > + * The reserved memory region will be released automatically when the device
> > + * is unbound.
> > + *
> > + * Returns: Negative errno on failure or zero on success.
> > + */
> > +int devm_of_reserved_mem_device_init_by_idx(struct device *dev,
> > + struct device_node *np, int idx)
>
> It looks to me like the only 2? users of this could be converted to
> devm_of_reserved_mem_device_init() instead. The mmc one obviously can.
> The imx one depends if np is dev->of_node. I'm not a fan of APIs with
> only a few users.
You are right, mmc can be but imx can't. I can make this static and drop
the API usage from imx but fix the leak by release function.
--
-Mukesh Ojha
^ permalink raw reply
* [PATCH] USB: phy: fsl-usb: fix missing static keywords
From: Johan Hovold @ 2026-07-17 15:49 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-usb, linuxppc-dev, linux-kernel, Johan Hovold, stable,
Mark Brown
A recent change enabling compile testing of a Freescale dual-role
controller indirectly enabled a USB PHY driver to be built. That driver
in turn is missing a bunch of static keywords which results in warnings
like:
drivers/usb/phy/phy-fsl-usb.c:105:5: error: no previous prototype for 'write_ulpi' [-Werror=missing-prototypes]
105 | int write_ulpi(u8 addr, u8 data)
| ^~~~~~~~~~
which consequently breaks -Werror builds.
Add the missing static keywords.
Fixes: 0807c500a1a6 ("USB: add Freescale USB OTG Transceiver driver")
Cc: stable@vger.kernel.org # 3.0
Reported-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/4f9f5ff9-8eaa-4bd5-9331-37119f78e13f@sirena.org.uk
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/usb/phy/phy-fsl-usb.c | 52 +++++++++++++++++------------------
drivers/usb/phy/phy-fsl-usb.h | 6 ++--
2 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
index 35d79f11b03d..1986f7e9d9be 100644
--- a/drivers/usb/phy/phy-fsl-usb.c
+++ b/drivers/usb/phy/phy-fsl-usb.c
@@ -46,7 +46,7 @@
static const char driver_name[] = "fsl-usb2-otg";
-const pm_message_t otg_suspend_state = {
+static const pm_message_t otg_suspend_state = {
.event = 1,
};
@@ -57,11 +57,11 @@ static struct fsl_otg *fsl_otg_dev;
static int srp_wait_done;
/* FSM timers */
-struct fsl_otg_timer *a_wait_vrise_tmr, *a_wait_bcon_tmr, *a_aidl_bdis_tmr,
+static struct fsl_otg_timer *a_wait_vrise_tmr, *a_wait_bcon_tmr, *a_aidl_bdis_tmr,
*b_ase0_brst_tmr, *b_se0_srp_tmr;
/* Driver specific timers */
-struct fsl_otg_timer *b_data_pulse_tmr, *b_vbus_pulse_tmr, *b_srp_fail_tmr,
+static struct fsl_otg_timer *b_data_pulse_tmr, *b_vbus_pulse_tmr, *b_srp_fail_tmr,
*b_srp_wait_tmr, *a_wait_enum_tmr;
static struct list_head active_timers;
@@ -102,7 +102,7 @@ static void (*_fsl_writel)(u32 v, unsigned __iomem *p);
#define fsl_writel(val, addr) writel(val, addr)
#endif /* CONFIG_PPC32 */
-int write_ulpi(u8 addr, u8 data)
+static int write_ulpi(u8 addr, u8 data)
{
u32 temp;
@@ -115,7 +115,7 @@ int write_ulpi(u8 addr, u8 data)
/* Operations that will be called from OTG Finite State Machine */
/* Charge vbus for vbus pulsing in SRP */
-void fsl_otg_chrg_vbus(struct otg_fsm *fsm, int on)
+static void fsl_otg_chrg_vbus(struct otg_fsm *fsm, int on)
{
u32 tmp;
@@ -133,7 +133,7 @@ void fsl_otg_chrg_vbus(struct otg_fsm *fsm, int on)
}
/* Discharge vbus through a resistor to ground */
-void fsl_otg_dischrg_vbus(int on)
+static void fsl_otg_dischrg_vbus(int on)
{
u32 tmp;
@@ -151,7 +151,7 @@ void fsl_otg_dischrg_vbus(int on)
}
/* A-device driver vbus, controlled through PP bit in PORTSC */
-void fsl_otg_drv_vbus(struct otg_fsm *fsm, int on)
+static void fsl_otg_drv_vbus(struct otg_fsm *fsm, int on)
{
u32 tmp;
@@ -169,7 +169,7 @@ void fsl_otg_drv_vbus(struct otg_fsm *fsm, int on)
* Pull-up D+, signalling connect by periperal. Also used in
* data-line pulsing in SRP
*/
-void fsl_otg_loc_conn(struct otg_fsm *fsm, int on)
+static void fsl_otg_loc_conn(struct otg_fsm *fsm, int on)
{
u32 tmp;
@@ -188,7 +188,7 @@ void fsl_otg_loc_conn(struct otg_fsm *fsm, int on)
* port. In host mode, controller will automatically send SOF.
* Suspend will block the data on the port.
*/
-void fsl_otg_loc_sof(struct otg_fsm *fsm, int on)
+static void fsl_otg_loc_sof(struct otg_fsm *fsm, int on)
{
u32 tmp;
@@ -203,7 +203,7 @@ void fsl_otg_loc_sof(struct otg_fsm *fsm, int on)
}
/* Start SRP pulsing by data-line pulsing, followed with v-bus pulsing. */
-void fsl_otg_start_pulse(struct otg_fsm *fsm)
+static void fsl_otg_start_pulse(struct otg_fsm *fsm)
{
u32 tmp;
@@ -219,7 +219,7 @@ void fsl_otg_start_pulse(struct otg_fsm *fsm)
fsl_otg_add_timer(fsm, b_data_pulse_tmr);
}
-void b_data_pulse_end(unsigned long foo)
+static void b_data_pulse_end(unsigned long foo)
{
#ifdef HA_DATA_PULSE
#else
@@ -230,7 +230,7 @@ void b_data_pulse_end(unsigned long foo)
fsl_otg_pulse_vbus();
}
-void fsl_otg_pulse_vbus(void)
+static void fsl_otg_pulse_vbus(void)
{
srp_wait_done = 0;
fsl_otg_chrg_vbus(&fsl_otg_dev->fsm, 1);
@@ -238,7 +238,7 @@ void fsl_otg_pulse_vbus(void)
fsl_otg_add_timer(&fsl_otg_dev->fsm, b_vbus_pulse_tmr);
}
-void b_vbus_pulse_end(unsigned long foo)
+static void b_vbus_pulse_end(unsigned long foo)
{
fsl_otg_chrg_vbus(&fsl_otg_dev->fsm, 0);
@@ -251,7 +251,7 @@ void b_vbus_pulse_end(unsigned long foo)
fsl_otg_add_timer(&fsl_otg_dev->fsm, b_srp_wait_tmr);
}
-void b_srp_end(unsigned long foo)
+static void b_srp_end(unsigned long foo)
{
fsl_otg_dischrg_vbus(0);
srp_wait_done = 1;
@@ -266,7 +266,7 @@ void b_srp_end(unsigned long foo)
* a_host will start by SRP. It needs to set b_hnp_enable before
* actually suspending to start HNP
*/
-void a_wait_enum(unsigned long foo)
+static void a_wait_enum(unsigned long foo)
{
VDBG("a_wait_enum timeout\n");
if (!fsl_otg_dev->phy.otg->host->b_hnp_enable)
@@ -276,13 +276,13 @@ void a_wait_enum(unsigned long foo)
}
/* The timeout callback function to set time out bit */
-void set_tmout(unsigned long indicator)
+static void set_tmout(unsigned long indicator)
{
*(int *)indicator = 1;
}
/* Initialize timers */
-int fsl_otg_init_timers(struct otg_fsm *fsm)
+static int fsl_otg_init_timers(struct otg_fsm *fsm)
{
/* FSM used timers */
a_wait_vrise_tmr = otg_timer_initializer(&set_tmout, TA_WAIT_VRISE,
@@ -339,7 +339,7 @@ int fsl_otg_init_timers(struct otg_fsm *fsm)
}
/* Uninitialize timers */
-void fsl_otg_uninit_timers(void)
+static void fsl_otg_uninit_timers(void)
{
/* FSM used timers */
kfree(a_wait_vrise_tmr);
@@ -391,7 +391,7 @@ static struct fsl_otg_timer *fsl_otg_get_timer(enum otg_fsm_timer t)
}
/* Add timer to timer list */
-void fsl_otg_add_timer(struct otg_fsm *fsm, void *gtimer)
+static void fsl_otg_add_timer(struct otg_fsm *fsm, void *gtimer)
{
struct fsl_otg_timer *timer = gtimer;
struct fsl_otg_timer *tmp_timer;
@@ -421,7 +421,7 @@ static void fsl_otg_fsm_add_timer(struct otg_fsm *fsm, enum otg_fsm_timer t)
}
/* Remove timer from the timer list; clear timeout status */
-void fsl_otg_del_timer(struct otg_fsm *fsm, void *gtimer)
+static void fsl_otg_del_timer(struct otg_fsm *fsm, void *gtimer)
{
struct fsl_otg_timer *timer = gtimer;
struct fsl_otg_timer *tmp_timer, *del_tmp;
@@ -443,7 +443,7 @@ static void fsl_otg_fsm_del_timer(struct otg_fsm *fsm, enum otg_fsm_timer t)
}
/* Reset controller, not reset the bus */
-void otg_reset_controller(void)
+static void otg_reset_controller(void)
{
u32 command;
@@ -455,7 +455,7 @@ void otg_reset_controller(void)
}
/* Call suspend/resume routines in host driver */
-int fsl_otg_start_host(struct otg_fsm *fsm, int on)
+static int fsl_otg_start_host(struct otg_fsm *fsm, int on)
{
struct usb_otg *otg = fsm->otg;
struct device *dev;
@@ -522,7 +522,7 @@ int fsl_otg_start_host(struct otg_fsm *fsm, int on)
* Call suspend and resume function in udc driver
* to stop and start udc driver.
*/
-int fsl_otg_start_gadget(struct otg_fsm *fsm, int on)
+static int fsl_otg_start_gadget(struct otg_fsm *fsm, int on)
{
struct usb_otg *otg = fsm->otg;
struct device *dev;
@@ -704,7 +704,7 @@ static int fsl_otg_start_hnp(struct usb_otg *otg)
* intact. It needs to have knowledge of some USB interrupts
* such as port change.
*/
-irqreturn_t fsl_otg_isr(int irq, void *dev_id)
+static irqreturn_t fsl_otg_isr(int irq, void *dev_id)
{
struct otg_fsm *fsm = &((struct fsl_otg *)dev_id)->fsm;
struct usb_otg *otg = ((struct fsl_otg *)dev_id)->phy.otg;
@@ -830,7 +830,7 @@ static int fsl_otg_conf(struct platform_device *pdev)
}
/* OTG Initialization */
-int usb_otg_start(struct platform_device *pdev)
+static int usb_otg_start(struct platform_device *pdev)
{
struct fsl_otg *p_otg;
struct usb_phy *otg_trans = usb_get_phy(USB_PHY_TYPE_USB2);
@@ -1002,7 +1002,7 @@ static void fsl_otg_remove(struct platform_device *pdev)
pdata->exit(pdev);
}
-struct platform_driver fsl_otg_driver = {
+static struct platform_driver fsl_otg_driver = {
.probe = fsl_otg_probe,
.remove = fsl_otg_remove,
.driver = {
diff --git a/drivers/usb/phy/phy-fsl-usb.h b/drivers/usb/phy/phy-fsl-usb.h
index 95bfe7f1b83a..b754077875c3 100644
--- a/drivers/usb/phy/phy-fsl-usb.h
+++ b/drivers/usb/phy/phy-fsl-usb.h
@@ -373,6 +373,6 @@ struct fsl_otg_config {
#define FSL_OTG_NAME "fsl-usb2-otg"
-void fsl_otg_add_timer(struct otg_fsm *fsm, void *timer);
-void fsl_otg_del_timer(struct otg_fsm *fsm, void *timer);
-void fsl_otg_pulse_vbus(void);
+static void fsl_otg_add_timer(struct otg_fsm *fsm, void *timer);
+static void fsl_otg_del_timer(struct otg_fsm *fsm, void *timer);
+static void fsl_otg_pulse_vbus(void);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 35/60] kvm: Add VCPU plane-scheduling state and helpers
From: James Bottomley @ 2026-07-17 15:56 UTC (permalink / raw)
To: Saenz Julienne, Nicolas, Jörg Rödel, Paolo Bonzini
Cc: Sean Christopherson, Tom Lendacky, ashish.kalra@amd.com,
michael.roth@amd.com, Orazgaliyeva, Anel, Melody Wang,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
kvmarm@lists.linux.dev, loongarch@lists.linux.dev,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
kvm-riscv@lists.infradead.org, x86@kernel.org,
coconut-svsm@lists.linux.dev, joerg.roedel@amd.com
In-Reply-To: <DK0W6G329B6W.2KGT7FAVSKNYS@amazon.com>
On Fri, 2026-07-17 at 13:48 +0000, Saenz Julienne, Nicolas wrote:
> Hi Joerg, I'm a bit late to the discussion hope it helps nonetheless,
>
> On Tue Jun 9, 2026 at 2:37 PM CEST, Jörg Rödel wrote:
> > CAUTION: This email originated from outside of the organization. Do
> > not click links or open attachments unless you can confirm the
> > sender and know the content is safe.
> >
> > > The idea of the userspace scheduling was that you're not forced
> > > to use it - the kernel can always choose to override it if it's
> > > using an accelerated implementation of planes (and of plane
> > > switching). But it also leaves some leeway to different
> > > accelerated implementations, each of which can pick their own
> > > algorithm.
> > >
> > > Conceptually I'd rather keep the possibility of userspace
> > > scheduling. But maybe it doesn't add much.
> >
> > My preference is to keep plane scheduling at one place (in the
> > kernel) to keep it simple. But if you see a need for user-mode to
> > interact there as well (only really works for VSM), then I can add
> > it.
>
> The responsibility split we had in mind when we built a VSM emulation
> prototype [1] was to keep all VTL policing in user-space. This
> includes VTL switching, Cross VTL IPIs, Intercepts (Memory, MSRs,
> Insns, CPU regs), VTL aware SMP bring-up, etc. Even with KVM Planes
> in place, my thinking was to keep it as such. While all this could be
> implemented in the kernel, in practical terms, I think it'll be
> easier to get VSM support upstream the more we move the
> implementation into user-space.
I looked at the kernel bit. The vsm/dev branch contains 72 patches
over 6.12 which is quite a lot ...
However, from a quick skim, the main thing is that you used multiple
KVM structures to manage the planes which means each plane naturally
gets its own address space. In the current planes model so far there's
only one address space (or two if you have SMM). SNP doesn't need
anything above this because the VMPL protection is naturally managed
inside the guest (so not really visible to the host) but a VTL
implementation will. So I think the big question becomes how are we
going to achieve address space separation for planes? It's tempting to
say simply one address space per plane and make SMM its own plane with
different switching but it's an awful lot of overhead especially as
most VMs won't even use planes, so it looks like there has to be a more
opportunistic model for planes address spaces.
> More importantly, I think the area of Virtualization Based Security
> would benefit from a versatile Planes implementation. Forcing
> specific plane switching semantics might prevent the introduction VSM
> alternatives or extensions. Heki and lVBS come to mind here.
>
> > I read a bit more about VSM and it seems their prioritization of
> > VTLs is a bit more complicated. VTL0 has the least privileges but
> > boots first, then sets up VTL1. But VTL1 is only higher-privileged
> > once it is locked by VTL0. Another way to look at it is that VTL0
> > de-prioritizes itself.
> >
> > The patches here are built around the assumption that plane0 is the
> > highest privileged one and is always runnable. Running any lower-
> > privilege plane must be triggered by the guest. This is clearly not
> > sufficient for VSM, the question is how to solve that.
>
> I'd suggest inverting the priorities, with higher planes being more
> privileged. It'll make introducing higher privilege levels easier.
> This is especially useful with VSM, where it's not possible to know
> how many levels will be enabled before launching the VM.
I already addressed this in a different reply
https://lore.kernel.org/kvm/570f82e8b8bc968a31a4ba859145f6c324e41247.camel@HansenPartnership.com/
but basically I think hierarchical privilege will be too limiting. I
agree we need to have enough primitives to bring up hierarchical VSMs
if that's what the guest wants (Windows definitely will) but this
shouldn't be the only thing we can arrange planes as. The mutually
distrusting model has a lot going for it in terms of security
properties.
Regards,
James
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-7.2-2 tag
From: pr-tracker-bot @ 2026-07-17 15:57 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: Linus Torvalds, amachhiw, chleroy, christophe.leroy, enelsonmoore,
gautam, linux-kernel, linuxppc-dev, moonafterrain, mpe, naveen,
npiggin, rosenp, sshegde, thorsten.blum
In-Reply-To: <65137690-360f-424a-b2f2-b62d5f40ee31@linux.ibm.com>
The pull request you sent on Fri, 17 Jul 2026 10:31:13 +0530:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-7.2-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6917aa77675f48e7bd33392ed6590c8837001697
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [PATCH 6.6.y 0/6] cBPF JIT spray hardening
From: Pawan Gupta @ 2026-07-17 17:05 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann, Dave Hansen
Hi,
These backports harden BPF JIT against spectre-v2 class of attacks. Without
a predictor flush, execution of new BPF program may use stale prediction
left behind by the freed one.
To avoid this, issue an IBPB flush on all CPUs on JIT program allocation.
The flush is conditional to spectre-v2 mitigation applied.
Patch 1-2: Adds the predictor flush hook and enables it on x86 via IBPB.
bpf: Support for hardening against JIT spraying
x86/bugs: Enable IBPB flush on BPF JIT allocation
Patch 3-6: Narrow the flush to only unprivileged JIT allocations
to avoid redundant flushes. Also adds pack-selection changes
that minimizes flushes.
bpf: Restrict JIT predictor flush to cBPF
bpf: Skip redundant IBPB in pack allocator
bpf: Prefer packs that won't trigger an IBPB flush on allocation
bpf: Prefer dirty packs for eBPF allocations
---
Pawan Gupta (6):
bpf: Support for hardening against JIT spraying
x86/bugs: Enable IBPB flush on BPF JIT allocation
bpf: Restrict JIT predictor flush to cBPF
bpf: Skip redundant IBPB in pack allocator
bpf: Prefer packs that won't trigger an IBPB flush on allocation
bpf: Prefer dirty packs for eBPF allocations
arch/riscv/net/bpf_jit_core.c | 3 +-
arch/x86/include/asm/nospec-branch.h | 4 +++
arch/x86/kernel/cpu/bugs.c | 50 +++++++++++++++++++++++---
arch/x86/net/bpf_jit_comp.c | 3 +-
include/linux/filter.h | 15 ++++++--
kernel/bpf/core.c | 68 ++++++++++++++++++++++++++++++++----
kernel/bpf/dispatcher.c | 2 +-
7 files changed, 129 insertions(+), 16 deletions(-)
---
base-commit: da47cbc254661aa66d61ef061485a7080305c4be
change-id: 20260716-cbpf-jit-spray-hardening-6-6-y-ac66e7f4237d
Best regards,
--
Pawan
^ permalink raw reply
* [PATCH 6.6.y 1/6] bpf: Support for hardening against JIT spraying
From: Pawan Gupta @ 2026-07-17 17:05 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20260717-cbpf-jit-spray-hardening-6-6-y-v1-0-e04f1b2893de@linux.intel.com>
commit 96cce16e26dd02a8678f1e87f88a4b5cdb63b995 upstream.
The BPF JIT allocator packs many small programs into larger executable
allocations and reuses space within those allocations as programs are
loaded and freed. When fresh code is written into space that a previous
program occupied, an indirect jump into the new program can reuse a branch
prediction left behind by the old one.
Flush the indirect branch predictors before reusing JIT memory so that
indirect jumps into a newly written program don't reuse predictions from an
old program that occupied the same space.
Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush
static call for flushing the branch predictors on JIT memory reuse.
Architectures that need a flush, can update it to a predictor flush
function. By default, its a NOP and does not emit any CALL.
Allocations larger than a pack are not covered by this flush. That is safe
because cBPF programs (the unprivileged attack surface) are bounded well
below a pack size. Issue a warning if this assumption is ever violated
while the flush is active.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/linux/filter.h | 10 ++++++++++
kernel/bpf/core.c | 19 +++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 30fe140d4888..72926bc394ad 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -22,6 +22,7 @@
#include <linux/vmalloc.h>
#include <linux/sockptr.h>
#include <crypto/sha1.h>
+#include <linux/static_call.h>
#include <linux/u64_stats_sync.h>
#include <net/sch_generic.h>
@@ -1041,6 +1042,15 @@ extern long bpf_jit_limit_max;
typedef void (*bpf_jit_fill_hole_t)(void *area, unsigned int size);
+/*
+ * Flush the indirect branch predictors before reusing JIT memory, so that
+ * indirect jumps into a newly written program don't reuse predictions left
+ * behind by an old program that occupied the same space.
+ */
+void bpf_arch_pred_flush(void);
+DECLARE_STATIC_CALL(bpf_arch_pred_flush, bpf_arch_pred_flush);
+DECLARE_STATIC_KEY_FALSE(bpf_pred_flush_enabled);
+
void bpf_jit_fill_hole_with_zero(void *area, unsigned int size);
struct bpf_binary_header *
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index d708cf3e6207..0d8008711629 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -37,6 +37,7 @@
#include <linux/nospec.h>
#include <linux/bpf_mem_alloc.h>
#include <linux/memcontrol.h>
+#include <linux/static_call.h>
#include <asm/barrier.h>
#include <asm/unaligned.h>
@@ -858,6 +859,15 @@ void bpf_jit_fill_hole_with_zero(void *area, unsigned int size)
memset(area, 0, size);
}
+DEFINE_STATIC_CALL_NULL(bpf_arch_pred_flush, bpf_arch_pred_flush);
+
+/*
+ * Enabled once bpf_arch_pred_flush points at a real flush routine. Lets the
+ * pack allocator test "is a predictor flush wired up at all" with a cheap
+ * static branch instead of repeatedly querying the static call target.
+ */
+DEFINE_STATIC_KEY_FALSE(bpf_pred_flush_enabled);
+
#define BPF_PROG_SIZE_TO_NBITS(size) (round_up(size, BPF_PROG_CHUNK_SIZE) / BPF_PROG_CHUNK_SIZE)
static DEFINE_MUTEX(pack_mutex);
@@ -910,6 +920,14 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
mutex_lock(&pack_mutex);
if (size > BPF_PROG_PACK_SIZE) {
+ /*
+ * Allocations larger than a pack get their own pages, and
+ * predictors are not flushed for such allocation. This is only
+ * safe because cBPF programs (the unprivileged attack surface)
+ * are bounded well below a pack size.
+ */
+ if (static_branch_unlikely(&bpf_pred_flush_enabled))
+ pr_warn_once("BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\n");
size = round_up(size, PAGE_SIZE);
ptr = bpf_jit_alloc_exec(size);
if (ptr) {
@@ -933,6 +951,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
pos = 0;
found_free_area:
+ static_call_cond(bpf_arch_pred_flush)();
bitmap_set(pack->bitmap, pos, nbits);
ptr = (void *)(pack->ptr) + (pos << BPF_PROG_CHUNK_SHIFT);
--
2.43.0
^ permalink raw reply related
* [PATCH 6.6.y 2/6] x86/bugs: Enable IBPB flush on BPF JIT allocation
From: Pawan Gupta @ 2026-07-17 17:06 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann, Dave Hansen
In-Reply-To: <20260717-cbpf-jit-spray-hardening-6-6-y-v1-0-e04f1b2893de@linux.intel.com>
commit a3af84b0fa00ead01fcd0e28b5d773ff25990a0d upstream.
Enable hardening against JIT spraying when Spectre-v2 mitigations are in
use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip
enabling the IBPB flush if the BPF dispatcher is already using a retpoline
sequence.
This hardening applies only when BPF-JIT is in use. Guard the enabling
under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n.
[ pawan: Use entry_ibpb() instead of write_ibpb(). JIT hardening enable
moved to spectre_v2_select_mitigation() because there is no
spectre_v2_apply_mitigation()]
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
arch/x86/include/asm/nospec-branch.h | 4 +++
arch/x86/kernel/cpu/bugs.c | 50 ++++++++++++++++++++++++++++++++----
2 files changed, 49 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/nospec-branch.h b/arch/x86/include/asm/nospec-branch.h
index fb469ace3839..c7d019b0ef4a 100644
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -418,6 +418,10 @@ extern void srso_alias_untrain_ret(void);
extern void entry_untrain_ret(void);
extern void entry_ibpb(void);
+#ifdef CONFIG_BPF_JIT
+extern void bpf_arch_ibpb(void);
+#endif
+
#ifdef CONFIG_X86_64
extern void clear_bhb_loop(void);
#endif
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index ef1d3a5024ed..32a27c19acde 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -16,6 +16,7 @@
#include <linux/sched/smt.h>
#include <linux/pgtable.h>
#include <linux/bpf.h>
+#include <linux/filter.h>
#include <asm/spec-ctrl.h>
#include <asm/cmdline.h>
@@ -1360,8 +1361,21 @@ static inline const char *spectre_v2_module_string(void)
{
return spectre_v2_bad_module ? " - vulnerable module loaded" : "";
}
+
+/*
+ * The "retpoline sequence" is the "call;mov;ret" sequence that
+ * replaces normal indirect branch instructions. Differentiate
+ * *the* retpoline sequence from the LFENCE-prefixed indirect
+ * branches that simply use the retpoline infrastructure.
+ */
+static inline bool retpoline_seq_enabled(void)
+{
+ return boot_cpu_has(X86_FEATURE_RETPOLINE) && !boot_cpu_has(X86_FEATURE_RETPOLINE_LFENCE);
+}
+
#else
static inline const char *spectre_v2_module_string(void) { return ""; }
+static inline bool retpoline_seq_enabled(void) { return false; }
#endif
#define SPECTRE_V2_LFENCE_MSG "WARNING: LFENCE mitigation is not recommended for this CPU, data leaks possible!\n"
@@ -1835,8 +1849,7 @@ static void __init bhi_select_mitigation(void)
return;
/* Retpoline mitigates against BHI unless the CPU has RRSBA behavior */
- if (boot_cpu_has(X86_FEATURE_RETPOLINE) &&
- !boot_cpu_has(X86_FEATURE_RETPOLINE_LFENCE)) {
+ if (retpoline_seq_enabled()) {
spec_ctrl_disable_kernel_rrsba();
if (rrsba_disabled)
return;
@@ -1858,6 +1871,27 @@ static void __init bhi_select_mitigation(void)
pr_info("Spectre BHI mitigation: SW BHB clearing on syscall\n");
}
+#ifdef CONFIG_BPF_JIT
+static void __bpf_arch_ibpb(void *unused)
+{
+ entry_ibpb();
+}
+
+void bpf_arch_ibpb(void)
+{
+ on_each_cpu(__bpf_arch_ibpb, NULL, 1);
+}
+
+static bool __init cpu_wants_ibpb_bpf(void)
+{
+ /* A genuine retpoline already neutralizes ring0 indirect predictions */
+ if (retpoline_seq_enabled())
+ return false;
+
+ return boot_cpu_has(X86_FEATURE_IBPB);
+}
+#endif
+
static void __init spectre_v2_select_mitigation(void)
{
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
@@ -2041,6 +2075,14 @@ static void __init spectre_v2_select_mitigation(void)
pr_info("Enabling Restricted Speculation for firmware calls\n");
}
+#ifdef CONFIG_BPF_JIT
+ if (cpu_wants_ibpb_bpf()) {
+ static_call_update(bpf_arch_pred_flush, bpf_arch_ibpb);
+ static_branch_enable(&bpf_pred_flush_enabled);
+ pr_info("Enabling IBPB for BPF\n");
+ }
+#endif
+
/* Set up IBPB and STIBP depending on the general spectre V2 command */
spectre_v2_cmd = cmd;
}
@@ -3210,9 +3252,7 @@ static const char *spectre_bhi_state(void)
return "; BHI: BHI_DIS_S";
else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP))
return "; BHI: SW loop, KVM: SW loop";
- else if (boot_cpu_has(X86_FEATURE_RETPOLINE) &&
- !boot_cpu_has(X86_FEATURE_RETPOLINE_LFENCE) &&
- rrsba_disabled)
+ else if (retpoline_seq_enabled() && rrsba_disabled)
return "; BHI: Retpoline";
else if (boot_cpu_has(X86_FEATURE_CLEAR_BHB_LOOP_ON_VMEXIT))
return "; BHI: Vulnerable, KVM: SW loop";
--
2.43.0
^ permalink raw reply related
* [PATCH 6.6.y 3/6] bpf: Restrict JIT predictor flush to cBPF
From: Pawan Gupta @ 2026-07-17 17:06 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20260717-cbpf-jit-spray-hardening-6-6-y-v1-0-e04f1b2893de@linux.intel.com>
commit 0bb99f2cfaae6822d734d69722de30af823efdf3 upstream.
Currently predictor flush on memory reuse is done for all BPF JIT
allocations, but only cBPF programs can be loaded by an unprivileged user.
eBPF is privileged by default, and flushing predictors for all CPUs on
every eBPF reuse penalizes the common case for no security benefit.
eBPF allocations can be frequent on busy systems, only flush predictors
for cBPF programs. Trampoline and dispatcher allocations also skip the
flush as they are eBPF-only.
[pawan: backport dropped "was_classic" hunk for arches that do not
support pack allocator]
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
arch/riscv/net/bpf_jit_core.c | 3 ++-
arch/x86/net/bpf_jit_comp.c | 3 ++-
include/linux/filter.h | 5 +++--
kernel/bpf/core.c | 13 ++++++++-----
kernel/bpf/dispatcher.c | 2 +-
5 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
index 7b70ccb7fec3..8d8c5eb2e8da 100644
--- a/arch/riscv/net/bpf_jit_core.c
+++ b/arch/riscv/net/bpf_jit_core.c
@@ -123,7 +123,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
bpf_jit_binary_pack_alloc(prog_size + extable_size,
&jit_data->ro_image, sizeof(u32),
&jit_data->header, &jit_data->image,
- bpf_fill_ill_insns);
+ bpf_fill_ill_insns,
+ bpf_prog_was_classic(prog));
if (!jit_data->ro_header) {
prog = orig_prog;
goto out_offset;
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 0be138fbd0a0..8028a5a4ab64 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -2927,7 +2927,8 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
/* allocate module memory for x86 insns and extable */
header = bpf_jit_binary_pack_alloc(roundup(proglen, align) + extable_size,
&image, align, &rw_header, &rw_image,
- jit_fill_hole);
+ jit_fill_hole,
+ bpf_prog_was_classic(prog));
if (!header) {
prog = orig_prog;
goto out_addrs;
diff --git a/include/linux/filter.h b/include/linux/filter.h
index 72926bc394ad..f2e351cc543d 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -1065,7 +1065,7 @@ void bpf_jit_free(struct bpf_prog *fp);
struct bpf_binary_header *
bpf_jit_binary_pack_hdr(const struct bpf_prog *fp);
-void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns);
+void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool was_classic);
void bpf_prog_pack_free(struct bpf_binary_header *hdr);
static inline bool bpf_prog_kallsyms_verify_off(const struct bpf_prog *fp)
@@ -1079,7 +1079,8 @@ bpf_jit_binary_pack_alloc(unsigned int proglen, u8 **ro_image,
unsigned int alignment,
struct bpf_binary_header **rw_hdr,
u8 **rw_image,
- bpf_jit_fill_hole_t bpf_fill_ill_insns);
+ bpf_jit_fill_hole_t bpf_fill_ill_insns,
+ bool was_classic);
int bpf_jit_binary_pack_finalize(struct bpf_prog *prog,
struct bpf_binary_header *ro_header,
struct bpf_binary_header *rw_header);
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 0d8008711629..509f1b9c2b2e 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -911,7 +911,7 @@ static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_ins
return pack;
}
-void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
+void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool was_classic)
{
unsigned int nbits = BPF_PROG_SIZE_TO_NBITS(size);
struct bpf_prog_pack *pack;
@@ -926,7 +926,7 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
* safe because cBPF programs (the unprivileged attack surface)
* are bounded well below a pack size.
*/
- if (static_branch_unlikely(&bpf_pred_flush_enabled))
+ if (was_classic && static_branch_unlikely(&bpf_pred_flush_enabled))
pr_warn_once("BPF: Predictors not flushed for allocations greater than BPF_PROG_PACK_SIZE\n");
size = round_up(size, PAGE_SIZE);
ptr = bpf_jit_alloc_exec(size);
@@ -951,7 +951,9 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns)
pos = 0;
found_free_area:
- static_call_cond(bpf_arch_pred_flush)();
+ /* Flush only for cBPF as it may contain a crafted gadget */
+ if (static_branch_unlikely(&bpf_pred_flush_enabled) && was_classic)
+ static_call_cond(bpf_arch_pred_flush)();
bitmap_set(pack->bitmap, pos, nbits);
ptr = (void *)(pack->ptr) + (pos << BPF_PROG_CHUNK_SHIFT);
@@ -1111,7 +1113,8 @@ bpf_jit_binary_pack_alloc(unsigned int proglen, u8 **image_ptr,
unsigned int alignment,
struct bpf_binary_header **rw_header,
u8 **rw_image,
- bpf_jit_fill_hole_t bpf_fill_ill_insns)
+ bpf_jit_fill_hole_t bpf_fill_ill_insns,
+ bool was_classic)
{
struct bpf_binary_header *ro_header;
u32 size, hole, start;
@@ -1124,7 +1127,7 @@ bpf_jit_binary_pack_alloc(unsigned int proglen, u8 **image_ptr,
if (bpf_jit_charge_modmem(size))
return NULL;
- ro_header = bpf_prog_pack_alloc(size, bpf_fill_ill_insns);
+ ro_header = bpf_prog_pack_alloc(size, bpf_fill_ill_insns, was_classic);
if (!ro_header) {
bpf_jit_uncharge_modmem(size);
return NULL;
diff --git a/kernel/bpf/dispatcher.c b/kernel/bpf/dispatcher.c
index fa3e9225aedc..b3f164e31c6b 100644
--- a/kernel/bpf/dispatcher.c
+++ b/kernel/bpf/dispatcher.c
@@ -145,7 +145,7 @@ void bpf_dispatcher_change_prog(struct bpf_dispatcher *d, struct bpf_prog *from,
mutex_lock(&d->mutex);
if (!d->image) {
- d->image = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero);
+ d->image = bpf_prog_pack_alloc(PAGE_SIZE, bpf_jit_fill_hole_with_zero, false);
if (!d->image)
goto out;
d->rw_image = bpf_jit_alloc_exec(PAGE_SIZE);
--
2.43.0
^ permalink raw reply related
* [PATCH 6.6.y 4/6] bpf: Skip redundant IBPB in pack allocator
From: Pawan Gupta @ 2026-07-17 17:06 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20260717-cbpf-jit-spray-hardening-6-6-y-v1-0-e04f1b2893de@linux.intel.com>
commit a23c1c5396a91680703360d1ee28a44657c503c4 upstream.
bpf_prog_pack_alloc() issues IBPB on all CPUs on every cBPF allocation,
even when reusing chunks from an existing pack where no new memory was
touched since the last IBPB.
Since IBPB on all CPUs is heavy, Dave Hansen suggested to track allocation
since last IBPB, and only issue IBPB at reuse for the chunks that have not
seen an IBPB since they were last freed.
Track per-pack whether an IBPB is needed via arch_flush_needed. Set it when
allocating a chunk, reset on IBPB flush. On reuse, conditionally issue the
flush. Since IBPB invalidates all BTB entries, clear the flag on all packs
after flushing.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/core.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 509f1b9c2b2e..a2e5684d6239 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -851,6 +851,7 @@ int bpf_jit_add_poke_descriptor(struct bpf_prog *prog,
struct bpf_prog_pack {
struct list_head list;
void *ptr;
+ bool arch_flush_needed;
unsigned long bitmap[];
};
@@ -906,6 +907,8 @@ static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_ins
bitmap_zero(pack->bitmap, BPF_PROG_PACK_SIZE / BPF_PROG_CHUNK_SIZE);
list_add_tail(&pack->list, &pack_list);
+ if (static_branch_unlikely(&bpf_pred_flush_enabled))
+ pack->arch_flush_needed = true;
set_vm_flush_reset_perms(pack->ptr);
set_memory_rox((unsigned long)pack->ptr, BPF_PROG_PACK_SIZE / PAGE_SIZE);
return pack;
@@ -952,8 +955,15 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool
found_free_area:
/* Flush only for cBPF as it may contain a crafted gadget */
- if (static_branch_unlikely(&bpf_pred_flush_enabled) && was_classic)
+ if (static_branch_unlikely(&bpf_pred_flush_enabled) &&
+ pack->arch_flush_needed &&
+ was_classic) {
+ struct bpf_prog_pack *p;
+
static_call_cond(bpf_arch_pred_flush)();
+ list_for_each_entry(p, &pack_list, list)
+ p->arch_flush_needed = false;
+ }
bitmap_set(pack->bitmap, pos, nbits);
ptr = (void *)(pack->ptr) + (pos << BPF_PROG_CHUNK_SHIFT);
@@ -991,6 +1001,9 @@ void bpf_prog_pack_free(struct bpf_binary_header *hdr)
"bpf_prog_pack bug: missing bpf_arch_text_invalidate?\n");
bitmap_clear(pack->bitmap, pos, nbits);
+
+ if (static_branch_unlikely(&bpf_pred_flush_enabled))
+ pack->arch_flush_needed = true;
if (bitmap_find_next_zero_area(pack->bitmap, BPF_PROG_CHUNK_COUNT, 0,
BPF_PROG_CHUNK_COUNT, 0) == 0) {
list_del(&pack->list);
--
2.43.0
^ permalink raw reply related
* [PATCH 6.6.y 5/6] bpf: Prefer packs that won't trigger an IBPB flush on allocation
From: Pawan Gupta @ 2026-07-17 17:06 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20260717-cbpf-jit-spray-hardening-6-6-y-v1-0-e04f1b2893de@linux.intel.com>
commit a9b1f19a6a673ba06820898d0f1ad02883ea1639 upstream.
Currently BPF pack allocator picks the chunks from the first available
pack. While this is okay, it naturally leads to more frequent flushes
when there are multiple packs in the system that weren't used since the
last flush.
As an optimization prefer allocating the new programs from packs that
are unused since last flush. When all packs are dirty, allocation forces
a flush and marks all packs clean.
Below are some future optimizations ideas:
1. Currently, the "dirty" tracking is only done at the pack-level.
Flush frequency can further be reduced with chunk-level tracking.
This requires a new bitmap per-pack to track the dirty state.
2. IBPB flush is done on all CPUs, even if only a single CPU ran the
BPF program. On a system with hundreds of CPUs this could be a
major bottleneck forcing hundreds of IPIs to deliver the flush.
The solution is to track the CPUs where a BPF program ran, and
issue IBPB only on those CPUs.
3. Avoid IBPB when flush is already done at other sources (e.g.
context switch).
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/core.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index a2e5684d6239..7dc59570cd25 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -917,8 +917,8 @@ static struct bpf_prog_pack *alloc_new_pack(bpf_jit_fill_hole_t bpf_fill_ill_ins
void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool was_classic)
{
unsigned int nbits = BPF_PROG_SIZE_TO_NBITS(size);
- struct bpf_prog_pack *pack;
- unsigned long pos;
+ struct bpf_prog_pack *pack, *fallback_pack = NULL;
+ unsigned long pos, fallback_pos = 0;
void *ptr = NULL;
mutex_lock(&pack_mutex);
@@ -943,8 +943,29 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool
list_for_each_entry(pack, &pack_list, list) {
pos = bitmap_find_next_zero_area(pack->bitmap, BPF_PROG_CHUNK_COUNT, 0,
nbits, 0);
- if (pos < BPF_PROG_CHUNK_COUNT)
+ if (pos >= BPF_PROG_CHUNK_COUNT)
+ continue;
+ /* Flush not enabled, use any pack */
+ if (!static_branch_unlikely(&bpf_pred_flush_enabled))
goto found_free_area;
+ /*
+ * cBPF reuse of a dirty pack triggers a flush, so prefer a
+ * clean pack for cBPF. eBPF never flushes, so pick the first
+ * free pack, dirty or clean.
+ */
+ if (!was_classic || !pack->arch_flush_needed)
+ goto found_free_area;
+ if (!fallback_pack) {
+ fallback_pack = pack;
+ fallback_pos = pos;
+ }
+ }
+
+ /* No preferred pack found */
+ if (fallback_pack) {
+ pack = fallback_pack;
+ pos = fallback_pos;
+ goto found_free_area;
}
pack = alloc_new_pack(bpf_fill_ill_insns);
--
2.43.0
^ permalink raw reply related
* [PATCH 6.6.y 6/6] bpf: Prefer dirty packs for eBPF allocations
From: Pawan Gupta @ 2026-07-17 17:07 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman, Sasha Levin
Cc: bpf, linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv, x86,
Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20260717-cbpf-jit-spray-hardening-6-6-y-v1-0-e04f1b2893de@linux.intel.com>
commit b72e29e0f7ee329d89f86db8700c8ea99b4a370a upstream.
The pack allocator only flushes predictors when reusing a dirty pack for
cBPF, eBPF allocations never trigger a flush. Currently, eBPF picks the
first free pack, which could be a clean pack. As an optimization, leaving
a clean pack for cBPF can avoid flushes.
Prefer dirty packs for eBPF and keep clean packs free for cBPF. This
mirrors the existing cBPF preference for clean packs: each program kind
prefers the pack that avoids an extra flush, and falls back to the other
kind only when no preferred pack has room. eBPF reuse of a dirty pack is
harmless since eBPF being privileged does not flush.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
kernel/bpf/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 7dc59570cd25..4669a57265ad 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -950,10 +950,10 @@ void *bpf_prog_pack_alloc(u32 size, bpf_jit_fill_hole_t bpf_fill_ill_insns, bool
goto found_free_area;
/*
* cBPF reuse of a dirty pack triggers a flush, so prefer a
- * clean pack for cBPF. eBPF never flushes, so pick the first
- * free pack, dirty or clean.
+ * clean pack for cBPF. eBPF never flushes, so steer it to a
+ * dirty pack and keep clean packs free for cBPF.
*/
- if (!was_classic || !pack->arch_flush_needed)
+ if (was_classic ^ pack->arch_flush_needed)
goto found_free_area;
if (!fallback_pack) {
fallback_pack = pack;
--
2.43.0
^ permalink raw reply related
* [PATCH v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
This series tracks confidential-computing shared DMA state through the
dma-direct, dma-pool, and swiotlb paths so that encrypted and decrypted
DMA buffers are handled consistently.
Today, the direct DMA path mostly relies on force_dma_unencrypted() for
shared/decrypted buffer handling. This series consolidates the
force_dma_unencrypted() checks in the top-level functions and ensures
that the remaining DMA interfaces use DMA attributes to make the correct
decisions.
The series separates mapping and allocation state:
- DMA_ATTR_CC_SHARED describes the DMA address attribute requested for a
mapping. It tells the DMA mapping path that the DMA address must target
shared/decrypted memory.
- __DMA_ATTR_ALLOC_CC_SHARED is an internal DMA-mapping attribute used only
by allocation paths after the DMA core decides that the backing pages
must be allocated as shared/decrypted memory.
The series:
- moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
- uses __DMA_ATTR_ALLOC_CC_SHARED through the dma-direct alloc/free paths
- teaches the atomic DMA pools to track encrypted versus decrypted
state
- tracks swiotlb pool encryption state and enforces strict pool
selection
- centralizes encrypted/decrypted pgprot handling in dma_pgprot() using
DMA attributes
- passes DMA attributes down to dma_capable() so capability checks can
validate whether the selected DMA address encoding matches
DMA_ATTR_CC_SHARED
- makes dma_direct_map_phys() choose the DMA address encoding from
DMA_ATTR_CC_SHARED and fall back to swiotlb when a shared DMA request
cannot use the direct mapping, which lets arm64 and x86 CCA guests stop
relying on SWIOTLB_FORCE for DMA mappings
- use the selected swiotlb pool state to derive the returned DMA
address
- reports CC_ATTR_GUEST_MEM_ENCRYPT for arm64 Realms, powerpc secure
guests, and s390 protected virtualization guests.
Dependency:
This series depends on the pKVM changes posted at:
https://lore.kernel.org/all/20260603110522.3331819-1-smostafa@google.com
Please merge this series only after the pKVM changes above are merged.
Otherwise pKVM will be broken.
Changes since v7:
https://lore.kernel.org/all/20260701054926.825925-1-aneesh.kumar@kernel.org
* Rebased onto dma-mapping-for-next
* Prepared the series on top of the prerequisite pKVM changes, resolving
conflicts so it can be applied directly to the pKVM topic branch once ready.
https://git.gitlab.arm.com/linux-arm/linux-cca/-/commits/scratch/pkvm/testing
* Added comments documenting possible follow-up improvements for CC_SHARED
atomic pools and physical-address-based pool freeing.
* Retained virtual-address-based pool freeing when
CONFIG_DMA_DIRECT_REMAP is disabled.
* Applied pgprot_decrypted() only when expanding a CC_SHARED atomic pool.
Changes since v6:
https://lore.kernel.org/all/20260604083959.1265923-1-aneesh.kumar@kernel.org
* Rebase onto the latest kernel.
* Add __DMA_ATTR_ALLOC_CC_SHARED for allocation paths. DMA_ATTR_CC_SHARED
is now used to describe the requested DMA mapping address attribute,
while __DMA_ATTR_ALLOC_CC_SHARED is used internally when allocating
shared/decrypted backing pages.
* Report CC_ATTR_GUEST_MEM_ENCRYPT for arm64 Realms, powerpc secure
guests, and s390 protected virtualization guests.
* Add CC_ATTR_HOST_MEM_ENCRYPT and swiotlb=force fixes.
Changes since v5:
https://lore.kernel.org/all/20260522042815.370873-1-aneesh.kumar@kernel.org
* Add Tested-by
* Drop the pKVM patch, which has now been posted separately:
https://lore.kernel.org/all/20260603110522.3331819-1-smostafa@google.com
* Remove the DO_NOT_MERGE tag from the s390 change.
* Add a patch to drop the SWIOTLB_FORCE flag.
* Rebase onto the latest kernel.
Changes since v4:
https://lore.kernel.org/all/20260512090408.794195-1-aneesh.kumar@kernel.org
* Add new patches based on Sashiko review:
swiotlb: Preserve allocation virtual address for dynamic pools
dma: free atomic pool pages by physical address
dma: swiotlb: handle set_memory_decrypted() failures
dma: swiotlb: free dynamic pools from process context
iommu/dma: Check atomic pool allocation result directly
* Include pKVM and s390 changes as dependent patches. These are not yet
ready to merge and are waiting for subsystem testing feedback.
* Drop the AMD GART patch because it requires wider testing.
* Update swiotlb_tbl_map_single() to take attrs by reference.
* Switch swiotlb_free() to use rcu_work.
* Avoid calling swiotlb_find_pool() multiple times in the free path.
* Make DMA_ATTR_MMIO imply DMA_ATTR_CC_SHARED for devices requiring unencrypted DMA.
Changes from v3:
https://lore.kernel.org/all/20260427055509.898190-1-aneesh.kumar@kernel.org
* Handle DMA_ATTR_MMIO correctly in dma_direct_map_phys()
* Address most of sashiko review
* Rebase to latest kernel
* drop SWIOTLB_FORCE for s390 and powerpc secure guest.
Changes from v2:
https://lore.kernel.org/all/20260420061415.3650870-1-aneesh.kumar@kernel.org
* pass attrs to dma_capable() and update direct, swiotlb, Xen swiotlb, and
x86 GART paths so the capability checks see the DMA address attr value
DMA_ATTR_CC_SHARED.
* rework dma_direct_map_phys() so DMA_ATTR_CC_SHARED selects
phys_to_dma_unencrypted() while the default path uses
phys_to_dma_encrypted(), with swiotlb fallback when the requested
shared/private state cannot be satisfied by a direct DMA address.
* stop relying on SWIOTLB_FORCE for arm64 and x86 CC guest DMA mappings;
swiotlb is still enabled there, but shared mappings is now selected
through the generic dma_direct_map_phys()/dma_capable() decision instead
of a global force-bounce flag.
Changes from v1:
https://lore.kernel.org/all/20260417085900.3062416-1-aneesh.kumar@kernel.org
* rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
* update the alloc path so DMA_ATTR_CC_SHARED is not a caller-visible attribute.
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Mostafa Saleh <smostafa@google.com>
Cc: Petr Tesarik <ptesarik@suse.com>
Cc: Alexey Kardashevskiy <aik@amd.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Xu Yilun <yilun.xu@linux.intel.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: x86@kernel.org
Aneesh Kumar K.V (Arm) (23):
dma-direct: return struct page from dma_direct_alloc_from_pool()
dma-pool: fix page leak in atomic_pool_expand() cleanup
iommu/dma: Check atomic pool allocation result directly
dma: free atomic pool pages by physical address
swiotlb: Preserve allocation virtual address for dynamic pools
s390: Expose protected virtualization through cc_platform_has()
dma-direct: swiotlb: handle swiotlb alloc/free outside
__dma_direct_alloc_pages
coco: arm64: s390: powerpc: Mark secure guests with
CC_ATTR_GUEST_MEM_ENCRYPT
dma-mapping: Add internal shared allocation attribute
dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free paths
dma-pool: track decrypted atomic pools and select them via attrs
dma: swiotlb: pass mapping attributes by reference
dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHARED
dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
dma-direct: Move dma_direct_map_phys() to dma/direct.c
dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
dma-direct: set decrypted flag for remapped DMA allocations
dma-direct: select DMA address encoding from
__DMA_ATTR_ALLOC_CC_SHARED
dma-direct: rename ret to cpu_addr in alloc helpers
dma: swiotlb: free dynamic pools from process context
dma: swiotlb: handle set_memory_decrypted() failures
swiotlb: remove unused SWIOTLB_FORCE flag
Documentation/core-api/dma-attributes.rst | 29 ++
arch/arm64/mm/init.c | 5 +-
arch/powerpc/platforms/pseries/cc_platform.c | 1 +
arch/powerpc/platforms/pseries/svm.c | 2 +-
arch/s390/Kconfig | 1 +
arch/s390/mm/init.c | 17 +-
arch/x86/kernel/amd_gart_64.c | 30 +-
arch/x86/kernel/pci-dma.c | 4 +-
drivers/iommu/dma-iommu.c | 20 +-
drivers/xen/swiotlb-xen.c | 8 +-
include/linux/dma-direct.h | 20 +-
include/linux/dma-map-ops.h | 3 +-
include/linux/dma-mapping.h | 8 +
include/linux/swiotlb.h | 25 +-
include/trace/events/dma.h | 3 +-
kernel/dma/direct.c | 326 ++++++++++++++-----
kernel/dma/direct.h | 56 +---
kernel/dma/mapping.c | 25 +-
kernel/dma/pool.c | 237 ++++++++++----
kernel/dma/swiotlb.c | 292 +++++++++++++----
20 files changed, 810 insertions(+), 302 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool()
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, stable, Michael Kelley,
Jason Gunthorpe
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool
helper") changed dma_direct_alloc_from_pool() to return the CPU address
from dma_alloc_from_pool(). That fits dma_direct_alloc(), but
dma_direct_alloc_pages() also uses the helper and expects a struct page *.
Fix this by making dma_direct_alloc_from_pool() return the struct page *
again, and pass the CPU address back through an out-parameter for the
dma_direct_alloc() caller.
Fixes: 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper")
Cc: stable@vger.kernel.org
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/direct.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index d8219efe3273..363d984d90e7 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -164,22 +164,21 @@ static bool dma_direct_use_pool(struct device *dev, gfp_t gfp)
return !gfpflags_allow_blocking(gfp) && !is_swiotlb_for_alloc(dev);
}
-static void *dma_direct_alloc_from_pool(struct device *dev, size_t size,
- dma_addr_t *dma_handle, gfp_t gfp)
+static struct page *dma_direct_alloc_from_pool(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, void **cpu_addr, gfp_t gfp)
{
struct page *page;
u64 phys_limit;
- void *ret;
if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_DMA_COHERENT_POOL)))
return NULL;
gfp |= dma_direct_optimal_gfp_mask(dev, &phys_limit);
- page = dma_alloc_from_pool(dev, size, &ret, gfp, dma_coherent_ok);
+ page = dma_alloc_from_pool(dev, size, cpu_addr, gfp, dma_coherent_ok);
if (!page)
return NULL;
*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
- return ret;
+ return page;
}
static void *dma_direct_alloc_no_mapping(struct device *dev, size_t size,
@@ -247,8 +246,11 @@ void *dma_direct_alloc(struct device *dev, size_t size,
* the atomic pools instead if we aren't allowed block.
*/
if ((remap || force_dma_unencrypted(dev)) &&
- dma_direct_use_pool(dev, gfp))
- return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ dma_direct_use_pool(dev, gfp)) {
+ page = dma_direct_alloc_from_pool(dev, size, dma_handle,
+ &ret, gfp);
+ return page ? ret : NULL;
+ }
/* we always manually zero the memory once we are done */
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true);
@@ -357,7 +359,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
void *ret;
if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
- return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ return dma_direct_alloc_from_pool(dev, size, dma_handle, &ret, gfp);
page = __dma_direct_alloc_pages(dev, size, gfp, false);
if (!page)
--
2.43.0
^ permalink raw reply related
* [PATCH v8 02/23] dma-pool: fix page leak in atomic_pool_expand() cleanup
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jason Gunthorpe,
Michael Kelley
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
atomic_pool_expand() frees the allocated pages from the remove_mapping
error path only when CONFIG_DMA_DIRECT_REMAP is enabled.
When CONFIG_DMA_DIRECT_REMAP is disabled, failures after page allocation,
such as gen_pool_add_virt(), jump to remove_mapping and return without
freeing the pages.
Move __free_pages(page, order) out of the CONFIG_DMA_DIRECT_REMAP block so
that cleanup paths always release the allocation.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/pool.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 2b2fbb709242..b0303efbc153 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -81,6 +81,7 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
{
unsigned int order;
struct page *page = NULL;
+ bool leak_pages = false;
void *addr;
int ret = -ENOMEM;
@@ -115,8 +116,10 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
*/
ret = set_memory_decrypted((unsigned long)page_to_virt(page),
1 << order);
- if (ret)
+ if (ret) {
+ leak_pages = true;
goto remove_mapping;
+ }
ret = gen_pool_add_virt(pool, (unsigned long)addr, page_to_phys(page),
pool_size, NUMA_NO_NODE);
if (ret)
@@ -130,14 +133,15 @@ static int atomic_pool_expand(struct gen_pool *pool, size_t pool_size,
1 << order);
if (WARN_ON_ONCE(ret)) {
/* Decrypt succeeded but encrypt failed, purposely leak */
- goto out;
+ leak_pages = true;
}
remove_mapping:
#ifdef CONFIG_DMA_DIRECT_REMAP
dma_common_free_remap(addr, pool_size);
free_page:
- __free_pages(page, order);
#endif
+ if (!leak_pages)
+ __free_pages(page, order);
out:
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v8 03/23] iommu/dma: Check atomic pool allocation result directly
From: Aneesh Kumar K.V (Arm) @ 2026-07-17 18:04 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jason Gunthorpe,
Michael Kelley
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
The non-blocking, non-coherent allocation path uses dma_alloc_from_pool(),
which returns the allocated page and fills cpu_addr only on success.
Do not rely on cpu_addr to detect allocation failure in this path. Check
the returned page directly before using it for the IOMMU mapping.
Fixes: 9420139f516d ("dma-pool: fix coherent pool allocations for IOMMU mappings")
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Mostafa Saleh <smostafa@google.com>
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
drivers/iommu/dma-iommu.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5598ed4bff72..6a45acbbfb0c 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1671,13 +1671,16 @@ void *iommu_dma_alloc(struct device *dev, size_t size, dma_addr_t *handle,
}
if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
- !gfpflags_allow_blocking(gfp) && !coherent)
+ !gfpflags_allow_blocking(gfp) && !coherent) {
page = dma_alloc_from_pool(dev, PAGE_ALIGN(size), &cpu_addr,
- gfp, NULL);
- else
+ gfp, NULL);
+ if (!page)
+ return NULL;
+ } else {
cpu_addr = iommu_dma_alloc_pages(dev, size, &page, gfp, attrs);
- if (!cpu_addr)
- return NULL;
+ if (!cpu_addr)
+ return NULL;
+ }
*handle = __iommu_dma_map(dev, page_to_phys(page), size, ioprot,
dev->coherent_dma_mask);
--
2.43.0
^ 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