* Re: [PATCH] KVM: Validate irqchip index for LoongArch and PowerPC
From: Yanfei Xu @ 2026-05-31 14:02 UTC (permalink / raw)
To: Sean Christopherson, Yanfei Xu
Cc: zhaotianrui, maobibo, chenhuacai, maddy, npiggin, sashiko-reviews,
pbonzini, kvm, loongarch, linuxppc-dev, caixiangfeng,
fangying.tommy, Sashiko
In-Reply-To: <ahoYdrs9dVzp6Ps6@google.com>
On 2026/5/30 06:51, Sean Christopherson wrote:
> Can you split this into two patches, and send a v2? I suspect the reason no one
> has picked this up is because it straddles two completely different (sub)subsystems.
That makes sense. Done :)
Thanks,
Yanfei
>
> That would also make it easier to get the fixes backported to stable trees. PPC
> has been around a lot longer than LoongArch, so I assume the PPC fix will need to
> go further back in time.
>
> Thanks!
^ permalink raw reply
* Re: [PATCH v3] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Harsh Prateek Bora @ 2026-05-31 17:48 UTC (permalink / raw)
To: Gaurav Batra, maddy, Venkat Rao Bagalkote, sbhat
Cc: linuxppc-dev, ritesh.list, vaibhav, donettom
In-Reply-To: <20260515155143.39050-1-gbatra@linux.ibm.com>
+ Venkat
Hi Gaurav,
Would just like to confirm if it is tested with multiple iterations of
hotplug of RAM (DLPAR) as well?
Hi Venkat,
Could you please help validate the patch for above-mentioned scenario as
well?
Hi Shivaprasad,
Please share your review feedback or any additional testing scenarios
needed?
Thanks
Harsh
On 15/05/26 9:21 pm, Gaurav Batra wrote:
> In powerPC, if Dynamic DMA Window is big enough, RAM is pre-mapped. To
> determine the size of RAM, a PAPR+ property "ibm,lrdr-capacity" is used.
> This OF property dictates what is the max size of RAM an LPAR can have,
> including DR added memory.
>
> In PowerPC, 16GB pages can be allocated at machine level and then
> assigned to LPARs. These 16GB pages are added to LPAR memory at the time
> of boot. The address range for these 16GB pages is above MAX RAM an LPAR
> can have (ibm,lrdr-capacity). In the current implementation, these 16GB
> pages are being excluded from pre-mapped TCEs. A driver can have DMA
> buffers allocated from 16GB pages. This results in platform to raise an
> EEH when DMA is attempted on buffers in 16GB memory range.
>
> commit 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly
> adds TCEs for pmemory")
>
> Prior to the above patch, memblock_end_of_DRAM() was being used to
> determine the MAX memory of an LPAR. This included 16GB pages as well.
> The issue with using memblock_end_of_DRAM() is that when pmemory is
> converted to RAM via daxctl command, the DDW engine will incorrectly try
> to add TCEs for pmemory as well.
>
> Below is the address distribution of RAM, 16GB pages and pmemory for an
> LPAR with max memory of 256GB, memory allocated 64GB, 2 16GB pages and
> assigned pmemory of 8GB.
>
> RANGE SIZE STATE REMOVABLE BLOCK
> 0x0000000000000000-0x0000000fffffffff 64G online yes 0-255
> 0x0000004000000000-0x00000047ffffffff 32G online yes 1024-1151
>
> cat /sys/bus/nd/devices/region0/resource
> 0x40100000000
> cat /sys/bus/nd/devices/region0/size
> 8589934592
>
> The approach to fix this problem is to revert back the code changes
> introduced by the above patch and to stash away the MAX memory of an
> LPAR, including 16GB pages, at the LPAR boot time. This value is then
> used whenever TCEs are needed to be pre-mapped - enable_DDW() or,
> iommu_mem_notifier()
>
> Fixes: 6aa989ab2bd0 ("powerpc/pseries/iommu: memory notifier incorrectly adds TCEs for pmemory")
> Signed-off-by: Gaurav Batra <gbatra@linux.ibm.com>
> ---
>
> Change log:
>
> V2 -> V3
>
> 1. Harsh: Remove R-b tags from the change log
>
> Response: Incorporated changes
>
> 2. Harsh: Change WARN_ON() to WARN_ONCE()
>
> Response: Incorporated changes
>
> 3. Harsh: Fix indendation
>
> Response: Incorporated changes
>
> 4. Harsh: Replace comment with a log if limit < arg->nr_pages ?
>
> Response: Doesn't seems to be needed since the WARN_ONCE() will log this
> scenario. I removed the comment instead.
>
> V1 -> V2
>
> 1. Harsh: Not only start_pfn, but end_pfn also needs to be within allowed
> range, which may require clamping arg->nr_pages if crossing the limits.
>
> Response: Incorporated changes.
>
> arch/powerpc/platforms/pseries/iommu.c | 58 ++++++++++++++++++--------
> 1 file changed, 41 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 3e1f915fe4f6..7bbe070006fa 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -69,6 +69,8 @@ static struct iommu_table *iommu_pseries_alloc_table(int node)
> return tbl;
> }
>
> +static phys_addr_t pseries_ddw_max_ram;
> +
> #ifdef CONFIG_IOMMU_API
> static struct iommu_table_group_ops spapr_tce_table_group_ops;
> #endif
> @@ -1285,13 +1287,17 @@ static LIST_HEAD(failed_ddw_pdn_list);
>
> static phys_addr_t ddw_memory_hotplug_max(void)
> {
> - resource_size_t max_addr;
> + resource_size_t max_addr = memory_hotplug_max();
> + struct device_node *memory;
>
> -#if defined(CONFIG_NUMA) && defined(CONFIG_MEMORY_HOTPLUG)
> - max_addr = hot_add_drconf_memory_max();
> -#else
> - max_addr = memblock_end_of_DRAM();
> -#endif
> + for_each_node_by_type(memory, "memory") {
> + struct resource res;
> +
> + if (of_address_to_resource(memory, 0, &res))
> + continue;
> +
> + max_addr = max_t(resource_size_t, max_addr, res.end + 1);
> + }
>
> return max_addr;
> }
> @@ -1446,7 +1452,7 @@ static struct property *ddw_property_create(const char *propname, u32 liobn, u64
> static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn, u64 dma_mask)
> {
> int len = 0, ret;
> - int max_ram_len = order_base_2(ddw_memory_hotplug_max());
> + int max_ram_len = order_base_2(pseries_ddw_max_ram);
> struct ddw_query_response query;
> struct ddw_create_response create;
> int page_shift;
> @@ -1668,7 +1674,7 @@ static bool enable_ddw(struct pci_dev *dev, struct device_node *pdn, u64 dma_mas
>
> if (direct_mapping) {
> /* DDW maps the whole partition, so enable direct DMA mapping */
> - ret = walk_system_ram_range(0, ddw_memory_hotplug_max() >> PAGE_SHIFT,
> + ret = walk_system_ram_range(0, pseries_ddw_max_ram >> PAGE_SHIFT,
> win64->value, tce_setrange_multi_pSeriesLP_walk);
> if (ret) {
> dev_info(&dev->dev, "failed to map DMA window for %pOF: %d\n",
> @@ -2419,23 +2425,35 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
> {
> struct dma_win *window;
> struct memory_notify *arg = data;
> + unsigned long limit = arg->nr_pages;
> + unsigned long max_ram_pages = pseries_ddw_max_ram >> PAGE_SHIFT;
> int ret = 0;
>
> /* This notifier can get called when onlining persistent memory as well.
> * TCEs are not pre-mapped for persistent memory. Persistent memory will
> - * always be above ddw_memory_hotplug_max()
> + * always be above pseries_ddw_max_ram
> */
> + if (arg->start_pfn >= max_ram_pages)
> + return NOTIFY_OK;
> +
> + /* RAM is being DLPAR'ed. The range should never exceed max ram.
> + * Just in case, clamp the range and throw a warning.
> + */
> + if (arg->start_pfn + limit > max_ram_pages) {
> + limit = max_ram_pages - arg->start_pfn;
> + WARN_ONCE(1, "Limiting Page Range %lx - %lx to Max Mem Pages: %lx\n",
> + arg->start_pfn, arg->start_pfn + arg->nr_pages,
> + max_ram_pages);
> + }
>
> switch (action) {
> case MEM_GOING_ONLINE:
> spin_lock(&dma_win_list_lock);
> list_for_each_entry(window, &dma_win_list, list) {
> - if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
> - ddw_memory_hotplug_max()) {
> + if (window->direct) {
> ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
> - arg->nr_pages, window->prop);
> + limit, window->prop);
> }
> - /* XXX log error */
> }
> spin_unlock(&dma_win_list_lock);
> break;
> @@ -2443,12 +2461,10 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
> case MEM_OFFLINE:
> spin_lock(&dma_win_list_lock);
> list_for_each_entry(window, &dma_win_list, list) {
> - if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
> - ddw_memory_hotplug_max()) {
> + if (window->direct) {
> ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
> - arg->nr_pages, window->prop);
> + limit, window->prop);
> }
> - /* XXX log error */
> }
> spin_unlock(&dma_win_list_lock);
> break;
> @@ -2532,6 +2548,14 @@ void __init iommu_init_early_pSeries(void)
> register_memory_notifier(&iommu_mem_nb);
>
> set_pci_dma_ops(&dma_iommu_ops);
> +
> + /* During init determine the max memory an LPAR can have and set it. This
> + * will be used for pre-mapping RAM in DDW. memblock_end_of_DRAM() can
> + * change during the running of LPAR - daxctl can add pmemory as
> + * "system-ram". This memory range should not be pre-mapped in DDW since
> + * the address of pmemory can be much higher than the DDW size.
> + */
> + pseries_ddw_max_ram = ddw_memory_hotplug_max();
> }
>
> static int __init disable_multitce(char *str)
>
> base-commit: 6d35786de28116ecf78797a62b84e6bf3c45aa5a
^ permalink raw reply
* Re: [PATCH v3] powerpc/pseries/Kconfig: Enable CONFIG_VPA_PMU to be used with KVM
From: Harsh Prateek Bora @ 2026-05-31 16:49 UTC (permalink / raw)
To: Gautam Menghani, maddy, mpe, npiggin, chleroy
Cc: linuxppc-dev, linux-kernel, atrajeev, stable, Sean Christopherson
In-Reply-To: <20260529141032.69559-1-gautam@linux.ibm.com>
On 29/05/26 7:40 pm, Gautam Menghani wrote:
> Currently, CONFIG_VPA_PMU is not enabled any of the configs, and
Not sure what is meant by "any of the configs" , distros ?
We could just say "not enabled by default" ..
> consequently cannot be used for KVM guests at all.
.. consequently cannot be used for KVM guests unless explicitly enabled
on host kernel (which is currently ignored by distro configs)?
>
> Mark CONFIG_VPA_PMU as "default m" to ensure it is available when KVM is
> being used.
I think title could have been rephrased to focus on "default m" enablement.
>
> Fixes: 176cda0619b6c ("powerpc/perf: Add perf interface to expose vpa counters")
> Cc: stable@vger.kernel.org # v6.13+
> Suggested-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Gautam Menghani <gautam@linux.ibm.com>
> ---
> v2 -> v3:
> 1. Make CONFIG_VPA_PMU as default m so that it can separately disabled
> (Sean)
This indeed is more appropriate way for enablement, thanks Sean!
regards,
Harsh
>
> v1 -> v2:
> 1. Rebased on latest master
>
> arch/powerpc/platforms/pseries/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index f7052b131a4c..74910ce3a541 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -154,6 +154,7 @@ config HV_PERF_CTRS
> config VPA_PMU
> tristate "VPA PMU events"
> depends on KVM_BOOK3S_64_HV && HV_PERF_CTRS
> + default m
> help
> Enable access to the VPA PMU counters via perf. This enables
> code that support measurement for KVM on PowerVM(KoP) feature.
^ permalink raw reply
* Re: [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Eric Biggers @ 2026-05-31 16:00 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: linux-crypto, Herbert Xu, Christian Lamparter, linuxppc-dev,
linux-kernel, stable
In-Reply-To: <465adf3a-2c27-43d0-afdb-68ae12b89d10@wp.pl>
On Sun, May 31, 2026 at 12:15:49PM +0200, Aleksander Jan Bajkowski wrote:
> Hi Eric,
>
> On 30/05/2026 21:26, Eric Biggers wrote:
> > On Sat, May 30, 2026 at 05:05:19PM +0200, Aleksander Jan Bajkowski wrote:
> > > Hi Eric,
> > >
> > > On 30/05/2026 00:04, Eric Biggers wrote:
> > > > Remove crypto4xx_rng, as it is insecure and unused:
> > > >
> > > > - It has only a 64-bit security strength, which is highly inadequate.
> > > > This can be seen by the fact that crypto4xx_hw_init() seeds it with
> > > > only 64 bits of entropy, and the fact that the original commit
> > > > mentions that it implements ANSI X9.17 Annex C.
> > > In addition to a seed, the PRNG also uses ring oscillators as sources of
> > > entropy. The entropy should be higher than 64b. This is the Rambus EIP-73d
> > > IP core. The same IP core is built into eip93 (EIP-73a), eip97 (EIP-73d),
> > > and eip197 (EIP-73d). You can find the documentation online. The complete
> > > "container" is actually Rambus EIP-94, and one of its parts is EIP-73d.
> > Just because it may have another source of entropy doesn't mean its
> > security strength is higher than 64 bits.
> >
> > I cannot find any documentation other than
> > https://datasheet.octopart.com/PPC460EX-SUB800T-AMCC-datasheet-11553412.pdf
> > which says "ANSI X9.17 Annex C compliant using a DES algorithm".
> >
> > DES actually has a 56-bit key, so maybe I was over-generous.
> >
> > And according to https://cacr.uwaterloo.ca/hac/about/chap5.pdf ANSI
> > X9.17 has only a 64-bit state anyway. So even if we assume the
> > datasheet is incorrect and the algorithm is actually 3DES which has a
> > longer key, the state is likely still 64-bit.
> According to the datasheet, there is no second source of entropy. The PRNG
> has three built-in LFSRs. Each of them can be initialized independently. The
> first LFSR is used to generate input data. The second and third are used to
> generate keys for DES encryption. The output of the first LFSR is encrypted
> using 3DES with two 64-bit keys. Between individual DES operations, data is
> XORed with the seed. It sounds like a fairly secure design if properly
> reseeded.
> There is also a newer design (EIP73a) based on the same algorithm. The
> only difference is the replacing of 3DES with AES using a 2TDEA scheme.
> The DES-based variant is more widely used, even in new SoCs.
Okay, it sounds like you're walking back your claim that there's a
second source of entropy. That leaves just the 64-bit seed that the
driver writes to CRYPTO4XX_PRNG_SEED_L || CRYPTO4XX_PRNG_SEED_H, which
probably corresponds to the "first LFSR" you mentioned. The driver
doesn't initialize the other LFSRs.
> > So it isn't looking good. And since it's an undocumented proprietary
> > design it shouldn't be given the benefit of the doubt either.
> >
> As I mentioned earlier, this IP core is quite well documented[1] (page 198).
> Half of all SOHO routers have the EIP-73d built in. The algorithm is also
> described in TRM for some of these SoCs :)
>
> List od SoCs with EIP-73d:
> AMCC PPC405EX/PPC460EX,
> Intel/Maxlinear GRX350, URX850,
> Marvell Armada 37x0, 7k, 8k,
> Mediatek MT7623/MT7981/MT7986/MT7987/MT7988,
> Qualcomm IPQ975x.
>
> [1] https://www.scribd.com/document/734250956/Safexcel-Ip-94-Plb-Sas-v1-5?_gl=1*dng4pf*_up*MQ..*_ga*OTQ4NjkzMTAxLjE3ODAyMjA4ODI.*_ga_Z4ZC50DED6*czE3ODAyMjA4ODEkbzEkZzEkdDE3ODAyMjA4ODEkajYwJGwwJGgw*_ga_8KZ8BV0P5W*czE3ODAyMjA4ODEkbzEkZzEkdDE3ODAyMjA4ODEkajYwJGwwJGgw
The option to download the file is paywalled.
Anyway, even if it turns out that this is secure (it won't), it's still
unused code that should be removed anyway. The fact that it's not up to
modern security standards just provides some additional motivation.
- Eric
^ permalink raw reply
* Re: [v2 0/2] KVM: Validate irqchip index in routing entries
From: Greg KH @ 2026-05-31 15:25 UTC (permalink / raw)
To: Yanfei Xu
Cc: Yanfei Xu, harshpb, zhaotianrui, maobibo, chenhuacai, maddy,
npiggin, sashiko-reviews, seanjc, pbonzini, kvm, stable,
loongarch, linuxppc-dev, caixiangfeng, fangying.tommy
In-Reply-To: <5ee310d9-d432-400d-8506-751ee4a41fc6@gmail.com>
On Sun, May 31, 2026 at 10:36:27PM +0800, Yanfei Xu wrote:
>
> On 2026/5/31 22:15, Greg KH wrote:
> > > --
> > > 2.20.1
> > >
> > <formletter>
> >
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree. Please read:
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > for how to do this properly.
> >
> > </formletter>
>
> Thanks for pointing out the correct process. I saw
> that PPC maintainer added "Cc: stable@vger.kernel.org"
> on v1, so I mistakenly thought v2 should cc...
That's great, then take a look at the file above to show you how to do
that :)
^ permalink raw reply
* Re: [v2 0/2] KVM: Validate irqchip index in routing entries
From: Greg KH @ 2026-05-31 14:15 UTC (permalink / raw)
To: Yanfei Xu
Cc: harshpb, zhaotianrui, maobibo, chenhuacai, maddy, npiggin,
sashiko-reviews, seanjc, pbonzini, kvm, stable, loongarch,
linuxppc-dev, caixiangfeng, fangying.tommy, isyanfei.xu
In-Reply-To: <20260531135326.2238555-1-yanfei.xu@bytedance.com>
On Sun, May 31, 2026 at 09:53:24PM +0800, Yanfei Xu wrote:
> Validate irqchip indexes for LoongArch and PowerPC irq routing entries
> to reject out-of-range values before indexing the irqchip array.
>
> v1->v2:
> - Split the patch into two by architecture (Sean)
> - Pick up Reviewed-by
>
> Yanfei Xu (2):
> KVM: LoongArch: Validate irqchip index in irqfd routing
> KVM: PPC: Validate irqchip index in MPIC routing
>
> arch/loongarch/kvm/irqfd.c | 3 ++-
> arch/powerpc/kvm/mpic.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> --
> 2.20.1
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* [v2 2/2] KVM: PPC: Validate irqchip index in MPIC routing
From: Yanfei Xu @ 2026-05-31 13:53 UTC (permalink / raw)
To: harshpb, zhaotianrui, maobibo, chenhuacai, maddy, npiggin,
sashiko-reviews, seanjc, pbonzini
Cc: kvm, stable, loongarch, linuxppc-dev, caixiangfeng,
fangying.tommy, yanfei.xu, isyanfei.xu, Sashiko
In-Reply-To: <20260531135326.2238555-1-yanfei.xu@bytedance.com>
Sashiko reported that the irqchip index is not validated for PowerPC.
Add validation and reject out-of-range irqchip indexes to avoid indexing
past the routing table's chip array.
Fixes: de9ba2f36368 ("KVM: PPC: Support irq routing and irqfd for in-kernel MPIC")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/kvm/20260525051714.485D51F000E9@smtp.kernel.org/
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
---
arch/powerpc/kvm/mpic.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
index 3070f36d9fb8..fb5f9e65e02e 100644
--- a/arch/powerpc/kvm/mpic.c
+++ b/arch/powerpc/kvm/mpic.c
@@ -1833,7 +1833,8 @@ int kvm_set_routing_entry(struct kvm *kvm,
e->set = mpic_set_irq;
e->irqchip.irqchip = ue->u.irqchip.irqchip;
e->irqchip.pin = ue->u.irqchip.pin;
- if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS)
+ if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS ||
+ e->irqchip.irqchip >= KVM_NR_IRQCHIPS)
goto out;
break;
case KVM_IRQ_ROUTING_MSI:
--
2.20.1
^ permalink raw reply related
* [v2 1/2] KVM: LoongArch: Validate irqchip index in irqfd routing
From: Yanfei Xu @ 2026-05-31 13:53 UTC (permalink / raw)
To: harshpb, zhaotianrui, maobibo, chenhuacai, maddy, npiggin,
sashiko-reviews, seanjc, pbonzini
Cc: kvm, stable, loongarch, linuxppc-dev, caixiangfeng,
fangying.tommy, yanfei.xu, isyanfei.xu, Sashiko
In-Reply-To: <20260531135326.2238555-1-yanfei.xu@bytedance.com>
Sashiko reported that the irqchip index is not validated for LoongArch.
Add validation and reject out-of-range irqchip indexes to avoid indexing
past the routing table's chip array.
Fixes: 1928254c5ccb ("LoongArch: KVM: Add irqfd support")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/kvm/20260525051714.485D51F000E9@smtp.kernel.org/
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Yanfei Xu <yanfei.xu@bytedance.com>
---
arch/loongarch/kvm/irqfd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/loongarch/kvm/irqfd.c b/arch/loongarch/kvm/irqfd.c
index f4f953b22419..40ed1081c4b6 100644
--- a/arch/loongarch/kvm/irqfd.c
+++ b/arch/loongarch/kvm/irqfd.c
@@ -51,7 +51,8 @@ int kvm_set_routing_entry(struct kvm *kvm,
e->irqchip.irqchip = ue->u.irqchip.irqchip;
e->irqchip.pin = ue->u.irqchip.pin;
- if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS)
+ if (e->irqchip.pin >= KVM_IRQCHIP_NUM_PINS ||
+ e->irqchip.irqchip >= KVM_NR_IRQCHIPS)
return -EINVAL;
return 0;
--
2.20.1
^ permalink raw reply related
* [v2 0/2] KVM: Validate irqchip index in routing entries
From: Yanfei Xu @ 2026-05-31 13:53 UTC (permalink / raw)
To: harshpb, zhaotianrui, maobibo, chenhuacai, maddy, npiggin,
sashiko-reviews, seanjc, pbonzini
Cc: kvm, stable, loongarch, linuxppc-dev, caixiangfeng,
fangying.tommy, yanfei.xu, isyanfei.xu
Validate irqchip indexes for LoongArch and PowerPC irq routing entries
to reject out-of-range values before indexing the irqchip array.
v1->v2:
- Split the patch into two by architecture (Sean)
- Pick up Reviewed-by
Yanfei Xu (2):
KVM: LoongArch: Validate irqchip index in irqfd routing
KVM: PPC: Validate irqchip index in MPIC routing
arch/loongarch/kvm/irqfd.c | 3 ++-
arch/powerpc/kvm/mpic.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Aleksander Jan Bajkowski @ 2026-05-31 10:15 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Herbert Xu, Christian Lamparter, linuxppc-dev,
linux-kernel, stable
In-Reply-To: <20260530192630.GB6807@quark>
Hi Eric,
On 30/05/2026 21:26, Eric Biggers wrote:
> On Sat, May 30, 2026 at 05:05:19PM +0200, Aleksander Jan Bajkowski wrote:
>> Hi Eric,
>>
>> On 30/05/2026 00:04, Eric Biggers wrote:
>>> Remove crypto4xx_rng, as it is insecure and unused:
>>>
>>> - It has only a 64-bit security strength, which is highly inadequate.
>>> This can be seen by the fact that crypto4xx_hw_init() seeds it with
>>> only 64 bits of entropy, and the fact that the original commit
>>> mentions that it implements ANSI X9.17 Annex C.
>> In addition to a seed, the PRNG also uses ring oscillators as sources of
>> entropy. The entropy should be higher than 64b. This is the Rambus EIP-73d
>> IP core. The same IP core is built into eip93 (EIP-73a), eip97 (EIP-73d),
>> and eip197 (EIP-73d). You can find the documentation online. The complete
>> "container" is actually Rambus EIP-94, and one of its parts is EIP-73d.
> Just because it may have another source of entropy doesn't mean its
> security strength is higher than 64 bits.
>
> I cannot find any documentation other than
> https://datasheet.octopart.com/PPC460EX-SUB800T-AMCC-datasheet-11553412.pdf
> which says "ANSI X9.17 Annex C compliant using a DES algorithm".
>
> DES actually has a 56-bit key, so maybe I was over-generous.
>
> And according to https://cacr.uwaterloo.ca/hac/about/chap5.pdf ANSI
> X9.17 has only a 64-bit state anyway. So even if we assume the
> datasheet is incorrect and the algorithm is actually 3DES which has a
> longer key, the state is likely still 64-bit.
According to the datasheet, there is no second source of entropy. The PRNG
has three built-in LFSRs. Each of them can be initialized independently. The
first LFSR is used to generate input data. The second and third are used to
generate keys for DES encryption. The output of the first LFSR is encrypted
using 3DES with two 64-bit keys. Between individual DES operations, data is
XORed with the seed. It sounds like a fairly secure design if properly
reseeded.
There is also a newer design (EIP73a) based on the same algorithm. The
only difference is the replacing of 3DES with AES using a 2TDEA scheme.
The DES-based variant is more widely used, even in new SoCs.
>
> So it isn't looking good. And since it's an undocumented proprietary
> design it shouldn't be given the benefit of the doubt either.
>
As I mentioned earlier, this IP core is quite well documented[1] (page 198).
Half of all SOHO routers have the EIP-73d built in. The algorithm is also
described in TRM for some of these SoCs :)
List od SoCs with EIP-73d:
AMCC PPC405EX/PPC460EX,
Intel/Maxlinear GRX350, URX850,
Marvell Armada 37x0, 7k, 8k,
Mediatek MT7623/MT7981/MT7986/MT7987/MT7988,
Qualcomm IPQ975x.
[1]
https://www.scribd.com/document/734250956/Safexcel-Ip-94-Plb-Sas-v1-5?_gl=1*dng4pf*_up*MQ..*_ga*OTQ4NjkzMTAxLjE3ODAyMjA4ODI.*_ga_Z4ZC50DED6*czE3ODAyMjA4ODEkbzEkZzEkdDE3ODAyMjA4ODEkajYwJGwwJGgw*_ga_8KZ8BV0P5W*czE3ODAyMjA4ODEkbzEkZzEkdDE3ODAyMjA4ODEkajYwJGwwJGgw
Best regards,
Aleksander
^ permalink raw reply
* Re: [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Aleksander Jan Bajkowski @ 2026-05-30 15:05 UTC (permalink / raw)
To: Eric Biggers, linux-crypto, Herbert Xu
Cc: Christian Lamparter, linuxppc-dev, linux-kernel, stable
In-Reply-To: <20260529220430.34135-1-ebiggers@kernel.org>
Hi Eric,
On 30/05/2026 00:04, Eric Biggers wrote:
> Remove crypto4xx_rng, as it is insecure and unused:
>
> - It has only a 64-bit security strength, which is highly inadequate.
> This can be seen by the fact that crypto4xx_hw_init() seeds it with
> only 64 bits of entropy, and the fact that the original commit
> mentions that it implements ANSI X9.17 Annex C.
In addition to a seed, the PRNG also uses ring oscillators as sources of
entropy. The entropy should be higher than 64b. This is the Rambus EIP-73d
IP core. The same IP core is built into eip93 (EIP-73a), eip97 (EIP-73d),
and eip197 (EIP-73d). You can find the documentation online. The complete
"container" is actually Rambus EIP-94, and one of its parts is EIP-73d.
>
> Another issue was that this driver didn't implement the crypto_rng API
> correctly, as crypto4xx_prng_generate() didn't return 0 on success.
>
> - No user of this code is known. It's usable only theoretically via the
> "rng" algorithm type of AF_ALG. But userspace actually just uses the
> actual Linux RNG (/dev/random etc) instead. And rng_algs don't
> contribute entropy to the actual Linux RNG either. (This may have
> been confused with hwrng, which does contribute entropy.)
This PRNG is also used internally for Generation IV with IPSEC offload. The
IPSEC offload implementation for eip93 was recently submitted to upstream.
I am not sure whether eip94 shares some of the logic for IPSEC offload and
it will be possible to use some of the code.
>
> Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> drivers/crypto/Kconfig | 1 -
> drivers/crypto/amcc/crypto4xx_core.c | 88 -------------------------
> drivers/crypto/amcc/crypto4xx_core.h | 4 --
> drivers/crypto/amcc/crypto4xx_reg_def.h | 11 ----
> 4 files changed, 104 deletions(-)
>
>
> base-commit: 49e05bb00f2e8168695f7af4d694c39e1423e8a2
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 3449b3c9c6ad..5dab813a9f74 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -299,11 +299,10 @@ config CRYPTO_DEV_PPC4XX
> select CRYPTO_AES
> select CRYPTO_LIB_AES
> select CRYPTO_CCM
> select CRYPTO_CTR
> select CRYPTO_GCM
> - select CRYPTO_RNG
> select CRYPTO_SKCIPHER
> help
> This option allows you to have support for AMCC crypto acceleration.
>
> config HW_RANDOM_PPC4XX
> diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c
> index b7b6c97d2147..68c5ff7a85b4 100644
> --- a/drivers/crypto/amcc/crypto4xx_core.c
> +++ b/drivers/crypto/amcc/crypto4xx_core.c
> @@ -29,15 +29,13 @@
> #include <crypto/aead.h>
> #include <crypto/aes.h>
> #include <crypto/ctr.h>
> #include <crypto/gcm.h>
> #include <crypto/sha1.h>
> -#include <crypto/rng.h>
> #include <crypto/scatterwalk.h>
> #include <crypto/skcipher.h>
> #include <crypto/internal/aead.h>
> -#include <crypto/internal/rng.h>
> #include <crypto/internal/skcipher.h>
> #include "crypto4xx_reg_def.h"
> #include "crypto4xx_core.h"
> #include "crypto4xx_sa.h"
> #include "crypto4xx_trng.h"
> @@ -983,14 +981,10 @@ static int crypto4xx_register_alg(struct crypto4xx_device *sec_dev,
> switch (alg->alg.type) {
> case CRYPTO_ALG_TYPE_AEAD:
> rc = crypto_register_aead(&alg->alg.u.aead);
> break;
>
> - case CRYPTO_ALG_TYPE_RNG:
> - rc = crypto_register_rng(&alg->alg.u.rng);
> - break;
> -
> default:
> rc = crypto_register_skcipher(&alg->alg.u.cipher);
> break;
> }
>
> @@ -1012,14 +1006,10 @@ static void crypto4xx_unregister_alg(struct crypto4xx_device *sec_dev)
> switch (alg->alg.type) {
> case CRYPTO_ALG_TYPE_AEAD:
> crypto_unregister_aead(&alg->alg.u.aead);
> break;
>
> - case CRYPTO_ALG_TYPE_RNG:
> - crypto_unregister_rng(&alg->alg.u.rng);
> - break;
> -
> default:
> crypto_unregister_skcipher(&alg->alg.u.cipher);
> }
> kfree(alg);
> }
> @@ -1074,73 +1064,10 @@ static irqreturn_t crypto4xx_ce_interrupt_handler_revb(int irq, void *data)
> {
> return crypto4xx_interrupt_handler(irq, data, PPC4XX_INTERRUPT_CLR |
> PPC4XX_TMO_ERR_INT);
> }
>
> -static int ppc4xx_prng_data_read(struct crypto4xx_device *dev,
> - u8 *data, unsigned int max)
> -{
> - unsigned int i, curr = 0;
> - u32 val[2];
> -
> - do {
> - /* trigger PRN generation */
> - writel(PPC4XX_PRNG_CTRL_AUTO_EN,
> - dev->ce_base + CRYPTO4XX_PRNG_CTRL);
> -
> - for (i = 0; i < 1024; i++) {
> - /* usually 19 iterations are enough */
> - if ((readl(dev->ce_base + CRYPTO4XX_PRNG_STAT) &
> - CRYPTO4XX_PRNG_STAT_BUSY))
> - continue;
> -
> - val[0] = readl_be(dev->ce_base + CRYPTO4XX_PRNG_RES_0);
> - val[1] = readl_be(dev->ce_base + CRYPTO4XX_PRNG_RES_1);
> - break;
> - }
> - if (i == 1024)
> - return -ETIMEDOUT;
> -
> - if ((max - curr) >= 8) {
> - memcpy(data, &val, 8);
> - data += 8;
> - curr += 8;
> - } else {
> - /* copy only remaining bytes */
> - memcpy(data, &val, max - curr);
> - break;
> - }
> - } while (curr < max);
> -
> - return curr;
> -}
> -
> -static int crypto4xx_prng_generate(struct crypto_rng *tfm,
> - const u8 *src, unsigned int slen,
> - u8 *dstn, unsigned int dlen)
> -{
> - struct rng_alg *alg = crypto_rng_alg(tfm);
> - struct crypto4xx_alg *amcc_alg;
> - struct crypto4xx_device *dev;
> - int ret;
> -
> - amcc_alg = container_of(alg, struct crypto4xx_alg, alg.u.rng);
> - dev = amcc_alg->dev;
> -
> - mutex_lock(&dev->core_dev->rng_lock);
> - ret = ppc4xx_prng_data_read(dev, dstn, dlen);
> - mutex_unlock(&dev->core_dev->rng_lock);
> - return ret;
> -}
> -
> -
> -static int crypto4xx_prng_seed(struct crypto_rng *tfm, const u8 *seed,
> - unsigned int slen)
> -{
> - return 0;
> -}
> -
> /*
> * Supported Crypto Algorithms
> */
> static struct crypto4xx_alg_common crypto4xx_alg[] = {
> /* Crypto AES modes */
> @@ -1266,22 +1193,10 @@ static struct crypto4xx_alg_common crypto4xx_alg[] = {
> .cra_blocksize = 1,
> .cra_ctxsize = sizeof(struct crypto4xx_ctx),
> .cra_module = THIS_MODULE,
> },
> } },
> - { .type = CRYPTO_ALG_TYPE_RNG, .u.rng = {
> - .base = {
> - .cra_name = "stdrng",
> - .cra_driver_name = "crypto4xx_rng",
> - .cra_priority = 300,
> - .cra_ctxsize = 0,
> - .cra_module = THIS_MODULE,
> - },
> - .generate = crypto4xx_prng_generate,
> - .seed = crypto4xx_prng_seed,
> - .seedsize = 0,
> - } },
> };
>
> /*
> * Module Initialization Routine
> */
> @@ -1351,13 +1266,10 @@ static int crypto4xx_probe(struct platform_device *ofdev)
> }
>
> core_dev->dev->core_dev = core_dev;
> core_dev->dev->is_revb = is_revb;
> core_dev->device = dev;
> - rc = devm_mutex_init(&ofdev->dev, &core_dev->rng_lock);
> - if (rc)
> - return rc;
> spin_lock_init(&core_dev->lock);
> INIT_LIST_HEAD(&core_dev->dev->alg_list);
> ratelimit_default_init(&core_dev->dev->aead_ratelimit);
> rc = crypto4xx_build_sdr(core_dev->dev);
> if (rc)
> diff --git a/drivers/crypto/amcc/crypto4xx_core.h b/drivers/crypto/amcc/crypto4xx_core.h
> index ee36630c670f..3a028aec3f0c 100644
> --- a/drivers/crypto/amcc/crypto4xx_core.h
> +++ b/drivers/crypto/amcc/crypto4xx_core.h
> @@ -12,14 +12,12 @@
>
> #ifndef __CRYPTO4XX_CORE_H__
> #define __CRYPTO4XX_CORE_H__
>
> #include <linux/ratelimit.h>
> -#include <linux/mutex.h>
> #include <linux/scatterlist.h>
> #include <crypto/internal/aead.h>
> -#include <crypto/internal/rng.h>
> #include <crypto/internal/skcipher.h>
> #include "crypto4xx_reg_def.h"
> #include "crypto4xx_sa.h"
>
> #define PPC460SX_SDR0_SRST 0x201
> @@ -109,11 +107,10 @@ struct crypto4xx_core_device {
> struct hwrng *trng;
> u32 int_status;
> u32 irq;
> struct tasklet_struct tasklet;
> spinlock_t lock;
> - struct mutex rng_lock;
> };
>
> struct crypto4xx_ctx {
> struct crypto4xx_device *dev;
> struct dynamic_sa_ctl *sa_in;
> @@ -133,11 +130,10 @@ struct crypto4xx_aead_reqctx {
> struct crypto4xx_alg_common {
> u32 type;
> union {
> struct skcipher_alg cipher;
> struct aead_alg aead;
> - struct rng_alg rng;
> } u;
> };
>
> struct crypto4xx_alg {
> struct list_head entry;
> diff --git a/drivers/crypto/amcc/crypto4xx_reg_def.h b/drivers/crypto/amcc/crypto4xx_reg_def.h
> index 1038061224da..73d626308a84 100644
> --- a/drivers/crypto/amcc/crypto4xx_reg_def.h
> +++ b/drivers/crypto/amcc/crypto4xx_reg_def.h
> @@ -88,24 +88,13 @@
>
> #define CRYPTO4XX_DMA_CFG 0x000600d4
> #define CRYPTO4XX_BYTE_ORDER_CFG 0x000600d8
> #define CRYPTO4XX_ENDIAN_CFG 0x000600d8
>
> -#define CRYPTO4XX_PRNG_STAT 0x00070000
> -#define CRYPTO4XX_PRNG_STAT_BUSY 0x1
> #define CRYPTO4XX_PRNG_CTRL 0x00070004
> #define CRYPTO4XX_PRNG_SEED_L 0x00070008
> #define CRYPTO4XX_PRNG_SEED_H 0x0007000c
> -
> -#define CRYPTO4XX_PRNG_RES_0 0x00070020
> -#define CRYPTO4XX_PRNG_RES_1 0x00070024
> -#define CRYPTO4XX_PRNG_RES_2 0x00070028
> -#define CRYPTO4XX_PRNG_RES_3 0x0007002C
> -
> -#define CRYPTO4XX_PRNG_LFSR_L 0x00070030
> -#define CRYPTO4XX_PRNG_LFSR_H 0x00070034
> -
> /*
> * Initialize CRYPTO ENGINE registers, and memory bases.
> */
> #define PPC4XX_PDR_POLL 0x3ff
> #define PPC4XX_OUTPUT_THRESHOLD 2
^ permalink raw reply
* Re: [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Eric Biggers @ 2026-05-30 19:26 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: linux-crypto, Herbert Xu, Christian Lamparter, linuxppc-dev,
linux-kernel, stable
In-Reply-To: <5c74c261-53cf-4185-a8a0-7554bc9fe5f7@wp.pl>
On Sat, May 30, 2026 at 05:05:19PM +0200, Aleksander Jan Bajkowski wrote:
> Hi Eric,
>
> On 30/05/2026 00:04, Eric Biggers wrote:
> > Remove crypto4xx_rng, as it is insecure and unused:
> >
> > - It has only a 64-bit security strength, which is highly inadequate.
> > This can be seen by the fact that crypto4xx_hw_init() seeds it with
> > only 64 bits of entropy, and the fact that the original commit
> > mentions that it implements ANSI X9.17 Annex C.
>
> In addition to a seed, the PRNG also uses ring oscillators as sources of
> entropy. The entropy should be higher than 64b. This is the Rambus EIP-73d
> IP core. The same IP core is built into eip93 (EIP-73a), eip97 (EIP-73d),
> and eip197 (EIP-73d). You can find the documentation online. The complete
> "container" is actually Rambus EIP-94, and one of its parts is EIP-73d.
Just because it may have another source of entropy doesn't mean its
security strength is higher than 64 bits.
I cannot find any documentation other than
https://datasheet.octopart.com/PPC460EX-SUB800T-AMCC-datasheet-11553412.pdf
which says "ANSI X9.17 Annex C compliant using a DES algorithm".
DES actually has a 56-bit key, so maybe I was over-generous.
And according to https://cacr.uwaterloo.ca/hac/about/chap5.pdf ANSI
X9.17 has only a 64-bit state anyway. So even if we assume the
datasheet is incorrect and the algorithm is actually 3DES which has a
longer key, the state is likely still 64-bit.
So it isn't looking good. And since it's an undocumented proprietary
design it shouldn't be given the benefit of the doubt either.
> This PRNG is also used internally for Generation IV with IPSEC offload. The
> IPSEC offload implementation for eip93 was recently submitted to upstream.
> I am not sure whether eip94 shares some of the logic for IPSEC offload and
> it will be possible to use some of the code.
That's not related to this patch.
- Eric
^ permalink raw reply
* Re: [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Eric Biggers @ 2026-05-30 19:12 UTC (permalink / raw)
To: Christian Lamparter
Cc: linux-crypto, Herbert Xu, linuxppc-dev, linux-kernel, stable
In-Reply-To: <e0b3cfc2-c6da-46d4-9dec-027dafaba74e@gmail.com>
On Sat, May 30, 2026 at 12:20:57PM +0200, Christian Lamparter wrote:
> > diff --git a/drivers/crypto/amcc/crypto4xx_reg_def.h b/drivers/crypto/amcc/crypto4xx_reg_def.h
> > index 1038061224da..73d626308a84 100644
> > --- a/drivers/crypto/amcc/crypto4xx_reg_def.h
> > +++ b/drivers/crypto/amcc/crypto4xx_reg_def.h
> > @@ -88,24 +88,13 @@
> > #define CRYPTO4XX_DMA_CFG 0x000600d4
> > #define CRYPTO4XX_BYTE_ORDER_CFG 0x000600d8
> > #define CRYPTO4XX_ENDIAN_CFG 0x000600d8
> > -#define CRYPTO4XX_PRNG_STAT 0x00070000
> > -#define CRYPTO4XX_PRNG_STAT_BUSY 0x1
> > #define CRYPTO4XX_PRNG_CTRL 0x00070004
> > #define CRYPTO4XX_PRNG_SEED_L 0x00070008
> > #define CRYPTO4XX_PRNG_SEED_H 0x0007000c
> > -
> > -#define CRYPTO4XX_PRNG_RES_0 0x00070020
> > -#define CRYPTO4XX_PRNG_RES_1 0x00070024
> > -#define CRYPTO4XX_PRNG_RES_2 0x00070028
> > -#define CRYPTO4XX_PRNG_RES_3 0x0007002C
> > -
> > -#define CRYPTO4XX_PRNG_LFSR_L 0x00070030
> > -#define CRYPTO4XX_PRNG_LFSR_H 0x00070034
> > -
>
> Hmm, don't think these defines will hurt anyone? As these are part of the hardware spec.
> Or do you forsee a future where AI-Agents will sent patches hallucinating that it "fixed"
> the issue which readds it? I have no idea.
Well, there's not really any point in keeping these when they aren't
used.
- Eric
^ permalink raw reply
* Re: [PATCH v7 12/15] sh: Drop cache flush of the zero page at boot
From: Mike Rapoport @ 2026-05-30 16:19 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, catalin.marinas,
mark.rutland, Ard Biesheuvel, Ryan Roberts, Anshuman Khandual,
Kevin Brodsky, Liz Prucka, Seth Jenkins, Kees Cook,
David Hildenbrand, Andrew Morton, Jann Horn, linux-mm,
linux-hardening, linuxppc-dev, linux-sh, Yoshinori Sato,
Rich Felker, John Paul Adrian Glaubitz, Geert Uytterhoeven
In-Reply-To: <20260529150150.1670604-29-ardb+git@google.com>
On Fri, May 29, 2026 at 05:02:03PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> SuperH performs cache maintenance on the zero page during boot,
> presumably because before commit
>
> 6215d9f4470f ("arch, mm: consolidate empty_zero_page")
>
> the zero page did double duty as a boot params region, and was cleared
> separately, as it was not part of BSS. The memset() in question was
> dropped by that commit, but the __flush_wback_region() call remained.
>
> As empty_zero_page[] has been moved to BSS, it can be treated as any
> other BSS memory, and so the cache flush can be dropped.
>
> Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
> Cc: Rich Felker <dalias@libc.org>
> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> arch/sh/mm/init.c | 3 ---
> 1 file changed, 3 deletions(-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH] scsi: core: Remove dead code export of scsi_device_from_queue
From: John Paul Adrian Glaubitz @ 2026-05-30 12:46 UTC (permalink / raw)
To: Catalin Iacob, Thomas Bogendoerfer, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Yoshinori Sato, Rich Felker, David S. Miller, Andreas Larsson,
James E.J. Bottomley, Martin K. Petersen, Jens Axboe
Cc: linux-mips, linux-kernel, linuxppc-dev, linux-sh, sparclinux,
linux-scsi
In-Reply-To: <20260530-remove-pktcdvd-references-v1-1-aa56941d4315@gmail.com>
Hi Catalin,
On Sat, 2026-05-30 at 15:31 +0300, Catalin Iacob wrote:
> Commit 1cea5180f2f8 ("block: remove pktcdvd driver") left behind some
> CONFIG_CONFIG_CDROM_PKTCDVD* references in defconfigs and around an
> export. Remove them.
>
> Signed-off-by: Catalin Iacob <iacobcatalin@gmail.com>
> ---
> Found this incidentally while looking at kernel sources to understand
> what pktcdvd is
> ---
> arch/mips/configs/fuloong2e_defconfig | 1 -
> arch/mips/configs/ip22_defconfig | 1 -
> arch/mips/configs/ip27_defconfig | 1 -
> arch/mips/configs/ip30_defconfig | 1 -
> arch/mips/configs/jazz_defconfig | 1 -
> arch/mips/configs/malta_defconfig | 1 -
> arch/mips/configs/malta_kvm_defconfig | 1 -
> arch/mips/configs/maltaup_xpa_defconfig | 1 -
> arch/mips/configs/rm200_defconfig | 1 -
> arch/mips/configs/sb1250_swarm_defconfig | 1 -
> arch/powerpc/configs/g5_defconfig | 1 -
> arch/powerpc/configs/ppc6xx_defconfig | 1 -
> arch/sh/configs/sh2007_defconfig | 1 -
> arch/sparc/configs/sparc64_defconfig | 2 --
> drivers/scsi/scsi_lib.c | 8 --------
> 15 files changed, 23 deletions(-)
>
> diff --git a/arch/mips/configs/fuloong2e_defconfig b/arch/mips/configs/fuloong2e_defconfig
> index b6fe3c962464..840130a73992 100644
> --- a/arch/mips/configs/fuloong2e_defconfig
> +++ b/arch/mips/configs/fuloong2e_defconfig
> @@ -89,7 +89,6 @@ CONFIG_MTD_CFI_STAA=m
> CONFIG_MTD_PHYSMAP=m
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=m
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_BLK_DEV_SD=y
> CONFIG_BLK_DEV_SR=y
> diff --git a/arch/mips/configs/ip22_defconfig b/arch/mips/configs/ip22_defconfig
> index e123848f94ab..61f09cc9ac12 100644
> --- a/arch/mips/configs/ip22_defconfig
> +++ b/arch/mips/configs/ip22_defconfig
> @@ -177,7 +177,6 @@ CONFIG_NET_ACT_SIMP=m
> CONFIG_NET_ACT_SKBEDIT=m
> CONFIG_RFKILL=m
> CONFIG_CONNECTOR=m
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_RAID_ATTRS=m
> CONFIG_SCSI=y
> diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
> index fea0ccee6948..60da9cf71b72 100644
> --- a/arch/mips/configs/ip27_defconfig
> +++ b/arch/mips/configs/ip27_defconfig
> @@ -83,7 +83,6 @@ CONFIG_CFG80211=m
> CONFIG_MAC80211=m
> CONFIG_RFKILL=m
> CONFIG_BLK_DEV_LOOP=y
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_SCSI=y
> CONFIG_BLK_DEV_SD=y
> diff --git a/arch/mips/configs/ip30_defconfig b/arch/mips/configs/ip30_defconfig
> index 718f3060d9fa..5c2911ff9a87 100644
> --- a/arch/mips/configs/ip30_defconfig
> +++ b/arch/mips/configs/ip30_defconfig
> @@ -77,7 +77,6 @@ CONFIG_NET_ACT_PEDIT=m
> CONFIG_NET_ACT_SKBEDIT=m
> # CONFIG_VGA_ARB is not set
> CONFIG_BLK_DEV_LOOP=y
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_SCSI=y
> CONFIG_BLK_DEV_SD=y
> diff --git a/arch/mips/configs/jazz_defconfig b/arch/mips/configs/jazz_defconfig
> index a790c2610fd3..dd3486b8d1fc 100644
> --- a/arch/mips/configs/jazz_defconfig
> +++ b/arch/mips/configs/jazz_defconfig
> @@ -33,7 +33,6 @@ CONFIG_BLK_DEV_FD=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=m
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_RAID_ATTRS=m
> CONFIG_SCSI=y
> diff --git a/arch/mips/configs/malta_defconfig b/arch/mips/configs/malta_defconfig
> index 81704ec67f09..b10dac71f400 100644
> --- a/arch/mips/configs/malta_defconfig
> +++ b/arch/mips/configs/malta_defconfig
> @@ -224,7 +224,6 @@ CONFIG_BLK_DEV_FD=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=y
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_RAID_ATTRS=m
> CONFIG_BLK_DEV_SD=y
> diff --git a/arch/mips/configs/malta_kvm_defconfig b/arch/mips/configs/malta_kvm_defconfig
> index 82a97f58bce1..bdd5d99884e3 100644
> --- a/arch/mips/configs/malta_kvm_defconfig
> +++ b/arch/mips/configs/malta_kvm_defconfig
> @@ -228,7 +228,6 @@ CONFIG_BLK_DEV_FD=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=y
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_RAID_ATTRS=m
> CONFIG_BLK_DEV_SD=y
> diff --git a/arch/mips/configs/maltaup_xpa_defconfig b/arch/mips/configs/maltaup_xpa_defconfig
> index 0f9ef20744f9..523c0ff329ac 100644
> --- a/arch/mips/configs/maltaup_xpa_defconfig
> +++ b/arch/mips/configs/maltaup_xpa_defconfig
> @@ -226,7 +226,6 @@ CONFIG_BLK_DEV_FD=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=y
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_RAID_ATTRS=m
> CONFIG_BLK_DEV_SD=y
> diff --git a/arch/mips/configs/rm200_defconfig b/arch/mips/configs/rm200_defconfig
> index ad9fbd0cbb38..60054e54bc5a 100644
> --- a/arch/mips/configs/rm200_defconfig
> +++ b/arch/mips/configs/rm200_defconfig
> @@ -177,7 +177,6 @@ CONFIG_PARIDE_ON26=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=m
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_RAID_ATTRS=m
> CONFIG_SCSI=y
> diff --git a/arch/mips/configs/sb1250_swarm_defconfig b/arch/mips/configs/sb1250_swarm_defconfig
> index 4a25b8d3e507..a50a7c097542 100644
> --- a/arch/mips/configs/sb1250_swarm_defconfig
> +++ b/arch/mips/configs/sb1250_swarm_defconfig
> @@ -43,7 +43,6 @@ CONFIG_FW_LOADER=m
> CONFIG_CONNECTOR=m
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_SIZE=9220
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_ATA_OVER_ETH=m
> CONFIG_RAID_ATTRS=m
> CONFIG_BLK_DEV_SD=y
> diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
> index 5ca1676e6058..647775f6d174 100644
> --- a/arch/powerpc/configs/g5_defconfig
> +++ b/arch/powerpc/configs/g5_defconfig
> @@ -57,7 +57,6 @@ CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_SIZE=65536
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_BLK_DEV_SD=y
> CONFIG_CHR_DEV_ST=y
> CONFIG_BLK_DEV_SR=y
> diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
> index eda1fec7ffd9..5c3e25fd8edd 100644
> --- a/arch/powerpc/configs/ppc6xx_defconfig
> +++ b/arch/powerpc/configs/ppc6xx_defconfig
> @@ -306,7 +306,6 @@ CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_NBD=m
> CONFIG_BLK_DEV_RAM=y
> CONFIG_BLK_DEV_RAM_SIZE=16384
> -CONFIG_CDROM_PKTCDVD=m
> CONFIG_VIRTIO_BLK=m
> CONFIG_ENCLOSURE_SERVICES=m
> CONFIG_SENSORS_TSL2550=m
> diff --git a/arch/sh/configs/sh2007_defconfig b/arch/sh/configs/sh2007_defconfig
> index 5d9080499485..f287a41cd38c 100644
> --- a/arch/sh/configs/sh2007_defconfig
> +++ b/arch/sh/configs/sh2007_defconfig
> @@ -45,7 +45,6 @@ CONFIG_NETWORK_SECMARK=y
> CONFIG_NET_PKTGEN=y
> CONFIG_BLK_DEV_LOOP=y
> CONFIG_BLK_DEV_RAM=y
> -CONFIG_CDROM_PKTCDVD=y
> CONFIG_RAID_ATTRS=y
> CONFIG_SCSI=y
> CONFIG_BLK_DEV_SD=y
> diff --git a/arch/sparc/configs/sparc64_defconfig b/arch/sparc/configs/sparc64_defconfig
> index 632081a262ba..4abea39281cd 100644
> --- a/arch/sparc/configs/sparc64_defconfig
> +++ b/arch/sparc/configs/sparc64_defconfig
> @@ -60,8 +60,6 @@ CONFIG_CONNECTOR=m
> CONFIG_BLK_DEV_LOOP=m
> CONFIG_BLK_DEV_CRYPTOLOOP=m
> CONFIG_BLK_DEV_NBD=m
> -CONFIG_CDROM_PKTCDVD=m
> -CONFIG_CDROM_PKTCDVD_WCACHE=y
> CONFIG_ATA_OVER_ETH=m
> CONFIG_SUNVDC=m
> CONFIG_ATA=y
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 6e8c7a42603e..f836212c2acf 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -2201,14 +2201,6 @@ struct scsi_device *scsi_device_from_queue(struct request_queue *q)
>
> return sdev;
> }
> -/*
> - * pktcdvd should have been integrated into the SCSI layers, but for historical
> - * reasons like the old IDE driver it isn't. This export allows it to safely
> - * probe if a given device is a SCSI one and only attach to that.
> - */
> -#ifdef CONFIG_CDROM_PKTCDVD_MODULE
> -EXPORT_SYMBOL_GPL(scsi_device_from_queue);
> -#endif
>
> /**
> * scsi_block_requests - Utility function used by low-level drivers to prevent
>
> ---
> base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
> change-id: 20260530-remove-pktcdvd-references-9d5c6362a5de
>
> Best regards,
> --
> Catalin Iacob <iacobcatalin@gmail.com>
I think the commit message should rather be:
scsi: core: Remove remaining references to CONFIG_CDROM_PKTCDVD
or better
scsi: core: Remove remaining references to package CD/DVD support
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [PATCH] scsi: core: Remove dead code export of scsi_device_from_queue
From: Catalin Iacob @ 2026-05-30 12:31 UTC (permalink / raw)
To: Thomas Bogendoerfer, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Yoshinori Sato,
Rich Felker, John Paul Adrian Glaubitz, David S. Miller,
Andreas Larsson, James E.J. Bottomley, Martin K. Petersen,
Jens Axboe
Cc: linux-mips, linux-kernel, linuxppc-dev, linux-sh, sparclinux,
linux-scsi, Catalin Iacob
Commit 1cea5180f2f8 ("block: remove pktcdvd driver") left behind some
CONFIG_CONFIG_CDROM_PKTCDVD* references in defconfigs and around an
export. Remove them.
Signed-off-by: Catalin Iacob <iacobcatalin@gmail.com>
---
Found this incidentally while looking at kernel sources to understand
what pktcdvd is
---
arch/mips/configs/fuloong2e_defconfig | 1 -
arch/mips/configs/ip22_defconfig | 1 -
arch/mips/configs/ip27_defconfig | 1 -
arch/mips/configs/ip30_defconfig | 1 -
arch/mips/configs/jazz_defconfig | 1 -
arch/mips/configs/malta_defconfig | 1 -
arch/mips/configs/malta_kvm_defconfig | 1 -
arch/mips/configs/maltaup_xpa_defconfig | 1 -
arch/mips/configs/rm200_defconfig | 1 -
arch/mips/configs/sb1250_swarm_defconfig | 1 -
arch/powerpc/configs/g5_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 1 -
arch/sh/configs/sh2007_defconfig | 1 -
arch/sparc/configs/sparc64_defconfig | 2 --
drivers/scsi/scsi_lib.c | 8 --------
15 files changed, 23 deletions(-)
diff --git a/arch/mips/configs/fuloong2e_defconfig b/arch/mips/configs/fuloong2e_defconfig
index b6fe3c962464..840130a73992 100644
--- a/arch/mips/configs/fuloong2e_defconfig
+++ b/arch/mips/configs/fuloong2e_defconfig
@@ -89,7 +89,6 @@ CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_PHYSMAP=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=m
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
diff --git a/arch/mips/configs/ip22_defconfig b/arch/mips/configs/ip22_defconfig
index e123848f94ab..61f09cc9ac12 100644
--- a/arch/mips/configs/ip22_defconfig
+++ b/arch/mips/configs/ip22_defconfig
@@ -177,7 +177,6 @@ CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_RFKILL=m
CONFIG_CONNECTOR=m
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
diff --git a/arch/mips/configs/ip27_defconfig b/arch/mips/configs/ip27_defconfig
index fea0ccee6948..60da9cf71b72 100644
--- a/arch/mips/configs/ip27_defconfig
+++ b/arch/mips/configs/ip27_defconfig
@@ -83,7 +83,6 @@ CONFIG_CFG80211=m
CONFIG_MAC80211=m
CONFIG_RFKILL=m
CONFIG_BLK_DEV_LOOP=y
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
diff --git a/arch/mips/configs/ip30_defconfig b/arch/mips/configs/ip30_defconfig
index 718f3060d9fa..5c2911ff9a87 100644
--- a/arch/mips/configs/ip30_defconfig
+++ b/arch/mips/configs/ip30_defconfig
@@ -77,7 +77,6 @@ CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SKBEDIT=m
# CONFIG_VGA_ARB is not set
CONFIG_BLK_DEV_LOOP=y
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
diff --git a/arch/mips/configs/jazz_defconfig b/arch/mips/configs/jazz_defconfig
index a790c2610fd3..dd3486b8d1fc 100644
--- a/arch/mips/configs/jazz_defconfig
+++ b/arch/mips/configs/jazz_defconfig
@@ -33,7 +33,6 @@ CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
diff --git a/arch/mips/configs/malta_defconfig b/arch/mips/configs/malta_defconfig
index 81704ec67f09..b10dac71f400 100644
--- a/arch/mips/configs/malta_defconfig
+++ b/arch/mips/configs/malta_defconfig
@@ -224,7 +224,6 @@ CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_RAID_ATTRS=m
CONFIG_BLK_DEV_SD=y
diff --git a/arch/mips/configs/malta_kvm_defconfig b/arch/mips/configs/malta_kvm_defconfig
index 82a97f58bce1..bdd5d99884e3 100644
--- a/arch/mips/configs/malta_kvm_defconfig
+++ b/arch/mips/configs/malta_kvm_defconfig
@@ -228,7 +228,6 @@ CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_RAID_ATTRS=m
CONFIG_BLK_DEV_SD=y
diff --git a/arch/mips/configs/maltaup_xpa_defconfig b/arch/mips/configs/maltaup_xpa_defconfig
index 0f9ef20744f9..523c0ff329ac 100644
--- a/arch/mips/configs/maltaup_xpa_defconfig
+++ b/arch/mips/configs/maltaup_xpa_defconfig
@@ -226,7 +226,6 @@ CONFIG_BLK_DEV_FD=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_RAID_ATTRS=m
CONFIG_BLK_DEV_SD=y
diff --git a/arch/mips/configs/rm200_defconfig b/arch/mips/configs/rm200_defconfig
index ad9fbd0cbb38..60054e54bc5a 100644
--- a/arch/mips/configs/rm200_defconfig
+++ b/arch/mips/configs/rm200_defconfig
@@ -177,7 +177,6 @@ CONFIG_PARIDE_ON26=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
diff --git a/arch/mips/configs/sb1250_swarm_defconfig b/arch/mips/configs/sb1250_swarm_defconfig
index 4a25b8d3e507..a50a7c097542 100644
--- a/arch/mips/configs/sb1250_swarm_defconfig
+++ b/arch/mips/configs/sb1250_swarm_defconfig
@@ -43,7 +43,6 @@ CONFIG_FW_LOADER=m
CONFIG_CONNECTOR=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=9220
-CONFIG_CDROM_PKTCDVD=m
CONFIG_ATA_OVER_ETH=m
CONFIG_RAID_ATTRS=m
CONFIG_BLK_DEV_SD=y
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 5ca1676e6058..647775f6d174 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -57,7 +57,6 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=65536
-CONFIG_CDROM_PKTCDVD=m
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_SR=y
diff --git a/arch/powerpc/configs/ppc6xx_defconfig b/arch/powerpc/configs/ppc6xx_defconfig
index eda1fec7ffd9..5c3e25fd8edd 100644
--- a/arch/powerpc/configs/ppc6xx_defconfig
+++ b/arch/powerpc/configs/ppc6xx_defconfig
@@ -306,7 +306,6 @@ CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=16384
-CONFIG_CDROM_PKTCDVD=m
CONFIG_VIRTIO_BLK=m
CONFIG_ENCLOSURE_SERVICES=m
CONFIG_SENSORS_TSL2550=m
diff --git a/arch/sh/configs/sh2007_defconfig b/arch/sh/configs/sh2007_defconfig
index 5d9080499485..f287a41cd38c 100644
--- a/arch/sh/configs/sh2007_defconfig
+++ b/arch/sh/configs/sh2007_defconfig
@@ -45,7 +45,6 @@ CONFIG_NETWORK_SECMARK=y
CONFIG_NET_PKTGEN=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
-CONFIG_CDROM_PKTCDVD=y
CONFIG_RAID_ATTRS=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
diff --git a/arch/sparc/configs/sparc64_defconfig b/arch/sparc/configs/sparc64_defconfig
index 632081a262ba..4abea39281cd 100644
--- a/arch/sparc/configs/sparc64_defconfig
+++ b/arch/sparc/configs/sparc64_defconfig
@@ -60,8 +60,6 @@ CONFIG_CONNECTOR=m
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
-CONFIG_CDROM_PKTCDVD=m
-CONFIG_CDROM_PKTCDVD_WCACHE=y
CONFIG_ATA_OVER_ETH=m
CONFIG_SUNVDC=m
CONFIG_ATA=y
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 6e8c7a42603e..f836212c2acf 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2201,14 +2201,6 @@ struct scsi_device *scsi_device_from_queue(struct request_queue *q)
return sdev;
}
-/*
- * pktcdvd should have been integrated into the SCSI layers, but for historical
- * reasons like the old IDE driver it isn't. This export allows it to safely
- * probe if a given device is a SCSI one and only attach to that.
- */
-#ifdef CONFIG_CDROM_PKTCDVD_MODULE
-EXPORT_SYMBOL_GPL(scsi_device_from_queue);
-#endif
/**
* scsi_block_requests - Utility function used by low-level drivers to prevent
---
base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
change-id: 20260530-remove-pktcdvd-references-9d5c6362a5de
Best regards,
--
Catalin Iacob <iacobcatalin@gmail.com>
^ permalink raw reply related
* Re: PowerPC: Random memory corruption causing kernel oops on Power11
From: David Laight @ 2026-05-30 11:03 UTC (permalink / raw)
To: Paul Moore
Cc: Venkat Rao Bagalkote, linuxppc-dev, Madhavan Srinivasan, selinux,
rppt, LKML, Ritesh Harjani, Christophe Leroy (CS GROUP)
In-Reply-To: <CAHC9VhRAbCAxg4swOCBT+nAUaqRPsdBuOa+nm=539ejpN4wmWQ@mail.gmail.com>
On Fri, 29 May 2026 14:23:06 -0400
Paul Moore <paul@paul-moore.com> wrote:
> On Fri, May 29, 2026 at 12:18 PM David Laight
...
> > PAGE_SIZE is not the length of the buffer.
> > Should be PATH_MAX.
>
> Yes, as discussed earlier in the thread some additional work needs to
> be done, and verified, but since we are at the end of -rc5 I simply
> reverted the patch. We can chase this down next dev cycle.
>
Emails crossed in the afternoon...
Like many of these changes the buffer size should never have been PAGE_SIZE.
Clearly here PATH_MAX is the best way to say 4096.
But I suspect some of the others should be (say) BUF_4K.
I wonder how much userspace code is left that does 'char buf[BUFSIZE]' and
just assumes it is 'big enough'.
-- David
^ permalink raw reply
* Re: [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Christian Lamparter @ 2026-05-30 10:20 UTC (permalink / raw)
To: Eric Biggers, linux-crypto, Herbert Xu; +Cc: linuxppc-dev, linux-kernel, stable
In-Reply-To: <20260529220430.34135-1-ebiggers@kernel.org>
Hi!
On 5/30/26 12:04 AM, Eric Biggers wrote:
> Remove crypto4xx_rng, as it is insecure and unused:
>
> - It has only a 64-bit security strength, which is highly inadequate.
> This can be seen by the fact that crypto4xx_hw_init() seeds it with
> only 64 bits of entropy, and the fact that the original commit
> mentions that it implements ANSI X9.17 Annex C.
Yes, that "ANSI X9.17 Annex C" comes from the datasheet for the PRNG.
> Another issue was that this driver didn't implement the crypto_rng API
> correctly, as crypto4xx_prng_generate() didn't return 0 on success.
Oh! Hmm, I think I copied that "return amount;" from another driver that
had it implemented? But I'm not sure, this was sooo long ago. That said,
if this never worked...
> - No user of this code is known. It's usable only theoretically via the
> "rng" algorithm type of AF_ALG. But userspace actually just uses the
> actual Linux RNG (/dev/random etc) instead. And rng_algs don't
> contribute entropy to the actual Linux RNG either. (This may have
> been confused with hwrng, which does contribute entropy.)
... and it's completely redundant: Sure!
just in case, this counts for anything, but as the person that added it in the
first place:
Acked-by: Christian Lamparter <chunkeey@gmail.com>
> Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> drivers/crypto/Kconfig | 1 -
> drivers/crypto/amcc/crypto4xx_core.c | 88 -------------------------
> drivers/crypto/amcc/crypto4xx_core.h | 4 --
> drivers/crypto/amcc/crypto4xx_reg_def.h | 11 ----
> 4 files changed, 104 deletions(-)
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 3449b3c9c6ad..5dab813a9f74 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -299,11 +299,10 @@ config CRYPTO_DEV_PPC4XX
> select CRYPTO_AES
> select CRYPTO_LIB_AES
> select CRYPTO_CCM
> select CRYPTO_CTR
> select CRYPTO_GCM
> - select CRYPTO_RNG
> select CRYPTO_SKCIPHER
> help
> This option allows you to have support for AMCC crypto acceleration.
>
> config HW_RANDOM_PPC4XX
> diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c
> index b7b6c97d2147..68c5ff7a85b4 100644
> --- a/drivers/crypto/amcc/crypto4xx_core.c
> +++ b/drivers/crypto/amcc/crypto4xx_core.c
> @@ -29,15 +29,13 @@
> #include <crypto/aead.h>
> #include <crypto/aes.h>
> #include <crypto/ctr.h>
> #include <crypto/gcm.h>
> #include <crypto/sha1.h>
> -#include <crypto/rng.h>
> #include <crypto/scatterwalk.h>
> #include <crypto/skcipher.h>
> #include <crypto/internal/aead.h>
> -#include <crypto/internal/rng.h>
> #include <crypto/internal/skcipher.h>
> #include "crypto4xx_reg_def.h"
> #include "crypto4xx_core.h"
> #include "crypto4xx_sa.h"
> #include "crypto4xx_trng.h"
> @@ -983,14 +981,10 @@ static int crypto4xx_register_alg(struct crypto4xx_device *sec_dev,
> switch (alg->alg.type) {
> case CRYPTO_ALG_TYPE_AEAD:
> rc = crypto_register_aead(&alg->alg.u.aead);
> break;
>
> - case CRYPTO_ALG_TYPE_RNG:
> - rc = crypto_register_rng(&alg->alg.u.rng);
> - break;
> -
> default:
> rc = crypto_register_skcipher(&alg->alg.u.cipher);
> break;
> }
>
> @@ -1012,14 +1006,10 @@ static void crypto4xx_unregister_alg(struct crypto4xx_device *sec_dev)
> switch (alg->alg.type) {
> case CRYPTO_ALG_TYPE_AEAD:
> crypto_unregister_aead(&alg->alg.u.aead);
> break;
>
> - case CRYPTO_ALG_TYPE_RNG:
> - crypto_unregister_rng(&alg->alg.u.rng);
> - break;
> -
> default:
> crypto_unregister_skcipher(&alg->alg.u.cipher);
> }
> kfree(alg);
> }
> @@ -1074,73 +1064,10 @@ static irqreturn_t crypto4xx_ce_interrupt_handler_revb(int irq, void *data)
> {
> return crypto4xx_interrupt_handler(irq, data, PPC4XX_INTERRUPT_CLR |
> PPC4XX_TMO_ERR_INT);
> }
>
> -static int ppc4xx_prng_data_read(struct crypto4xx_device *dev,
> - u8 *data, unsigned int max)
> -{
> - unsigned int i, curr = 0;
> - u32 val[2];
> -
> - do {
> - /* trigger PRN generation */
> - writel(PPC4XX_PRNG_CTRL_AUTO_EN,
> - dev->ce_base + CRYPTO4XX_PRNG_CTRL);
> -
> - for (i = 0; i < 1024; i++) {
> - /* usually 19 iterations are enough */
> - if ((readl(dev->ce_base + CRYPTO4XX_PRNG_STAT) &
> - CRYPTO4XX_PRNG_STAT_BUSY))
> - continue;
> -
> - val[0] = readl_be(dev->ce_base + CRYPTO4XX_PRNG_RES_0);
> - val[1] = readl_be(dev->ce_base + CRYPTO4XX_PRNG_RES_1);
> - break;
> - }
> - if (i == 1024)
> - return -ETIMEDOUT;
> -
> - if ((max - curr) >= 8) {
> - memcpy(data, &val, 8);
> - data += 8;
> - curr += 8;
> - } else {
> - /* copy only remaining bytes */
> - memcpy(data, &val, max - curr);
> - break;
> - }
> - } while (curr < max);
> -
> - return curr;
> -}
> -
> -static int crypto4xx_prng_generate(struct crypto_rng *tfm,
> - const u8 *src, unsigned int slen,
> - u8 *dstn, unsigned int dlen)
> -{
> - struct rng_alg *alg = crypto_rng_alg(tfm);
> - struct crypto4xx_alg *amcc_alg;
> - struct crypto4xx_device *dev;
> - int ret;
> -
> - amcc_alg = container_of(alg, struct crypto4xx_alg, alg.u.rng);
> - dev = amcc_alg->dev;
> -
> - mutex_lock(&dev->core_dev->rng_lock);
> - ret = ppc4xx_prng_data_read(dev, dstn, dlen);
> - mutex_unlock(&dev->core_dev->rng_lock);
> - return ret;
> -}
> -
> -
> -static int crypto4xx_prng_seed(struct crypto_rng *tfm, const u8 *seed,
> - unsigned int slen)
> -{
> - return 0;
> -}
> -
> /*
> * Supported Crypto Algorithms
> */
> static struct crypto4xx_alg_common crypto4xx_alg[] = {
> /* Crypto AES modes */
> @@ -1266,22 +1193,10 @@ static struct crypto4xx_alg_common crypto4xx_alg[] = {
> .cra_blocksize = 1,
> .cra_ctxsize = sizeof(struct crypto4xx_ctx),
> .cra_module = THIS_MODULE,
> },
> } },
> - { .type = CRYPTO_ALG_TYPE_RNG, .u.rng = {
> - .base = {
> - .cra_name = "stdrng",
> - .cra_driver_name = "crypto4xx_rng",
> - .cra_priority = 300,
> - .cra_ctxsize = 0,
> - .cra_module = THIS_MODULE,
> - },
> - .generate = crypto4xx_prng_generate,
> - .seed = crypto4xx_prng_seed,
> - .seedsize = 0,
> - } },
> };
>
> /*
> * Module Initialization Routine
> */
> @@ -1351,13 +1266,10 @@ static int crypto4xx_probe(struct platform_device *ofdev)
> }
>
> core_dev->dev->core_dev = core_dev;
> core_dev->dev->is_revb = is_revb;
> core_dev->device = dev;
> - rc = devm_mutex_init(&ofdev->dev, &core_dev->rng_lock);
> - if (rc)
> - return rc;
> spin_lock_init(&core_dev->lock);
> INIT_LIST_HEAD(&core_dev->dev->alg_list);
> ratelimit_default_init(&core_dev->dev->aead_ratelimit);
> rc = crypto4xx_build_sdr(core_dev->dev);
> if (rc)
> diff --git a/drivers/crypto/amcc/crypto4xx_core.h b/drivers/crypto/amcc/crypto4xx_core.h
> index ee36630c670f..3a028aec3f0c 100644
> --- a/drivers/crypto/amcc/crypto4xx_core.h
> +++ b/drivers/crypto/amcc/crypto4xx_core.h
> @@ -12,14 +12,12 @@
>
> #ifndef __CRYPTO4XX_CORE_H__
> #define __CRYPTO4XX_CORE_H__
>
> #include <linux/ratelimit.h>
> -#include <linux/mutex.h>
> #include <linux/scatterlist.h>
> #include <crypto/internal/aead.h>
> -#include <crypto/internal/rng.h>
> #include <crypto/internal/skcipher.h>
> #include "crypto4xx_reg_def.h"
> #include "crypto4xx_sa.h"
>
> #define PPC460SX_SDR0_SRST 0x201
> @@ -109,11 +107,10 @@ struct crypto4xx_core_device {
> struct hwrng *trng;
> u32 int_status;
> u32 irq;
> struct tasklet_struct tasklet;
> spinlock_t lock;
> - struct mutex rng_lock;
> };
>
> struct crypto4xx_ctx {
> struct crypto4xx_device *dev;
> struct dynamic_sa_ctl *sa_in;
> @@ -133,11 +130,10 @@ struct crypto4xx_aead_reqctx {
> struct crypto4xx_alg_common {
> u32 type;
> union {
> struct skcipher_alg cipher;
> struct aead_alg aead;
> - struct rng_alg rng;
> } u;
> };
>
> struct crypto4xx_alg {
> struct list_head entry;
> diff --git a/drivers/crypto/amcc/crypto4xx_reg_def.h b/drivers/crypto/amcc/crypto4xx_reg_def.h
> index 1038061224da..73d626308a84 100644
> --- a/drivers/crypto/amcc/crypto4xx_reg_def.h
> +++ b/drivers/crypto/amcc/crypto4xx_reg_def.h
> @@ -88,24 +88,13 @@
>
> #define CRYPTO4XX_DMA_CFG 0x000600d4
> #define CRYPTO4XX_BYTE_ORDER_CFG 0x000600d8
> #define CRYPTO4XX_ENDIAN_CFG 0x000600d8
>
> -#define CRYPTO4XX_PRNG_STAT 0x00070000
> -#define CRYPTO4XX_PRNG_STAT_BUSY 0x1
> #define CRYPTO4XX_PRNG_CTRL 0x00070004
> #define CRYPTO4XX_PRNG_SEED_L 0x00070008
> #define CRYPTO4XX_PRNG_SEED_H 0x0007000c
> -
> -#define CRYPTO4XX_PRNG_RES_0 0x00070020
> -#define CRYPTO4XX_PRNG_RES_1 0x00070024
> -#define CRYPTO4XX_PRNG_RES_2 0x00070028
> -#define CRYPTO4XX_PRNG_RES_3 0x0007002C
> -
> -#define CRYPTO4XX_PRNG_LFSR_L 0x00070030
> -#define CRYPTO4XX_PRNG_LFSR_H 0x00070034
> -
Hmm, don't think these defines will hurt anyone? As these are part of the hardware spec.
Or do you forsee a future where AI-Agents will sent patches hallucinating that it "fixed"
the issue which readds it? I have no idea.
> /*
> * Initialize CRYPTO ENGINE registers, and memory bases.
> */
> #define PPC4XX_PDR_POLL 0x3ff
> #define PPC4XX_OUTPUT_THRESHOLD 2
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH] perf script powerpc: Update the hcall list with new hcalls
From: Arnaldo Carvalho de Melo @ 2026-05-30 0:01 UTC (permalink / raw)
To: Tejas Manhas
Cc: Gautam Menghani, peterz, mingo, namhyung, mark.rutland,
alexander.shishkin, jolsa, irogers, adrian.hunter, james.clark,
atrajeev, Gautam Menghani, linux-perf-users, linuxppc-dev,
linux-kernel
In-Reply-To: <61c8d600-72b4-4320-a1ff-18e061569f24@linux.ibm.com>
On Wed, May 20, 2026 at 09:25:08AM +0530, Tejas Manhas wrote:
> From: Gautam Menghani [1]<gautam@linux.ibm.com>
>
> Update the hcall list with the hcalls in bcc's ppchcalls script [1].
>
> [1] : [2]https://github.com/iovisor/bcc/blob/master/tools/ppchcalls.py
>
>
> Hi Gautam,
>
> This patch doesn't seem to resolve the issue where numbers are seen instead of h
> calls.
> I have applied to the latest upstream but the numbers are still visible in perf
> script.
> Also the command doesn't recognise python-audit already present in the system.
>
> Please find logs below for better understanding.
Any progress on this?
- Arnaldo
> before patch
> # perf record -a -e powerpc:hcall* sleep 10
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.343 MB perf.data (2388 samples) ]
> [root@ltcden14-lp10 perf]# perf script -s ./powerpc-hcalls.py -i ./perf.data
> Install the python-audit package to get syscall names.
> For example:
> # apt-get install python3-audit (Ubuntu)
> # yum install python3-audit (Fedora)
> etc.
>
> hcall count min(ns) max(ns) avg(ns)
> --------------------------------------------------------------------
> H_VIO_SIGNAL 614 376 14068 1644
> 584 36 1094 16120 2839
> H_ADD_LOGICAL_LAN_BUFFER 9 660 3572 1320
> H_STUFF_TCE 132 632 12530 1310
> H_PUT_TCE 236 466 5500 865
> H_RANDOM 4 446 3300 1168
> H_PUT_TCE_INDIRECT 53 648 14318 2066
> H_SEND_CRQ 108 848 7754 1983
> after patch
> # yum install python3-audit
> Updating Subscription Management repositories.
> Unable to read consumer identity
>
> This system is not registered with an entitlement server. You can use subscripti
> on-manager to register.
>
> rhe12_debug1 8.4 kB/s | 1.5 kB 00:00
> rh102_base_upd 41 kB/s | 2.7 kB 00:00
> rh102_app_upd 14 kB/s | 2.8 kB 00:00
> rh102_crb 14 kB/s | 2.7 kB 00:00
> rh102_srcbase 7.6 kB/s | 1.5 kB 00:00
> rh102_srcas 6.9 kB/s | 1.5 kB 00:00
> rh102_debug 7.1 kB/s | 1.5 kB 00:00
> rhe102_debug1 7.1 kB/s | 1.5 kB 00:00
> Package python3-audit-4.0.3-5.el10.ppc64le is already installed.
> Dependencies resolved.
> Nothing to do.
> Complete!
> # ./perf script -s scripts/python/powerpc-hcalls.py -i ./perf.data
> Install the python-audit package to get syscall names.
> For example:
> # apt-get install python3-audit (Ubuntu)
> # yum install python3-audit (Fedora)
> etc.
>
> hcall count min(ns) max(ns) avg(ns)
> --------------------------------------------------------------------
> H_VIO_SIGNAL 533 404 13154 1638
> 584 37 1034 14722 3178
> H_ADD_LOGICAL_LAN_BUFFER 8 802 2602 1217
> H_SEND_CRQ 11 926 17536 4105
> H_STUFF_TCE 13 658 5306 1974
> H_PUT_TCE 18 476 5034 1476
> H_PUT_TCE_INDIRECT 5 1698 8934 4370
> [root@ltcden14-lp10 perf]#
>
> Please add the tag below.
> Reported-by: Tejas Manhas [4]<tejas05@linux.ibm.com>
>
> Thanks & Regards,
> Tejas
>
> References
>
> 1. mailto:gautam@linux.ibm.com
> 2. https://github.com/iovisor/bcc/blob/master/tools/ppchcalls.py
> 3. mailto:gautam@linux.ibm.com
> 4. mailto:tejas05@linux.ibm.com
^ permalink raw reply
* Re: [PATCH] KVM: Validate irqchip index for LoongArch and PowerPC
From: Sean Christopherson @ 2026-05-29 22:51 UTC (permalink / raw)
To: Yanfei Xu
Cc: zhaotianrui, maobibo, chenhuacai, maddy, npiggin, sashiko-reviews,
pbonzini, kvm, loongarch, linuxppc-dev, caixiangfeng,
fangying.tommy, isyanfei.xu, Sashiko
In-Reply-To: <20260525070154.495455-1-yanfei.xu@bytedance.com>
On Mon, May 25, 2026, Yanfei Xu wrote:
> Sashiko reported that irqchip index is not validated for LoongArch and
> PowerPC. Add validation and reject out-of-range irqchip indexes to avoid
> indexing past the routing table's chip array.
Can you split this into two patches, and send a v2? I suspect the reason no one
has picked this up is because it straddles two completely different (sub)subsystems.
That would also make it easier to get the fixes backported to stable trees. PPC
has been around a lot longer than LoongArch, so I assume the PPC fix will need to
go further back in time.
Thanks!
^ permalink raw reply
* Re: (subset) [PATCH 00/23] driver core: count references of the platform device's fwnode, not OF node
From: Srinivas Kandagatla @ 2026-05-29 12:55 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Greg Kroah-Hartman, Vinod Koul, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Andy Shevchenko,
Joerg Roedel, Will Deacon, Robin Murphy, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Matthew Brost, Thomas Hellström, Rodrigo Vivi,
David Airlie, Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu,
Philipp Zabel, Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, Bartosz Golaszewski
Cc: brgl, linux-kernel, netdev, linux-arm-msm, linux-sound,
driver-core, devicetree, linuxppc-dev, linux-i2c, iommu, linux-pm,
imx, linux-arm-kernel, intel-xe, dri-devel, linux-usb, linux-mips,
platform-driver-x86, stable
In-Reply-To: <20260521-pdev-fwnode-ref-v1-0-88c324a1b8d2@oss.qualcomm.com>
On Thu, 21 May 2026 10:36:23 +0200, Bartosz Golaszewski wrote:
> I'd like to first apologize for the long, treewide series and an
> extensive Cc list but I think it's important to show the big picture and
> the end result of this rework.
>
> Platform device core provides helper interfaces for dealing with
> dynamically created platform devices. Most users should use
> platform_device_register_full() which encapsulates most of the
> operations but some modules will want to use the split approach of
> calling platform_device_alloc() + platform_device_add() separately for
> various reasons.
>
> [...]
Applied, thanks!
[03/23] slimbus: qcom-ngd-ctrl: fix OF node refcount
commit: 0208edaf0b32cae5b922729c4ef52dcd865e2e19
Best regards,
--
Srinivas Kandagatla <srini@kernel.org>
^ permalink raw reply
* [PATCH] crypto: crypto4xx - Remove insecure and unused rng_alg
From: Eric Biggers @ 2026-05-29 22:04 UTC (permalink / raw)
To: linux-crypto, Herbert Xu
Cc: Christian Lamparter, linuxppc-dev, linux-kernel, Eric Biggers,
stable
Remove crypto4xx_rng, as it is insecure and unused:
- It has only a 64-bit security strength, which is highly inadequate.
This can be seen by the fact that crypto4xx_hw_init() seeds it with
only 64 bits of entropy, and the fact that the original commit
mentions that it implements ANSI X9.17 Annex C.
Another issue was that this driver didn't implement the crypto_rng API
correctly, as crypto4xx_prng_generate() didn't return 0 on success.
- No user of this code is known. It's usable only theoretically via the
"rng" algorithm type of AF_ALG. But userspace actually just uses the
actual Linux RNG (/dev/random etc) instead. And rng_algs don't
contribute entropy to the actual Linux RNG either. (This may have
been confused with hwrng, which does contribute entropy.)
Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
drivers/crypto/Kconfig | 1 -
drivers/crypto/amcc/crypto4xx_core.c | 88 -------------------------
drivers/crypto/amcc/crypto4xx_core.h | 4 --
drivers/crypto/amcc/crypto4xx_reg_def.h | 11 ----
4 files changed, 104 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 3449b3c9c6ad..5dab813a9f74 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -299,11 +299,10 @@ config CRYPTO_DEV_PPC4XX
select CRYPTO_AES
select CRYPTO_LIB_AES
select CRYPTO_CCM
select CRYPTO_CTR
select CRYPTO_GCM
- select CRYPTO_RNG
select CRYPTO_SKCIPHER
help
This option allows you to have support for AMCC crypto acceleration.
config HW_RANDOM_PPC4XX
diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c
index b7b6c97d2147..68c5ff7a85b4 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -29,15 +29,13 @@
#include <crypto/aead.h>
#include <crypto/aes.h>
#include <crypto/ctr.h>
#include <crypto/gcm.h>
#include <crypto/sha1.h>
-#include <crypto/rng.h>
#include <crypto/scatterwalk.h>
#include <crypto/skcipher.h>
#include <crypto/internal/aead.h>
-#include <crypto/internal/rng.h>
#include <crypto/internal/skcipher.h>
#include "crypto4xx_reg_def.h"
#include "crypto4xx_core.h"
#include "crypto4xx_sa.h"
#include "crypto4xx_trng.h"
@@ -983,14 +981,10 @@ static int crypto4xx_register_alg(struct crypto4xx_device *sec_dev,
switch (alg->alg.type) {
case CRYPTO_ALG_TYPE_AEAD:
rc = crypto_register_aead(&alg->alg.u.aead);
break;
- case CRYPTO_ALG_TYPE_RNG:
- rc = crypto_register_rng(&alg->alg.u.rng);
- break;
-
default:
rc = crypto_register_skcipher(&alg->alg.u.cipher);
break;
}
@@ -1012,14 +1006,10 @@ static void crypto4xx_unregister_alg(struct crypto4xx_device *sec_dev)
switch (alg->alg.type) {
case CRYPTO_ALG_TYPE_AEAD:
crypto_unregister_aead(&alg->alg.u.aead);
break;
- case CRYPTO_ALG_TYPE_RNG:
- crypto_unregister_rng(&alg->alg.u.rng);
- break;
-
default:
crypto_unregister_skcipher(&alg->alg.u.cipher);
}
kfree(alg);
}
@@ -1074,73 +1064,10 @@ static irqreturn_t crypto4xx_ce_interrupt_handler_revb(int irq, void *data)
{
return crypto4xx_interrupt_handler(irq, data, PPC4XX_INTERRUPT_CLR |
PPC4XX_TMO_ERR_INT);
}
-static int ppc4xx_prng_data_read(struct crypto4xx_device *dev,
- u8 *data, unsigned int max)
-{
- unsigned int i, curr = 0;
- u32 val[2];
-
- do {
- /* trigger PRN generation */
- writel(PPC4XX_PRNG_CTRL_AUTO_EN,
- dev->ce_base + CRYPTO4XX_PRNG_CTRL);
-
- for (i = 0; i < 1024; i++) {
- /* usually 19 iterations are enough */
- if ((readl(dev->ce_base + CRYPTO4XX_PRNG_STAT) &
- CRYPTO4XX_PRNG_STAT_BUSY))
- continue;
-
- val[0] = readl_be(dev->ce_base + CRYPTO4XX_PRNG_RES_0);
- val[1] = readl_be(dev->ce_base + CRYPTO4XX_PRNG_RES_1);
- break;
- }
- if (i == 1024)
- return -ETIMEDOUT;
-
- if ((max - curr) >= 8) {
- memcpy(data, &val, 8);
- data += 8;
- curr += 8;
- } else {
- /* copy only remaining bytes */
- memcpy(data, &val, max - curr);
- break;
- }
- } while (curr < max);
-
- return curr;
-}
-
-static int crypto4xx_prng_generate(struct crypto_rng *tfm,
- const u8 *src, unsigned int slen,
- u8 *dstn, unsigned int dlen)
-{
- struct rng_alg *alg = crypto_rng_alg(tfm);
- struct crypto4xx_alg *amcc_alg;
- struct crypto4xx_device *dev;
- int ret;
-
- amcc_alg = container_of(alg, struct crypto4xx_alg, alg.u.rng);
- dev = amcc_alg->dev;
-
- mutex_lock(&dev->core_dev->rng_lock);
- ret = ppc4xx_prng_data_read(dev, dstn, dlen);
- mutex_unlock(&dev->core_dev->rng_lock);
- return ret;
-}
-
-
-static int crypto4xx_prng_seed(struct crypto_rng *tfm, const u8 *seed,
- unsigned int slen)
-{
- return 0;
-}
-
/*
* Supported Crypto Algorithms
*/
static struct crypto4xx_alg_common crypto4xx_alg[] = {
/* Crypto AES modes */
@@ -1266,22 +1193,10 @@ static struct crypto4xx_alg_common crypto4xx_alg[] = {
.cra_blocksize = 1,
.cra_ctxsize = sizeof(struct crypto4xx_ctx),
.cra_module = THIS_MODULE,
},
} },
- { .type = CRYPTO_ALG_TYPE_RNG, .u.rng = {
- .base = {
- .cra_name = "stdrng",
- .cra_driver_name = "crypto4xx_rng",
- .cra_priority = 300,
- .cra_ctxsize = 0,
- .cra_module = THIS_MODULE,
- },
- .generate = crypto4xx_prng_generate,
- .seed = crypto4xx_prng_seed,
- .seedsize = 0,
- } },
};
/*
* Module Initialization Routine
*/
@@ -1351,13 +1266,10 @@ static int crypto4xx_probe(struct platform_device *ofdev)
}
core_dev->dev->core_dev = core_dev;
core_dev->dev->is_revb = is_revb;
core_dev->device = dev;
- rc = devm_mutex_init(&ofdev->dev, &core_dev->rng_lock);
- if (rc)
- return rc;
spin_lock_init(&core_dev->lock);
INIT_LIST_HEAD(&core_dev->dev->alg_list);
ratelimit_default_init(&core_dev->dev->aead_ratelimit);
rc = crypto4xx_build_sdr(core_dev->dev);
if (rc)
diff --git a/drivers/crypto/amcc/crypto4xx_core.h b/drivers/crypto/amcc/crypto4xx_core.h
index ee36630c670f..3a028aec3f0c 100644
--- a/drivers/crypto/amcc/crypto4xx_core.h
+++ b/drivers/crypto/amcc/crypto4xx_core.h
@@ -12,14 +12,12 @@
#ifndef __CRYPTO4XX_CORE_H__
#define __CRYPTO4XX_CORE_H__
#include <linux/ratelimit.h>
-#include <linux/mutex.h>
#include <linux/scatterlist.h>
#include <crypto/internal/aead.h>
-#include <crypto/internal/rng.h>
#include <crypto/internal/skcipher.h>
#include "crypto4xx_reg_def.h"
#include "crypto4xx_sa.h"
#define PPC460SX_SDR0_SRST 0x201
@@ -109,11 +107,10 @@ struct crypto4xx_core_device {
struct hwrng *trng;
u32 int_status;
u32 irq;
struct tasklet_struct tasklet;
spinlock_t lock;
- struct mutex rng_lock;
};
struct crypto4xx_ctx {
struct crypto4xx_device *dev;
struct dynamic_sa_ctl *sa_in;
@@ -133,11 +130,10 @@ struct crypto4xx_aead_reqctx {
struct crypto4xx_alg_common {
u32 type;
union {
struct skcipher_alg cipher;
struct aead_alg aead;
- struct rng_alg rng;
} u;
};
struct crypto4xx_alg {
struct list_head entry;
diff --git a/drivers/crypto/amcc/crypto4xx_reg_def.h b/drivers/crypto/amcc/crypto4xx_reg_def.h
index 1038061224da..73d626308a84 100644
--- a/drivers/crypto/amcc/crypto4xx_reg_def.h
+++ b/drivers/crypto/amcc/crypto4xx_reg_def.h
@@ -88,24 +88,13 @@
#define CRYPTO4XX_DMA_CFG 0x000600d4
#define CRYPTO4XX_BYTE_ORDER_CFG 0x000600d8
#define CRYPTO4XX_ENDIAN_CFG 0x000600d8
-#define CRYPTO4XX_PRNG_STAT 0x00070000
-#define CRYPTO4XX_PRNG_STAT_BUSY 0x1
#define CRYPTO4XX_PRNG_CTRL 0x00070004
#define CRYPTO4XX_PRNG_SEED_L 0x00070008
#define CRYPTO4XX_PRNG_SEED_H 0x0007000c
-
-#define CRYPTO4XX_PRNG_RES_0 0x00070020
-#define CRYPTO4XX_PRNG_RES_1 0x00070024
-#define CRYPTO4XX_PRNG_RES_2 0x00070028
-#define CRYPTO4XX_PRNG_RES_3 0x0007002C
-
-#define CRYPTO4XX_PRNG_LFSR_L 0x00070030
-#define CRYPTO4XX_PRNG_LFSR_H 0x00070034
-
/*
* Initialize CRYPTO ENGINE registers, and memory bases.
*/
#define PPC4XX_PDR_POLL 0x3ff
#define PPC4XX_OUTPUT_THRESHOLD 2
base-commit: 49e05bb00f2e8168695f7af4d694c39e1423e8a2
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] powerpc/boot: remove unused min_t/max_t macros
From: kernel test robot @ 2026-05-29 19:50 UTC (permalink / raw)
To: Thorsten Blum, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP)
Cc: oe-kbuild-all, Thorsten Blum, linuxppc-dev, linux-kernel
In-Reply-To: <20260525091839.817778-3-thorsten.blum@linux.dev>
Hi Thorsten,
kernel test robot noticed the following build errors:
[auto build test ERROR on powerpc/next]
[also build test ERROR on powerpc/fixes linus/master v7.1-rc5 next-20260528]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Thorsten-Blum/powerpc-boot-remove-unused-min_t-max_t-macros/20260525-172120
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
patch link: https://lore.kernel.org/r/20260525091839.817778-3-thorsten.blum%40linux.dev
patch subject: [PATCH] powerpc/boot: remove unused min_t/max_t macros
config: powerpc64-randconfig-r061-20260529 (https://download.01.org/0day-ci/archive/20260530/202605300340.G7sL2jlK-lkp@intel.com/config)
compiler: clang version 23.0.0git (https://github.com/llvm/llvm-project 9409c07de6378507397ecdb6f05f628f58110112)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260530/202605300340.G7sL2jlK-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605300340.G7sL2jlK-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from arch/powerpc/boot/decompress.c:37:
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:241:
>> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:158:21: error: call to undeclared function 'min_t'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
158 | size_t copy_size = min_t(size_t,
| ^
>> arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c:158:27: error: unexpected type name 'size_t': expected expression
158 | size_t copy_size = min_t(size_t,
| ^
In file included from arch/powerpc/boot/decompress.c:37:
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:242:
>> arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:357:9: error: call to undeclared function 'min_t'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
357 | left = min_t(size_t, dict->limit - dict->pos, *len);
| ^
>> arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:357:15: error: unexpected type name 'size_t': expected expression
357 | left = min_t(size_t, dict->limit - dict->pos, *len);
| ^
arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:1101:25: error: call to undeclared function 'min_t'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
1101 | dict_limit(&s->dict, min_t(size_t,
| ^
arch/powerpc/boot/../../../lib/xz/xz_dec_lzma2.c:1101:31: error: unexpected type name 'size_t': expected expression
1101 | dict_limit(&s->dict, min_t(size_t,
| ^
In file included from arch/powerpc/boot/decompress.c:37:
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:243:
>> arch/powerpc/boot/../../../lib/xz/xz_dec_bcj.c:469:14: error: call to undeclared function 'min_t'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
469 | copy_size = min_t(size_t, s->temp.filtered, b->out_size - b->out_pos);
| ^
>> arch/powerpc/boot/../../../lib/xz/xz_dec_bcj.c:469:20: error: unexpected type name 'size_t': expected expression
469 | copy_size = min_t(size_t, s->temp.filtered, b->out_size - b->out_pos);
| ^
8 errors generated.
vim +/min_t +158 arch/powerpc/boot/../../../lib/xz/xz_dec_stream.c
24fa0402a9b6a5 Lasse Collin 2011-01-12 149
24fa0402a9b6a5 Lasse Collin 2011-01-12 150 /*
24fa0402a9b6a5 Lasse Collin 2011-01-12 151 * Fill s->temp by copying data starting from b->in[b->in_pos]. Caller
24fa0402a9b6a5 Lasse Collin 2011-01-12 152 * must have set s->temp.pos to indicate how much data we are supposed
24fa0402a9b6a5 Lasse Collin 2011-01-12 153 * to copy into s->temp.buf. Return true once s->temp.pos has reached
24fa0402a9b6a5 Lasse Collin 2011-01-12 154 * s->temp.size.
24fa0402a9b6a5 Lasse Collin 2011-01-12 155 */
24fa0402a9b6a5 Lasse Collin 2011-01-12 156 static bool fill_temp(struct xz_dec *s, struct xz_buf *b)
24fa0402a9b6a5 Lasse Collin 2011-01-12 157 {
24fa0402a9b6a5 Lasse Collin 2011-01-12 @158 size_t copy_size = min_t(size_t,
24fa0402a9b6a5 Lasse Collin 2011-01-12 159 b->in_size - b->in_pos, s->temp.size - s->temp.pos);
24fa0402a9b6a5 Lasse Collin 2011-01-12 160
24fa0402a9b6a5 Lasse Collin 2011-01-12 161 memcpy(s->temp.buf + s->temp.pos, b->in + b->in_pos, copy_size);
24fa0402a9b6a5 Lasse Collin 2011-01-12 162 b->in_pos += copy_size;
24fa0402a9b6a5 Lasse Collin 2011-01-12 163 s->temp.pos += copy_size;
24fa0402a9b6a5 Lasse Collin 2011-01-12 164
24fa0402a9b6a5 Lasse Collin 2011-01-12 165 if (s->temp.pos == s->temp.size) {
24fa0402a9b6a5 Lasse Collin 2011-01-12 166 s->temp.pos = 0;
24fa0402a9b6a5 Lasse Collin 2011-01-12 167 return true;
24fa0402a9b6a5 Lasse Collin 2011-01-12 168 }
24fa0402a9b6a5 Lasse Collin 2011-01-12 169
24fa0402a9b6a5 Lasse Collin 2011-01-12 170 return false;
24fa0402a9b6a5 Lasse Collin 2011-01-12 171 }
24fa0402a9b6a5 Lasse Collin 2011-01-12 172
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: PowerPC: Random memory corruption causing kernel oops on Power11
From: Paul Moore @ 2026-05-29 18:24 UTC (permalink / raw)
To: Stephen Smalley
Cc: rppt, Venkat Rao Bagalkote, linuxppc-dev, Madhavan Srinivasan,
selinux, LKML, Ritesh Harjani, Christophe Leroy (CS GROUP)
In-Reply-To: <CAEjxPJ5wS+sXvCjO3q2sfrckuMo71_Y3uSdgu+Vte7xLkW0Huw@mail.gmail.com>
On Fri, May 29, 2026 at 12:11 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Fri, May 29, 2026 at 11:39 AM Paul Moore <paul@paul-moore.com> wrote:
> > On Fri, May 29, 2026 at 11:19 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > > Alternatively, I suppose we could just update the dentry_path_raw()
> > > call to also pass PATH_MAX, but
> > > I don't see why we want to use __getname/__putname() instead of just
> > > direct kmalloc/kfree here so
> > > the size of the buffer is immediately evident to the reader.
> >
> > It's reverted, see the posting below:
> >
> > https://lore.kernel.org/selinux/20260529153608.30853-2-paul@paul-moore.com
> >
> > I think there is still value in using __getname()/__putname() here as
> > opposed to a simple kmalloc()/kfree() pairing, but either way we need
> > to adjust the buffer length in selinux_genfs_get_sid() accordingly to
> > use PATH_MAX instead of PAGE_SIZE.
>
> IIUC, __getname()/__putname() were originally internal helpers for
> getname()/putname() and allocated from names_cachep for struct
> filename. commit c3a3577cdb35 ("struct filename: use names_cachep only
> for getname() and friends") switched __getname()/__putname() over to
> just generic kmalloc/kfree so that other users of those helpers would
> stop allocating from names_cachep and noted that those lingering users
> could be converted to explicit kmalloc() over time. So I don't think
> vfs folks want new users of __getname()/__putname() but I could be
> wrong.
Whoever wants to submit a patch to do the conversion again should
chase that down.
--
paul-moore.com
^ permalink raw reply
* Re: PowerPC: Random memory corruption causing kernel oops on Power11
From: Paul Moore @ 2026-05-29 18:23 UTC (permalink / raw)
To: David Laight
Cc: Venkat Rao Bagalkote, linuxppc-dev, Madhavan Srinivasan, selinux,
rppt, LKML, Ritesh Harjani, Christophe Leroy (CS GROUP)
In-Reply-To: <20260529171855.7966b752@pumpkin>
On Fri, May 29, 2026 at 12:18 PM David Laight
<david.laight.linux@gmail.com> wrote:
> On Fri, 29 May 2026 19:07:22 +0530
> Venkat Rao Bagalkote <venkat88@linux.ibm.com> wrote:
> > On 29/05/26 12:20 pm, Venkat Rao Bagalkote wrote:
> > > Greetings!!!
> > >
> > > Kernel 7.1.0-rc5-next-20260528 crashes randomly on IBM Power11
> > > hardware. Attached is the config file.
> > >
> .
> >
> > Git bisect is pointing to 54067bacb49c selinux: hooks: use __getname()
> > to allocate path buffer as the first bad commit.
> >
> >
> > # git bisect good
> > 54067bacb49caeada82b20b6bd706dca0cb99ffc is the first bad commit
> > commit 54067bacb49caeada82b20b6bd706dca0cb99ffc
> > Author: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > Date: Wed May 20 11:18:56 2026 +0300
> >
> > selinux: hooks: use __getname() to allocate path buffer
> >
> > selinux_genfs_get_sid() allocates memory for a path with
> > __get_free_page()
> > although there is a dedicated helper for allocation of file paths:
> > __getname().
> >
> > Replace __get_free_page() for allocation of a path buffer with
> > __getname().
> >
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > Signed-off-by: Paul Moore <paul@paul-moore.com>
> >
> > security/selinux/hooks.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> __getname() is kmalloc(PATH_MAX) aka kmalloc(4096).
>
> The old code was:
> buffer = (char *)__get_free_page(GFP_KERNEL);
> if (!buffer)
> return -ENOMEM;
>
> path = dentry_path_raw(dentry, buffer, PAGE_SIZE);
> only the allocate was changed.
>
> PAGE_SIZE is not the length of the buffer.
> Should be PATH_MAX.
Yes, as discussed earlier in the thread some additional work needs to
be done, and verified, but since we are at the end of -rc5 I simply
reverted the patch. We can chase this down next dev cycle.
--
paul-moore.com
^ 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