* [PATCH v3 5/5] powerpc/powernv/eeh: Map VFIO EEH error injection to OPAL
From: Narayana Murty N @ 2026-07-21 3:38 UTC (permalink / raw)
To: mahesh, maddy, mpe, christophe.leroy, gregkh, oohall, npiggin
Cc: linuxppc-dev, linux-kernel, tyreld, vaibhav, sbhat, ganeshgr,
sourabhjain, haren, nnmlinux, thuth
In-Reply-To: <20260721033815.5300-1-nnmlinux@linux.ibm.com>
The EEH error-injection interface passes the generic userspace ABI
values EEH_ERR_TYPE_32 and EEH_ERR_TYPE_64 to the platform backend.
The PowerNV backend currently compares those generic values directly
with OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR and
OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR64. Although the corresponding values
are currently numerically identical, this implicitly couples the
generic EEH ABI to the OPAL firmware encoding.
Explicitly translate the generic EEH error types to their OPAL
equivalents in pnv_eeh_err_inject(). Keep the platform-specific
encoding within the PowerNV backend and reject unsupported generic
types with -EINVAL.
No userspace ABI values are changed.
Signed-off-by: Narayana Murty N <nnmlinux@linux.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 36 +++++++++++++++++---
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c b/arch/powerpc/platforms/powernv/eeh-powernv.c
index db3370d1673c..b0bcd014a133 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -1169,11 +1169,39 @@ static int pnv_eeh_err_inject(struct eeh_pe *pe, int type, int func,
struct pnv_phb *phb = hose->private_data;
s64 rc;
- if (type != OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR &&
- type != OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR64) {
- pr_warn("%s: Invalid error type %d\n",
+ /*
+ * Map generic EEH error-type ABI values to OPAL-specific type codes.
+ * EEH_ERR_TYPE_32 and EEH_ERR_TYPE_64 are the only types supported by
+ * OPAL. Additional generic types defined in the UAPI header are valid
+ * for pSeries RTAS but unsupported here; return -EOPNOTSUPP for those.
+ * Unknown or invalid values return -EINVAL.
+ *
+ * Note: currently OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR == 0 ==
+ * EEH_ERR_TYPE_32 and OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR64 == 1 ==
+ * EEH_ERR_TYPE_64, but the explicit switch makes the coupling
+ * visible and allows the values to diverge independently.
+ */
+ switch (type) {
+ case EEH_ERR_TYPE_32:
+ type = OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR;
+ break;
+ case EEH_ERR_TYPE_64:
+ type = OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR64;
+ break;
+ case EEH_ERR_TYPE_RECOVERED_SPECIAL_EVENT:
+ case EEH_ERR_TYPE_CORRUPTED_PAGE:
+ case EEH_ERR_TYPE_CORRUPTED_DCACHE_START:
+ case EEH_ERR_TYPE_CORRUPTED_DCACHE_END:
+ case EEH_ERR_TYPE_CORRUPTED_ICACHE_START:
+ case EEH_ERR_TYPE_CORRUPTED_ICACHE_END:
+ case EEH_ERR_TYPE_CORRUPTED_TLB_START:
+ case EEH_ERR_TYPE_CORRUPTED_TLB_END:
+ pr_warn("%s: EEH error type %d not supported by OPAL\n",
__func__, type);
- return -ERANGE;
+ return -EOPNOTSUPP;
+ default:
+ pr_warn("%s: unsupported EEH error type %d\n", __func__, type);
+ return -EINVAL;
}
if (func < OPAL_ERR_INJECT_FUNC_IOA_LD_MEM_ADDR ||
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()
From: Bartosz Golaszewski @ 2026-07-21 7:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andi Shyti,
Joerg Roedel (AMD), Will Deacon, Robin Murphy, Andy Shevchenko,
Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Lee Jones, Sebastian Hesselbarth,
Srinivas Kandagatla, driver-core, linuxppc-dev, linux-kernel,
linux-i2c, iommu, netdev, linux-pm, imx, linux-arm-kernel, mfd,
linux-arm-msm, linux-sound, Bartosz Golaszewski
In-Reply-To: <3e14e41f-ecd5-432b-9f52-690a05b38a8a@lunn.ch>
On Mon, 20 Jul 2026 20:28:39 +0200, Andrew Lunn <andrew@lunn.ch> said:
> On Mon, Jul 20, 2026 at 06:01:37PM +0200, Bartosz Golaszewski wrote:
>> On Mon, 20 Jul 2026 16:43:40 +0200, Andrew Lunn <andrew@lunn.ch> said:
>> > On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote:
>> >> Prefer the higher-level platform_device_set_fwnode() over the
>> >> OF-specific platform_device_set_of_node() for dynamically allocated
>> >> platform devices.
>> >>
>> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> >> ---
>> >> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
>> >> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>> >> goto put_err;
>> >> }
>> >> ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> >> - platform_device_set_of_node(ppdev, pnp);
>> >> + platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
>> >
>> > This is definitely an OF only driver. There are no other calls to
>> > fwnode functions in this driver, so this is the wrong thing to do.
>> >
>> > Sorry, NACK.
>> >
>>
>> I'm not going to die on this hill but drivers are OF-only until they're not.
>> For example, Qualcomm is now working on a hybrid ACPI-OF approach for
>> laptops[1] and we may end up needing to start converting drivers to fwnode
>> after all.
>>
>> There's no real benefit to sticking to OF-specific APIs unless you need to
>> iterate over all properties of a node or use some other functionality not
>> available in fwnode. The overhead is minimal and it's never a hot path.
>
> There is a lot of benefit to sticking to OF specific APIs, because
> within the kernel OF is well maintained, has active maintainers, there
> are tools to validate bindings, etc. ACPI is a Wild West, each driver
> is a snow flake, there is no review, no binding documentation, no
> validation tools etc.
>
> I hope you allow plenty of time to convert any networking drivers,
> where Linux is driving the hardware, to ACPI. Your first stop will be
> the UEFI forum making a proposal for MDIO busses, because that
> currently is not part of ACPI. You will then need to spend time
> understanding the DT bindings, and figuring out which properties are
> deprecated so need to stay OF only, and which can be converted to dual
> OF/ACPI. I've seen too many naive attempts which blindly convert
> everything, copying all the past errors in the DT binding into the
> brand new ACPI binding. That will get NACKed.
>
> OF != ACPI
>
I've never said that and ACPI is actually irrelevant to this discussion. Fwnode
is the abstraction layer and OF happens to implement it. Unless you need
fine-grained control (only exposed by the lower-level abstraction) or
performance - neither of which is the case here - you should use the top-level
API. As I said: there's no good reason to stick to OF-specific interfaces for
drivers that don't really require it - and even then, we should strive to fill
the gaps in the fwnode API instead.
Bart
^ permalink raw reply
* Re: [PATCH] powerpc: Remove dead non-preemption code
From: Madhavan Srinivasan @ 2026-07-21 8:15 UTC (permalink / raw)
To: Shrikanth Hegde, Peter Zijlstra, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP)
Cc: linux-kernel, linuxppc-dev
In-Reply-To: <2bf10a0afffefb6aca44bf2f864cc17471a80e31.1781870889.git.chleroy@kernel.org>
On Fri, 19 Jun 2026 14:08:28 +0200, Christophe Leroy (CS GROUP) wrote:
> Since commit 7dadeaa6e851 ("sched: Further restrict the preemption
> modes"), powerpc always has CONFIG_PREEMPTION because only
> CONFIG_PREEMPT and CONFIG_PREEMPT_LAZY are possible, even in
> dynamic preemption mode (see sched_dynamic_mode).
>
> As a consequence, need_irq_preemption() is always true and can be
> removed.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc: Remove dead non-preemption code
https://git.kernel.org/powerpc/c/a2c02aa0c6ca3ec9fab6f1c99912a440c7b8bfdb
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/vtime: Initialize starttime at boot for native accounting
From: Madhavan Srinivasan @ 2026-07-21 8:15 UTC (permalink / raw)
To: linuxppc-dev, Christophe Leroy, Shrikanth Hegde; +Cc: frederic
In-Reply-To: <20260605124329.377533-1-sshegde@linux.ibm.com>
On Fri, 05 Jun 2026 18:13:29 +0530, Shrikanth Hegde wrote:
> It was observed that /proc/stat had very large value for one ore more
> CPUs. It was more visible after recent code simplifications around
> cpustats.
>
> System has 240 CPUs.
>
> cat /proc/uptime;
> 194.18 46500.55
> cat /proc/stat
> cpu 5966 39 837032887 4650070 164 185 100 0 0 0
> cpu0 108 0 837030890 19109 24 4 23 0 0 0
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/vtime: Initialize starttime at boot for native accounting
https://git.kernel.org/powerpc/c/c1c1ffa490fc33591e90852ed0d38804dd20bc36
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: fix memory leak on krealloc failure in papr_init
From: Madhavan Srinivasan @ 2026-07-21 8:15 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Kees Cook, Pratik R. Sampat, Thorsten Blum
Cc: stable, linuxppc-dev, linux-kernel
In-Reply-To: <20260614142356.658212-2-thorsten.blum@linux.dev>
On Sun, 14 Jun 2026 16:23:56 +0200, Thorsten Blum wrote:
> When krealloc() fails, free the original esi_buf before returning to
> avoid a memory leak.
>
>
Applied to powerpc/fixes.
[1/1] powerpc/pseries: fix memory leak on krealloc failure in papr_init
https://git.kernel.org/powerpc/c/bd83c98b988d2c560531084e296dbfb530aff829
cheers
^ permalink raw reply
* Re: [patch 00/18] entry: Consolidate and rework syscall entry handling
From: Thomas Gleixner @ 2026-07-21 8:17 UTC (permalink / raw)
To: Magnus Lindholm
Cc: LKML, Peter Zijlstra, Michael Ellerman, Shrikanth Hegde,
linuxppc-dev, Kees Cook, Huacai Chen, loongarch, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Sven Schnelle, linux-s390, x86,
Mark Rutland, Jinjie Ruan, Andy Lutomirski, Oleg Nesterov,
Richard Henderson, Russell King, Catalin Marinas, Guo Ren,
Geert Uytterhoeven, Thomas Bogendoerfer, Helge Deller,
Yoshinori Sato, Richard Weinberger, Chris Zankel,
linux-arm-kernel, linux-alpha, linux-csky, linux-m68k, linux-mips,
linux-parisc, linux-sh, linux-um, Arnd Bergmann, Vineet Gupta,
Will Deacon, Brian Cain, Michal Simek, Dinh Nguyen,
David S. Miller, Andreas Larsson, linux-snps-arc, linux-hexagon,
linux-openrisc, sparclinux, linux-arch, Michal Suchánek,
Jonathan Corbet, linux-doc
In-Reply-To: <CA+=Fv5Sd5+-K3-MOiEc2N8z_5CoLQPVPUwjiugSj3u8cBWJXXQ@mail.gmail.com>
Magnus!
On Tue, Jul 21 2026 at 00:01, Magnus Lindholm wrote:
> On Mon, Jul 20, 2026 at 9:21 PM Thomas Gleixner <tglx@kernel.org> wrote:
>> If you want to base your stuff on that for 7.3, I can add a tag which
>> makes it immutable so it can be pulled into the alpha tree.
>
> Yes, please. There is still some ongoing testing/review of my Alpha
> GENERIC_ENTRY series, but assuming it is ready in time for the 7.3 merge
> window, an immutable tag would be very helpful.
Here you go:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-entry-for-arch-07-21-26
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()
From: Madhavan Srinivasan @ 2026-07-21 8:15 UTC (permalink / raw)
To: Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Rik van Riel, Benjamin Herrenschmidt, Andrew Morton, Junrui Luo
Cc: linuxppc-dev, linux-kernel, Yuhao Jiang, stable
In-Reply-To: <SYBPR01MB7881EE775E8B51C09F5A29E7AF152@SYBPR01MB7881.ausprd01.prod.outlook.com>
On Mon, 01 Jun 2026 15:50:00 +0800, Junrui Luo wrote:
> spufs_mem_mmap_access() computes the local store offset as
> address - vma->vm_start, but bounds-checks it against vma->vm_end
> instead of the local store size. On 64-bit, offset is always well
> below vma->vm_end, so the clamp never fires and len stays unbounded
> against the LS_SIZE buffer returned by ctx->ops->get_ls().
>
> Reject offsets at or beyond LS_SIZE and clamp len to the remaining
> space, mirroring the guard already used by spufs_mem_mmap_fault() and
> spufs_ps_fault().
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/spufs: fix out-of-bounds access in spufs_mem_mmap_access()
https://git.kernel.org/powerpc/c/47b87f469a35b5ffc81c16eee6b13a9b6c8d55c6
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later processors
From: Madhavan Srinivasan @ 2026-07-21 8:14 UTC (permalink / raw)
To: linuxppc-dev, Amit Machhiwal
Cc: Vaibhav Jain, Harsh Prateek Bora, Ritesh Harjani, Anushree Mathur,
Gautam Menghani, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), stable, linux-kernel
In-Reply-To: <20260614173437.26352-1-amachhiw@linux.ibm.com>
On Sun, 14 Jun 2026 23:04:37 +0530, Amit Machhiwal wrote:
> When using device tree CPU features (dt-cpu-ftrs), the kernel bypasses
> the traditional cputable-based CPU identification and instead derives
> CPU features from the device tree's "ibm,powerpc-cpu-features" node
> provided by firmware.
>
> However, CPU_FTR_P11_PVR is a kernel-internal feature flag used to
> identify Power11 and later processors, and is not represented in the
> device tree's ISA feature set. While ISA v3.1 support (indicated by
> CPU_FTR_ARCH_31) is present on both Power10 and Power11, the
> CPU_FTR_P11_PVR flag is specifically needed by code that must
> distinguish between Power10 and Power11 processors.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/dt_cpu_ftrs: Set CPU_FTR_P11_PVR for Power11 and later processors
https://git.kernel.org/powerpc/c/e4de1b9cb3b5c981e4fe9bca253a7fb9161f5acd
cheers
^ permalink raw reply
* Re: [PATCH v18 11/13] PCI: Cache PCI DSN into pci_dev->dsn during probe
From: Lukas Wunner @ 2026-07-21 8:37 UTC (permalink / raw)
To: Bowman, Terry
Cc: Bjorn Helgaas, Dan Williams, Dave Jiang, Ira Weiny,
Jonathan Cameron, Len Brown, Rafael J . Wysocki, Robert Richter,
linux-acpi, linux-cxl, linux-doc, linux-kernel, linux-pci,
linuxppc-dev, Alejandro Lucero, Alison Schofield, Ankit Agrawal,
Ard Biesheuvel, Ben Cheatham, Borislav Petkov, Breno Leitao,
Davidlohr Bueso, Fabio M . De Francesco, Gregory Price,
Hanjun Guo, Jonathan Corbet, Kees Cook,
Kuppuswamy Sathyanarayanan, Li Ming, Mahesh J Salgaonkar,
Mauro Carvalho Chehab, Oliver O'Halloran, Shiju Jose,
Shuah Khan, Shuai Xue, Smita Koralahalli, Tony Luck, Vishal Verma
In-Reply-To: <91e35807-9483-45f5-b4a8-0388aa48ff6f@amd.com>
On Mon, Jul 20, 2026 at 10:48:06AM -0500, Bowman, Terry wrote:
> +++ b/drivers/pci/hotplug/pciehp.h
> @@ -90,7 +90,6 @@ extern int pciehp_poll_time;
> */
> struct controller {
> struct pcie_device *pcie;
> - u64 dsn;
>
Please drop the kernel-doc for this struct member as well.
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -1086,8 +1086,6 @@ struct controller *pcie_init(struct pcie_device *dev)
> }
>
> pdev = pci_get_slot(subordinate, PCI_DEVFN(0, 0));
> - if (pdev)
> - ctrl->dsn = pci_get_dsn(pdev);
> pci_dev_put(pdev);
>
Please drop the pci_get_slot() + pci_dev_put() as well,
they're obviously superfluous now.
> +++ b/drivers/pci/hotplug/pciehp_pci.c
> @@ -73,7 +73,6 @@ int pciehp_configure_device(struct controller *ctrl)
> down_read_nested(&ctrl->reset_lock, ctrl->depth);
>
> dev = pci_get_slot(parent, PCI_DEVFN(0, 0));
> - ctrl->dsn = pci_get_dsn(dev);
> pci_dev_put(dev);
>
Same here.
Thanks,
Lukas
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: sound: fsl,imx-asrc: update port binding to support multiple pairs
From: Shengjiu Wang @ 2026-07-21 8:58 UTC (permalink / raw)
To: Mark Brown
Cc: shengjiu.wang, lgirdwood, robh, krzk+dt, conor+dt, Frank.Li,
s.hauer, kernel, festevam, shawnguo, linux-sound, devicetree, imx,
linux-arm-kernel, linux-kernel, Xiubo.Lee, nicoleotsuka, perex,
tiwai, linuxppc-dev, Shengjiu Wang
In-Reply-To: <3ce4bfa8-b051-40af-9478-00540019680b@sirena.org.uk>
On Mon, Jul 20, 2026 at 10:28 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Jul 20, 2026 at 05:54:47PM +0800, shengjiu.wang@oss.nxp.com wrote:
> > From: Shengjiu Wang <shengjiu.wang@nxp.com>
> >
> > The i.MX ASRC hardware supports up to three conversion pairs (A, B, C).
> > The existing binding exposed only a single generic audio-graph port,
> > which cannot represent the individual pair endpoints.
>
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
Thanks for pointing this out. There are also some comments from sashiko.dev
I will try to address in the next version.
Best regards
Shengjiu Wang
^ permalink raw reply
* Re: [PATCH v2] powerpc/uaccess: correct check for CONFIG_PPC_E500 in mask_user_address()
From: Madhavan Srinivasan @ 2026-07-21 8:15 UTC (permalink / raw)
To: Nicholas Piggin, Christophe Leroy (CS GROUP), Sayali Patil,
linuxppc-dev, Ethan Nelson-Moore
Cc: stable, Michael Ellerman
In-Reply-To: <20260615233729.29386-1-enelsonmoore@gmail.com>
On Mon, 15 Jun 2026 16:37:26 -0700, Ethan Nelson-Moore wrote:
> mask_user_address() incorrectly checks for CONFIG_E500 instead of
> CONFIG_PPC_E500, causing mask_user_address_isel() to not be used on
> E500 hardware. Fix the check to use the correct name.
>
> Fixes: 861574d51bbd ("powerpc/uaccess: Implement masked user access")
> Cc: stable@vger.kernel.org # 7.0+
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/uaccess: correct check for CONFIG_PPC_E500 in mask_user_address()
https://git.kernel.org/powerpc/c/d610d3ab18197d87618da11ec5fe8b3cebf32208
cheers
^ permalink raw reply
* Re: [PATCH 2/5] powerpc/msi: Treat bitmap size as allocation failure
From: Madhavan Srinivasan @ 2026-07-21 9:16 UTC (permalink / raw)
To: Yury Norov, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), linuxppc-dev, linux-kernel
In-Reply-To: <20260709020312.133977-3-ynorov@nvidia.com>
On 7/9/26 7:33 AM, Yury Norov wrote:
> bitmap_find_next_zero_area() uses an out-of-range return value to
> indicate failure. Check for values greater than or equal to the bitmap
> size so the caller does not depend on the exact failure sentinel.
Changes seems to fine.
Acked-by: Madhavan Srinivasan <maddy@linux.ibm.com>
When reviewing this, I did find the return value of
bitmap_find_next_zero_area
to be unsigned long, but we are casting it to int. Not as concern at
this point
this will be an issue when irq_count exceeds. May be a follow patch is
needed
to fix this I guess.
Maddy
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
> ---
> arch/powerpc/sysdev/msi_bitmap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
> index 456a4f64ae0a..2f38d4b41ad3 100644
> --- a/arch/powerpc/sysdev/msi_bitmap.c
> +++ b/arch/powerpc/sysdev/msi_bitmap.c
> @@ -21,7 +21,7 @@ int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num)
>
> offset = bitmap_find_next_zero_area(bmp->bitmap, bmp->irq_count, 0,
> num, (1 << order) - 1);
> - if (offset > bmp->irq_count)
> + if (offset >= bmp->irq_count)
> goto err;
>
> bitmap_set(bmp->bitmap, offset, num);
^ permalink raw reply
* Re: [PATCH v5] powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM
From: Madhavan Srinivasan @ 2026-07-21 8:15 UTC (permalink / raw)
To: mpe, npiggin, chleroy, Gautam Menghani
Cc: linuxppc-dev, linux-kernel, stable, Sean Christopherson,
Amit Machhiwal, Harsh Prateek Bora
In-Reply-To: <20260615091120.84169-1-gautam@linux.ibm.com>
On Mon, 15 Jun 2026 14:41:19 +0530, Gautam Menghani wrote:
> Currently, CONFIG_VPA_PMU is not enabled by default, and consequently
> cannot be used for KVM guests at all, unless explicitly enabled on
> host kernel.
>
> Mark CONFIG_VPA_PMU as "default m" to ensure it is available when KVM is
> being used.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM
https://git.kernel.org/powerpc/c/fe179677b6dcb4b658586038a811f87265e97777
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Add fsl,ifc to common device ids
From: Madhavan Srinivasan @ 2026-07-21 8:15 UTC (permalink / raw)
To: linuxppc-dev, Rosen Penev
Cc: Scott Wood, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Frank Li, Li Yang, linux-kernel
In-Reply-To: <20260604043309.91280-1-rosenp@gmail.com>
On Wed, 03 Jun 2026 21:33:09 -0700, Rosen Penev wrote:
> Add fsl,ifc to mpc85xx_common_ids so that of_platform_bus_probe
> creates a platform device for the IFC node even without 'simple-bus'
> in its compatible property. On P1010 and similar platforms the IFC
> node is a direct child of the root, so it must be explicitly matched
> to be populated.
>
> Fixes: 0bf51cc9e9e5 ("powerpc: dts: mpc85xx: remove simple-bus compatible from ifc node")
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/85xx: Add fsl,ifc to common device ids
https://git.kernel.org/powerpc/c/25957f7c3dac3265332d766b71233e3622f17e14
cheers
^ permalink raw reply
* [PATCH] seccomp: Fix syscall skip logic on ptrace
From: Michal Suchanek @ 2026-07-21 10:44 UTC (permalink / raw)
To: LKML
Cc: Kees Cook, Andy Lutomirski, Will Drewry, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, linux-kernel,
linux-riscv, Thomas Gleixner, Michal Suchánek,
Michael Ellerman, Shrikanth Hegde, linuxppc-dev, Huacai Chen,
loongarch, Sven Schnelle, linux-s390, x86, Mark Rutland,
Jinjie Ruan, Magnus Lindholm, Mukesh Kumar Chaurasiya (IBM),
Jonathan Corbet, Radu Rendec, Renzo Davoli, Oleg Nesterov
In-Reply-To: <20260707181957.433213175@kernel.org>
seccomp takes a shortcut here. When the syscall number is re-read after
ptrace and the sign bit is set in the syscall number the syscall is
skipped right away.
This works fairly well on x86 where the return value of the syscall is
preset before seccomp is processed.
However, on some architectures the syscall return value overlaps with
the syscall number or syscall arguments, and as a result the return
value cannot be preset in advance.
For these architectures seccomp needs to exit without flagging the
syscall as skipped. Then processing of invalid syscall number in the
architecture code should set the return value to -ENOSYS and skip the
syscall.
This introduces a change: If the syscall number has the sign bit
set, such as -1, previously the filter re-check would not be done, not
applying the filter after trace. Now the re-check is done both for
syscall nubers with and without sign bit set. This would only make a
difference if the syscall number or the filter was changed by the
tracer. Otherwise the filter would be resolved the first time around.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
kernel/seccomp.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 066909393c38..9e40a38aaedf 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -1318,11 +1318,8 @@ static int __seccomp_filter(int this_syscall, const bool recheck_after_trace)
*/
if (fatal_signal_pending(current))
goto skip;
- /* Check if the tracer forced the syscall to be skipped. */
- this_syscall = syscall_get_nr(current, current_pt_regs());
- if (this_syscall < 0)
- goto skip;
+ this_syscall = syscall_get_nr(current, current_pt_regs());
/*
* Recheck the syscall, since it may have changed. This
* intentionally uses a NULL struct seccomp_data to force
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool()
From: Leon Romanovsky @ 2026-07-21 11:54 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, 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-2-aneesh.kumar@kernel.org>
On Fri, Jul 17, 2026 at 11:34:19PM +0530, Aneesh Kumar K.V (Arm) wrote:
> 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;
Sorry for joining the discussion late, but the line above caught my
attention.
Why do we need both ret and page? We can derive cpu_addr from page and
vice versa. Do we really need the &ret parameter? Or, more generally, do
we really need "struct page *"?
static struct page *__dma_alloc_from_pool(struct device *dev, size_t size,
struct gen_pool *pool, void **cpu_addr,
bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t))
{
...
*cpu_addr = (void *)addr;
memset(*cpu_addr, 0, size);
return pfn_to_page(__phys_to_pfn(phys));
}
Why
> + }
>
> /* 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
* Re: [PATCH v8 02/23] dma-pool: fix page leak in atomic_pool_expand() cleanup
From: Leon Romanovsky @ 2026-07-21 12:31 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm)
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, 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-3-aneesh.kumar@kernel.org>
On Fri, Jul 17, 2026 at 11:34:20PM +0530, Aneesh Kumar K.V (Arm) wrote:
> 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;
Instead of doing this dance with temporal variable, change "goto out" to
be "return true".
> }
> remove_mapping:
> #ifdef CONFIG_DMA_DIRECT_REMAP
> dma_common_free_remap(addr, pool_size);
> free_page:
Remove free_page label, and change leftover of "goto free_page" to be
"goto out"
> - __free_pages(page, order);
> #endif
> + if (!leak_pages)
> + __free_pages(page, order);
Put these checks under out label and rely on page != NULL as a marker.
if (page)
__free_pages(page, order);
> out:
> return ret;
> }
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH v8 00/23] dma-mapping: Track shared DMA state through direct, pool and swiotlb paths
From: Leon Romanovsky @ 2026-07-21 12:40 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), Marek Szyprowski
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, Robin Murphy,
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
In-Reply-To: <20260717180442.110954-1-aneesh.kumar@kernel.org>
On Fri, Jul 17, 2026 at 11:34:18PM +0530, Aneesh Kumar K.V (Arm) wrote:
> 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.
<...>
> - 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
Why don't we continue the effort to remove "struct page" entirely
from the DMA API internals?
IMHO, everything not exposed to DMA API users should use
phys_addr_t, including the DMA address pool.
Thanks
^ permalink raw reply
* Re: [PATCH 6.16.y 0/6] cBPF JIT spray hardening
From: Greg Kroah-Hartman @ 2026-07-21 13:08 UTC (permalink / raw)
To: Pawan Gupta
Cc: stable, Sasha Levin, bpf, linux-arm-kernel, loongarch,
linuxppc-dev, linux-riscv, x86, Alexei Starovoitov,
Daniel Borkmann, Dave Hansen
In-Reply-To: <20260714-cbpf-jit-spray-hardening-6-16-y-v1-0-2fc3e16263ac@linux.intel.com>
On Tue, Jul 14, 2026 at 11:58:24AM -0700, Pawan Gupta wrote:
> 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
>
> This one is mostly similar to 6.18:
>
> https://lore.kernel.org/all/20260713-cbpf-jit-spray-hardening-6-18-y-v1-0-755f60c55705@linux.intel.com/
There is no active 6.16.y kernel branch, so why is this being sent to
us?
confused,
greg k-h
^ permalink raw reply
* [PATCH v2 0/3] Bring includes in linux/kmod.h up to date
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
The usermode helper declarations were previously provided by linux/kmod.h
but commit c1f3fa2a4fde ("kmod: split off umh headers into its own file")
moved them to linux/umh.h in 2017. Add explicit includes of linux/umh.h to
files that use usermode helpers and remove linux/kmod.h where it is no
longer needed.
Also add a missing include of linux/sysctl.h to kernel/time/jiffies.c.
Finally, clean up linux/kmod.h so that it includes only the headers that it
actually requires, importantly removing the compat linux/umh.h include.
This cleanup is motivated by trying to reduce the preprocessed size of
linux/module.h, which includes linux/kmod.h. The linux/module.h header is
included by every *.mod.c file to provide `struct module` and other related
definitions, so it should avoid pulling in unnecessary dependencies. Note
that this series doesn't immediately improve the situation, since most of
the files included by linux/kmod.h are, for now, also included by
linux/module.h through other paths.
Apologies for the wide distribution. Acked-bys are appreciated.
Changes in v2:
- Remove the linux/kmod.h include from kernel/cgroup/cgroup-v1.c.
- Add a missing include of linux/sysctl.h to kernel/time/jiffies.c.
- Link to v1: https://lore.kernel.org/linux-modules/20260708154510.6794-1-petr.pavlu@suse.com/
Petr Pavlu (3):
umh, treewide: Explicitly include linux/umh.h where needed
time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
module: Bring includes in linux/kmod.h up to date
arch/x86/kernel/cpu/mce/dev-mcelog.c | 2 +-
drivers/block/drbd/drbd_nl.c | 1 +
drivers/greybus/svc_watchdog.c | 1 +
drivers/macintosh/windfarm_core.c | 1 +
drivers/pnp/pnpbios/core.c | 2 +-
drivers/video/fbdev/uvesafb.c | 1 +
fs/coredump.c | 2 +-
fs/nfs/cache_lib.c | 2 +-
fs/nfsd/nfs4layouts.c | 2 +-
fs/nfsd/nfs4recover.c | 1 +
fs/ocfs2/stackglue.c | 1 +
include/linux/kmod.h | 12 ++----------
kernel/cgroup/cgroup-v1.c | 2 +-
kernel/module/kmod.c | 1 +
kernel/power/process.c | 2 +-
kernel/reboot.c | 2 +-
kernel/time/jiffies.c | 1 +
kernel/umh.c | 2 +-
lib/kobject_uevent.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
security/keys/request_key.c | 2 +-
security/tomoyo/common.h | 2 +-
22 files changed, 23 insertions(+), 23 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/3] umh, treewide: Explicitly include linux/umh.h where needed
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
The usermode helper declarations were previously provided by linux/kmod.h
but commit c1f3fa2a4fde ("kmod: split off umh headers into its own file")
moved them to linux/umh.h in 2017. Add explicit includes of linux/umh.h to
files that use usermode helpers and remove linux/kmod.h where it is no
longer needed.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
arch/x86/kernel/cpu/mce/dev-mcelog.c | 2 +-
drivers/block/drbd/drbd_nl.c | 1 +
drivers/greybus/svc_watchdog.c | 1 +
drivers/macintosh/windfarm_core.c | 1 +
drivers/pnp/pnpbios/core.c | 2 +-
drivers/video/fbdev/uvesafb.c | 1 +
fs/coredump.c | 2 +-
fs/nfs/cache_lib.c | 2 +-
fs/nfsd/nfs4layouts.c | 2 +-
fs/nfsd/nfs4recover.c | 1 +
fs/ocfs2/stackglue.c | 1 +
kernel/cgroup/cgroup-v1.c | 2 +-
kernel/module/kmod.c | 1 +
kernel/power/process.c | 2 +-
kernel/reboot.c | 2 +-
kernel/umh.c | 2 +-
lib/kobject_uevent.c | 2 +-
net/bridge/br_stp_if.c | 2 +-
security/keys/request_key.c | 2 +-
security/tomoyo/common.h | 2 +-
20 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/mce/dev-mcelog.c b/arch/x86/kernel/cpu/mce/dev-mcelog.c
index 053555206d81..af4e76babe7a 100644
--- a/arch/x86/kernel/cpu/mce/dev-mcelog.c
+++ b/arch/x86/kernel/cpu/mce/dev-mcelog.c
@@ -11,7 +11,7 @@
#include <linux/miscdevice.h>
#include <linux/slab.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/poll.h>
#include "internal.h"
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index f9ffcd67607b..de90cf4a0789 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/module.h>
+#include <linux/umh.h>
#include <linux/drbd.h>
#include <linux/in.h>
#include <linux/fs.h>
diff --git a/drivers/greybus/svc_watchdog.c b/drivers/greybus/svc_watchdog.c
index 16e6de5e9eff..b318eb34bcca 100644
--- a/drivers/greybus/svc_watchdog.c
+++ b/drivers/greybus/svc_watchdog.c
@@ -7,6 +7,7 @@
#include <linux/delay.h>
#include <linux/suspend.h>
+#include <linux/umh.h>
#include <linux/workqueue.h>
#include <linux/greybus.h>
diff --git a/drivers/macintosh/windfarm_core.c b/drivers/macintosh/windfarm_core.c
index 5307b1e34261..e66de11c69a3 100644
--- a/drivers/macintosh/windfarm_core.c
+++ b/drivers/macintosh/windfarm_core.c
@@ -34,6 +34,7 @@
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/freezer.h>
+#include <linux/umh.h>
#include "windfarm.h"
diff --git a/drivers/pnp/pnpbios/core.c b/drivers/pnp/pnpbios/core.c
index f7e86ae9f72f..46af1f549337 100644
--- a/drivers/pnp/pnpbios/core.c
+++ b/drivers/pnp/pnpbios/core.c
@@ -47,7 +47,7 @@
#include <linux/delay.h>
#include <linux/acpi.h>
#include <linux/freezer.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/kthread.h>
#include <asm/page.h>
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 9d82326c744f..6c503e6914d6 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -23,6 +23,7 @@
#include <linux/io.h>
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/umh.h>
#include <video/edid.h>
#include <video/uvesafb.h>
#ifdef CONFIG_X86
diff --git a/fs/coredump.c b/fs/coredump.c
index e68a76ff92a3..4908b44f6fdc 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -32,7 +32,7 @@
#include <linux/tsacct_kern.h>
#include <linux/cn_proc.h>
#include <linux/audit.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/fsnotify.h>
#include <linux/fs_struct.h>
#include <linux/pipe_fs_i.h>
diff --git a/fs/nfs/cache_lib.c b/fs/nfs/cache_lib.c
index 9738a1ae92ca..ca4e81d4e315 100644
--- a/fs/nfs/cache_lib.c
+++ b/fs/nfs/cache_lib.c
@@ -6,7 +6,7 @@
*
* Copyright (c) 2009 Trond Myklebust <Trond.Myklebust@netapp.com>
*/
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/mount.h>
diff --git a/fs/nfsd/nfs4layouts.c b/fs/nfsd/nfs4layouts.c
index f34320e4c2f4..008f0f088c3a 100644
--- a/fs/nfsd/nfs4layouts.c
+++ b/fs/nfsd/nfs4layouts.c
@@ -3,7 +3,7 @@
* Copyright (c) 2014 Christoph Hellwig.
*/
#include <linux/exportfs_block.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/file.h>
#include <linux/jhash.h>
#include <linux/sched.h>
diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 6ea25a52d2f4..20b98e43f668 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -41,6 +41,7 @@
#include <linux/fs.h>
#include <linux/hex.h>
#include <linux/module.h>
+#include <linux/umh.h>
#include <net/net_namespace.h>
#include <linux/sunrpc/rpc_pipe_fs.h>
#include <linux/sunrpc/clnt.h>
diff --git a/fs/ocfs2/stackglue.c b/fs/ocfs2/stackglue.c
index 741d6191d871..0ccaab29426d 100644
--- a/fs/ocfs2/stackglue.c
+++ b/fs/ocfs2/stackglue.c
@@ -18,6 +18,7 @@
#include <linux/kobject.h>
#include <linux/sysfs.h>
#include <linux/sysctl.h>
+#include <linux/umh.h>
#include "ocfs2_fs.h"
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index a4337c9b5287..cbcde5c28b18 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -2,7 +2,7 @@
#include "cgroup-internal.h"
#include <linux/ctype.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/sort.h>
#include <linux/delay.h>
#include <linux/mm.h>
diff --git a/kernel/module/kmod.c b/kernel/module/kmod.c
index a25dccdf7aa7..dcaad5d65275 100644
--- a/kernel/module/kmod.c
+++ b/kernel/module/kmod.c
@@ -28,6 +28,7 @@
#include <linux/ptrace.h>
#include <linux/async.h>
#include <linux/uaccess.h>
+#include <linux/umh.h>
#include <trace/events/module.h>
#include "internal.h"
diff --git a/kernel/power/process.c b/kernel/power/process.c
index dc0dfc349f22..295904ec9a82 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -16,7 +16,7 @@
#include <linux/freezer.h>
#include <linux/delay.h>
#include <linux/workqueue.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <trace/events/power.h>
#include <linux/cpuset.h>
diff --git a/kernel/reboot.c b/kernel/reboot.c
index 695c33e75efd..3d4a262973e7 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -11,13 +11,13 @@
#include <linux/ctype.h>
#include <linux/export.h>
#include <linux/kexec.h>
-#include <linux/kmod.h>
#include <linux/kmsg_dump.h>
#include <linux/reboot.h>
#include <linux/suspend.h>
#include <linux/syscalls.h>
#include <linux/syscore_ops.h>
#include <linux/uaccess.h>
+#include <linux/umh.h>
/*
* this indicates whether you can reboot with ctrl-alt-del: the default is yes
diff --git a/kernel/umh.c b/kernel/umh.c
index 48117c569e1a..72b2d9a878aa 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -8,7 +8,7 @@
#include <linux/binfmts.h>
#include <linux/syscalls.h>
#include <linux/unistd.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/slab.h>
#include <linux/completion.h>
#include <linux/cred.h>
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index ddbc4d7482d2..a67129e452a3 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -17,7 +17,7 @@
#include <linux/string.h>
#include <linux/kobject.h>
#include <linux/export.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/slab.h>
#include <linux/socket.h>
#include <linux/skbuff.h>
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index a7e5422eb5d1..89bc161a4b47 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -8,7 +8,7 @@
*/
#include <linux/kernel.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/etherdevice.h>
#include <linux/rtnetlink.h>
#include <net/switchdev.h>
diff --git a/security/keys/request_key.c b/security/keys/request_key.c
index fa2bb9f2f538..e6ba2d054399 100644
--- a/security/keys/request_key.c
+++ b/security/keys/request_key.c
@@ -9,7 +9,7 @@
#include <linux/export.h>
#include <linux/sched.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/err.h>
#include <linux/keyctl.h>
#include <linux/slab.h>
diff --git a/security/tomoyo/common.h b/security/tomoyo/common.h
index d098cf8aae61..d26034000913 100644
--- a/security/tomoyo/common.h
+++ b/security/tomoyo/common.h
@@ -16,7 +16,7 @@
#include <linux/string.h>
#include <linux/mm.h>
#include <linux/file.h>
-#include <linux/kmod.h>
+#include <linux/umh.h>
#include <linux/fs.h>
#include <linux/sched.h>
#include <linux/namei.h>
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/3] time/jiffies: Include linux/sysctl.h for proc_int_u2k_conv_uop(), ...
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
The kernel/time/jiffies.c file uses proc_int_u2k_conv_uop(),
proc_int_k2u_conv_kop(), proc_int_conv(), proc_dointvec_conv() and
proc_doulongvec_minmax_conv(), which are declared in linux/sysctl.h. It
currently relies on this header being included indirectly through
linux/module.h -> linux/kmod.h. Add the missing include in preparation for
removing the linux/sysctl.h include from linux/kmod.h.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
---
kernel/time/jiffies.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/time/jiffies.c b/kernel/time/jiffies.c
index d51428867a33..17cdb5ef8893 100644
--- a/kernel/time/jiffies.c
+++ b/kernel/time/jiffies.c
@@ -8,6 +8,7 @@
#include <linux/jiffies.h>
#include <linux/module.h>
#include <linux/init.h>
+#include <linux/sysctl.h>
#include "timekeeping.h"
#include "tick-internal.h"
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/3] module: Bring includes in linux/kmod.h up to date
From: Petr Pavlu @ 2026-07-21 13:11 UTC (permalink / raw)
To: Tony Luck, Borislav Petkov, Thomas Gleixner, Ingo Molnar,
Dave Hansen, x86, H. Peter Anvin, Philipp Reisner, Lars Ellenberg,
Christoph Böhmwalder, Jens Axboe, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Rafael J. Wysocki, Michal Januszewski,
Helge Deller, Alexander Viro, Christian Brauner, Jan Kara,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey, Mark Fasheh,
Joel Becker, Joseph Qi, Tejun Heo, Johannes Weiner,
Michal Koutný, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Pavel Machek, Len Brown,
Andrew Morton, Danilo Krummrich, Nikolay Aleksandrov,
Ido Schimmel, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Howells, Jarkko Sakkinen,
Paul Moore, James Morris, Serge E. Hallyn, Kentaro Takeda,
Tetsuo Handa
Cc: linux-edac, linux-kernel, drbd-dev, linux-block, greybus-dev,
linuxppc-dev, linux-acpi, linux-fbdev, dri-devel, linux-fsdevel,
linux-nfs, ocfs2-devel, cgroups, linux-modules, linux-pm,
driver-core, bridge, netdev, keyrings, linux-security-module
In-Reply-To: <20260721131207.803760-1-petr.pavlu@suse.com>
Including linux/kmod.h alone results in 1.5 MB of preprocessed output, even
though it provides only a few functions and macros.
The header currently depends on:
* __printf() -> linux/compiler_attributes.h,
* ENOSYS -> linux/errno.h,
* bool -> linux/types.h.
Include only these files, reducing the preprocessed output to 10 kB.
Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
---
include/linux/kmod.h | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index 9a07c3215389..b9474a62a568 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
@@ -2,17 +2,9 @@
#ifndef __LINUX_KMOD_H__
#define __LINUX_KMOD_H__
-/*
- * include/linux/kmod.h
- */
-
-#include <linux/umh.h>
-#include <linux/gfp.h>
-#include <linux/stddef.h>
+#include <linux/compiler_attributes.h>
#include <linux/errno.h>
-#include <linux/compiler.h>
-#include <linux/workqueue.h>
-#include <linux/sysctl.h>
+#include <linux/types.h>
#ifdef CONFIG_MODULES
/* modprobe exit status on success, -ve on error. Return value
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool()
From: Aneesh Kumar K.V @ 2026-07-21 14:20 UTC (permalink / raw)
To: Leon Romanovsky
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, 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: <20260721115456.GI110966@unreal>
Leon Romanovsky <leon@kernel.org> writes:
> On Fri, Jul 17, 2026 at 11:34:19PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> 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;
>
> Sorry for joining the discussion late, but the line above caught my
> attention.
>
> Why do we need both ret and page? We can derive cpu_addr from page and
> vice versa. Do we really need the &ret parameter? Or, more generally, do
> we really need "struct page *"?
>
> static struct page *__dma_alloc_from_pool(struct device *dev, size_t size,
> struct gen_pool *pool, void **cpu_addr,
> bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t))
> {
> ...
> *cpu_addr = (void *)addr;
> memset(*cpu_addr, 0, size);
> return pfn_to_page(__phys_to_pfn(phys));
> }
>
> Why
>
With CONFIG_DMA_DIRECT_REMAP the cpu_addr can be different from
page_address.
-aneesh
^ permalink raw reply
* Re: [PATCH v8 01/23] dma-direct: return struct page from dma_direct_alloc_from_pool()
From: Leon Romanovsky @ 2026-07-21 14:29 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: iommu, linux-arm-kernel, linux-kernel, linux-coco, 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: <yq5atsps77c5.fsf@kernel.org>
On Tue, Jul 21, 2026 at 07:50:10PM +0530, Aneesh Kumar K.V wrote:
> Leon Romanovsky <leon@kernel.org> writes:
>
> > On Fri, Jul 17, 2026 at 11:34:19PM +0530, Aneesh Kumar K.V (Arm) wrote:
> >> 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;
> >
> > Sorry for joining the discussion late, but the line above caught my
> > attention.
> >
> > Why do we need both ret and page? We can derive cpu_addr from page and
> > vice versa. Do we really need the &ret parameter? Or, more generally, do
> > we really need "struct page *"?
> >
> > static struct page *__dma_alloc_from_pool(struct device *dev, size_t size,
> > struct gen_pool *pool, void **cpu_addr,
> > bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t))
> > {
> > ...
> > *cpu_addr = (void *)addr;
> > memset(*cpu_addr, 0, size);
> > return pfn_to_page(__phys_to_pfn(phys));
> > }
> >
> > Why
> >
>
> With CONFIG_DMA_DIRECT_REMAP the cpu_addr can be different from
> page_address.
Can you please point to the code there it can happen?
__dma_alloc_from_pool() has direct connection between physical address
and struct page.
Thanks
>
> -aneesh
>
^ permalink raw reply
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