[PATCH] tools/perf/arch/powerpc/util: Fix is_compat_mode build break in ppc64
Commit 54f9aa1092457 ("tools/perf/powerpc/util: Add support to
handle compatible mode PVR for perf json events") introduced
to select proper JSON events in case of compat mode using
auxiliary vector. But this caused a compilation error in ppc64
Big Endian.
arch/powerpc/util/header.c: In function 'is_compat_mode':
arch/powerpc/util/header.c:20:21: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
| ^
arch/powerpc/util/header.c:20:39: error: cast to pointer from
integer of different size [-Werror=int-to-pointer-cast]
20 | if (!strcmp((char *)platform, (char *)base_platform))
|
Commit saved the getauxval(AT_BASE_PLATFORM) and getauxval(AT_PLATFORM)
return values in u64 which causes the compilation error.
Patch fixes this issue by changing u64 to "unsigned long".
Fixes: 54f9aa1092457 ("tools/perf/powerpc/util: Add support to handle
compatible mode PVR for perf json events")
Signed-off-by: Likhitha Korrapati
---
tools/perf/arch/powerpc/util/header.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/arch/powerpc/util/header.c
b/tools/perf/arch/powerpc/util/header.c
index c7df534dbf8f..0be74f048f96 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -14,8 +14,8 @@
static bool is_compat_mode(void)
{
- u64 base_platform = getauxval(AT_BASE_PLATFORM);
- u64 platform = getauxval(AT_PLATFORM);
+ unsigned long base_platform = getauxval(AT_BASE_PLATFORM);
+ unsigned long platform = getauxval(AT_PLATFORM);
if (!strcmp((char *)platform, (char *)base_platform))
return false;
--
2.43.5
Re: [PATCH v4 1/3] lsm: introduce new hooks for setting/getting inode fsxattr
On Fri, Mar 21, 2025 at 05:32:25PM -0400, Paul Moore wrote:
> On Mar 21, 2025 Andrey Albershteyn wrote:
> >
> > Introduce new hooks for setting and getting filesystem extended
> > attributes on inode (FS_IOC_FSGETXATTR).
> >
> > Cc: seli...@vger.kernel.org
> > Cc: Paul Moore
> >
> > Signed-off-by: Andrey Albershteyn
> > ---
> > fs/ioctl.c| 7 ++-
> > include/linux/lsm_hook_defs.h | 4
> > include/linux/security.h | 16
> > security/security.c | 32
> > 4 files changed, 58 insertions(+), 1 deletion(-)
>
> Thanks Andrey, one small change below, but otherwise this looks pretty
> good. If you feel like trying to work up the SELinux implementation but
> need some assitance please let me know, I'll be happy to help :)
>
> > diff --git a/fs/ioctl.c b/fs/ioctl.c
> > index
> > 638a36be31c14afc66a7fd6eb237d9545e8ad997..4434c97bc5dff5a3e8635e28745cd99404ff353e
> > 100644
> > --- a/fs/ioctl.c
> > +++ b/fs/ioctl.c
> > @@ -525,10 +525,15 @@ EXPORT_SYMBOL(fileattr_fill_flags);
> > int vfs_fileattr_get(struct dentry *dentry, struct fileattr *fa)
> > {
> > struct inode *inode = d_inode(dentry);
> > + int error;
> >
> > if (!inode->i_op->fileattr_get)
> > return -ENOIOCTLCMD;
> >
> > + error = security_inode_getfsxattr(inode, fa);
> > + if (error)
> > + return error;
> > +
> > return inode->i_op->fileattr_get(dentry, fa);
> > }
> > EXPORT_SYMBOL(vfs_fileattr_get);
> > @@ -692,7 +697,7 @@ int vfs_fileattr_set(struct mnt_idmap *idmap, struct
> > dentry *dentry,
> > fa->flags |= old_ma.flags & ~FS_COMMON_FL;
> > }
> > err = fileattr_set_prepare(inode, &old_ma, fa);
> > - if (!err)
> > + if (!err && !security_inode_setfsxattr(inode, fa))
> > err = inode->i_op->fileattr_set(idmap, dentry, fa);
> > }
> > inode_unlock(inode);
>
> I don't believe we want to hide or otherwise drop the LSM return code as
> that could lead to odd behavior, e.g. returning 0/success despite not
> having executed the fileattr_set operation.
Yes, this should look something like this:
err = fileattr_set_prepare(inode, &old_ma, fa);
if (err)
goto out;
err = security_inode_setfsxattr(dentry, fa);
if (err)
goto out;
err = inode->i_op->fileattr_set(idmap, dentry, fa);
if (err)
goto out;
>
> --
> paul-moore.com
>
Using Restricted DMA for virtio-pci
On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote: > This series implements mitigations for lack of DMA access control on > systems without an IOMMU, which could result in the DMA accessing the > system memory at unexpected times and/or unexpected addresses, possibly > leading to data leakage or corruption. Replying to an ancient (2021) thread which has already been merged... I'd like to be able to use this facility for virtio devices. Virtio already has a complicated relationship with the DMA API, because there were a bunch of early VMM bugs where the virtio devices where magically exempted from IOMMU protection, but the VMM lied to the guest and claimed they weren't. With the advent of confidential computing, and the VMM (or whatever's emulating the virtio device) not being *allowed* to arbitrarily access all of the guest's memory, the DMA API becomes necessary again. Either a virtual IOMMU needs to determine which guest memory the VMM may access, or the DMA API is wrappers around operations which share/unshare (or unencrypt/encrypt) the memory in question. All of which is complicated and slow, if we're looking at a minimal privileged hypervisor stub like pKVM which enforces the lack of guest memory access from VMM. I'm thinking of defining a new type of virtio-pci device which cannot do DMA to arbitrary system memory. Instead it has an additional memory BAR which is used as a SWIOTLB for bounce buffering. The driver for it would look much like the existing virtio-pci device except that it would register the restricted-dma region first (and thus the swiotlb dma_ops), and then just go through the rest of the setup like any other virtio device. That seems like it ought to be fairly simple, and seems like a reasonable way to allow an untrusted VMM to provide virtio devices with restricted DMA access. While I start actually doing the typing... does anyone want to start yelling at me now? Christoph? mst? :) smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH v13 00/11] Support page table check on PowerPC
On 2/11/25 9:43 PM, Andrew Donnellan wrote:
> Support page table check on all PowerPC platforms. This works by
> serialising assignments, reassignments and clears of page table
> entries at each level in order to ensure that anonymous mappings
> have at most one writable consumer, and likewise that file-backed
> mappings are not simultaneously also anonymous mappings.
>
> In order to support this infrastructure, a number of stubs must be
> defined for all powerpc platforms. Additionally, seperate set_pte_at()
> and set_pte_at_unchecked(), to allow for internal, uninstrumented mappings.
>
> (This series was written by Rohan McLure, who has left IBM and is no longer
> working on powerpc - I've taken far too long to pick this up and finally
> send it.)
>
For powerpc changes
Acked-by: Madhavan Srinivasan
> v13:
> * Rebase on mainline
> * Don't use set_pte_at_unchecked() for early boot purposes (Pasha)
>
> v12:
> * Rename commits that revert changes to instead reflect that we are
>reinstating old behaviour due to it providing more flexibility
> * Add return line to pud_pfn() stub
> * Instrument ptep_get_and_clear() for nohash
> Link:
> https://lore.kernel.org/linuxppc-dev/20240402051154.476244-1-rmcl...@linux.ibm.com/
>
> v11:
> * The pud_pfn() stub, which previously had no legitimate users on any
>powerpc platform, now has users in Book3s64 with transparent pages.
>Include a stub of the same name for each platform that does not
>define their own.
> * Drop patch that standardised use of p*d_leaf(), as already included
>upstream in v6.9.
> * Provide fallback definitions of p{m,u}d_user_accessible_page() that
>do not reference p*d_leaf(), p*d_pte(), as they are defined after
>powerpc/mm headers by linux/mm headers.
> * Ensure that set_pte_at_unchecked() has the same checks as
>set_pte_at().
> Link:
> https://lore.kernel.org/linuxppc-dev/20240328045535.194800-14-rmcl...@linux.ibm.com/
>
>
> v10:
> * Revert patches that removed address and mm parameters from page table
>check routines, including consuming code from arm64, x86_64 and
>riscv.
> * Implement *_user_accessible_page() routines in terms of pte_user()
>where available (64-bit, book3s) but otherwise by checking the
>address (on platforms where the pte does not imply whether the
>mapping is for user or kernel)
> * Internal set_pte_at() calls replaced with set_pte_at_unchecked(), which
>is identical, but prevents double instrumentation.
> Link:
> https://lore.kernel.org/linuxppc-dev/20240313042118.230397-9-rmcl...@linux.ibm.com/T/
>
> v9:
> * Adapt to using the set_ptes() API, using __set_pte_at() where we need
>must avoid instrumentation.
> * Use the logic of *_access_permitted() for implementing
>*_user_accessible_page(), which are required routines for page table
>check.
> * Even though we no longer need p{m,u,4}d_leaf(), still default
>implement these to assist in refactoring out extant
>p{m,u,4}_is_leaf().
> * Add p{m,u}_pte() stubs where asm-generic does not provide them, as
>page table check wants all *user_accessible_page() variants, and we
>would like to default implement the variants in terms of
>pte_user_accessible_page().
> * Avoid the ugly pmdp_collapse_flush() macro nonsense! Just instrument
>its constituent calls instead for radix and hash.
> Link:
> https://lore.kernel.org/linuxppc-dev/20231130025404.37179-2-rmcl...@linux.ibm.com/
>
> v8:
> * Fix linux/page_table_check.h include in asm/pgtable.h breaking
>32-bit.
> Link:
> https://lore.kernel.org/linuxppc-dev/20230215231153.2147454-1-rmcl...@linux.ibm.com/
>
> v7:
> * Remove use of extern in set_pte prototypes
> * Clean up pmdp_collapse_flush macro
> * Replace set_pte_at with static inline function
> * Fix commit message for patch 7
> Link:
> https://lore.kernel.org/linuxppc-dev/20230215020155.1969194-1-rmcl...@linux.ibm.com/
>
> v6:
> * Support huge pages and p{m,u}d accounting.
> * Remove instrumentation from set_pte from kernel internal pages.
> * 64s: Implement pmdp_collapse_flush in terms of __pmdp_collapse_flush
>as access to the mm_struct * is required.
> Link:
> https://lore.kernel.org/linuxppc-dev/20230214015939.1853438-1-rmcl...@linux.ibm.com/
>
> v5:
> Link:
> https://lore.kernel.org/linuxppc-dev/20221118002146.25979-1-rmcl...@linux.ibm.com/
>
> Rohan McLure (11):
> mm/page_table_check: Reinstate address parameter in
> [__]page_table_check_pud_set()
> mm/page_table_check: Reinstate address parameter in
> [__]page_table_check_pmd_set()
> mm/page_table_check: Provide addr parameter to
> page_table_check_pte_set()
> mm/page_table_check: Reinstate address parameter in
> [__]page_table_check_pud_clear()
> mm/page_table_check: Reinstate address parameter in
> [__]page_table_check_pmd_clear()
> mm/page_table_check: Reinstate address parameter in
> [__]page_table_check_pte_clear()
> mm: Provide address
Re: [BUG?] ppc64le: fentry BPF not triggered after live patch (v6.14)
On Mon, 31 Mar 2025 21:19:36 +0800
Shung-Hsi Yu wrote:
> Hi all,
>
> On ppc64le (v6.14, kernel config attached), I've observed that fentry
> BPF programs stop being invoked after the target kernel function is live
> patched. This occurs regardless of whether the BPF program was attached
> before or after the live patch. I believe fentry/fprobe on ppc64le is
> added with [1].
>
> Steps to reproduce on ppc64le:
> - Use bpftrace (v0.10.0+) to attach a BPF program to cmdline_proc_show
> with fentry (kfunc is the older name bpftrace used for fentry, used
> here for max compatability)
>
> bpftrace -e 'kfunc:cmdline_proc_show { printf("%lld: cmdline_proc_show()
> called by %s\n", nsecs(), comm) }'
>
> - Run `cat /proc/cmdline` and observe bpftrace output
>
> - Load samples/livepatch/livepatch-sample.ko
>
> - Run `cat /proc/cmdline` again. Observe "this has been live patched" in
> output, but no new bpftrace output.
>
> Note: once the live patching module is disabled through the sysfs interface
> the BPF program invocation is restored.
>
> Is this the expected interaction between fentry BPF and live patching?
> On x86_64 it does _not_ happen, so I'd guess the behavior on ppc64le is
> unintended. Any insights appreciated.
Hmm, I'm not sure how well BPF function attachment and live patching
interact. Can you see if on x86 the live patch is actually updated when a
BPF program is attached?
Would be even more interesting to see how BPF reading the return code works
with live patching, as it calls the function directly from the BPF
trampoline. I wonder, does it call the live patched function, or does it
call the original one?
-- Steve
>
>
> Thanks,
> Shung-Hsi Yu
>
> 1:
> https://lore.kernel.org/all/20241030070850.1361304-2-hbath...@linux.ibm.com/
[PATCH v3] powerpc/boot: Fix build with gcc 15
Similar to x86 the ppc boot code does not build with GCC 15.
Copy the fix from
commit ee2ab467bddf ("x86/boot: Use '-std=gnu11' to fix build with GCC 15")
Signed-off-by: Michal Suchanek
---
v2: Move the fix outside of ifdef to apply to all subarchitectures
v3: Change BOOTCFLAGS rather than BOOTTARGETFLAGS
---
arch/powerpc/boot/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 184d0680e661..a7ab087d412c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -70,6 +70,7 @@ BOOTCPPFLAGS := -nostdinc $(LINUXINCLUDE)
BOOTCPPFLAGS += -isystem $(shell $(BOOTCC) -print-file-name=include)
BOOTCFLAGS := $(BOOTTARGETFLAGS) \
+ -std=gnu11 \
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -O2 \
-msoft-float -mno-altivec -mno-vsx \
--
2.47.1
Re: [BUG?] ppc64le: fentry BPF not triggered after live patch (v6.14)
On Mon, Mar 31, 2025 at 10:09:40AM -0400, Steven Rostedt wrote:
> On Mon, 31 Mar 2025 21:19:36 +0800
> Shung-Hsi Yu wrote:
>
> > Hi all,
> >
> > On ppc64le (v6.14, kernel config attached), I've observed that fentry
> > BPF programs stop being invoked after the target kernel function is live
> > patched. This occurs regardless of whether the BPF program was attached
> > before or after the live patch. I believe fentry/fprobe on ppc64le is
> > added with [1].
> >
> > Steps to reproduce on ppc64le:
> > - Use bpftrace (v0.10.0+) to attach a BPF program to cmdline_proc_show
> > with fentry (kfunc is the older name bpftrace used for fentry, used
> > here for max compatability)
> >
> > bpftrace -e 'kfunc:cmdline_proc_show { printf("%lld:
> > cmdline_proc_show() called by %s\n", nsecs(), comm) }'
> >
> > - Run `cat /proc/cmdline` and observe bpftrace output
> >
> > - Load samples/livepatch/livepatch-sample.ko
> >
> > - Run `cat /proc/cmdline` again. Observe "this has been live patched" in
> > output, but no new bpftrace output.
> >
> > Note: once the live patching module is disabled through the sysfs interface
> > the BPF program invocation is restored.
> >
> > Is this the expected interaction between fentry BPF and live patching?
> > On x86_64 it does _not_ happen, so I'd guess the behavior on ppc64le is
> > unintended. Any insights appreciated.
>
> Hmm, I'm not sure how well BPF function attachment and live patching
> interact. Can you see if on x86 the live patch is actually updated when a
> BPF program is attached?
above works for me on x86, there's both 'this has been live patched'
and bpftrace output
>
> Would be even more interesting to see how BPF reading the return code works
> with live patching, as it calls the function directly from the BPF
> trampoline. I wonder, does it call the live patched function, or does it
> call the original one?
yes, that should work, Song fixed some time ago with:
00963a2e75a8 bpf: Support bpf_trampoline on functions with IPMODIFY (e.g.
livepatch)
jirka
>
> -- Steve
>
>
> >
> >
> > Thanks,
> > Shung-Hsi Yu
> >
> > 1:
> > https://lore.kernel.org/all/20241030070850.1361304-2-hbath...@linux.ibm.com/
>
>
Re: [PATCH v2 1/1] mm: pgtable: fix pte_swp_exclusive
Sam James writes: > Lovely cleanup and a great suggestion from Al. > > Reviewed-by: Sam James > > I'd suggest adding a: > Suggested-by: Al Viro Al, were you planning on taking this through your tree? > > thanks, > sam
Re: [PATCH v5 6/6] powerpc/kvm-hv-pmu: Add perf-events for Hostwide counters
> On 17 Mar 2025, at 3:38 PM, Vaibhav Jain wrote:
>
> Update 'kvm-hv-pmu.c' to add five new perf-events mapped to the five
> Hostwide counters. Since these newly introduced perf events are at system
> wide scope and can be read from any L1-Lpar CPU, 'kvmppc_pmu' scope and
> capabilities are updated appropriately.
>
> Also introduce two new helpers. First is kvmppc_update_l0_stats() that uses
> the infrastructure introduced in previous patches to issues the
> H_GUEST_GET_STATE hcall L0-PowerVM to fetch guest-state-buffer holding the
> latest values of these counters which is then parsed and 'l0_stats'
> variable updated.
>
> Second helper is kvmppc_pmu_event_update() which is called from
> 'kvmppv_pmu' callbacks and uses kvmppc_update_l0_stats() to update
> 'l0_stats' and the update the 'struct perf_event's event-counter.
>
> Some minor updates to kvmppc_pmu_{add, del, read}() to remove some debug
> scaffolding code.
>
> Signed-off-by: Vaibhav Jain
Thanks Vaibhav for including the changes in V5. Changes looks good to me in
patches for perf events.
Reviewed-by: Athira Rajeev
Thanks
Athira
> ---
> Changelog
>
> v4->v5:
> * Call kvmppc_pmu_event_update() during pmu's 'del()' callback [ Atheera ]
>
> v3->v4:
> * Minor tweaks to patch description and code as its now being built as a
> separate kernel module.
>
> v2->v3:
> None
>
> v1->v2:
> None
> ---
> arch/powerpc/perf/kvm-hv-pmu.c | 92 +-
> 1 file changed, 91 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/perf/kvm-hv-pmu.c b/arch/powerpc/perf/kvm-hv-pmu.c
> index 705be24ccb43..ae264c9080ef 100644
> --- a/arch/powerpc/perf/kvm-hv-pmu.c
> +++ b/arch/powerpc/perf/kvm-hv-pmu.c
> @@ -30,6 +30,11 @@
> #include "asm/guest-state-buffer.h"
>
> enum kvmppc_pmu_eventid {
> + KVMPPC_EVENT_HOST_HEAP,
> + KVMPPC_EVENT_HOST_HEAP_MAX,
> + KVMPPC_EVENT_HOST_PGTABLE,
> + KVMPPC_EVENT_HOST_PGTABLE_MAX,
> + KVMPPC_EVENT_HOST_PGTABLE_RECLAIM,
> KVMPPC_EVENT_MAX,
> };
>
> @@ -61,8 +66,14 @@ static DEFINE_SPINLOCK(lock_l0_stats);
> /* GSB related structs needed to talk to L0 */
> static struct kvmppc_gs_msg *gsm_l0_stats;
> static struct kvmppc_gs_buff *gsb_l0_stats;
> +static struct kvmppc_gs_parser gsp_l0_stats;
>
> static struct attribute *kvmppc_pmu_events_attr[] = {
> + KVMPPC_PMU_EVENT_ATTR(host_heap, KVMPPC_EVENT_HOST_HEAP),
> + KVMPPC_PMU_EVENT_ATTR(host_heap_max, KVMPPC_EVENT_HOST_HEAP_MAX),
> + KVMPPC_PMU_EVENT_ATTR(host_pagetable, KVMPPC_EVENT_HOST_PGTABLE),
> + KVMPPC_PMU_EVENT_ATTR(host_pagetable_max, KVMPPC_EVENT_HOST_PGTABLE_MAX),
> + KVMPPC_PMU_EVENT_ATTR(host_pagetable_reclaim,
> KVMPPC_EVENT_HOST_PGTABLE_RECLAIM),
> NULL,
> };
>
> @@ -71,7 +82,7 @@ static const struct attribute_group kvmppc_pmu_events_group
> = {
> .attrs = kvmppc_pmu_events_attr,
> };
>
> -PMU_FORMAT_ATTR(event, "config:0");
> +PMU_FORMAT_ATTR(event, "config:0-5");
> static struct attribute *kvmppc_pmu_format_attr[] = {
> &format_attr_event.attr,
> NULL,
> @@ -88,6 +99,79 @@ static const struct attribute_group
> *kvmppc_pmu_attr_groups[] = {
> NULL,
> };
>
> +/*
> + * Issue the hcall to get the L0-host stats.
> + * Should be called with l0-stat lock held
> + */
> +static int kvmppc_update_l0_stats(void)
> +{
> + int rc;
> +
> + /* With HOST_WIDE flags guestid and vcpuid will be ignored */
> + rc = kvmppc_gsb_recv(gsb_l0_stats, KVMPPC_GS_FLAGS_HOST_WIDE);
> + if (rc)
> + goto out;
> +
> + /* Parse the guest state buffer is successful */
> + rc = kvmppc_gse_parse(&gsp_l0_stats, gsb_l0_stats);
> + if (rc)
> + goto out;
> +
> + /* Update the l0 returned stats*/
> + memset(&l0_stats, 0, sizeof(l0_stats));
> + rc = kvmppc_gsm_refresh_info(gsm_l0_stats, gsb_l0_stats);
> +
> +out:
> + return rc;
> +}
> +
> +/* Update the value of the given perf_event */
> +static int kvmppc_pmu_event_update(struct perf_event *event)
> +{
> + int rc;
> + u64 curr_val, prev_val;
> + unsigned long flags;
> + unsigned int config = event->attr.config;
> +
> + /* Ensure no one else is modifying the l0_stats */
> + spin_lock_irqsave(&lock_l0_stats, flags);
> +
> + rc = kvmppc_update_l0_stats();
> + if (!rc) {
> + switch (config) {
> + case KVMPPC_EVENT_HOST_HEAP:
> + curr_val = l0_stats.guest_heap;
> + break;
> + case KVMPPC_EVENT_HOST_HEAP_MAX:
> + curr_val = l0_stats.guest_heap_max;
> + break;
> + case KVMPPC_EVENT_HOST_PGTABLE:
> + curr_val = l0_stats.guest_pgtable_size;
> + break;
> + case KVMPPC_EVENT_HOST_PGTABLE_MAX:
> + curr_val = l0_stats.guest_pgtable_size_max;
> + break;
> + case KVMPPC_EVENT_HOST_PGTABLE_RECLAIM:
> + curr_val = l0_stats.guest_pgtable_reclaim;
> + break;
> + default:
> + rc = -ENOENT;
> + break;
> + }
> + }
> +
> + spin_unlock_irqrestore(&lock_l0_stats, flags);
> +
> + /* If no error than update the perf event */
> + if (!rc) {
> + prev_val = local64_xchg(&event->hw.prev_count, curr_val);
> + if (curr_val > prev_val)
> + local64_add(curr_val - prev_val, &event->count);
> + }
> +
> + return rc;
> +}
> +
> static int kvmppc_pmu_ev
Re: [PATCH v1] ASoC: imx-card: Add NULL check in imx_card_probe()
On Tue, 01 Apr 2025 22:25:10 +0800, Henry Martin wrote: > devm_kasprintf() returns NULL when memory allocation fails. Currently, > imx_card_probe() does not check for this case, which results in a NULL > pointer dereference. > > Add NULL check after devm_kasprintf() to prevent this issue. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: imx-card: Add NULL check in imx_card_probe() commit: 93d34608fd162f725172e780b1c60cc93a920719 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 00/11] Always call constructor for kernel page tables
On 17/03/2025 16:30, Ryan Roberts wrote:
> On 17/03/2025 14:16, Kevin Brodsky wrote:
>> The complications in those special pgtable allocators beg the question:
>> does it really make sense to treat efi_mm and init_mm differently in
>> e.g. apply_to_pte_range()? Maybe what we really need is a way to tell if
>> an mm corresponds to user memory or not, and never use split locks for
>> non-user mm's. Feedback and suggestions welcome!
> The difference in treatment is whether or not the ptl is taken, right? So the
> real question is when calling apply_to_pte_range() for efi_mm, is there
> already
> a higher level serialization mechanism that prevents racy accesses? For
> init_mm,
> I think this is handled implicitly because there is no way for user space to
> cause apply_to_pte_range() for an arbitrary piece of kernel memory. Although I
> can't even see where apply_to_page_range() is called for efi_mm.
The commit I mentioned above, 61444cde9170 ("ARM: 8591/1: mm: use fully
constructed struct pages for EFI pgd allocations"), shows that
apply_to_page_range() is called from efi_set_mapping_permissions(), and
this indeed hasn't changed. It is itself called from efi_virtmap_init().
I would expect that no locking at all is necessary here, since the
mapping has just been created and surely isn't used yet. Now the
question is where exactly init_mm is special-cased in this manner. I can
see that walk_page_range() does something similar, there may be more
cases. And the other question is whether those functions are ever used
on special mm's, aside from efi_set_mapping_permissions().
> FWIW, contpte.c has mm_is_user() which is used by arm64.
Interesting! But not pretty, that's basically checking that the mm is
not &init_mm or &efi_mm... which wouldn't work for a generic
implementation. It feels like adding some attribute to mm_struct
wouldn't hurt. It looks like we've run out of MMF_* flags though :/
- Kevin
Re: [PATCH v4 1/3] lsm: introduce new hooks for setting/getting inode fsxattr
On Mar 21, 2025 Andrey Albershteyn wrote:
>
> Introduce new hooks for setting and getting filesystem extended
> attributes on inode (FS_IOC_FSGETXATTR).
>
> Cc: seli...@vger.kernel.org
> Cc: Paul Moore
>
> Signed-off-by: Andrey Albershteyn
> ---
> fs/ioctl.c| 7 ++-
> include/linux/lsm_hook_defs.h | 4
> include/linux/security.h | 16
> security/security.c | 32
> 4 files changed, 58 insertions(+), 1 deletion(-)
Thanks Andrey, one small change below, but otherwise this looks pretty
good. If you feel like trying to work up the SELinux implementation but
need some assitance please let me know, I'll be happy to help :)
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index
> 638a36be31c14afc66a7fd6eb237d9545e8ad997..4434c97bc5dff5a3e8635e28745cd99404ff353e
> 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -525,10 +525,15 @@ EXPORT_SYMBOL(fileattr_fill_flags);
> int vfs_fileattr_get(struct dentry *dentry, struct fileattr *fa)
> {
> struct inode *inode = d_inode(dentry);
> + int error;
>
> if (!inode->i_op->fileattr_get)
> return -ENOIOCTLCMD;
>
> + error = security_inode_getfsxattr(inode, fa);
> + if (error)
> + return error;
> +
> return inode->i_op->fileattr_get(dentry, fa);
> }
> EXPORT_SYMBOL(vfs_fileattr_get);
> @@ -692,7 +697,7 @@ int vfs_fileattr_set(struct mnt_idmap *idmap, struct
> dentry *dentry,
> fa->flags |= old_ma.flags & ~FS_COMMON_FL;
> }
> err = fileattr_set_prepare(inode, &old_ma, fa);
> - if (!err)
> + if (!err && !security_inode_setfsxattr(inode, fa))
> err = inode->i_op->fileattr_set(idmap, dentry, fa);
> }
> inode_unlock(inode);
I don't believe we want to hide or otherwise drop the LSM return code as
that could lead to odd behavior, e.g. returning 0/success despite not
having executed the fileattr_set operation.
--
paul-moore.com
Re: [PATCH 2/3] MAINTAINERS: fix nonexistent dtbinding file name
Le 19/03/2025 à 10:43, Ioana Ciornei a écrit :
[Vous ne recevez pas souvent de courriers de ioana.cior...@nxp.com. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
The blamed commit converted the fsl,qoriq-mc.txt into fsl,qoriq-mc.yaml
but forgot to also update the MAINTAINERS file to reference the new
filename.
Fix this by using the corrent filename - fsl,qoriq-mc.yaml.
Fixes: bfb921b2a9d5 ("dt-bindings: misc: fsl,qoriq-mc: convert to yaml format")
Signed-off-by: Ioana Ciornei
Reviewed-by: Christophe Leroy
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 76b6db4074ce..1e6aac2962dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19637,7 +19637,7 @@ M: Ioana Ciornei
L: linux-ker...@vger.kernel.org
S: Maintained
F: Documentation/ABI/stable/sysfs-bus-fsl-mc
-F: Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+F: Documentation/devicetree/bindings/misc/fsl,qoriq-mc.yaml
F:
Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst
F: drivers/bus/fsl-mc/
F: include/uapi/linux/fsl_mc.h
--
2.34.1
Re: [PATCH v2 1/1] mm: pgtable: fix pte_swp_exclusive
Hi Magnus,
On Tue, 2025-02-18 at 18:55 +0100, Magnus Lindholm wrote:
> Make pte_swp_exclusive return bool instead of int. This will better reflect
> how pte_swp_exclusive is actually used in the code. This fixes swap/swapoff
> problems on Alpha due pte_swp_exclusive not returning correct values when
> _PAGE_SWP_EXCLUSIVE bit resides in upper 32-bits of PTE (like on alpha).
Minor nitpick:
"when _PAGE_SWP_EXCLUSIVE" => "when the _PAGE_SWP_EXCLUSIVE"
>
> Signed-off-by: Magnus Lindholm
> ---
> arch/alpha/include/asm/pgtable.h | 2 +-
> arch/arc/include/asm/pgtable-bits-arcv2.h| 2 +-
> arch/arm/include/asm/pgtable.h | 2 +-
> arch/arm64/include/asm/pgtable.h | 2 +-
> arch/csky/include/asm/pgtable.h | 2 +-
> arch/hexagon/include/asm/pgtable.h | 2 +-
> arch/loongarch/include/asm/pgtable.h | 2 +-
> arch/m68k/include/asm/mcf_pgtable.h | 2 +-
> arch/m68k/include/asm/motorola_pgtable.h | 2 +-
> arch/m68k/include/asm/sun3_pgtable.h | 2 +-
> arch/microblaze/include/asm/pgtable.h| 2 +-
> arch/mips/include/asm/pgtable.h | 4 ++--
> arch/nios2/include/asm/pgtable.h | 2 +-
> arch/openrisc/include/asm/pgtable.h | 2 +-
> arch/parisc/include/asm/pgtable.h| 2 +-
> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 +-
> arch/powerpc/include/asm/book3s/64/pgtable.h | 2 +-
> arch/powerpc/include/asm/nohash/pgtable.h| 2 +-
> arch/riscv/include/asm/pgtable.h | 2 +-
> arch/s390/include/asm/pgtable.h | 2 +-
> arch/sh/include/asm/pgtable_32.h | 2 +-
> arch/sparc/include/asm/pgtable_32.h | 2 +-
> arch/sparc/include/asm/pgtable_64.h | 2 +-
> arch/um/include/asm/pgtable.h| 2 +-
> arch/x86/include/asm/pgtable.h | 2 +-
> arch/xtensa/include/asm/pgtable.h| 2 +-
> 26 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/arch/alpha/include/asm/pgtable.h
> b/arch/alpha/include/asm/pgtable.h
> index 02e8817a8921..b0870de4b5b8 100644
> --- a/arch/alpha/include/asm/pgtable.h
> +++ b/arch/alpha/include/asm/pgtable.h
> @@ -334,7 +334,7 @@ extern inline pte_t mk_swap_pte(unsigned long type,
> unsigned long offset)
> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
> #define __swp_entry_to_pte(x)((pte_t) { (x).val })
>
> -static inline int pte_swp_exclusive(pte_t pte)
> +static inline bool pte_swp_exclusive(pte_t pte)
> {
> return pte_val(pte) & _PAGE_SWP_EXCLUSIVE;
> }
> diff --git a/arch/arc/include/asm/pgtable-bits-arcv2.h
> b/arch/arc/include/asm/pgtable-bits-arcv2.h
> index 8ebec1b21d24..3084c53f402d 100644
> --- a/arch/arc/include/asm/pgtable-bits-arcv2.h
> +++ b/arch/arc/include/asm/pgtable-bits-arcv2.h
> @@ -130,7 +130,7 @@ void update_mmu_cache_range(struct vm_fault *vmf, struct
> vm_area_struct *vma,
> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
> #define __swp_entry_to_pte(x)((pte_t) { (x).val })
>
> -static inline int pte_swp_exclusive(pte_t pte)
> +static inline bool pte_swp_exclusive(pte_t pte)
> {
> return pte_val(pte) & _PAGE_SWP_EXCLUSIVE;
> }
> diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
> index be91e376df79..aa4f3f71789c 100644
> --- a/arch/arm/include/asm/pgtable.h
> +++ b/arch/arm/include/asm/pgtable.h
> @@ -303,7 +303,7 @@ static inline pte_t pte_modify(pte_t pte, pgprot_t
> newprot)
> #define __pte_to_swp_entry(pte) ((swp_entry_t) { pte_val(pte) })
> #define __swp_entry_to_pte(swp) __pte((swp).val)
>
> -static inline int pte_swp_exclusive(pte_t pte)
> +static inline bool pte_swp_exclusive(pte_t pte)
> {
> return pte_isset(pte, L_PTE_SWP_EXCLUSIVE);
> }
> diff --git a/arch/arm64/include/asm/pgtable.h
> b/arch/arm64/include/asm/pgtable.h
> index 0b2a2ad1b9e8..b48b70d8d12d 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -496,7 +496,7 @@ static inline pte_t pte_swp_mkexclusive(pte_t pte)
> return set_pte_bit(pte, __pgprot(PTE_SWP_EXCLUSIVE));
> }
>
> -static inline int pte_swp_exclusive(pte_t pte)
> +static inline bool pte_swp_exclusive(pte_t pte)
> {
> return pte_val(pte) & PTE_SWP_EXCLUSIVE;
> }
> diff --git a/arch/csky/include/asm/pgtable.h b/arch/csky/include/asm/pgtable.h
> index a397e1718ab6..e68722eb33d9 100644
> --- a/arch/csky/include/asm/pgtable.h
> +++ b/arch/csky/include/asm/pgtable.h
> @@ -200,7 +200,7 @@ static inline pte_t pte_mkyoung(pte_t pte)
> return pte;
> }
>
> -static inline int pte_swp_exclusive(pte_t pte)
> +static inline bool pte_swp_exclusive(pte_t pte)
> {
> return pte_val(pte) & _PAGE_SWP_EXCLUSIVE;
> }
> diff --git a/arch/hexagon/include/asm/pgtable.h
> b/arch/hexagon/include/asm/pgtable.h
> index 8c5b7a1c3d90..fa007eb9aad3 100644
> --- a/arch/hexagon/include/asm/pgtable.h
> +++
Re: [RFC 2/3] mm: introduce GCMA
On Thu, Mar 20, 2025 at 10:39:30AM -0700, Suren Baghdasaryan wrote: > From: Minchan Kim > > This patch introduces GCMA (Guaranteed Contiguous Memory Allocator) > cleacache backend which reserves some amount of memory at the boot > and then donates it to store clean file-backed pages in the cleancache. > GCMA aims to guarantee contiguous memory allocation success as well as > low and deterministic allocation latency. > > Notes: > Originally, the idea was posted by SeongJae Park and Minchan Kim [1]. > Later Minchan reworked it to be used in Android as a reference for > Android vendors to use [2]. That is not a very good summay. It needs to explain how you ensure that the pages do stay clean forever.
Re: [PATCH v4 06/14] x86: Add support for suppressing warning backtraces
On Tue, Apr 01, 2025 at 10:53:46AM -0700, Guenter Roeck wrote:
> > > #define _BUG_FLAGS(ins, flags, extra)
> > > \
> > > do {
> > > \
> > > asm_inline volatile("1:\t" ins "\n"
> > > \
> > >".pushsection __bug_table,\"aw\"\n"
> > > \
> > >"2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"
> > > \
> > >"\t" __BUG_REL(%c0) "\t# bug_entry::file\n"
> > > \
> > > - "\t.word %c1""\t# bug_entry::line\n" \
> > > - "\t.word %c2""\t# bug_entry::flags\n" \
> > > - "\t.org 2b+%c3\n" \
> > > + "\t" __BUG_FUNC_PTR "\t# bug_entry::function\n" \
> > > + "\t.word %c2""\t# bug_entry::line\n" \
> > > + "\t.word %c3""\t# bug_entry::flags\n" \
> > > + "\t.org 2b+%c4\n" \
> > >".popsection\n"
> > > \
> > >extra
> > > \
> > > - : : "i" (__FILE__), "i" (__LINE__),\
> > > + : : "i" (__FILE__), "i" (__BUG_FUNC), "i" (__LINE__),\
> > >"i" (flags),
> > > \
> > >"i" (sizeof(struct bug_entry)));
> > > \
> > > } while (0)
Also this, why do you need this extra function in the bug entry? Isn't
that trivial from the trap site itself? symbol information should be
able to get you the function from the trap ip.
None of this makes any sense.
[PATCH v2 39/57] irqdomain: ppc: Switch irq_domain_add_nomap() to use fwnode
All irq_domain_add_*() functions are going away. PowerPC is the only
user of irq_domain_add_nomap() and there is no irq_domain_create_nomap()
complement.
Therefore, to align with the rest of kernel, rename
irq_domain_add_nomap() to irq_domain_create_nomap() and accept
fwnode_handle instead of device_node.
Signed-off-by: Jiri Slaby (SUSE)
Cc: Alex Shi
Cc: Yanteng Si
Cc: Dongliang Mu
Cc: Madhavan Srinivasan
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Naveen N Rao
Cc: Geoff Levand
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
Documentation/core-api/irq/irq-domain.rst| 2 +-
Documentation/translations/zh_CN/core-api/irq/irq-domain.rst | 2 +-
arch/powerpc/platforms/powermac/smp.c| 2 +-
arch/powerpc/platforms/ps3/interrupt.c | 2 +-
include/linux/irqdomain.h| 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/core-api/irq/irq-domain.rst
b/Documentation/core-api/irq/irq-domain.rst
index f88a6ee67a35..44f4ba5480df 100644
--- a/Documentation/core-api/irq/irq-domain.rst
+++ b/Documentation/core-api/irq/irq-domain.rst
@@ -141,7 +141,7 @@ No Map
::
- irq_domain_add_nomap()
+ irq_domain_create_nomap()
The No Map mapping is to be used when the hwirq number is
programmable in the hardware. In this case it is best to program the
diff --git a/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst
b/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst
index 9174fce12c1b..ecb23cfbc9fc 100644
--- a/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst
+++ b/Documentation/translations/zh_CN/core-api/irq/irq-domain.rst
@@ -124,7 +124,7 @@ irq_domain_add_tree()和irq_domain_create_tree()在功能上是等价的，除
::
- irq_domain_add_nomap()
+ irq_domain_create_nomap()
当硬件中的hwirq号是可编程的时候，就可以采用无映射类型。 在这种情况下，最好将
Linux IRQ号编入硬件本身，这样就不需要映射了。 调用irq_create_direct_mapping()
diff --git a/arch/powerpc/platforms/powermac/smp.c
b/arch/powerpc/platforms/powermac/smp.c
index 09e7fe24fac1..88e92af8acf9 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -190,7 +190,7 @@ static int __init psurge_secondary_ipi_init(void)
{
int rc = -ENOMEM;
- psurge_host = irq_domain_add_nomap(NULL, ~0, &psurge_host_ops, NULL);
+ psurge_host = irq_domain_create_nomap(NULL, ~0, &psurge_host_ops, NULL);
if (psurge_host)
psurge_secondary_virq = irq_create_direct_mapping(psurge_host);
diff --git a/arch/powerpc/platforms/ps3/interrupt.c
b/arch/powerpc/platforms/ps3/interrupt.c
index 95e96bd61a20..a4ad4b49eef7 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -743,7 +743,7 @@ void __init ps3_init_IRQ(void)
unsigned cpu;
struct irq_domain *host;
- host = irq_domain_add_nomap(NULL, PS3_PLUG_MAX + 1, &ps3_host_ops,
NULL);
+ host = irq_domain_create_nomap(NULL, PS3_PLUG_MAX + 1, &ps3_host_ops,
NULL);
irq_set_default_domain(host);
for_each_possible_cpu(cpu) {
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 1480951a690b..984d0188f9ec 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -431,13 +431,13 @@ static inline struct irq_domain
*irq_domain_add_linear(struct device_node *of_no
}
#ifdef CONFIG_IRQ_DOMAIN_NOMAP
-static inline struct irq_domain *irq_domain_add_nomap(struct device_node
*of_node,
+static inline struct irq_domain *irq_domain_create_nomap(struct fwnode_handle
*fwnode,
unsigned int max_irq,
const struct irq_domain_ops *ops,
void *host_data)
{
struct irq_domain_info info = {
- .fwnode = of_fwnode_handle(of_node),
+ .fwnode = fwnode,
.hwirq_max = max_irq,
.direct_max = max_irq,
.ops= ops,
--
2.49.0
Re: Using Restricted DMA for virtio-pci
On Fri, Mar 21, 2025 at 06:42:20PM +, David Woodhouse wrote: > On Fri, 2025-03-21 at 14:32 -0400, Michael S. Tsirkin wrote: > > On Fri, Mar 21, 2025 at 03:38:10PM +, David Woodhouse wrote: > > > On Tue, 2021-02-09 at 14:21 +0800, Claire Chang wrote: > > > > This series implements mitigations for lack of DMA access control on > > > > systems without an IOMMU, which could result in the DMA accessing the > > > > system memory at unexpected times and/or unexpected addresses, possibly > > > > leading to data leakage or corruption. > > > > > > Replying to an ancient (2021) thread which has already been merged... > > > > > > I'd like to be able to use this facility for virtio devices. > > > > > > Virtio already has a complicated relationship with the DMA API, because > > > there were a bunch of early VMM bugs where the virtio devices where > > > magically exempted from IOMMU protection, but the VMM lied to the guest > > > and claimed they weren't. > > > > > > With the advent of confidential computing, and the VMM (or whatever's > > > emulating the virtio device) not being *allowed* to arbitrarily access > > > all of the guest's memory, the DMA API becomes necessary again. > > > > > > Either a virtual IOMMU needs to determine which guest memory the VMM > > > may access, or the DMA API is wrappers around operations which > > > share/unshare (or unencrypt/encrypt) the memory in question. > > > > > > All of which is complicated and slow, if we're looking at a minimal > > > privileged hypervisor stub like pKVM which enforces the lack of guest > > > memory access from VMM. > > > > > > I'm thinking of defining a new type of virtio-pci device which cannot > > > do DMA to arbitrary system memory. Instead it has an additional memory > > > BAR which is used as a SWIOTLB for bounce buffering. > > > > > > The driver for it would look much like the existing virtio-pci device > > > except that it would register the restricted-dma region first (and thus > > > the swiotlb dma_ops), and then just go through the rest of the setup > > > like any other virtio device. > > > > > > That seems like it ought to be fairly simple, and seems like a > > > reasonable way to allow an untrusted VMM to provide virtio devices with > > > restricted DMA access. > > > > > > While I start actually doing the typing... does anyone want to start > > > yelling at me now? Christoph? mst? :) > > > > > > I don't mind as such (though I don't understand completely), but since > > this is changing the device anyway, I am a bit confused why you can't > > just set the VIRTIO_F_ACCESS_PLATFORM feature bit? This forces DMA API > > which will DTRT for you, will it not? > > That would be necessary but not sufficient. The question is *what* does > the DMA API do? > > For a real passthrough PCI device, perhaps we'd have a vIOMMU exposed > to the guest so that it can do real protection with two-stage page > tables (IOVA→GPA under control of the guest, GPA→HPA under control of > the hypervisor). For that to work in the pKVM model though, you'd need > pKVM to be talking the guest's stage1 I/O page tables to see if a given > access from the VMM ought to be permitted? > > Or for confidential guests there could be DMA ops which are an > 'enlightenment'; a hypercall into pKVM to share/unshare pages so that > the VMM can actually access them, or SEV-SNP guests might mark pages > unencrypted to have the same effect with hardware protection. > > Doing any of those dynamically to allow the VMM to access buffers in > arbitrary guest memory (when it wouldn't normally have access to > arbitrary guest memory) is complex and doesn't perform very well. And > exposes a full 4KiB page for any byte that needs to be made available. > > Thus the idea of having a fixed range of memory to use for a SWIOTLB, > which is fairly much what the restricted DMA setup is all about. > > We're just proposing that we build it in to a virtio-pci device model, > which automatically uses the extra memory BAR instead of the > restricted-dma-pool DT node. > > It's basically just allowing us to expose through PCI, what I believe > we can already do for virtio in DT. I am not saying I am against this extension. The idea to restrict DMA has a lot of merit outside pkvm. For example, with a physical devices, limiting its DMA to a fixed range can be good for security at a cost of an extra data copy. So I am not saying we have to block this specific hack. what worries me fundamentally is I am not sure it works well e.g. for physical virtio cards. Attempts to pass data between devices will now also require extra data copies. Did you think about adding an swiotlb mode to virtio-iommu at all? Much easier than parsing page tables. -- MST
Re: [PATCH v4 07/14] arm64: Add support for suppressing warning backtraces
On 3/18/25 08:59, Will Deacon wrote:
On Thu, Mar 13, 2025 at 05:40:59PM +0100, Alessandro Carminati wrote:
On Thu, Mar 13, 2025 at 1:25 PM Will Deacon wrote:
On Thu, Mar 13, 2025 at 11:43:22AM +, Alessandro Carminati wrote:
diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 28be048db3f6..044c5e24a17d 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -11,8 +11,14 @@
#include
+#ifdef HAVE_BUG_FUNCTION
+# define __BUG_FUNC __func__
+#else
+# define __BUG_FUNC NULL
+#endif
+
#define __BUG_FLAGS(flags) \
- asm volatile (__stringify(ASM_BUG_FLAGS(flags)));
+ asm volatile (__stringify(ASM_BUG_FLAGS(flags, %c0)) : : "i"
(__BUG_FUNC));
Why is 'i' the right asm constraint to use here? It seems a bit odd to
use that for a pointer.
I received this code as legacy from a previous version.
In my review, I considered the case when HAVE_BUG_FUNCTION is defined:
Here, __BUG_FUNC is defined as __func__, which is the name of the
current function as a string literal.
Using the constraint "i" seems appropriate to me in this case.
However, when HAVE_BUG_FUNCTION is not defined:
__BUG_FUNC is defined as NULL. Initially, I considered it literal 0,
but after investigating your concern, I found:
```
$ echo -E "#include \n#include \nint main()
{\nreturn 0;\n}" | aarch64-linux-gnu-gcc -E -dM - | grep NULL
#define NULL ((void *)0)
```
I realized that NULL is actually a pointer that is not a link time
symbol, and using the "i" constraint with NULL may result in undefined
behavior.
Would the following alternative definition for __BUG_FUNC be more convincing?
```
#ifdef HAVE_BUG_FUNCTION
#define __BUG_FUNC __func__
#else
#define __BUG_FUNC (uintptr_t)0
#endif
```
Let me know your thoughts.
Thanks for the analysis; I hadn't noticed this specific issue, it just
smelled a bit fishy. Anyway, the diff above looks better, thanks.
It has been a long time, but I seem to recall that I ran into trouble when
trying to use a different constraint.
Guenter
Re: [PATCH 0/9] Add support for configure and control of Hardware Trace Macro(HTM)
> On 20 Mar 2025, at 6:43 PM, Venkat Rao Bagalkote > wrote: > > On 14/03/25 7:25 pm, Athira Rajeev wrote: >> H_HTM (Hardware Trace Macro) hypervisor call is an HCALL to export >> data from Hardware Trace Macro (HTM) function. The debugfs interface >> to export the HTM function data in a partition currently supports only >> dumping of HTM data in an lpar. Patchset add support for configuration >> and control of HTM function via debugfs interface. >> >> With the patchset, after loading htmdump module, >> below files are present: >> >> ls /sys/kernel/debug/powerpc/htmdump/ >> coreindexonchip htmcaps htmconfigure htmflags htminfo htmsetup >> htmstart htmstatus htmtype nodalchipindex nodeindex trace >> >> - nodeindex, nodalchipindex, coreindexonchip specifies which >> partition to configure the HTM for. >> - htmtype: specifies the type of HTM. Supported target is >> hardwareTarget. >> - trace: is to read the HTM data. >> - htmconfigure: Configure/Deconfigure the HTM. Writing 1 to >> the file will configure the trace, writing 0 to the file >> will do deconfigure. >> - htmstart: start/Stop the HTM. Writing 1 to the file will >> start the tracing, writing 0 to the file will stop the tracing. >> - htmstatus: get the status of HTM. This is needed to understand >> the HTM state after each operation. >> - htmsetup: set the HTM buffer size. Size of HTM buffer is in >> power of 2. >> - htminfo: provides the system processor configuration details. >> This is needed to understand the appropriate values for nodeindex, >> nodalchipindex, coreindexonchip. >> - htmcaps : provides the HTM capabilities like minimum/maximum buffer >> size, what kind of tracing the HTM supports etc. >> - htmflags : allows to pass flags to hcall. Currently supports >> controlling the wrapping of HTM buffer. >> >> Example usage: >> To collect HTM traces for a partition represented by nodeindex as >> zero, nodalchipindex as 1 and coreindexonchip as 12. >> >> # cd /sys/kernel/debug/powerpc/htmdump/ >> # echo 2 > htmtype >> # echo 0 > nodeindex >> # echo 1 > nodalchipindex >> # echo 12 > coreindexonchip >> # echo 1 > htmflags # to set noWrap for HTM buffers >> # echo 1 > htmconfigure # Configure the HTM >> # echo 1 > htmstart # Start the HTM >> # echo 0 > htmstart # Stop the HTM >> # echo 0 > htmconfigure # Deconfigure the HTM >> # cat htmstatus # Dump the status of HTM entries as data >> >> Athira Rajeev (9): >> powerpc/pseries/htmdump: Add htm_hcall_wrapper to integrate other htm >> operations >> powerpc/pseries/htmdump: Add htm configure support to htmdump module >> powerpc/pseries/htmdump: Add htm start support to htmdump module >> powerpc/pseries/htmdump: Add htm status support to htmdump module >> powerpc/pseries/htmdump: Add htm info support to htmdump module >> powerpc/pseries/htmdump: Add htm setup support to htmdump module >> powerpc/pseries/htmdump: Add htm flags support to htmdump module >> powerpc/pseries/htmdump: Add htm capabilities support to htmdump >> module >> powerpc/pseries/htmdump: Add documentation for H_HTM debugfs interface >> >> Documentation/arch/powerpc/htm.rst| 104 ++ >> arch/powerpc/include/asm/plpar_wrappers.h | 20 +- >> arch/powerpc/platforms/pseries/htmdump.c | 370 +- >> 3 files changed, 475 insertions(+), 19 deletions(-) >> create mode 100644 Documentation/arch/powerpc/htm.rst >> > Hello Athira, > > I tried to apply this patch set on powerpc-next repo, but pacth 007 failed. > Please refer the failure below. > > > Signed-off-by: Athira Rajeev > -- > Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all: a > Applying: powerpc/pseries/htmdump: Add htm_hcall_wrapper to integrate other > htm operations > Applying: powerpc/pseries/htmdump: Add htm configure support to htmdump module > Applying: powerpc/pseries/htmdump: Add htm start support to htmdump module > Applying: powerpc/pseries/htmdump: Add htm status support to htmdump module > Applying: powerpc/pseries/htmdump: Add htm info support to htmdump module > Applying: powerpc/pseries/htmdump: Add htm setup support to htmdump module > Applying: powerpc/pseries/htmdump: Add htm flags support to htmdump module > error: patch failed: arch/powerpc/platforms/pseries/htmdump.c:180 > error: arch/powerpc/platforms/pseries/htmdump.c: patch does not apply > Patch failed at 0007 powerpc/pseries/htmdump: Add htm flags support to > htmdump module > hint: Use 'git am --show-current-patch=diff' to see the failed patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort”. Hi Venkat Thanks for checking the patch series. I will be posting a V2 with changes soon to address above issue. Thanks Athira > > > Regards, > > Venkat.
[PATCH V2 5/9] powerpc/pseries/htmdump: Add htm info support to htmdump module
Support dumping system processor configuration from Hardware
Trace Macro (HTM) function via debugfs interface. Under
debugfs folder "/sys/kernel/debug/powerpc/htmdump", add
file "htminfo”.
The interface allows only read of this file which will present the
content of HTM buffer from the hcall. The 16th offset of HTM
buffer has value for the number of entries for array of processors.
Use this information to copy data to the debugfs file
Signed-off-by: Athira Rajeev
---
arch/powerpc/platforms/pseries/htmdump.c | 49
1 file changed, 49 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/htmdump.c
b/arch/powerpc/platforms/pseries/htmdump.c
index ef530c092ae4..b387e46f2b8e 100644
--- a/arch/powerpc/platforms/pseries/htmdump.c
+++ b/arch/powerpc/platforms/pseries/htmdump.c
@@ -13,6 +13,7 @@
static void *htm_buf;
static void *htm_status_buf;
+static void *htm_info_buf;
static u32 nodeindex;
static u32 nodalchipindex;
static u32 coreindexonchip;
@@ -243,6 +244,46 @@ static const struct file_operations htmstatus_fops = {
.open = simple_open,
};
+static ssize_t htminfo_read(struct file *filp, char __user *ubuf,
+size_t count, loff_t *ppos)
+{
+ void *htm_info_buf = filp->private_data;
+ long rc, ret;
+ u64 *num_entries;
+ u64 to_copy;
+
+ /*
+* Invoke H_HTM call with:
+* - operation as htm status (H_HTM_OP_STATUS)
+* - last three values as addr, size and offset
+*/
+ rc = htm_hcall_wrapper(nodeindex, nodalchipindex, coreindexonchip,
+ htmtype, H_HTM_OP_DUMP_SYSPROC_CONF,
virt_to_phys(htm_info_buf),
+ PAGE_SIZE, 0);
+
+ ret = htm_return_check(rc);
+ if (ret <= 0)
+ return ret;
+
+ /*
+* HTM status buffer, start of buffer + 0x10 gives the
+* number of HTM entries in the buffer. Each entry of processor
+* is 16 bytes.
+*
+* So total count to copy is:
+* 32 bytes (for first 5 fields) + (number of HTM entries * entry size)
+*/
+ num_entries = htm_info_buf + 0x10;
+ to_copy = 32 + (be64_to_cpu(*num_entries) * 16);
+ return simple_read_from_buffer(ubuf, count, ppos, htm_info_buf,
to_copy);
+}
+
+static const struct file_operations htminfo_fops = {
+ .llseek = NULL,
+ .read = htminfo_read,
+ .open = simple_open,
+};
+
DEFINE_SIMPLE_ATTRIBUTE(htmconfigure_fops, htmconfigure_get, htmconfigure_set,
"%llu\n");
DEFINE_SIMPLE_ATTRIBUTE(htmstart_fops, htmstart_get, htmstart_set, "%llu\n");
@@ -280,7 +321,15 @@ static int htmdump_init_debugfs(void)
return -ENOMEM;
}
+ /* Debugfs interface file to present System Processor Configuration */
+ htm_info_buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!htm_info_buf) {
+ pr_err("Failed to allocate htm info buf\n");
+ return -ENOMEM;
+ }
+
debugfs_create_file("htmstatus", 0400, htmdump_debugfs_dir,
htm_status_buf, &htmstatus_fops);
+ debugfs_create_file("htminfo", 0400, htmdump_debugfs_dir, htm_info_buf,
&htminfo_fops);
return 0;
}
--
2.43.5
Re: Please add powerpc topic/cxl branch to linux-next
Hi Michael, On Thu, 03 Apr 2025 13:32:43 +1100 Michael Ellerman wrote: > > This branch has been merged intoo mainline, you can drop it from > linux-next. Thanks. Done. -- Cheers, Stephen Rothwell pgpYE1UKqL5ho.pgp Description: OpenPGP digital signature
Re: [PATCH] bus: fsl-mc: Remove deadcode
Ioana,
Le 15/11/2024 à 16:20, li...@treblig.org a écrit :
[Vous ne recevez pas souvent de courriers de li...@treblig.org. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
From: "Dr. David Alan Gilbert"
fsl_mc_allocator_driver_exit() was added explicitly by
commit 1e8ac83b6caf ("bus: fsl-mc: add fsl_mc_allocator cleanup function")
but was never used.
Remove it.
fsl_mc_portal_reset() was added in 2015 by
commit 197f4d6a4a00 ("staging: fsl-mc: fsl-mc object allocator driver")
but was never used.
Remove it.
fsl_mc_portal_reset() was the only caller of dpmcp_reset().
Remove it.
Signed-off-by: Dr. David Alan Gilbert
Can you ack this patch ?
Thanks
Christophe
---
drivers/bus/fsl-mc/dpmcp.c| 22 --
drivers/bus/fsl-mc/fsl-mc-allocator.c | 5 -
drivers/bus/fsl-mc/fsl-mc-private.h | 6 --
drivers/bus/fsl-mc/mc-io.c| 20
include/linux/fsl/mc.h| 2 --
5 files changed, 55 deletions(-)
diff --git a/drivers/bus/fsl-mc/dpmcp.c b/drivers/bus/fsl-mc/dpmcp.c
index 5fbd0dbde24a..7816c0a728ef 100644
--- a/drivers/bus/fsl-mc/dpmcp.c
+++ b/drivers/bus/fsl-mc/dpmcp.c
@@ -75,25 +75,3 @@ int dpmcp_close(struct fsl_mc_io *mc_io,
/* send command to mc*/
return mc_send_command(mc_io, &cmd);
}
-
-/**
- * dpmcp_reset() - Reset the DPMCP, returns the object to initial state.
- * @mc_io: Pointer to MC portal's I/O object
- * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
- * @token: Token of DPMCP object
- *
- * Return: '0' on Success; Error code otherwise.
- */
-int dpmcp_reset(struct fsl_mc_io *mc_io,
- u32 cmd_flags,
- u16 token)
-{
- struct fsl_mc_command cmd = { 0 };
-
- /* prepare command */
- cmd.header = mc_encode_cmd_header(DPMCP_CMDID_RESET,
- cmd_flags, token);
-
- /* send command to mc*/
- return mc_send_command(mc_io, &cmd);
-}
diff --git a/drivers/bus/fsl-mc/fsl-mc-allocator.c
b/drivers/bus/fsl-mc/fsl-mc-allocator.c
index b5e8c021fa1f..6c3beb82dd1b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-allocator.c
+++ b/drivers/bus/fsl-mc/fsl-mc-allocator.c
@@ -656,8 +656,3 @@ int __init fsl_mc_allocator_driver_init(void)
{
return fsl_mc_driver_register(&fsl_mc_allocator_driver);
}
-
-void fsl_mc_allocator_driver_exit(void)
-{
- fsl_mc_driver_unregister(&fsl_mc_allocator_driver);
-}
diff --git a/drivers/bus/fsl-mc/fsl-mc-private.h
b/drivers/bus/fsl-mc/fsl-mc-private.h
index b3520ea1b9f4..e1b7ec3ed1a7 100644
--- a/drivers/bus/fsl-mc/fsl-mc-private.h
+++ b/drivers/bus/fsl-mc/fsl-mc-private.h
@@ -66,10 +66,6 @@ int dpmcp_close(struct fsl_mc_io *mc_io,
u32 cmd_flags,
u16 token);
-int dpmcp_reset(struct fsl_mc_io *mc_io,
- u32 cmd_flags,
- u16 token);
-
/*
* Data Path Resource Container (DPRC) API
*/
@@ -631,8 +627,6 @@ int dprc_scan_objects(struct fsl_mc_device *mc_bus_dev,
int __init fsl_mc_allocator_driver_init(void);
-void fsl_mc_allocator_driver_exit(void);
-
void fsl_mc_init_all_resource_pools(struct fsl_mc_device *mc_bus_dev);
void fsl_mc_cleanup_all_resource_pools(struct fsl_mc_device *mc_bus_dev);
diff --git a/drivers/bus/fsl-mc/mc-io.c b/drivers/bus/fsl-mc/mc-io.c
index 95b10a6cf307..a0ad7866cbfc 100644
--- a/drivers/bus/fsl-mc/mc-io.c
+++ b/drivers/bus/fsl-mc/mc-io.c
@@ -263,23 +263,3 @@ void fsl_mc_portal_free(struct fsl_mc_io *mc_io)
dpmcp_dev->consumer_link = NULL;
}
EXPORT_SYMBOL_GPL(fsl_mc_portal_free);
-
-/**
- * fsl_mc_portal_reset - Resets the dpmcp object for a given fsl_mc_io object
- *
- * @mc_io: Pointer to the fsl_mc_io object that wraps the MC portal to free
- */
-int fsl_mc_portal_reset(struct fsl_mc_io *mc_io)
-{
- int error;
- struct fsl_mc_device *dpmcp_dev = mc_io->dpmcp_dev;
-
- error = dpmcp_reset(mc_io, 0, dpmcp_dev->mc_handle);
- if (error < 0) {
- dev_err(&dpmcp_dev->dev, "dpmcp_reset() failed: %d\n", error);
- return error;
- }
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(fsl_mc_portal_reset);
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index c90ec889bfc2..37316a58d2ed 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -417,8 +417,6 @@ int __must_check fsl_mc_portal_allocate(struct
fsl_mc_device *mc_dev,
void fsl_mc_portal_free(struct fsl_mc_io *mc_io);
-int fsl_mc_portal_reset(struct fsl_mc_io *mc_io);
-
int __must_check fsl_mc_object_allocate(struct fsl_mc_device *mc_dev,
enum fsl_mc_pool_type pool_type,
struct fsl_mc_device **new_mc_adev);
--
2.47.0
[PATCH v2 0/3] MAINTAINERS: updates for the fsl-mc bus entry
This patch set updates the fsl-mc bus driver MAINTAINERS entry. Since there are small separate changes, I put each of them into a separate patch. Changes in v2: - 1/3: also removed Stuart from the MAINTAINERS file https://lore.kernel.org/linuxppc-dev/caeac7tyqe76z4pyminhvmjr6gz66rprv4pxm-u9vpgjjvn6...@mail.gmail.com/ Ioana Ciornei (3): MAINTAINERS: add myself as maintainer for the fsl-mc bus MAINTAINERS: fix nonexistent dtbinding file name MAINTAINERS: add the linuppc-dev list to the fsl-mc bus entry MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.34.1
[PATCH 3/4] PCI: Add link down handling for host bridges
From: Manivannan Sadhasivam
The PCI link, when down, needs to be recovered to bring it back. But that
cannot be done in a generic way as link recovery procedure is specific to
host bridges. So add a new API pci_host_handle_link_down() that could be
called by the host bridge drivers when the link goes down.
The API will iterate through all the slots and calls the pcie_do_recovery()
function with 'pci_channel_io_frozen' as the state. This will result in the
execution of the AER Fatal error handling code. Since the link down
recovery is pretty much the same as AER Fatal error handling,
pcie_do_recovery() helper is reused here. First the AER error_detected
callback will be triggered for the bridge and the downstream devices, then
the 'reset_slot' callback for the host bridge will be called to recover the
link. Once that's done, resume message will be broadcasted to the bridge
and the downstream devices indicating successful link recovery.
In case if the AER support is not enabled in the kernel, only the
'reset_slot' callback will be called for each slots as there is no way we
could inform the drivers about link recovery.
Signed-off-by: Manivannan Sadhasivam
---
drivers/pci/pci.h | 22 ++
drivers/pci/pcie/err.c | 13 -
drivers/pci/probe.c| 7 +++
include/linux/pci.h| 1 +
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index
b81e99cd4b62a3022c8b07a09f212f6888674487..7ea81d596d5f9608237f5897c5c13288d9169207
100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -966,6 +966,7 @@ int pci_aer_clear_status(struct pci_dev *dev);
int pci_aer_raw_clear_status(struct pci_dev *dev);
void pci_save_aer_state(struct pci_dev *dev);
void pci_restore_aer_state(struct pci_dev *dev);
+void pcie_do_recover_slots(struct pci_host_bridge *host);
#else
static inline void pci_no_aer(void) { }
static inline void pci_aer_init(struct pci_dev *d) { }
@@ -975,6 +976,27 @@ static inline int pci_aer_clear_status(struct pci_dev
*dev) { return -EINVAL; }
static inline int pci_aer_raw_clear_status(struct pci_dev *dev) { return
-EINVAL; }
static inline void pci_save_aer_state(struct pci_dev *dev) { }
static inline void pci_restore_aer_state(struct pci_dev *dev) { }
+static inline void pcie_do_recover_slots(struct pci_host_bridge *host)
+{
+ struct pci_bus *bus = host->bus;
+ struct pci_dev *dev;
+ int ret;
+
+ if (!host->reset_slot) {
+ dev_warn(&host->dev, "Missing reset_slot() callback\n");
+ return;
+ }
+
+ for_each_pci_bridge(dev, bus) {
+ ret = host->reset_slot(host, dev);
+ if (ret)
+ dev_err(&host->dev, "failed to reset slot (%s): %d\n",
+ pci_name(dev), ret);
+ else
+ dev_dbg(&host->dev, "recovered slot (%s)\n",
+ pci_name(dev));
+ }
+}
#endif
#ifdef CONFIG_ACPI
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index
77ce9354532afee209f658175b86e625bba8a5ee..0f86c228245ef80c5bba4433c109ec37c57f4a67
100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -196,6 +196,7 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
struct pci_dev *bridge;
pci_ers_result_t status = PCI_ERS_RESULT_CAN_RECOVER;
struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
+ int ret;
/*
* If the error was detected by a Root Port, Downstream Port, RCEC,
@@ -219,7 +220,8 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
pci_dbg(bridge, "broadcast error_detected message\n");
if (state == pci_channel_io_frozen) {
pci_walk_bridge(bridge, report_frozen_detected, &status);
- if (reset_subordinates(bridge) != PCI_ERS_RESULT_RECOVERED) {
+ if (reset_subordinates && reset_subordinates(bridge) !=
+ PCI_ERS_RESULT_RECOVERED) {
pci_warn(bridge, "subordinate device reset failed\n");
goto failed;
}
@@ -280,3 +282,12 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
return status;
}
+
+void pcie_do_recover_slots(struct pci_host_bridge *host)
+{
+ struct pci_bus *bus = host->bus;
+ struct pci_dev *dev;
+
+ for_each_pci_bridge(dev, bus)
+ pcie_do_recovery(dev, pci_channel_io_frozen, NULL);
+}
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index
364fa2a514f8a68fb18bded3259c6847d3932f8b..60ad20eea0259797e68afa7979bb1fc24b6f213b
100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -3249,6 +3249,13 @@ int pci_host_probe(struct pci_host_bridge *bridge)
}
EXPORT_SYMBOL_GPL(pci_host_probe);
+void pci_host_handle_link_down(struct pci_host_bridge *bridge)
+{
+ dev_info(&bridge->dev, "Recovering slots due to L
Re: [PATCH v4 00/14] Add support for suppressing warning backtraces
On 3/13/25 16:05, Andrew Morton wrote: On Thu, 13 Mar 2025 11:31:12 -0700 Guenter Roeck wrote: On Thu, Mar 13, 2025 at 06:24:25PM +0100, Maxime Ripard wrote: Yeah, as with my prior review, I'm a fan of this. It makes a bunch of my very noisy tests much easier to deal with. And for the record, we're also affected by this in DRM and would very much like to get it merged in one shape or another. I was unable to get maintainers of major architectures interested enough to provide feedback, and did not see a path forward. Maybe Alessandro has more success than me. I'll put them into mm.git, to advance things a bit. I haven't heard from kunit maintainers yet. This thread got lost in inbox due to travel. David/Brendan/Rae, Okay to take this series? Andrew, Okay to take this through your tree - this needs merging. thanks, -- Shuah
Re: Using Restricted DMA for virtio-pci
On Sun, 2025-03-30 at 09:42 -0400, Michael S. Tsirkin wrote:
> On Fri, Mar 28, 2025 at 05:40:41PM +, David Woodhouse wrote:
> > On Fri, 2025-03-21 at 18:42 +, David Woodhouse wrote:
> > > >
> > > > I don't mind as such (though I don't understand completely), but since
> > > > this is changing the device anyway, I am a bit confused why you can't
> > > > just set the VIRTIO_F_ACCESS_PLATFORM feature bit? This forces DMA API
> > > > which will DTRT for you, will it not?
> > >
> > > That would be necessary but not sufficient. ...
>
> could you explain pls?
There was more to that in the previous email which I elided for this
followup.
https://lore.kernel.org/all/d1382a6ee959f22dc5f6628d8648af77f4702418.ca...@infradead.org/
> > My first cut at a proposed spec change looks something like this. I'll
> > post it to the virtio-comment list once I've done some corporate
> > bureaucracy and when the list stops sending me python tracebacks in
> > response to my subscribe request.
>
> the linux foundation one does this? maybe poke at the admins.
>
> > In the meantime I'll hack up some QEMU and guest Linux driver support
> > to match.
> >
> > diff --git a/content.tex b/content.tex
> > index c17ffa6..1e6e1d6 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -773,6 +773,9 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved
> > Feature Bits}
> > Currently these device-independent feature bits are defined:
> >
> > \begin{description}
> > + \item[VIRTIO_F_SWIOTLB (27)] This feature indicates that the device
> > + provides a memory region which is to be used for bounce buffering,
> > + rather than permitting direct memory access to system memory.
> > \item[VIRTIO_F_INDIRECT_DESC (28)] Negotiating this feature indicates
> > that the driver can use descriptors with the VIRTQ_DESC_F_INDIRECT
> > flag set, as described in \ref{sec:Basic Facilities of a Virtio
> > @@ -885,6 +888,10 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved
> > Feature Bits}
> > VIRTIO_F_ACCESS_PLATFORM is not offered, then a driver MUST pass only
> > physical
> > addresses to the device.
> >
> > +A driver SHOULD accept VIRTIO_F_SWIOTLB if it is offered, and it MUST
> > +then pass only addresses within the Software IOTLB bounce buffer to the
> > +device.
> > +
> > A driver SHOULD accept VIRTIO_F_RING_PACKED if it is offered.
> >
> > A driver SHOULD accept VIRTIO_F_ORDER_PLATFORM if it is offered.
> > @@ -921,6 +928,10 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved
> > Feature Bits}
> > A device MAY fail to operate further if VIRTIO_F_ACCESS_PLATFORM is not
> > accepted.
> >
> > +A device MUST NOT offer VIRTIO_F_SWIOTLB if its transport does not
> > +provide a Software IOTLB bounce buffer.
> > +A device MAY fail to operate further if VIRTIO_F_SWIOTLB is not accepted.
> > +
> > If VIRTIO_F_IN_ORDER has been negotiated, a device MUST use
> > buffers in the same order in which they have been available.
> >
> > diff --git a/transport-pci.tex b/transport-pci.tex
> > index a5c6719..23e0d57 100644
> > --- a/transport-pci.tex
> > +++ b/transport-pci.tex
> > @@ -129,6 +129,7 @@ \subsection{Virtio Structure PCI
> > Capabilities}\label{sec:Virtio Transport Option
> > \item ISR Status
> > \item Device-specific configuration (optional)
> > \item PCI configuration access
> > +\item SWIOTLB bounce buffer
> > \end{itemize}
> >
> > Each structure can be mapped by a Base Address register (BAR) belonging to
> > @@ -188,6 +189,8 @@ \subsection{Virtio Structure PCI
> > Capabilities}\label{sec:Virtio Transport Option
> > #define VIRTIO_PCI_CAP_SHARED_MEMORY_CFG 8
> > /* Vendor-specific data */
> > #define VIRTIO_PCI_CAP_VENDOR_CFG 9
> > +/* Software IOTLB bounce buffer */
> > +#define VIRTIO_PCI_CAP_SWIOTLB 10
> > \end{lstlisting}
> >
> > Any other value is reserved for future use.
> > @@ -744,6 +747,36 @@ \subsubsection{Vendor data capability}\label{sec:Virtio
> > The driver MUST qualify the \field{vendor_id} before
> > interpreting or writing into the Vendor data capability.
> >
> > +\subsubsection{Software IOTLB bounce buffer capability}\label{sec:Virtio
> > +Transport Options / Virtio Over PCI Bus / PCI Device Layout /
> > +Software IOTLB bounce buffer capability}
> > +
> > +The optional Software IOTLB bounce buffer capability allows the
> > +device to provide a memory region which can be used by the driver
> > +driver for bounce buffering. This allows a device on the PCI
> > +transport to operate without DMA access to system memory addresses.
> > +
> > +The Software IOTLB region is referenced by the
> > +VIRTIO_PCI_CAP_SWIOTLB capability. Bus addresses within the referenced
> > +range are not subject to the requirements of the VIRTIO_F_ORDER_PLATFORM
> > +capability, if negotiated.
>
>
> why not? an optimization?
> A mix of swiotlb and system memory might be very challenging from POV
> of ordering.
Conceptually, these addresses are *on* the PCI device. If
Re: [PATCH v13 2/5] arm64: add support for ARCH_HAS_COPY_MC
在 2025/3/29 1:06, Yeoreum Yun 写道: Hi, 在 2025/2/13 0:21, Catalin Marinas 写道: (catching up with old threads) On Mon, Dec 09, 2024 at 10:42:54AM +0800, Tong Tiangen wrote: For the arm64 kernel, when it processes hardware memory errors for synchronize notifications(do_sea()), if the errors is consumed within the kernel, the current processing is panic. However, it is not optimal. Take copy_from/to_user for example, If ld* triggers a memory error, even in kernel mode, only the associated process is affected. Killing the user process and isolating the corrupt page is a better choice. I agree that killing the user process and isolating the page is a better choice but I don't see how the latter happens after this patch. Which page would be isolated? The SEA is triggered when the page with hardware error is read. After that, the page is isolated in memory_failure() (mf). The processing of mf is mentioned in the comments of do_sea(). /* * APEI claimed this as a firmware-first notification. * Some processing deferred to task_work before ret_to_user(). */ Some processing include mf. Add new fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR to identify insn that can recover from memory errors triggered by access to kernel memory, and this fixup type is used in __arch_copy_to_user(), This make the regular copy_to_user() will handle kernel memory errors. Is the assumption that the error on accessing kernel memory is transient? There's no way to isolate the kernel page and also no point in isolating the destination page either. Yes, it's transient, the kernel page in mf can't be isolated, the transient access (ld) of this kernel page is currently expected to kill the user-mode process to avoid error spread. I'm not sure about how this works. IIUC, the memory_failure() wouldn't kill any process if page which raises sea is kernel page (because this wasn't mapped). right. But, to mark the kernel page as posision, I think it also need to call apei_claim_sea() in !user_mode(). What about calling the apei_claim_sea() when fix_exception_me() successed only in !user_mode() case? This was discussed with Mark in V12: https://lore.kernel.org/lkml/20240528085915.1955987-3-tongtian...@huawei.com/ Sorry for didn't catch your reply in time:) Thanks, Tong. Thanks. The SEA processes synchronization errors. Only hardware errors on the source page can be detected (Through synchronous ld insn) and processed. The destination page cannot be processed. .
Re: [PATCH v9 0/7] Add character devices for indices, platform-dump
On 3/15/25 2:57 PM, Haren Myneni wrote:
Several APIs such as rtas_get_indices(), rtas_get_dynamic_sensor(),
rtas_set_dynamic_indicator(), rtas_platform_dump() and
rtas_physical_attestation() provided by librtas library are
implemented in user space using rtas syscall in combination with
writable mappings of /dev/mem. But this implementation is not
compatible with system lockdown which prohibits /dev/mem access.
The current kernel already provides char based driver interfaces
for several RTAS calls such as VPD and system parameters to
support lockdown feature.
This patch series adds new char based drivers, /dev/papr-indices
for ibm,get-indices, ibm,get-dynamic-sensor-state and
ibm,set-dynamic-indicator RTAS Calls. /dev/papr-platform-dump
for ibm,platform-dump and /dev/papr-physical-attestation
fir ibm,physical-attestation. Providing the similar
open/ioctl/read interfaces to the user space as in the case of
VPD and system parameters.
I have made changes to librtas library to use the new kernel
interfaces if the corresponding device entry is available.
This patch series has the following patches:
powerpc/pseries: Define common functions for RTAS sequence calls
- For some of sequence based RTAS calls, the OS should not start
another sequence with different input until the previous sequence
is completed. So the sequence should be completed during ioctl()
and expose the entire buffer during read(). ibm,get-indices is
sequence based RTAS function similar to ibm,get-vpd and we already
have the corresponding implementation for VPD driver. So update
papr_rtas_sequence struct for RTAS call specific functions and move
the top level sequence functions in to a separate file.
powerpc/pseries: Define papr_indices_io_block for papr-indices ioctls
- /dev/papr-indices driver supports ibm,get-indices,
ibm,get-dynamic-sensor-state and ibm,set-dynamic-indicator RTAS Calls.
papr-indices.h introduces 3 different ioctls for these RTAS calls and
the corresponding ioctl input buffer.
powerpc/pseries: Add papr-indices char driver for ibm,get-indices
- Introduce /dev/papr-indices char based driver and add support for
get-indices RTAS function
powerpc/pseries: Add ibm,set-dynamic-indicator RTAS call support
- Update /dev/papr-indices for set-dynamic-indicator RTAS function
powerpc/pseries: Add ibm,get-dynamic-sensor-state RTAS call support
- Update /dev/papr-indices for get-dynamic-sensor-state RTAS function
powerpc/pseries: Add papr-platform-dump character driver for dump
retrieval
- Introduce /dev/papr-platform-dump char driver and adds support for
ibm,platform-dump. Received suggestions from the previous post as a
separate patch - Updated the patch with invalidating the dump using
a separate ioctl.
powerpc/pseries: Add a char driver for papr-physical-attestation RTAS
- Introduce /dev/papr-physical-attestation char driver to provide
kernel interface for ibm,physical-attestation RTAS function.
Thanks to Sathvika Vasireddy for testing these kernel APIs with various
tools.
Changelog:
v9:
- Fixed syntax issue in papr-rtas-common.c as reported by
Mukesh Kumar Chaurasiya
v8:
- Fixed build warnings for the proper function parameter descriptions
(vpd_sequence_begin(), few papr_rtas_*() functions, and etc) as
reported by kernel test robot
v7:
- Pass the proper next value to the subsequent RTAS calls for the
get-indices sequence RTAS.
(Vasireddy Sathvika found this bug).
v6:
- Define the proper command ID for PAPR_PHY_ATTEST_IOC_HANDLE ioctl
- Update ioctls description in ioctl-number.rst.
v5:
- Return with -EINPROGRESS in papr_platform_dump_invalidate_ioctl()
if the complete dump is not read (Suggested by Michal Suchánek).
v4:
- Include patch "Add char driver for papr-physical-attestation RTAS"
in this series. ibm,physical-attestation is sequence based RTAS
call and the implementation is also similar to ibm,get-vpd and
ibm,get-indices.
v3:
- put_unused_fd() only after get_unused_fd() successful for the failure
case later ("Add papr-platform-dump character driver for dump
retrieval" patch).
v2:
- Added unlock rtas_ibm_set_dynamic_indicator_lock and
rtas_ibm_get_dynamic_sensor_state_lock mutex for failure cases
as reported by Dan Carpenter
- Fixed build warnings for the proper function parameter descriptions
as reported by kernel test robot
Haren Myneni (7):
powerpc/pseries: Define common functions for RTAS sequence calls
powerpc/pseries: Define papr_indices_io_block for papr-indices ioctls
powerpc/pseries: Add papr-indices char driver for ibm,get-indices
powerpc/pseries: Add ibm,set-dynamic-indicator RTAS call support
powerpc/pseries: Add ibm,get-dynamic-sensor-state RTAS call support
powerpc/pseries: Add papr-platform-dump character driver for dump
retrieval
powerpc/pseries: Add a char driver for physical-attestation RTAS
.../userspace-api/ioctl/ioctl-number.rst | 6 +
arch/powerpc/include
[PATCH v2 1/3] MAINTAINERS: add myself as maintainer for the fsl-mc bus
Both Laurentiu and Stuart left the company and are no longer involved with the fsl-mc bus. Remove them and add myself as maintainer. Signed-off-by: Ioana Ciornei --- Changes in v2: - also removed Stuart from the MAINTAINERS file https://lore.kernel.org/linuxppc-dev/caeac7tyqe76z4pyminhvmjr6gz66rprv4pxm-u9vpgjjvn6...@mail.gmail.com/ MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 565efd642bd6..95cf8b1a40d5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19638,8 +19638,7 @@ F: fs/qnx6/ F: include/linux/qnx6_fs.h QORIQ DPAA2 FSL-MC BUS DRIVER -M: Stuart Yoder -M: Laurentiu Tudor +M: Ioana Ciornei L: linux-ker...@vger.kernel.org S: Maintained F: Documentation/ABI/stable/sysfs-bus-fsl-mc -- 2.34.1
Re: [PATCH v4 00/14] Add support for suppressing warning backtraces
On Thu, 13 Mar 2025 at 19:44, Alessandro Carminati wrote: > > Some unit tests intentionally trigger warning backtraces by passing bad > parameters to kernel API functions. Such unit tests typically check the > return value from such calls, not the existence of the warning backtrace. > > Such intentionally generated warning backtraces are neither desirable > nor useful for a number of reasons. > - They can result in overlooked real problems. > - A warning that suddenly starts to show up in unit tests needs to be > investigated and has to be marked to be ignored, for example by > adjusting filter scripts. Such filters are ad-hoc because there is > no real standard format for warnings. On top of that, such filter > scripts would require constant maintenance. > > One option to address problem would be to add messages such as "expected > warning backtraces start / end here" to the kernel log. However, that > would again require filter scripts, it might result in missing real > problematic warning backtraces triggered while the test is running, and > the irrelevant backtrace(s) would still clog the kernel log. > > Solve the problem by providing a means to identify and suppress specific > warning backtraces while executing test code. Support suppressing multiple > backtraces while at the same time limiting changes to generic code to the > absolute minimum. Architecture specific changes are kept at minimum by > retaining function names only if both CONFIG_DEBUG_BUGVERBOSE and > CONFIG_KUNIT are enabled. > > The first patch of the series introduces the necessary infrastructure. > The second patch introduces support for counting suppressed backtraces. > This capability is used in patch three to implement unit tests. > Patch four documents the new API. > The next two patches add support for suppressing backtraces in drm_rect > and dev_addr_lists unit tests. These patches are intended to serve as > examples for the use of the functionality introduced with this series. > The remaining patches implement the necessary changes for all > architectures with GENERIC_BUG support. > > With CONFIG_KUNIT enabled, image size increase with this series applied is > approximately 1%. The image size increase (and with it the functionality > introduced by this series) can be avoided by disabling > CONFIG_KUNIT_SUPPRESS_BACKTRACE. > > This series is based on the RFC patch and subsequent discussion at > https://patchwork.kernel.org/project/linux-kselftest/patch/02546e59-1afe-4b08-ba81-d94f3b691c9a@moroto.mountain/ > and offers a more comprehensive solution of the problem discussed there. > > Design note: > Function pointers are only added to the __bug_table section if both > CONFIG_KUNIT_SUPPRESS_BACKTRACE and CONFIG_DEBUG_BUGVERBOSE are enabled > to avoid image size increases if CONFIG_KUNIT is disabled. There would be > some benefits to adding those pointers all the time (reduced complexity, > ability to display function names in BUG/WARNING messages). That change, > if desired, can be made later. > > Checkpatch note: > Remaining checkpatch errors and warnings were deliberately ignored. > Some are triggered by matching coding style or by comments interpreted > as code, others by assembler macros which are disliked by checkpatch. > Suggestions for improvements are welcome. > > Changes since RFC: > - Introduced CONFIG_KUNIT_SUPPRESS_BACKTRACE > - Minor cleanups and bug fixes > - Added support for all affected architectures > - Added support for counting suppressed warnings > - Added unit tests using those counters > - Added patch to suppress warning backtraces in dev_addr_lists tests > > Changes since v1: > - Rebased to v6.9-rc1 > - Added Tested-by:, Acked-by:, and Reviewed-by: tags > [I retained those tags since there have been no functional changes] > - Introduced KUNIT_SUPPRESS_BACKTRACE configuration option, enabled by > default. > > Changes since v2: > - Rebased to v6.9-rc2 > - Added comments to drm warning suppression explaining why it is needed. > - Added patch to move conditional code in arch/sh/include/asm/bug.h > to avoid kerneldoc warning > - Added architecture maintainers to Cc: for architecture specific patches > - No functional changes > > Changes since v3: > - Rebased to v6.14-rc6 > - Dropped net: "kunit: Suppress lock warning noise at end of dev_addr_lists > tests" > since 3db3b62955cd6d73afde05a17d7e8e106695c3b9 > - Added __kunit_ and KUNIT_ prefixes. > - Tested on interessed architectures. > > Sorry: I also thought this had already landed. I'm definitely in favour of us taking this, though agree that we definitely can't afford to break the s390x build. I've (re-)reviewed the early patches as well, and am generally acking the series (though some of the architecture-specific patches are definitely beyond my expertise to review fully). Acked-by: David Gow Cheers, -- David > Guenter Roeck (14): > bug/kunit: Core support for suppressing warning backtraces > kunit: bug:
[PATCH 1/3] pci/hotplug/pnv_php: Properly clean up allocated IRQs on unplug
In cases where the root of a nested PCIe bridge configuration is
unplugged, the pnv_php driver would leak the allocated IRQ resources for
the child bridges' hotplug event notifications, resulting in a panic.
Fix this by walking all child buses and deallocating all it's IRQ
resources before calling pci_hp_remove_devices.
Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so
that it is only destroyed in pnv_php_free_slot, instead of
pnv_php_disable_irq. This is required since pnv_php_disable_irq will now
be called by workers triggered by hot unplug interrupts, so the
workqueue needs to stay allocated.
The abridged kernel panic that occurs without this patch is as follows:
WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292
msi_device_data_release+0x6c/0x9c
CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2
Call Trace:
msi_device_data_release+0x34/0x9c (unreliable)
release_nodes+0x64/0x13c
devres_release_all+0xc0/0x140
device_del+0x2d4/0x46c
pci_destroy_dev+0x5c/0x194
pci_hp_remove_devices+0x90/0x128
pci_hp_remove_devices+0x44/0x128
pnv_php_disable_slot+0x54/0xd4
power_write_file+0xf8/0x18c
pci_slot_attr_store+0x40/0x5c
sysfs_kf_write+0x64/0x78
kernfs_fop_write_iter+0x1b0/0x290
vfs_write+0x3bc/0x50c
ksys_write+0x84/0x140
system_call_exception+0x124/0x230
system_call_vectored_common+0x15c/0x2ec
Signed-off-by: Shawn Anastasio
---
drivers/pci/hotplug/pnv_php.c | 76 ++-
1 file changed, 57 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/hotplug/pnv_php.c b/drivers/pci/hotplug/pnv_php.c
index 573a41869c15..2c07544216fb 100644
--- a/drivers/pci/hotplug/pnv_php.c
+++ b/drivers/pci/hotplug/pnv_php.c
@@ -36,8 +36,10 @@ static void pnv_php_register(struct device_node *dn);
static void pnv_php_unregister_one(struct device_node *dn);
static void pnv_php_unregister(struct device_node *dn);
+static void pnv_php_enable_irq(struct pnv_php_slot *php_slot);
+
static void pnv_php_disable_irq(struct pnv_php_slot *php_slot,
- bool disable_device)
+ bool disable_device, bool disable_msi)
{
struct pci_dev *pdev = php_slot->pdev;
u16 ctrl;
@@ -53,19 +55,15 @@ static void pnv_php_disable_irq(struct pnv_php_slot
*php_slot,
php_slot->irq = 0;
}
- if (php_slot->wq) {
- destroy_workqueue(php_slot->wq);
- php_slot->wq = NULL;
- }
-
- if (disable_device) {
+ if (disable_device || disable_msi) {
if (pdev->msix_enabled)
pci_disable_msix(pdev);
else if (pdev->msi_enabled)
pci_disable_msi(pdev);
+ }
+ if (disable_device)
pci_disable_device(pdev);
- }
}
static void pnv_php_free_slot(struct kref *kref)
@@ -74,7 +72,8 @@ static void pnv_php_free_slot(struct kref *kref)
struct pnv_php_slot, kref);
WARN_ON(!list_empty(&php_slot->children));
- pnv_php_disable_irq(php_slot, false);
+ pnv_php_disable_irq(php_slot, false, false);
+ destroy_workqueue(php_slot->wq);
kfree(php_slot->name);
kfree(php_slot);
}
@@ -561,8 +560,42 @@ static int pnv_php_reset_slot(struct hotplug_slot *slot,
bool probe)
static int pnv_php_enable_slot(struct hotplug_slot *slot)
{
struct pnv_php_slot *php_slot = to_pnv_php_slot(slot);
+ u32 prop32;
+ int ret;
+
+ ret = pnv_php_enable(php_slot, true);
+ if (ret)
+ return ret;
- return pnv_php_enable(php_slot, true);
+ /* (Re-)enable interrupt if the slot supports surprise hotplug */
+ ret = of_property_read_u32(php_slot->dn, "ibm,slot-surprise-pluggable",
&prop32);
+ if (!ret && prop32)
+ pnv_php_enable_irq(php_slot);
+
+ return 0;
+}
+
+/**
+ * Disable any hotplug interrupts for all slots on the provided bus, as well as
+ * all downstream slots in preparation for a hot unplug.
+ */
+static int pnv_php_disable_all_irqs(struct pci_bus *bus)
+{
+ struct pci_bus *child_bus;
+ struct pci_slot *cur_slot;
+
+ /* First go down child busses */
+ list_for_each_entry(child_bus, &bus->children, node)
+ pnv_php_disable_all_irqs(child_bus);
+
+ /* Disable IRQs for all pnv_php slots on this bus */
+ list_for_each_entry(cur_slot, &bus->slots, list) {
+ struct pnv_php_slot *php_slot =
to_pnv_php_slot(cur_slot->hotplug);
+
+ pnv_php_disable_irq(php_slot, false, true);
+ }
+
+ return 0;
}
static int pnv_php_disable_slot(struct hotplug_slot *slot)
@@ -579,6 +612,10 @@ static int pnv_php_disable_slot(struct hotplug_slot *slot)
php_slot->state != PNV_PHP_STATE_REGISTERED)
return 0;
+
+ /* Free all irq resources from slot and all child slots befor
[PATCH 0/9] Remove per-architecture ChaCha skcipher glue code
Currently each architecture exposes ChaCha not only through the library API, but also through the crypto_skcipher API. That requires each architecture to implement essentially the same skcipher glue code. Following the example of what's been done for crc32 and crc32c, eliminate this redundancy by making crypto/chacha.c register both the generic and architecture-optimized skcipher algorithms, implemented on top of the appropriate library functions. This removes almost 800 lines of code and disentangles the library code from the skcipher API. >From what I remember, the following are the reasons why it wasn't just done this way originally. But none of these really hold water: - The skcipher code was there first, so it may have seemed more natural to add onto it rather than replace it. - Architectures could register multiple skcipher algorithms using different CPU features and have them all be tested in a single boot. This was convenient in theory, but it never really worked properly. It didn't apply to the library code, the x86 ChaCha code wasn't actually doing this (it used static keys instead), and this cannot catch bugs like accidentally using an AVX instruction in SSE code. Instead, a correct solution, which also doesn't require any special kernel support, is to just boot the kernel in QEMU using different -cpu arguments as needed to test all the code. - There was a concern about changing cra_driver_names potentially breaking users. But in practice users rely on cra_name, not cra_driver_name. We already change, add, and remove cra_driver_names occasionally for various reasons. And even if someone was relying on a specific cra_driver_name, there are some more lightweight compatibility tricks that could be used. - There was a desire for users to be able to override the kernel's choice of ChaCha implementation by blacklisting the arch-optimized ChaCha module. But that already became mostly impossible when the library functions were added to the same module. And in practice users don't do this anyway. Even if, hypothetically, someone really needed to do this and for some reason the kernel couldn't be fixed to make the right choice in their case automatically, there are other ways this could be implemented such as a module parameter. Eric Biggers (9): crypto: riscv/chacha - implement library instead of skcipher crypto: chacha - centralize the skcipher wrappers for arch code crypto: arm/chacha - remove the redundant skcipher algorithms crypto: arm64/chacha - remove the skcipher algorithms crypto: mips/chacha - remove the skcipher algorithms crypto: powerpc/chacha - remove the skcipher algorithms crypto: s390/chacha - remove the skcipher algorithms crypto: x86/chacha - remove the skcipher algorithms crypto: chacha - remove arch/arm/crypto/Kconfig | 7 - arch/arm/crypto/chacha-glue.c | 243 +- arch/arm/crypto/chacha-neon-core.S | 2 +- arch/arm64/crypto/Kconfig | 7 - arch/arm64/crypto/chacha-neon-core.S| 2 +- arch/arm64/crypto/chacha-neon-glue.c| 146 + arch/mips/crypto/Kconfig| 6 - arch/mips/crypto/chacha-glue.c | 131 +--- arch/powerpc/crypto/Kconfig | 8 - arch/powerpc/crypto/chacha-p10-glue.c | 147 +- arch/riscv/crypto/Kconfig | 11 +- arch/riscv/crypto/chacha-riscv64-glue.c | 112 -- arch/riscv/crypto/chacha-riscv64-zvkb.S | 71 +++ arch/s390/crypto/Kconfig| 7 - arch/s390/crypto/chacha-glue.c | 99 ++--- arch/x86/crypto/Kconfig | 9 - arch/x86/crypto/chacha_glue.c | 144 + crypto/Makefile | 3 +- crypto/chacha.c | 260 crypto/chacha_generic.c | 139 - include/crypto/chacha.h | 9 + include/crypto/internal/chacha.h| 43 22 files changed, 413 insertions(+), 1193 deletions(-) create mode 100644 crypto/chacha.c delete mode 100644 crypto/chacha_generic.c delete mode 100644 include/crypto/internal/chacha.h base-commit: 56f944529ec2292cbe63377a76df3759d702dd39 -- 2.49.0
[PATCH 3/9] crypto: arm/chacha - remove the redundant skcipher algorithms
From: Eric Biggers
Since crypto/chacha.c now registers chacha20-$(ARCH), xchacha20-$(ARCH),
and xchacha12-$(ARCH) skcipher algorithms that use the architecture's
ChaCha and HChaCha library functions, individual architectures no longer
need to do the same. Therefore, remove the redundant skcipher
algorithms and leave just the library functions.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/Kconfig| 7 -
arch/arm/crypto/chacha-glue.c | 242 +
arch/arm/crypto/chacha-neon-core.S | 2 +-
3 files changed, 7 insertions(+), 244 deletions(-)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index 23e4ea067ddbb..624c4c8c5296a 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -214,17 +214,10 @@ config CRYPTO_AES_ARM_CE
Architecture: arm using:
- ARMv8 Crypto Extensions
config CRYPTO_CHACHA20_NEON
tristate
- select CRYPTO_SKCIPHER
select CRYPTO_ARCH_HAVE_LIB_CHACHA
default CRYPTO_LIB_CHACHA_INTERNAL
- help
- Length-preserving ciphers: ChaCha20, XChaCha20, and XChaCha12
- stream cipher algorithms
-
- Architecture: arm using:
- - NEON (Advanced SIMD) extensions
endmenu
diff --git a/arch/arm/crypto/chacha-glue.c b/arch/arm/crypto/chacha-glue.c
index e1cb34d317712..3a5c75c95d43b 100644
--- a/arch/arm/crypto/chacha-glue.c
+++ b/arch/arm/crypto/chacha-glue.c
@@ -1,18 +1,15 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * ARM NEON accelerated ChaCha and XChaCha stream ciphers,
- * including ChaCha20 (RFC7539)
+ * ChaCha and HChaCha functions (ARM optimized)
*
* Copyright (C) 2016-2019 Linaro, Ltd.
* Copyright (C) 2015 Martin Willi
*/
-#include
-#include
+#include
#include
-#include
#include
#include
#include
#include
@@ -98,262 +95,35 @@ void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes,
dst += todo;
} while (bytes);
}
EXPORT_SYMBOL(chacha_crypt_arch);
-static int chacha_stream_xor(struct skcipher_request *req,
-const struct chacha_ctx *ctx, const u8 *iv,
-bool neon)
-{
- struct skcipher_walk walk;
- u32 state[16];
- int err;
-
- err = skcipher_walk_virt(&walk, req, false);
-
- chacha_init(state, ctx->key, iv);
-
- while (walk.nbytes > 0) {
- unsigned int nbytes = walk.nbytes;
-
- if (nbytes < walk.total)
- nbytes = round_down(nbytes, walk.stride);
-
- if (!IS_ENABLED(CONFIG_KERNEL_MODE_NEON) || !neon) {
- chacha_doarm(walk.dst.virt.addr, walk.src.virt.addr,
-nbytes, state, ctx->nrounds);
- state[12] += DIV_ROUND_UP(nbytes, CHACHA_BLOCK_SIZE);
- } else {
- kernel_neon_begin();
- chacha_doneon(state, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes, ctx->nrounds);
- kernel_neon_end();
- }
- err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
- }
-
- return err;
-}
-
-static int do_chacha(struct skcipher_request *req, bool neon)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
-
- return chacha_stream_xor(req, ctx, req->iv, neon);
-}
-
-static int chacha_arm(struct skcipher_request *req)
-{
- return do_chacha(req, false);
-}
-
-static int chacha_neon(struct skcipher_request *req)
-{
- return do_chacha(req, neon_usable());
-}
-
-static int do_xchacha(struct skcipher_request *req, bool neon)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- struct chacha_ctx subctx;
- u32 state[16];
- u8 real_iv[16];
-
- chacha_init(state, ctx->key, req->iv);
-
- if (!IS_ENABLED(CONFIG_KERNEL_MODE_NEON) || !neon) {
- hchacha_block_arm(state, subctx.key, ctx->nrounds);
- } else {
- kernel_neon_begin();
- hchacha_block_neon(state, subctx.key, ctx->nrounds);
- kernel_neon_end();
- }
- subctx.nrounds = ctx->nrounds;
-
- memcpy(&real_iv[0], req->iv + 24, 8);
- memcpy(&real_iv[8], req->iv + 16, 8);
- return chacha_stream_xor(req, &subctx, real_iv, neon);
-}
-
-static int xchacha_arm(struct skcipher_request *req)
-{
- return do_xchacha(req, false);
-}
-
-static int xchacha_neon(struct skcipher_request *req)
-{
- return do_xchacha(req, neon_usable());
-}
-
-static struct skcipher_alg arm_algs[] = {
- {
- .base.cra_name = "chacha20",
- .base.cra_driver_name = "chacha20-arm",
- .base.cra_priority = 200,
- .base.cra_bloc
[PATCH 6/9] crypto: powerpc/chacha - remove the skcipher algorithms
From: Eric Biggers
Since crypto/chacha.c now registers chacha20-$(ARCH), xchacha20-$(ARCH),
and xchacha12-$(ARCH) skcipher algorithms that use the architecture's
ChaCha and HChaCha library functions, individual architectures no longer
need to do the same. Therefore, remove the redundant skcipher
algorithms and leave just the library functions.
Signed-off-by: Eric Biggers
---
arch/powerpc/crypto/Kconfig | 8 --
arch/powerpc/crypto/chacha-p10-glue.c | 145 ++
2 files changed, 6 insertions(+), 147 deletions(-)
diff --git a/arch/powerpc/crypto/Kconfig b/arch/powerpc/crypto/Kconfig
index 370db8192ce62..47dccdd496374 100644
--- a/arch/powerpc/crypto/Kconfig
+++ b/arch/powerpc/crypto/Kconfig
@@ -93,21 +93,13 @@ config CRYPTO_AES_GCM_P10
later CPU. This module supports stitched acceleration for AES/GCM.
config CRYPTO_CHACHA20_P10
tristate
depends on PPC64 && CPU_LITTLE_ENDIAN && VSX
- select CRYPTO_SKCIPHER
select CRYPTO_LIB_CHACHA_GENERIC
select CRYPTO_ARCH_HAVE_LIB_CHACHA
default CRYPTO_LIB_CHACHA_INTERNAL
- help
- Length-preserving ciphers: ChaCha20, XChaCha20, and XChaCha12
- stream cipher algorithms
-
- Architecture: PowerPC64
- - Power10 or later
- - Little-endian
config CRYPTO_POLY1305_P10
tristate "Hash functions: Poly1305 (P10 or later)"
depends on PPC64 && CPU_LITTLE_ENDIAN && VSX
select CRYPTO_HASH
diff --git a/arch/powerpc/crypto/chacha-p10-glue.c
b/arch/powerpc/crypto/chacha-p10-glue.c
index 3355305b6c7f8..9982929573add 100644
--- a/arch/powerpc/crypto/chacha-p10-glue.c
+++ b/arch/powerpc/crypto/chacha-p10-glue.c
@@ -1,17 +1,14 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * PowerPC P10 (ppc64le) accelerated ChaCha and XChaCha stream ciphers,
- * including ChaCha20 (RFC7539)
+ * ChaCha stream cipher (P10 accelerated)
*
* Copyright 2023- IBM Corp. All rights reserved.
*/
-#include
-#include
+#include
#include
-#include
#include
#include
#include
#include
#include
@@ -76,152 +73,22 @@ void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes,
dst += todo;
} while (bytes);
}
EXPORT_SYMBOL(chacha_crypt_arch);
-static int chacha_p10_stream_xor(struct skcipher_request *req,
-const struct chacha_ctx *ctx, const u8 *iv)
-{
- struct skcipher_walk walk;
- u32 state[16];
- int err;
-
- err = skcipher_walk_virt(&walk, req, false);
- if (err)
- return err;
-
- chacha_init(state, ctx->key, iv);
-
- while (walk.nbytes > 0) {
- unsigned int nbytes = walk.nbytes;
-
- if (nbytes < walk.total)
- nbytes = rounddown(nbytes, walk.stride);
-
- if (!crypto_simd_usable()) {
- chacha_crypt_generic(state, walk.dst.virt.addr,
-walk.src.virt.addr, nbytes,
-ctx->nrounds);
- } else {
- vsx_begin();
- chacha_p10_do_8x(state, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes, ctx->nrounds);
- vsx_end();
- }
- err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
- if (err)
- break;
- }
-
- return err;
-}
-
-static int chacha_p10(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
-
- return chacha_p10_stream_xor(req, ctx, req->iv);
-}
-
-static int xchacha_p10(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- struct chacha_ctx subctx;
- u32 state[16];
- u8 real_iv[16];
-
- chacha_init(state, ctx->key, req->iv);
- hchacha_block_arch(state, subctx.key, ctx->nrounds);
- subctx.nrounds = ctx->nrounds;
-
- memcpy(&real_iv[0], req->iv + 24, 8);
- memcpy(&real_iv[8], req->iv + 16, 8);
- return chacha_p10_stream_xor(req, &subctx, real_iv);
-}
-
-static struct skcipher_alg algs[] = {
- {
- .base.cra_name = "chacha20",
- .base.cra_driver_name = "chacha20-p10",
- .base.cra_priority = 300,
- .base.cra_blocksize = 1,
- .base.cra_ctxsize = sizeof(struct chacha_ctx),
- .base.cra_module= THIS_MODULE,
-
- .min_keysize= CHACHA_KEY_SIZE,
- .max_keysize= CHACHA_KEY_SIZE,
- .ivsize = CHACHA_IV_SIZE,
- .chunksize = CHACHA_BLOCK_SIZE,
- .setke
[PATCH 7/9] crypto: s390/chacha - remove the skcipher algorithms
From: Eric Biggers
Since crypto/chacha.c now registers chacha20-$(ARCH), xchacha20-$(ARCH),
and xchacha12-$(ARCH) skcipher algorithms that use the architecture's
ChaCha and HChaCha library functions, individual architectures no longer
need to do the same. Therefore, remove the redundant skcipher
algorithms and leave just the library functions.
Signed-off-by: Eric Biggers
---
arch/s390/crypto/Kconfig | 7 ---
arch/s390/crypto/chacha-glue.c | 101 +
2 files changed, 13 insertions(+), 95 deletions(-)
diff --git a/arch/s390/crypto/Kconfig b/arch/s390/crypto/Kconfig
index 8c4db8b64fa21..055b08f259ab2 100644
--- a/arch/s390/crypto/Kconfig
+++ b/arch/s390/crypto/Kconfig
@@ -108,20 +108,13 @@ config CRYPTO_DES_S390
As of z196 the CTR mode is hardware accelerated.
config CRYPTO_CHACHA_S390
tristate
depends on S390
- select CRYPTO_SKCIPHER
select CRYPTO_LIB_CHACHA_GENERIC
select CRYPTO_ARCH_HAVE_LIB_CHACHA
default CRYPTO_LIB_CHACHA_INTERNAL
- help
- Length-preserving cipher: ChaCha20 stream cipher (RFC 7539)
-
- Architecture: s390
-
- It is available as of z13.
config CRYPTO_HMAC_S390
tristate "Keyed-hash message authentication code: HMAC"
depends on S390
select CRYPTO_HASH
diff --git a/arch/s390/crypto/chacha-glue.c b/arch/s390/crypto/chacha-glue.c
index 0c68191f2aa4c..b3ffaa5553855 100644
--- a/arch/s390/crypto/chacha-glue.c
+++ b/arch/s390/crypto/chacha-glue.c
@@ -1,69 +1,23 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * s390 ChaCha stream cipher.
+ * ChaCha stream cipher (s390 optimized)
*
* Copyright IBM Corp. 2021
*/
#define KMSG_COMPONENT "chacha_s390"
#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt
-#include
-#include
-#include
+#include
#include
#include
#include
#include
#include
#include "chacha-s390.h"
-static void chacha20_crypt_s390(u32 *state, u8 *dst, const u8 *src,
- unsigned int nbytes, const u32 *key,
- u32 *counter)
-{
- DECLARE_KERNEL_FPU_ONSTACK32(vxstate);
-
- kernel_fpu_begin(&vxstate, KERNEL_VXR);
- chacha20_vx(dst, src, nbytes, key, counter);
- kernel_fpu_end(&vxstate, KERNEL_VXR);
-
- *counter += round_up(nbytes, CHACHA_BLOCK_SIZE) / CHACHA_BLOCK_SIZE;
-}
-
-static int chacha20_s390(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- u32 state[CHACHA_STATE_WORDS] __aligned(16);
- struct skcipher_walk walk;
- unsigned int nbytes;
- int rc;
-
- rc = skcipher_walk_virt(&walk, req, false);
- chacha_init(state, ctx->key, req->iv);
-
- while (walk.nbytes > 0) {
- nbytes = walk.nbytes;
- if (nbytes < walk.total)
- nbytes = round_down(nbytes, walk.stride);
-
- if (nbytes <= CHACHA_BLOCK_SIZE) {
- chacha_crypt_generic(state, walk.dst.virt.addr,
-walk.src.virt.addr, nbytes,
-ctx->nrounds);
- } else {
- chacha20_crypt_s390(state, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes,
- &state[4], &state[12]);
- }
- rc = skcipher_walk_done(&walk, walk.nbytes - nbytes);
- }
- return rc;
-}
-
void hchacha_block_arch(const u32 *state, u32 *stream, int nrounds)
{
/* TODO: implement hchacha_block_arch() in assembly */
hchacha_block_generic(state, stream, nrounds);
}
@@ -74,57 +28,28 @@ void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src,
{
/* s390 chacha20 implementation has 20 rounds hard-coded,
* it cannot handle a block of data or less, but otherwise
* it can handle data of arbitrary size
*/
- if (bytes <= CHACHA_BLOCK_SIZE || nrounds != 20 || !cpu_has_vx())
+ if (bytes <= CHACHA_BLOCK_SIZE || nrounds != 20 || !cpu_has_vx()) {
chacha_crypt_generic(state, dst, src, bytes, nrounds);
- else
- chacha20_crypt_s390(state, dst, src, bytes,
- &state[4], &state[12]);
-}
-EXPORT_SYMBOL(chacha_crypt_arch);
+ } else {
+ DECLARE_KERNEL_FPU_ONSTACK32(vxstate);
-static struct skcipher_alg chacha_algs[] = {
- {
- .base.cra_name = "chacha20",
- .base.cra_driver_name = "chacha20-s390",
- .base.cra_priority = 900,
- .base.cra_blocksize = 1,
- .base.cra_ctxsize = sizeof(struct chacha_ctx),
- .base.cra_module= THIS_MODULE,
+ kernel_fpu_begin(&vxstate, KERNEL_VXR);
+ ch
Re: [PATCH 1/2] mm/ptdump: Split note_page() into level specific callbacks
On Mon, Mar 17, 2025 at 11:48:17AM +0530, Anshuman Khandual wrote:
Hi Anshuman,
...
> --- a/include/linux/ptdump.h
> +++ b/include/linux/ptdump.h
> @@ -11,9 +11,12 @@ struct ptdump_range {
> };
>
> struct ptdump_state {
> - /* level is 0:PGD to 4:PTE, or -1 if unknown */
> - void (*note_page)(struct ptdump_state *st, unsigned long addr,
> - int level, u64 val);
> + void (*note_page_pte)(struct ptdump_state *st, unsigned long addr,
> pte_t pte);
> + void (*note_page_pmd)(struct ptdump_state *st, unsigned long addr,
> pmd_t pmd);
> + void (*note_page_pud)(struct ptdump_state *st, unsigned long addr,
> pud_t pud);
> + void (*note_page_p4d)(struct ptdump_state *st, unsigned long addr,
> p4d_t p4d);
> + void (*note_page_pgd)(struct ptdump_state *st, unsigned long addr,
> pgd_t pgd);
> + void (*note_page_flush)(struct ptdump_state *st);
> void (*effective_prot)(struct ptdump_state *st, int level, u64 val);
Should you treat effective_prot() similarly?
> const struct ptdump_range *range;
> };
Re: [PATCH v4 10/14] s390: Add support for suppressing warning backtraces
On Fri, Mar 21, 2025 at 10:05:42PM +0100, Alessandro Carminati wrote: > > > +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE > > > +# define HAVE_BUG_FUNCTION > > > +# define __BUG_FUNC_PTR " .long %0-.\n" > > > +# define __BUG_FUNC __func__ > > > > gcc 7.5.0 on s390 barfs; it doesn't like the use of "__func__" with "%0-." ... > GCC makes significant efforts to handle this, and for several > architectures, it manages to solve the problem. > However, this is not universally the case. > Additionally, -fPIC is not widely used in kernel code... I have only > seen it used for VDSO, the x86 boot piggyback decompressor, PowerPC > boot, and the s390x architecture. > > That said, GCC has been mitigating this issue, allowing us to treat a > non-compile-time constant as if it were one. > A proof of this is that, at least since GCC 11, the s390x version of > GCC is able to build this code. > Before that... certainly in GCC 7.5 it couldn't. > > A simple fix would be to restrict usage to GCC versions greater than > 11 for s390. But please add that dependency only for this new feature for the time being. Right now I would not like to see that s390 is the only architecture (besides parisc) which requires a much higher minimum gcc level than every other architecture. Unless there are specific reasons.
[PATCH 5/9] crypto: mips/chacha - remove the skcipher algorithms
From: Eric Biggers
Since crypto/chacha.c now registers chacha20-$(ARCH), xchacha20-$(ARCH),
and xchacha12-$(ARCH) skcipher algorithms that use the architecture's
ChaCha and HChaCha library functions, individual architectures no longer
need to do the same. Therefore, remove the redundant skcipher
algorithms and leave just the library functions.
Signed-off-by: Eric Biggers
---
arch/mips/crypto/Kconfig | 6 --
arch/mips/crypto/chacha-glue.c | 131 +
2 files changed, 3 insertions(+), 134 deletions(-)
diff --git a/arch/mips/crypto/Kconfig b/arch/mips/crypto/Kconfig
index 545fc0e12422d..0189686de3a12 100644
--- a/arch/mips/crypto/Kconfig
+++ b/arch/mips/crypto/Kconfig
@@ -54,15 +54,9 @@ config CRYPTO_SHA512_OCTEON
Architecture: mips OCTEON using crypto instructions, when available
config CRYPTO_CHACHA_MIPS
tristate
depends on CPU_MIPS32_R2
- select CRYPTO_SKCIPHER
select CRYPTO_ARCH_HAVE_LIB_CHACHA
default CRYPTO_LIB_CHACHA_INTERNAL
- help
- Length-preserving ciphers: ChaCha20, XChaCha20, and XChaCha12
- stream cipher algorithms
-
- Architecture: MIPS32r2
endmenu
diff --git a/arch/mips/crypto/chacha-glue.c b/arch/mips/crypto/chacha-glue.c
index 64ccaeaeaa1e1..334ecb29fb8fa 100644
--- a/arch/mips/crypto/chacha-glue.c
+++ b/arch/mips/crypto/chacha-glue.c
@@ -1,152 +1,27 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * MIPS accelerated ChaCha and XChaCha stream ciphers,
- * including ChaCha20 (RFC7539)
+ * ChaCha and HChaCha functions (MIPS optimized)
*
* Copyright (C) 2019 Linaro, Ltd.
*/
-#include
-#include
-#include
-#include
+#include
#include
#include
asmlinkage void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes, int nrounds);
EXPORT_SYMBOL(chacha_crypt_arch);
asmlinkage void hchacha_block_arch(const u32 *state, u32 *stream, int nrounds);
EXPORT_SYMBOL(hchacha_block_arch);
-static int chacha_mips_stream_xor(struct skcipher_request *req,
- const struct chacha_ctx *ctx, const u8 *iv)
-{
- struct skcipher_walk walk;
- u32 state[16];
- int err;
-
- err = skcipher_walk_virt(&walk, req, false);
-
- chacha_init(state, ctx->key, iv);
-
- while (walk.nbytes > 0) {
- unsigned int nbytes = walk.nbytes;
-
- if (nbytes < walk.total)
- nbytes = round_down(nbytes, walk.stride);
-
- chacha_crypt(state, walk.dst.virt.addr, walk.src.virt.addr,
-nbytes, ctx->nrounds);
- err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
- }
-
- return err;
-}
-
-static int chacha_mips(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
-
- return chacha_mips_stream_xor(req, ctx, req->iv);
-}
-
-static int xchacha_mips(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- struct chacha_ctx subctx;
- u32 state[16];
- u8 real_iv[16];
-
- chacha_init(state, ctx->key, req->iv);
-
- hchacha_block(state, subctx.key, ctx->nrounds);
- subctx.nrounds = ctx->nrounds;
-
- memcpy(&real_iv[0], req->iv + 24, 8);
- memcpy(&real_iv[8], req->iv + 16, 8);
- return chacha_mips_stream_xor(req, &subctx, real_iv);
-}
-
-static struct skcipher_alg algs[] = {
- {
- .base.cra_name = "chacha20",
- .base.cra_driver_name = "chacha20-mips",
- .base.cra_priority = 200,
- .base.cra_blocksize = 1,
- .base.cra_ctxsize = sizeof(struct chacha_ctx),
- .base.cra_module= THIS_MODULE,
-
- .min_keysize= CHACHA_KEY_SIZE,
- .max_keysize= CHACHA_KEY_SIZE,
- .ivsize = CHACHA_IV_SIZE,
- .chunksize = CHACHA_BLOCK_SIZE,
- .setkey = chacha20_setkey,
- .encrypt= chacha_mips,
- .decrypt= chacha_mips,
- }, {
- .base.cra_name = "xchacha20",
- .base.cra_driver_name = "xchacha20-mips",
- .base.cra_priority = 200,
- .base.cra_blocksize = 1,
- .base.cra_ctxsize = sizeof(struct chacha_ctx),
- .base.cra_module= THIS_MODULE,
-
- .min_keysize= CHACHA_KEY_SIZE,
- .max_keysize= CHACHA_KEY_SIZE,
- .ivsize = XCHACHA_IV_SIZE,
- .chunksize = CHACHA_BLOCK_SIZE,
- .setkey
[PATCH 1/9] crypto: riscv/chacha - implement library instead of skcipher
From: Eric Biggers
Currently the RISC-V optimized ChaCha20 is only wired up to the
crypto_skcipher API, which makes it unavailable to users of the library
API. The crypto_skcipher API for ChaCha20 is going to change to be
implemented on top of the library API, so the library API needs to be
supported. And of course it's needed anyway to serve the library users.
Therefore, change the RISC-V ChaCha20 code to implement the library API
instead of the crypto_skcipher API.
The library functions take the ChaCha state matrix directly (instead of
key and IV) and support both ChaCha20 and ChaCha12. To make the RISC-V
code work properly for that, change the assembly code to take the state
matrix directly and add a nrounds parameter.
Signed-off-by: Eric Biggers
---
arch/riscv/crypto/Kconfig | 11 +--
arch/riscv/crypto/chacha-riscv64-glue.c | 106
arch/riscv/crypto/chacha-riscv64-zvkb.S | 71
3 files changed, 75 insertions(+), 113 deletions(-)
diff --git a/arch/riscv/crypto/Kconfig b/arch/riscv/crypto/Kconfig
index c67095a3d6690..6392e1e11bc96 100644
--- a/arch/riscv/crypto/Kconfig
+++ b/arch/riscv/crypto/Kconfig
@@ -17,18 +17,15 @@ config CRYPTO_AES_RISCV64
- Zvbb vector extension (XTS)
- Zvkb vector crypto extension (CTR)
- Zvkg vector crypto extension (XTS)
config CRYPTO_CHACHA_RISCV64
- tristate "Ciphers: ChaCha"
+ tristate
depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO
- select CRYPTO_SKCIPHER
- help
- Length-preserving ciphers: ChaCha20 stream cipher algorithm
-
- Architecture: riscv64 using:
- - Zvkb vector crypto extension
+ select CRYPTO_ARCH_HAVE_LIB_CHACHA
+ select CRYPTO_LIB_CHACHA_GENERIC
+ default CRYPTO_LIB_CHACHA_INTERNAL
config CRYPTO_GHASH_RISCV64
tristate "Hash functions: GHASH"
depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO
select CRYPTO_GCM
diff --git a/arch/riscv/crypto/chacha-riscv64-glue.c
b/arch/riscv/crypto/chacha-riscv64-glue.c
index 10b46f36375af..68caef7a3d50b 100644
--- a/arch/riscv/crypto/chacha-riscv64-glue.c
+++ b/arch/riscv/crypto/chacha-riscv64-glue.c
@@ -1,101 +1,63 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * ChaCha20 using the RISC-V vector crypto extensions
+ * ChaCha stream cipher (RISC-V optimized)
*
* Copyright (C) 2023 SiFive, Inc.
* Author: Jerry Shih
*/
#include
#include
-#include
-#include
+#include
+#include
#include
#include
-asmlinkage void chacha20_zvkb(const u32 key[8], const u8 *in, u8 *out,
- size_t len, const u32 iv[4]);
+static __ro_after_init DEFINE_STATIC_KEY_FALSE(use_zvkb);
-static int riscv64_chacha20_crypt(struct skcipher_request *req)
+asmlinkage void chacha_zvkb(u32 state[16], const u8 *in, u8 *out,
+ size_t nblocks, int nrounds);
+
+void hchacha_block_arch(const u32 *state, u32 *out, int nrounds)
{
- u32 iv[CHACHA_IV_SIZE / sizeof(u32)];
- u8 block_buffer[CHACHA_BLOCK_SIZE];
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- const struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- struct skcipher_walk walk;
- unsigned int nbytes;
- unsigned int tail_bytes;
- int err;
+ hchacha_block_generic(state, out, nrounds);
+}
+EXPORT_SYMBOL(hchacha_block_arch);
- iv[0] = get_unaligned_le32(req->iv);
- iv[1] = get_unaligned_le32(req->iv + 4);
- iv[2] = get_unaligned_le32(req->iv + 8);
- iv[3] = get_unaligned_le32(req->iv + 12);
+void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src, unsigned int bytes,
+ int nrounds)
+{
+ u8 block_buffer[CHACHA_BLOCK_SIZE];
+ unsigned int full_blocks = bytes / CHACHA_BLOCK_SIZE;
+ unsigned int tail_bytes = bytes % CHACHA_BLOCK_SIZE;
- err = skcipher_walk_virt(&walk, req, false);
- while (walk.nbytes) {
- nbytes = walk.nbytes & ~(CHACHA_BLOCK_SIZE - 1);
- tail_bytes = walk.nbytes & (CHACHA_BLOCK_SIZE - 1);
- kernel_vector_begin();
- if (nbytes) {
- chacha20_zvkb(ctx->key, walk.src.virt.addr,
- walk.dst.virt.addr, nbytes, iv);
- iv[0] += nbytes / CHACHA_BLOCK_SIZE;
- }
- if (walk.nbytes == walk.total && tail_bytes > 0) {
- memcpy(block_buffer, walk.src.virt.addr + nbytes,
- tail_bytes);
- chacha20_zvkb(ctx->key, block_buffer, block_buffer,
- CHACHA_BLOCK_SIZE, iv);
- memcpy(walk.dst.virt.addr + nbytes, block_buffer,
- tail_bytes);
- tail_bytes = 0;
- }
- kernel_vector_end();
+ if (!static_branch_
[PATCH 2/9] crypto: chacha - centralize the skcipher wrappers for arch code
From: Eric Biggers
Following the example of the crc32 and crc32c code, make the crypto
subsystem register both generic and architecture-optimized chacha20,
xchacha20, and xchacha12 skcipher algorithms, all implemented on top of
the appropriate library functions. This eliminates the need for every
architecture to implement the same skcipher glue code.
To register the architecture-optimized skciphers only when
architecture-optimized code is actually being used, add a function
chacha_is_arch_optimized() and make each arch implement it. Change each
architecture's ChaCha module_init function to arch_initcall so that the
CPU feature detection is guaranteed to run before
chacha_is_arch_optimized() gets called by crypto/chacha.c. In the case
of s390, remove the CPU feature based module autoloading, which is no
longer needed since the module just gets pulled in via function linkage.
Signed-off-by: Eric Biggers
---
arch/arm/crypto/chacha-glue.c | 9 +-
arch/arm64/crypto/chacha-neon-glue.c| 8 +-
arch/mips/crypto/chacha-glue.c | 8 +-
arch/powerpc/crypto/chacha-p10-glue.c | 8 +-
arch/riscv/crypto/chacha-riscv64-glue.c | 8 +-
arch/s390/crypto/chacha-glue.c | 8 +-
arch/x86/crypto/chacha_glue.c | 8 +-
crypto/Makefile | 3 +-
crypto/chacha.c | 227
crypto/chacha_generic.c | 139 ---
include/crypto/chacha.h | 9 +
11 files changed, 288 insertions(+), 147 deletions(-)
create mode 100644 crypto/chacha.c
delete mode 100644 crypto/chacha_generic.c
diff --git a/arch/arm/crypto/chacha-glue.c b/arch/arm/crypto/chacha-glue.c
index 50e635512046e..e1cb34d317712 100644
--- a/arch/arm/crypto/chacha-glue.c
+++ b/arch/arm/crypto/chacha-glue.c
@@ -285,10 +285,17 @@ static struct skcipher_alg neon_algs[] = {
.encrypt= xchacha_neon,
.decrypt= xchacha_neon,
}
};
+bool chacha_is_arch_optimized(void)
+{
+ /* We always can use at least the ARM scalar implementation. */
+ return true;
+}
+EXPORT_SYMBOL(chacha_is_arch_optimized);
+
static int __init chacha_simd_mod_init(void)
{
int err = 0;
if (IS_REACHABLE(CONFIG_CRYPTO_SKCIPHER)) {
@@ -331,11 +338,11 @@ static void __exit chacha_simd_mod_fini(void)
if (IS_ENABLED(CONFIG_KERNEL_MODE_NEON) && (elf_hwcap &
HWCAP_NEON))
crypto_unregister_skciphers(neon_algs,
ARRAY_SIZE(neon_algs));
}
}
-module_init(chacha_simd_mod_init);
+arch_initcall(chacha_simd_mod_init);
module_exit(chacha_simd_mod_fini);
MODULE_DESCRIPTION("ChaCha and XChaCha stream ciphers (scalar and NEON
accelerated)");
MODULE_AUTHOR("Ard Biesheuvel ");
MODULE_LICENSE("GPL v2");
diff --git a/arch/arm64/crypto/chacha-neon-glue.c
b/arch/arm64/crypto/chacha-neon-glue.c
index 229876acfc581..bb9b52321bda7 100644
--- a/arch/arm64/crypto/chacha-neon-glue.c
+++ b/arch/arm64/crypto/chacha-neon-glue.c
@@ -204,10 +204,16 @@ static struct skcipher_alg algs[] = {
.encrypt= xchacha_neon,
.decrypt= xchacha_neon,
}
};
+bool chacha_is_arch_optimized(void)
+{
+ return static_key_enabled(&have_neon);
+}
+EXPORT_SYMBOL(chacha_is_arch_optimized);
+
static int __init chacha_simd_mod_init(void)
{
if (!cpu_have_named_feature(ASIMD))
return 0;
@@ -221,11 +227,11 @@ static void __exit chacha_simd_mod_fini(void)
{
if (IS_REACHABLE(CONFIG_CRYPTO_SKCIPHER) &&
cpu_have_named_feature(ASIMD))
crypto_unregister_skciphers(algs, ARRAY_SIZE(algs));
}
-module_init(chacha_simd_mod_init);
+arch_initcall(chacha_simd_mod_init);
module_exit(chacha_simd_mod_fini);
MODULE_DESCRIPTION("ChaCha and XChaCha stream ciphers (NEON accelerated)");
MODULE_AUTHOR("Ard Biesheuvel ");
MODULE_LICENSE("GPL v2");
diff --git a/arch/mips/crypto/chacha-glue.c b/arch/mips/crypto/chacha-glue.c
index f6fc2e1079a19..64ccaeaeaa1e1 100644
--- a/arch/mips/crypto/chacha-glue.c
+++ b/arch/mips/crypto/chacha-glue.c
@@ -118,10 +118,16 @@ static struct skcipher_alg algs[] = {
.encrypt= xchacha_mips,
.decrypt= xchacha_mips,
}
};
+bool chacha_is_arch_optimized(void)
+{
+ return true;
+}
+EXPORT_SYMBOL(chacha_is_arch_optimized);
+
static int __init chacha_simd_mod_init(void)
{
return IS_REACHABLE(CONFIG_CRYPTO_SKCIPHER) ?
crypto_register_skciphers(algs, ARRAY_SIZE(algs)) : 0;
}
@@ -130,11 +136,11 @@ static void __exit chacha_simd_mod_fini(void)
{
if (IS_REACHABLE(CONFIG_CRYPTO_SKCIPHER))
crypto_unregister_skciphers(algs, ARRAY_SIZE(algs));
}
-module_init(chacha_simd_mod_init);
+arch_initcall(chacha_simd_mod_init);
module_exit(chacha_simd_mod_fini);
MODULE_DESCRIPTION("ChaCha and
[PATCH 9/9] crypto: chacha - remove
From: Eric Biggers
is now included only by crypto/chacha.c, so
fold it into there.
Signed-off-by: Eric Biggers
---
crypto/chacha.c | 35 +-
include/crypto/internal/chacha.h | 43
2 files changed, 34 insertions(+), 44 deletions(-)
delete mode 100644 include/crypto/internal/chacha.h
diff --git a/crypto/chacha.c b/crypto/chacha.c
index 2009038c5e56c..5103bc0b2881f 100644
--- a/crypto/chacha.c
+++ b/crypto/chacha.c
@@ -6,14 +6,47 @@
* Copyright (C) 2018 Google LLC
*/
#include
#include
-#include
+#include
#include
#include
+struct chacha_ctx {
+ u32 key[8];
+ int nrounds;
+};
+
+static int chacha_setkey(struct crypto_skcipher *tfm,
+const u8 *key, unsigned int keysize, int nrounds)
+{
+ struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
+ int i;
+
+ if (keysize != CHACHA_KEY_SIZE)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(ctx->key); i++)
+ ctx->key[i] = get_unaligned_le32(key + i * sizeof(u32));
+
+ ctx->nrounds = nrounds;
+ return 0;
+}
+
+static int chacha20_setkey(struct crypto_skcipher *tfm,
+ const u8 *key, unsigned int keysize)
+{
+ return chacha_setkey(tfm, key, keysize, 20);
+}
+
+static int chacha12_setkey(struct crypto_skcipher *tfm,
+ const u8 *key, unsigned int keysize)
+{
+ return chacha_setkey(tfm, key, keysize, 12);
+}
+
static int chacha_stream_xor(struct skcipher_request *req,
const struct chacha_ctx *ctx, const u8 *iv,
bool arch)
{
struct skcipher_walk walk;
diff --git a/include/crypto/internal/chacha.h b/include/crypto/internal/chacha.h
deleted file mode 100644
index b085dc1ac1516..0
--- a/include/crypto/internal/chacha.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-
-#ifndef _CRYPTO_INTERNAL_CHACHA_H
-#define _CRYPTO_INTERNAL_CHACHA_H
-
-#include
-#include
-#include
-
-struct chacha_ctx {
- u32 key[8];
- int nrounds;
-};
-
-static inline int chacha_setkey(struct crypto_skcipher *tfm, const u8 *key,
- unsigned int keysize, int nrounds)
-{
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- int i;
-
- if (keysize != CHACHA_KEY_SIZE)
- return -EINVAL;
-
- for (i = 0; i < ARRAY_SIZE(ctx->key); i++)
- ctx->key[i] = get_unaligned_le32(key + i * sizeof(u32));
-
- ctx->nrounds = nrounds;
- return 0;
-}
-
-static inline int chacha20_setkey(struct crypto_skcipher *tfm, const u8 *key,
- unsigned int keysize)
-{
- return chacha_setkey(tfm, key, keysize, 20);
-}
-
-static inline int chacha12_setkey(struct crypto_skcipher *tfm, const u8 *key,
- unsigned int keysize)
-{
- return chacha_setkey(tfm, key, keysize, 12);
-}
-
-#endif /* _CRYPTO_CHACHA_H */
--
2.49.0
[PATCH 8/9] crypto: x86/chacha - remove the skcipher algorithms
From: Eric Biggers
Since crypto/chacha.c now registers chacha20-$(ARCH), xchacha20-$(ARCH),
and xchacha12-$(ARCH) skcipher algorithms that use the architecture's
ChaCha and HChaCha library functions, individual architectures no longer
need to do the same. Therefore, remove the redundant skcipher
algorithms and leave just the library functions.
Signed-off-by: Eric Biggers
---
arch/x86/crypto/Kconfig | 9 ---
arch/x86/crypto/chacha_glue.c | 142 +-
2 files changed, 4 insertions(+), 147 deletions(-)
diff --git a/arch/x86/crypto/Kconfig b/arch/x86/crypto/Kconfig
index 3d948f10c94cd..8cf0a3f55576e 100644
--- a/arch/x86/crypto/Kconfig
+++ b/arch/x86/crypto/Kconfig
@@ -350,22 +350,13 @@ config CRYPTO_ARIA_GFNI_AVX512_X86_64
Processes 64 blocks in parallel.
config CRYPTO_CHACHA20_X86_64
tristate
depends on X86 && 64BIT
- select CRYPTO_SKCIPHER
select CRYPTO_LIB_CHACHA_GENERIC
select CRYPTO_ARCH_HAVE_LIB_CHACHA
default CRYPTO_LIB_CHACHA_INTERNAL
- help
- Length-preserving ciphers: ChaCha20, XChaCha20, and XChaCha12
- stream cipher algorithms
-
- Architecture: x86_64 using:
- - SSSE3 (Supplemental SSE3)
- - AVX2 (Advanced Vector Extensions 2)
- - AVX-512VL (Advanced Vector Extensions-512VL)
config CRYPTO_AEGIS128_AESNI_SSE2
tristate "AEAD ciphers: AEGIS-128 (AES-NI/SSE4.1)"
depends on X86 && 64BIT
select CRYPTO_AEAD
diff --git a/arch/x86/crypto/chacha_glue.c b/arch/x86/crypto/chacha_glue.c
index 83a07b31cdd3a..71ec959caadaa 100644
--- a/arch/x86/crypto/chacha_glue.c
+++ b/arch/x86/crypto/chacha_glue.c
@@ -1,17 +1,14 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * x64 SIMD accelerated ChaCha and XChaCha stream ciphers,
- * including ChaCha20 (RFC7539)
+ * ChaCha and HChaCha functions (x86_64 optimized)
*
* Copyright (C) 2015 Martin Willi
*/
-#include
-#include
+#include
#include
-#include
#include
#include
#include
#include
@@ -152,126 +149,10 @@ void chacha_crypt_arch(u32 *state, u8 *dst, const u8
*src, unsigned int bytes,
dst += todo;
} while (bytes);
}
EXPORT_SYMBOL(chacha_crypt_arch);
-static int chacha_simd_stream_xor(struct skcipher_request *req,
- const struct chacha_ctx *ctx, const u8 *iv)
-{
- u32 state[CHACHA_STATE_WORDS] __aligned(8);
- struct skcipher_walk walk;
- int err;
-
- err = skcipher_walk_virt(&walk, req, false);
-
- chacha_init(state, ctx->key, iv);
-
- while (walk.nbytes > 0) {
- unsigned int nbytes = walk.nbytes;
-
- if (nbytes < walk.total)
- nbytes = round_down(nbytes, walk.stride);
-
- if (!static_branch_likely(&chacha_use_simd) ||
- !crypto_simd_usable()) {
- chacha_crypt_generic(state, walk.dst.virt.addr,
-walk.src.virt.addr, nbytes,
-ctx->nrounds);
- } else {
- kernel_fpu_begin();
- chacha_dosimd(state, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes,
- ctx->nrounds);
- kernel_fpu_end();
- }
- err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
- }
-
- return err;
-}
-
-static int chacha_simd(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
-
- return chacha_simd_stream_xor(req, ctx, req->iv);
-}
-
-static int xchacha_simd(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- u32 state[CHACHA_STATE_WORDS] __aligned(8);
- struct chacha_ctx subctx;
- u8 real_iv[16];
-
- chacha_init(state, ctx->key, req->iv);
-
- if (req->cryptlen > CHACHA_BLOCK_SIZE && crypto_simd_usable()) {
- kernel_fpu_begin();
- hchacha_block_ssse3(state, subctx.key, ctx->nrounds);
- kernel_fpu_end();
- } else {
- hchacha_block_generic(state, subctx.key, ctx->nrounds);
- }
- subctx.nrounds = ctx->nrounds;
-
- memcpy(&real_iv[0], req->iv + 24, 8);
- memcpy(&real_iv[8], req->iv + 16, 8);
- return chacha_simd_stream_xor(req, &subctx, real_iv);
-}
-
-static struct skcipher_alg algs[] = {
- {
- .base.cra_name = "chacha20",
- .base.cra_driver_name = "chacha20-simd",
- .base.cra_priority = 300,
- .base.cra_blocksize = 1,
- .base.cra_ctxsize = sizeof(struct chacha_ctx),
- .base.cra_mo
[PATCH 4/9] crypto: arm64/chacha - remove the skcipher algorithms
From: Eric Biggers
Since crypto/chacha.c now registers chacha20-$(ARCH), xchacha20-$(ARCH),
and xchacha12-$(ARCH) skcipher algorithms that use the architecture's
ChaCha and HChaCha library functions, individual architectures no longer
need to do the same. Therefore, remove the redundant skcipher
algorithms and leave just the library functions.
Signed-off-by: Eric Biggers
---
arch/arm64/crypto/Kconfig| 7 --
arch/arm64/crypto/chacha-neon-core.S | 2 +-
arch/arm64/crypto/chacha-neon-glue.c | 144 ++-
3 files changed, 7 insertions(+), 146 deletions(-)
diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 3418c8d3c78d4..ce655da0fbeea 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -187,20 +187,13 @@ config CRYPTO_AES_ARM64_NEON_BLK
- NEON (Advanced SIMD) extensions
config CRYPTO_CHACHA20_NEON
tristate
depends on KERNEL_MODE_NEON
- select CRYPTO_SKCIPHER
select CRYPTO_LIB_CHACHA_GENERIC
select CRYPTO_ARCH_HAVE_LIB_CHACHA
default CRYPTO_LIB_CHACHA_INTERNAL
- help
- Length-preserving ciphers: ChaCha20, XChaCha20, and XChaCha12
- stream cipher algorithms
-
- Architecture: arm64 using:
- - NEON (Advanced SIMD) extensions
config CRYPTO_AES_ARM64_BS
tristate "Ciphers: AES, modes: ECB/CBC/CTR/XCTR/XTS modes (bit-sliced
NEON)"
depends on KERNEL_MODE_NEON
select CRYPTO_SKCIPHER
diff --git a/arch/arm64/crypto/chacha-neon-core.S
b/arch/arm64/crypto/chacha-neon-core.S
index b70ac76f2610c..80079586ecc7a 100644
--- a/arch/arm64/crypto/chacha-neon-core.S
+++ b/arch/arm64/crypto/chacha-neon-core.S
@@ -1,7 +1,7 @@
/*
- * ChaCha/XChaCha NEON helper functions
+ * ChaCha/HChaCha NEON helper functions
*
* Copyright (C) 2016-2018 Linaro, Ltd.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
diff --git a/arch/arm64/crypto/chacha-neon-glue.c
b/arch/arm64/crypto/chacha-neon-glue.c
index bb9b52321bda7..a0c336b284027 100644
--- a/arch/arm64/crypto/chacha-neon-glue.c
+++ b/arch/arm64/crypto/chacha-neon-glue.c
@@ -1,8 +1,7 @@
/*
- * ARM NEON and scalar accelerated ChaCha and XChaCha stream ciphers,
- * including ChaCha20 (RFC7539)
+ * ChaCha and HChaCha functions (ARM64 optimized)
*
* Copyright (C) 2016 - 2017 Linaro, Ltd.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -17,14 +16,12 @@
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
-#include
-#include
+#include
#include
-#include
#include
#include
#include
#include
@@ -93,151 +90,22 @@ void chacha_crypt_arch(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes,
dst += todo;
} while (bytes);
}
EXPORT_SYMBOL(chacha_crypt_arch);
-static int chacha_neon_stream_xor(struct skcipher_request *req,
- const struct chacha_ctx *ctx, const u8 *iv)
-{
- struct skcipher_walk walk;
- u32 state[16];
- int err;
-
- err = skcipher_walk_virt(&walk, req, false);
-
- chacha_init(state, ctx->key, iv);
-
- while (walk.nbytes > 0) {
- unsigned int nbytes = walk.nbytes;
-
- if (nbytes < walk.total)
- nbytes = rounddown(nbytes, walk.stride);
-
- if (!static_branch_likely(&have_neon) ||
- !crypto_simd_usable()) {
- chacha_crypt_generic(state, walk.dst.virt.addr,
-walk.src.virt.addr, nbytes,
-ctx->nrounds);
- } else {
- kernel_neon_begin();
- chacha_doneon(state, walk.dst.virt.addr,
- walk.src.virt.addr, nbytes, ctx->nrounds);
- kernel_neon_end();
- }
- err = skcipher_walk_done(&walk, walk.nbytes - nbytes);
- }
-
- return err;
-}
-
-static int chacha_neon(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
-
- return chacha_neon_stream_xor(req, ctx, req->iv);
-}
-
-static int xchacha_neon(struct skcipher_request *req)
-{
- struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
- struct chacha_ctx *ctx = crypto_skcipher_ctx(tfm);
- struct chacha_ctx subctx;
- u32 state[16];
- u8 real_iv[16];
-
- chacha_init(state, ctx->key, req->iv);
- hchacha_block_arch(state, subctx.key, ctx->nrounds);
- subctx.nrounds = ctx->nrounds;
-
- memcpy(&r
