[PATCH] powerpc/ptdump: Fix walk_vmemmap to also print first vmemmap entry
walk_vmemmap() was skipping the first vmemmap entry pointed by
vmemmap_list pointer itself. This patch fixes that.
With this we should see the vmemmap entry at 0xc00c for hash
which wasn't getting printed on doing
"cat /sys/kernel/debug/kernel_hash_pagetable"
Signed-off-by: Ritesh Harjani (IBM)
---
arch/powerpc/mm/ptdump/hashpagetable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c
b/arch/powerpc/mm/ptdump/hashpagetable.c
index 9a601587836b..a6baa6166d94 100644
--- a/arch/powerpc/mm/ptdump/hashpagetable.c
+++ b/arch/powerpc/mm/ptdump/hashpagetable.c
@@ -491,7 +491,7 @@ static void walk_vmemmap(struct pg_state *st)
* Traverse the vmemmaped memory and dump pages that are in the hash
* pagetable.
*/
- while (ptr->list) {
+ while (ptr) {
hpte_find(st, ptr->virt_addr, mmu_vmemmap_psize);
ptr = ptr->list;
}
--
2.44.0
Re: [PATCH 2/4] fs: define a firmware security filesystem named fwsecurityfs
Hello Nayna,
On 22/11/09 03:10PM, Nayna wrote:
>
> On 11/9/22 08:46, Greg Kroah-Hartman wrote:
> > On Sun, Nov 06, 2022 at 04:07:42PM -0500, Nayna Jain wrote:
> > > securityfs is meant for Linux security subsystems to expose policies/logs
> > > or any other information. However, there are various firmware security
> > > features which expose their variables for user management via the kernel.
> > > There is currently no single place to expose these variables. Different
> > > platforms use sysfs/platform specific filesystem(efivarfs)/securityfs
> > > interface as they find it appropriate. Thus, there is a gap in kernel
> > > interfaces to expose variables for security features.
> > >
> > > Define a firmware security filesystem (fwsecurityfs) to be used by
> > > security features enabled by the firmware. These variables are platform
> > > specific. This filesystem provides platforms a way to implement their
> > > own underlying semantics by defining own inode and file operations.
> > >
> > > Similar to securityfs, the firmware security filesystem is recommended
> > > to be exposed on a well known mount point /sys/firmware/security.
> > > Platforms can define their own directory or file structure under this
> > > path.
> > >
> > > Example:
> > >
> > > # mount -t fwsecurityfs fwsecurityfs /sys/firmware/security
> > Why not juset use securityfs in /sys/security/firmware/ instead? Then
> > you don't have to create a new filesystem and convince userspace to
> > mount it in a specific location?
I am also curious to know on why not use securityfs, given the similarity
between the two. :)
More specifics on that below...
>
> From man 5 sysfs page:
>
> /sys/firmware: This subdirectory contains interfaces for viewing and
> manipulating firmware-specific objects and attributes.
>
> /sys/kernel: This subdirectory contains various files and subdirectories
> that provide information about the running kernel.
>
> The security variables which are being exposed via fwsecurityfs are managed
> by firmware, stored in firmware managed space and also often consumed by
> firmware for enabling various security features.
That's ok. As I see it users of securityfs can define their own fileops
(like how you are doing in fwsecurityfs).
See securityfs_create_file() & securityfs_create_symlink(), can accept the fops
& iops. Except maybe securityfs_create_dir(), that could be since there might
not be a usecase for it. But do you also need it in your case is the question to
ask.
>
> From git commit b67dbf9d4c1987c370fd18fdc4cf9d8aaea604c2, the purpose of
> securityfs(/sys/kernel/security) is to provide a common place for all kernel
> LSMs. The idea of
Which was then seperated out by commit,
da31894ed7b654e2 ("securityfs: do not depend on CONFIG_SECURITY").
securityfs now has a seperate CONFIG_SECURITYFS config option. In fact I was
even
thinking of why shouldn't we move security/inode.c into fs/securityfs/inode.c .
fs/* is a common place for all filesystems. Users of securityfs can call it's
exported kernel APIs to create files/dirs/symlinks.
If we move security/inode.c to fs/security/inode.c, then...
...below call within securityfs_init() should be moved into some lsm sepecific
file.
#ifdef CONFIG_SECURITY
static struct dentry *lsm_dentry;
static ssize_t lsm_read(struct file *filp, char __user *buf, size_t count,
loff_t *ppos)
{
return simple_read_from_buffer(buf, count, ppos, lsm_names,
strlen(lsm_names));
}
static const struct file_operations lsm_ops = {
.read = lsm_read,
.llseek = generic_file_llseek,
};
#endif
securityfs_init()
#ifdef CONFIG_SECURITY
lsm_dentry = securityfs_create_file("lsm", 0444, NULL, NULL,
_ops);
#endif
So why not move it? Maybe others, can comment more on whether it's a good idea
to move security/inode.c into fs/security/inode.c?
This should then help others identify securityfs filesystem in fs/security/
for everyone to notice and utilize for their use?
> fwsecurityfs(/sys/firmware/security) is to similarly provide a common place
> for all firmware security objects.
>
> /sys/firmware already exists. The patch now defines a new /security
> directory in it for firmware security features. Using /sys/kernel/security
> would mean scattering firmware objects in multiple places and confusing the
> purpose of /sys/kernel and /sys/firmware.
We can also think of it this way that, all security related exports should
happen via /sys/kernel/security/. Then /sys/kernel/security/firmware/ becomes
the security related firmware exports.
If you see find /sys -iname firmware, I am sure you will find other firmware
specifics directories related to other specific subsystems
(e.g.
root@qemu:/home/qemu# find /sys -iname firmware
/sys/devices/ndbus0/nmem0/firmware
/sys/devices/ndbus0/firmware
/sys/firmware
)
But it could be, I am not an expert here, although I was thinking a
Re: [PATCH v2 1/4] Make place for common balloon code
On 22/08/16 12:41PM, Alexander Atanasov wrote:
> File already contains code that is common along balloon
> drivers so rename it to reflect its contents.
> mm/balloon_compaction.c -> mm/balloon_common.c
>
> Signed-off-by: Alexander Atanasov
> ---
> MAINTAINERS | 4 ++--
> arch/powerpc/platforms/pseries/cmm.c | 2 +-
> drivers/misc/vmw_balloon.c | 2 +-
> drivers/virtio/virtio_balloon.c | 2 +-
> include/linux/{balloon_compaction.h => balloon_common.h} | 2 +-
> mm/Makefile | 2 +-
> mm/{balloon_compaction.c => balloon_common.c}| 4 ++--
> mm/migrate.c | 2 +-
> mm/vmscan.c | 2 +-
I think we don't need balloon headers in above two files at all.
I don't see any references of balloon functions in them.
I guess this commit removed it -
commit b1123ea6d3b3da25af5c8a9d843bd07ab63213f4
Author: Minchan Kim
Date: Tue Jul 26 15:23:09 2016 -0700
mm: balloon: use general non-lru movable page feature
Now, VM has a feature to migrate non-lru movable pages so balloon
doesn't need custom migration hooks in migrate.c and compaction.c.
Instead, this patch implements the page->mapping->a_ops->
{isolate|migrate|putback} functions.
With that, we could remove hooks for ballooning in general migration
functions and make balloon compaction simple.
Since I don't often look into this side of code, it's better to confirm :)
-ritesh
Re: [PATCH v2] of: check previous kernel's ima-kexec-buffer against memory bounds
Just a minor nit which I noticed.
On 22/05/24 11:20AM, Vaibhav Jain wrote:
> Presently ima_get_kexec_buffer() doesn't check if the previous kernel's
> ima-kexec-buffer lies outside the addressable memory range. This can result
> in a kernel panic if the new kernel is booted with 'mem=X' arg and the
> ima-kexec-buffer was allocated beyond that range by the previous kernel.
> The panic is usually of the form below:
>
> $ sudo kexec --initrd initrd vmlinux --append='mem=16G'
>
>
> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f
> Faulting instruction address: 0xc0837974
> Oops: Kernel access of bad area, sig: 11 [#1]
>
> NIP [c0837974] ima_restore_measurement_list+0x94/0x6c0
> LR [c083b55c] ima_load_kexec_buffer+0xac/0x160
> Call Trace:
> [c371fa80] [c083b55c] ima_load_kexec_buffer+0xac/0x160
> [c371fb00] [c20512c4] ima_init+0x80/0x108
> [c371fb70] [c20514dc] init_ima+0x4c/0x120
> [c371fbf0] [c0012240] do_one_initcall+0x60/0x2c0
> [c371fcc0] [c2004ad0] kernel_init_freeable+0x344/0x3ec
> [c371fda0] [c00128a4] kernel_init+0x34/0x1b0
> [c371fe10] [c000ce64] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc0 40810330
> 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010
> ---[ end trace ]---
>
> Fix this issue by checking returned PFN range of previous kernel's
> ima-kexec-buffer with pfn_valid to ensure correct memory bounds.
>
> Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the
> previous kernel")
> Cc: Frank Rowand
> Cc: Prakhar Srivastava
> Cc: Lakshmi Ramasubramanian
> Cc: Thiago Jung Bauermann
> Cc: Rob Herring
> Signed-off-by: Vaibhav Jain
>
> ---
> Changelog
> ==
>
> v2:
> * Instead of using memblock to determine the valid bounds use pfn_valid() to
> do
> so since memblock may not be available late after the kernel init. [ Mpe ]
> * Changed the patch prefix from 'powerpc' to 'of' [ Mpe ]
> * Updated the 'Fixes' tag to point to correct commit that introduced this
> function. [ Rob ]
> * Fixed some whitespace/tab issues in the patch description [ Rob ]
> * Added another check for checking ig 'tmp_size' for ima-kexec-buffer is > 0
> ---
> drivers/of/kexec.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
> index 8d374cc552be..879e984fe901 100644
> --- a/drivers/of/kexec.c
> +++ b/drivers/of/kexec.c
> @@ -126,6 +126,7 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
> {
> int ret, len;
> unsigned long tmp_addr;
> + unsigned int start_pfn, end_pfn;
^^^ Shouldn't this be unsigned long?
-ritesh
> size_t tmp_size;
> const void *prop;
>
> @@ -140,6 +141,22 @@ int ima_get_kexec_buffer(void **addr, size_t *size)
> if (ret)
> return ret;
>
> + /* Do some sanity on the returned size for the ima-kexec buffer */
> + if (!tmp_size)
> + return -ENOENT;
> +
> + /*
> + * Calculate the PFNs for the buffer and ensure
> + * they are with in addressable memory.
> + */
> + start_pfn = PHYS_PFN(tmp_addr);
> + end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1);
> + if (!pfn_valid(start_pfn) || !pfn_valid(end_pfn)) {
> + pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n",
> + tmp_addr, tmp_size);
> + return -EINVAL;
> + }
> +
> *addr = __va(tmp_addr);
> *size = tmp_size;
>
> --
> 2.35.1
>
Re: [powerpc]Kernel crash while running LTP (execveat03) [next-20220315]
On 22/03/16 01:47PM, Sachin Sant wrote: > While running LTP tests(execveat03) against 5.17.0-rc8-next-20220315 > On a POWER10 LPAR following crash is seen: > > [ 945.659049] dummy_del_mod: loading out-of-tree module taints kernel. > [ 945.659951] dummy_del_mod: module verification failed: signature and/or > required key missing - tainting kernel > [ 955.520206] process 'execveat01' launched '/dev/fd/-1' with NULL argv: > empty string added > [ 955.529560] loop0: detected capacity change from 0 to 524288 > [ 955.830492] EXT4-fs (loop0): mounting ext2 file system using the ext4 > subsystem Ok, so it has mounted ext2 using ext4 subsystem. This means there is no journal. > [ 955.831047] EXT4-fs (loop0): mounted filesystem without journal. Quota > mode: none. > [ 955.831056] ext2 filesystem being mounted at > /var/tmp/avocado_2hol2hy1/ltp-SHEyyra8b0/3CPNpu/mntpoint supports timestamps > until 2038 (0x7fff) > [ 955.907793] Kernel attempted to read user page (1) - exploit attempt? > (uid: 0) > [ 955.907806] BUG: Kernel NULL pointer dereference on read at 0x0001 > [ 955.907809] Faulting instruction address: 0xc00800be04ec > [ 955.907811] Oops: Kernel access of bad area, sig: 11 [#1] > [ 955.907814] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries > [ 955.907818] Modules linked in: overlay vfat fat btrfs blake2b_generic xor > raid6_pq zstd_compress xfs loop sctp ip6_udp_tunnel udp_tunnel dm_mod nft_ct > nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set rfkill nf_tables bonding > libcrc32c nfnetlink sunrpc pseries_rng xts vmx_crypto sch_fq_codel ext4 > mbcache jbd2 sd_mod t10_pi crc64_rocksoft crc64 sg ibmvscsi ibmveth > scsi_transport_srp fuse [last unloaded: dummy_del_mod] > [ 955.907849] CPU: 30 PID: 1947255 Comm: execveat03 Tainted: G OE >5.17.0-rc8-next-20220315 #1 > [ 955.907853] NIP: c00800be04ec LR: c00800ba4b00 CTR: > c04fd040 > [ 955.907856] REGS: c002474831a0 TRAP: 0300 Tainted: G OE > (5.17.0-rc8-next-20220315) > [ 955.907860] MSR: 8280b033 CR: > 28028282 XER: 2004 > [ 955.907869] CFAR: c00800ba4afc DAR: 0001 DSISR: 4000 > IRQMASK: 0 > [ 955.907869] GPR00: c00800ba4b00 c00247483440 c00800c28000 > 0001 > [ 955.907869] GPR04: c00206668af8 c00800be0068 > > [ 955.907869] GPR08: 0002 0004 > c00800be7f68 > [ 955.907869] GPR12: c04fd040 c00effbe7280 > 0001 > [ 955.907869] GPR16: c29b4048 > > [ 955.907869] GPR20: c29b4048 0004 > c00206668af8 > [ 955.907869] GPR24: c00247483528 0001 c00800c01208 > > [ 955.907869] GPR28: 0001 c00206668af8 c001f0d92e80 > 0001 > [ 955.907904] NIP [c00800be04ec] __ext4_fc_track_link+0x44/0xf0 [ext4] > [ 955.907927] LR [c00800ba4b00] ext4_rename+0x878/0xdc0 [ext4] > [ 955.907946] Call Trace: > [ 955.907947] [c00247483440] [0004] 0x4 (unreliable) > [ 955.907950] [c002474834a0] [c00800ba4b00] ext4_rename+0x878/0xdc0 > [ext4] > [ 955.907969] [c00247483670] [c04a498c] vfs_rename+0x9cc/0xe00 > [ 955.907975] [c00247483760] [c00800341820] > ovl_do_rename.constprop.28+0x78/0x140 [overlay] > [ 955.907982] [c00247483830] [c00800341b50] > ovl_make_workdir+0x268/0x7e0 [overlay] > [ 955.907988] [c00247483960] [c00800343aa8] > ovl_fill_super+0x1060/0x2160 [overlay] > [ 955.907994] [c00247483ae0] [c0492f68] mount_nodev+0x78/0x100 > [ 955.907998] [c00247483b20] [c00800340054] ovl_mount+0x2c/0x50 > [overlay] > [ 955.908004] [c00247483b40] [c04f676c] legacy_get_tree+0x4c/0xb0 > [ 955.908008] [c00247483b70] [c049063c] vfs_get_tree+0x4c/0x150 > [ 955.908012] [c00247483bf0] [c04d3768] path_mount+0x8e8/0xd50 > [ 955.908017] [c00247483cb0] [c04d3c50] do_mount+0x80/0xd0 > [ 955.908021] [c00247483d10] [c04d3e3c] sys_mount+0x19c/0x370 > [ 955.908025] [c00247483db0] [c003375c] > system_call_exception+0x18c/0x390 > [ 955.908029] [c00247483e10] [c000c64c] > system_call_common+0xec/0x270 > [ 955.908034] --- interrupt: c00 at 0x7fffa9b38dfc > [ 955.908036] NIP: 7fffa9b38dfc LR: 1001ba78 CTR: > > [ 955.908039] REGS: c00247483e80 TRAP: 0c00 Tainted: G OE > (5.17.0-rc8-next-20220315) > [ 955.908042] MSR: 8280f033 > CR: 24002202 XER: > [ 955.908050] IRQMASK: 0 > [ 955.908050] GPR00: 0015 795c64c0 7fffa9c07300 > 10029a08 > [ 955.908050] GPR04: 10027de0 10029a08 > 100299c0 > [ 955.908050] GPR08:
Re: [powerpc] Warning mm/slub.c:3246 during boot (next-20220210) w/ext4
On 22/02/10 06:57PM, Sachin Sant wrote: > While booting 5.17.0-rc3-next-20220210 on Power following warning > is seen: > > [ 32.626501] EXT4-fs (sda2): re-mounted. Quota mode: none. > [ 32.627225] [ cut here ] > [ 32.627236] WARNING: CPU: 27 PID: 1084 at mm/slub.c:3246 > kmem_cache_alloc+0x3b0/0x680 > [ 32.627250] Modules linked in: ext4 mbcache jbd2 sd_mod t10_pi sg ipr tg3 > libata ptp pps_core fuse > [ 32.627273] CPU: 27 PID: 1084 Comm: kworker/u161:0 Not tainted > 5.17.0-rc3-next-20220210 #17 > [ 32.627283] NIP: c0444df0 LR: c00807fe6b44 CTR: > c0444a40 > [ 32.627291] REGS: c00052393480 TRAP: 0700 Not tainted > (5.17.0-rc3-next-20220210) > [ 32.627298] MSR: 90029033 CR: 44002822 > XER: 2000 > [ 32.627316] CFAR: c0444a6c IRQMASK: 0 > [ 32.627316] GPR00: c00807fe6b44 c00052393720 c2a06b00 > c00059660200 > [ 32.627316] GPR04: 0d40 c0004f735000 > c00050760618 > [ 32.627316] GPR08: 0001 0008 0038 > c00807fe7a70 > [ 32.627316] GPR12: c0444a40 c007fffe1a80 c017a6b8 > > [ 32.627316] GPR16: > > [ 32.627316] GPR20: 0041 c00052393b78 c00052393a88 > 0338 > [ 32.627316] GPR24: c008089706d8 c008089706d8 c0004f735000 > c00808014a98 > [ 32.627316] GPR28: 8d40 0040 > 0100 > [ 32.627398] NIP [c0444df0] kmem_cache_alloc+0x3b0/0x680 > [ 32.627406] LR [c00807fe6b44] > jbd2_journal_add_journal_head+0x13c/0x2b8 [jbd2] > [ 32.627430] Call Trace: > [ 32.627433] [c00052393720] [c00807fd0e18] > start_this_handle+0x530/0x6b0 [jbd2] (unreliable) > [ 32.627454] [c00052393790] [0d40] 0xd40 > [ 32.627462] [c00052393820] [c00807fd36d8] > jbd2_journal_get_write_access+0x80/0x110 [jbd2] > [ 32.627482] [c00052393860] [c008088c5640] > __ext4_journal_get_write_access+0xb8/0x2d0 [ext4] > [ 32.627528] [c00052393910] [c008088d69b8] > ext4_file_open+0x2e0/0x430 [ext4] > [ 32.627571] [c000523939e0] [c0488cf0] > do_dentry_open+0x170/0x4e0 > [ 32.627582] [c00052393a30] [c04aabfc] path_openat+0xedc/0x1560 > [ 32.627593] [c00052393b30] [c04ac634] do_filp_open+0xa4/0x130 > [ 32.627602] [c00052393c70] [c0499c8c] do_open_execat+0x9c/0x2f0 > [ 32.627611] [c00052393cc0] [c049ad44] bprm_execve+0x184/0x7f0 > [ 32.627620] [c00052393d80] [c049c6d8] kernel_execve+0x1a8/0x240 > [ 32.627630] [c00052393dd0] [c017a838] > call_usermodehelper_exec_async+0x188/0x2c0 > [ 32.627642] [c00052393e10] [c000ce64] > ret_from_kernel_thread+0x5c/0x64 > [ 32.627652] Instruction dump: > [ 32.627657] e90d0030 7d49402a 394a 7d49412a 4bbd1f79 6000 eae10028 > eb610048 > [ 32.627672] 4bfffd80 6000 6000 6000 <0fe0> 7c0802a6 > f8410018 fae10028 > [ 32.627686] ---[ end trace ]— > > This WARN_ONCE was introduced by following commit: > > commit 120aa5e574796c9a3ef5f22cdb391747da997a26 > mm: Check for SLAB_TYPESAFE_BY_RCU and __GFP_ZERO slab allocation > > The system has ext4 file system. Yup, this is getting discussed in this thread [1] @ linux-ext4 [1]: https://lore.kernel.org/linux-ext4/20220210091648.w5wie3llqri5k...@quack3.lan/T/#m5f371e9910ee646e6361f484b2f12eab6aa47eeb -ritesh
Re: [PATCHv2] selftests/powerpc/copyloops: Add memmove_64 test
Found this, while checking my older emails. Sorry about not checking on this before. Have addressed the review comments here [1] This still applies cleanly on 5.17-rc3 and passes. riteshh-> ./copyloops/memmove_64 test: memmove tags: git_version:v5.17-rc3-1-g84f773abc114 success: memmove [1]: https://lore.kernel.org/all/87sfybl5f9@mpe.ellerman.id.au/ -ritesh On 21/09/13 11:47AM, Ritesh Harjani wrote: > While debugging an issue, we wanted to check whether the arch specific > kernel memmove implementation is correct. > This selftest could help test that. > > Suggested-by: Aneesh Kumar K.V > Suggested-by: Vaibhav Jain > Signed-off-by: Ritesh Harjani > --- > v1 -> v2: Integrated memmove_64 test within copyloops tests > [v1]: https://patchwork.ozlabs.org/patch/1518082 > > .../selftests/powerpc/copyloops/.gitignore| 1 + > .../selftests/powerpc/copyloops/Makefile | 9 ++- > .../selftests/powerpc/copyloops/asm/ppc_asm.h | 1 + > .../selftests/powerpc/copyloops/mem_64.S | 1 + > .../powerpc/copyloops/memcpy_stubs.S | 8 +++ > .../powerpc/copyloops/memmove_validate.c | 58 +++ > 6 files changed, 77 insertions(+), 1 deletion(-) > create mode 12 tools/testing/selftests/powerpc/copyloops/mem_64.S > create mode 100644 tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S > create mode 100644 > tools/testing/selftests/powerpc/copyloops/memmove_validate.c > > diff --git a/tools/testing/selftests/powerpc/copyloops/.gitignore > b/tools/testing/selftests/powerpc/copyloops/.gitignore > index 994b11af765c..7283e8b07b75 100644 > --- a/tools/testing/selftests/powerpc/copyloops/.gitignore > +++ b/tools/testing/selftests/powerpc/copyloops/.gitignore > @@ -13,3 +13,4 @@ copyuser_64_exc_t0 > copyuser_64_exc_t1 > copyuser_64_exc_t2 > copy_mc_64 > +memmove_64 > diff --git a/tools/testing/selftests/powerpc/copyloops/Makefile > b/tools/testing/selftests/powerpc/copyloops/Makefile > index 3095b1f1c02b..77594e697f2f 100644 > --- a/tools/testing/selftests/powerpc/copyloops/Makefile > +++ b/tools/testing/selftests/powerpc/copyloops/Makefile > @@ -13,7 +13,8 @@ TEST_GEN_PROGS := copyuser_64_t0 copyuser_64_t1 > copyuser_64_t2 \ > copyuser_p7_t0 copyuser_p7_t1 \ > memcpy_64_t0 memcpy_64_t1 memcpy_64_t2 \ > memcpy_p7_t0 memcpy_p7_t1 copy_mc_64 \ > - copyuser_64_exc_t0 copyuser_64_exc_t1 copyuser_64_exc_t2 > + copyuser_64_exc_t0 copyuser_64_exc_t1 copyuser_64_exc_t2 \ > + memmove_64 > > EXTRA_SOURCES := validate.c ../harness.c stubs.S > > @@ -56,3 +57,9 @@ $(OUTPUT)/copyuser_64_exc_t%: copyuser_64.S exc_validate.c > ../harness.c \ > -D COPY_LOOP=test___copy_tofrom_user_base \ > -D SELFTEST_CASE=$(subst copyuser_64_exc_t,,$(notdir $@)) \ > -o $@ $^ > + > +$(OUTPUT)/memmove_64: mem_64.S memcpy_64.S memmove_validate.c ../harness.c \ > + memcpy_stubs.S > + $(CC) $(CPPFLAGS) $(CFLAGS) \ > + -D TEST_MEMMOVE=test_memmove \ > + -o $@ $^ > diff --git a/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h > b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h > index 58c1cef3e399..003e1b3d9300 100644 > --- a/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h > +++ b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h > @@ -26,6 +26,7 @@ > #define _GLOBAL(A) FUNC_START(test_ ## A) > #define _GLOBAL_TOC(A) _GLOBAL(A) > #define _GLOBAL_TOC_KASAN(A) _GLOBAL(A) > +#define _GLOBAL_KASAN(A) _GLOBAL(A) > > #define PPC_MTOCRF(A, B) mtocrf A, B > > diff --git a/tools/testing/selftests/powerpc/copyloops/mem_64.S > b/tools/testing/selftests/powerpc/copyloops/mem_64.S > new file mode 12 > index ..db254c9a5f5c > --- /dev/null > +++ b/tools/testing/selftests/powerpc/copyloops/mem_64.S > @@ -0,0 +1 @@ > +../../../../../arch/powerpc/lib/mem_64.S > \ No newline at end of file > diff --git a/tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S > b/tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S > new file mode 100644 > index ..d9baa832fa49 > --- /dev/null > +++ b/tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S > @@ -0,0 +1,8 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +#include > + > +FUNC_START(memcpy) > + b test_memcpy > + > +FUNC_START(backwards_memcpy) > + b test_backwards_memcpy > diff --git a/tools/testing/selftests/powerpc/copyloops/memmove_validate.c > b/tools/testing/selftests/powerpc/copyloops/memmove_validate.c > new file mode 100644 > index ..1a23218b5757 > --- /dev/null > +++ b/tools/testing/selftests/powerpc/copy
[PATCHv2] selftests/powerpc/copyloops: Add memmove_64 test
While debugging an issue, we wanted to check whether the arch specific
kernel memmove implementation is correct.
This selftest could help test that.
Suggested-by: Aneesh Kumar K.V
Suggested-by: Vaibhav Jain
Signed-off-by: Ritesh Harjani
---
v1 -> v2: Integrated memmove_64 test within copyloops tests
[v1]: https://patchwork.ozlabs.org/patch/1518082
.../selftests/powerpc/copyloops/.gitignore| 1 +
.../selftests/powerpc/copyloops/Makefile | 9 ++-
.../selftests/powerpc/copyloops/asm/ppc_asm.h | 1 +
.../selftests/powerpc/copyloops/mem_64.S | 1 +
.../powerpc/copyloops/memcpy_stubs.S | 8 +++
.../powerpc/copyloops/memmove_validate.c | 58 +++
6 files changed, 77 insertions(+), 1 deletion(-)
create mode 12 tools/testing/selftests/powerpc/copyloops/mem_64.S
create mode 100644 tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S
create mode 100644 tools/testing/selftests/powerpc/copyloops/memmove_validate.c
diff --git a/tools/testing/selftests/powerpc/copyloops/.gitignore
b/tools/testing/selftests/powerpc/copyloops/.gitignore
index 994b11af765c..7283e8b07b75 100644
--- a/tools/testing/selftests/powerpc/copyloops/.gitignore
+++ b/tools/testing/selftests/powerpc/copyloops/.gitignore
@@ -13,3 +13,4 @@ copyuser_64_exc_t0
copyuser_64_exc_t1
copyuser_64_exc_t2
copy_mc_64
+memmove_64
diff --git a/tools/testing/selftests/powerpc/copyloops/Makefile
b/tools/testing/selftests/powerpc/copyloops/Makefile
index 3095b1f1c02b..77594e697f2f 100644
--- a/tools/testing/selftests/powerpc/copyloops/Makefile
+++ b/tools/testing/selftests/powerpc/copyloops/Makefile
@@ -13,7 +13,8 @@ TEST_GEN_PROGS := copyuser_64_t0 copyuser_64_t1
copyuser_64_t2 \
copyuser_p7_t0 copyuser_p7_t1 \
memcpy_64_t0 memcpy_64_t1 memcpy_64_t2 \
memcpy_p7_t0 memcpy_p7_t1 copy_mc_64 \
- copyuser_64_exc_t0 copyuser_64_exc_t1 copyuser_64_exc_t2
+ copyuser_64_exc_t0 copyuser_64_exc_t1 copyuser_64_exc_t2 \
+ memmove_64
EXTRA_SOURCES := validate.c ../harness.c stubs.S
@@ -56,3 +57,9 @@ $(OUTPUT)/copyuser_64_exc_t%: copyuser_64.S exc_validate.c
../harness.c \
-D COPY_LOOP=test___copy_tofrom_user_base \
-D SELFTEST_CASE=$(subst copyuser_64_exc_t,,$(notdir $@)) \
-o $@ $^
+
+$(OUTPUT)/memmove_64: mem_64.S memcpy_64.S memmove_validate.c ../harness.c \
+ memcpy_stubs.S
+ $(CC) $(CPPFLAGS) $(CFLAGS) \
+ -D TEST_MEMMOVE=test_memmove \
+ -o $@ $^
diff --git a/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h
b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h
index 58c1cef3e399..003e1b3d9300 100644
--- a/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h
+++ b/tools/testing/selftests/powerpc/copyloops/asm/ppc_asm.h
@@ -26,6 +26,7 @@
#define _GLOBAL(A) FUNC_START(test_ ## A)
#define _GLOBAL_TOC(A) _GLOBAL(A)
#define _GLOBAL_TOC_KASAN(A) _GLOBAL(A)
+#define _GLOBAL_KASAN(A) _GLOBAL(A)
#define PPC_MTOCRF(A, B) mtocrf A, B
diff --git a/tools/testing/selftests/powerpc/copyloops/mem_64.S
b/tools/testing/selftests/powerpc/copyloops/mem_64.S
new file mode 12
index ..db254c9a5f5c
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/mem_64.S
@@ -0,0 +1 @@
+../../../../../arch/powerpc/lib/mem_64.S
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S
b/tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S
new file mode 100644
index ..d9baa832fa49
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/memcpy_stubs.S
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include
+
+FUNC_START(memcpy)
+ b test_memcpy
+
+FUNC_START(backwards_memcpy)
+ b test_backwards_memcpy
diff --git a/tools/testing/selftests/powerpc/copyloops/memmove_validate.c
b/tools/testing/selftests/powerpc/copyloops/memmove_validate.c
new file mode 100644
index ..1a23218b5757
--- /dev/null
+++ b/tools/testing/selftests/powerpc/copyloops/memmove_validate.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include "utils.h"
+
+void *TEST_MEMMOVE(const void *s1, const void *s2, size_t n);
+
+#define BUF_LEN 65536
+#define MAX_OFFSET 512
+
+size_t max(size_t a, size_t b)
+{
+ if (a >= b)
+ return a;
+ return b;
+}
+
+static int testcase_run(void)
+{
+ size_t i, src_off, dst_off, len;
+
+ char *usermap = memalign(BUF_LEN, BUF_LEN);
+ char *kernelmap = memalign(BUF_LEN, BUF_LEN);
+
+ assert(usermap != NULL);
+ assert(kernelmap != NULL);
+
+ memset(usermap, 0, BUF_LEN);
+ memset(kernelmap, 0, BUF_LEN);
+
+ for (i = 0; i < BUF_LEN; i++) {
+ usermap[i] = i & 0xff;
+ kernelmap[i] = i & 0xff;
+ }
+
+ for (src_off = 0; sr
Re: [PATCH 1/1] selftests/powerpc: Add memmove_64 test
On 21/09/11 09:26PM, Michael Ellerman wrote: > Ritesh Harjani writes: > > While debugging an issue, we wanted to check whether the arch specific > > kernel memmove implementation is correct. This selftest could help test > > that. > > > > Suggested-by: Aneesh Kumar K.V > > Suggested-by: Vaibhav Jain > > Signed-off-by: Ritesh Harjani > > --- > > tools/testing/selftests/powerpc/Makefile | 1 + > > .../selftests/powerpc/memmoveloop/.gitignore | 2 + > > .../selftests/powerpc/memmoveloop/Makefile| 19 +++ > > .../powerpc/memmoveloop/asm/asm-compat.h | 0 > > .../powerpc/memmoveloop/asm/export.h | 4 ++ > > .../powerpc/memmoveloop/asm/feature-fixups.h | 0 > > .../selftests/powerpc/memmoveloop/asm/kasan.h | 0 > > .../powerpc/memmoveloop/asm/ppc_asm.h | 39 + > > .../powerpc/memmoveloop/asm/processor.h | 0 > > .../selftests/powerpc/memmoveloop/mem_64.S| 1 + > > .../selftests/powerpc/memmoveloop/memcpy_64.S | 1 + > > .../selftests/powerpc/memmoveloop/stubs.S | 8 +++ > > .../selftests/powerpc/memmoveloop/validate.c | 56 +++ > > 13 files changed, 131 insertions(+) > > create mode 100644 tools/testing/selftests/powerpc/memmoveloop/.gitignore > > create mode 100644 tools/testing/selftests/powerpc/memmoveloop/Makefile > > create mode 100644 > > tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h > > create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/export.h > > create mode 100644 > > tools/testing/selftests/powerpc/memmoveloop/asm/feature-fixups.h > > create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/kasan.h > > create mode 100644 > > tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h > > create mode 100644 > > tools/testing/selftests/powerpc/memmoveloop/asm/processor.h > > create mode 12 tools/testing/selftests/powerpc/memmoveloop/mem_64.S > > create mode 12 tools/testing/selftests/powerpc/memmoveloop/memcpy_64.S > > create mode 100644 tools/testing/selftests/powerpc/memmoveloop/stubs.S > > create mode 100644 tools/testing/selftests/powerpc/memmoveloop/validate.c > > You've copied a lot of tools/testing/selftests/powerpc/copyloops > > I'd be happier if you integrated the memmove test into that existing > code. I realise memmove is not technically a copy loop, but it's close > enough. Sure. > > Did you try that and hit some roadblock? Nope, let me try that and send it in v2. -ritesh > > cheers > > > > diff --git a/tools/testing/selftests/powerpc/Makefile > > b/tools/testing/selftests/powerpc/Makefile > > index 0830e63818c1..d110b3e5cbcd 100644 > > --- a/tools/testing/selftests/powerpc/Makefile > > +++ b/tools/testing/selftests/powerpc/Makefile > > @@ -16,6 +16,7 @@ export CFLAGS > > SUB_DIRS = alignment \ > >benchmarks \ > >cache_shape \ > > + memmoveloop \ > >copyloops\ > >dscr \ > >mm \ > > diff --git a/tools/testing/selftests/powerpc/memmoveloop/.gitignore > > b/tools/testing/selftests/powerpc/memmoveloop/.gitignore > > new file mode 100644 > > index ..56c1426013d5 > > --- /dev/null > > +++ b/tools/testing/selftests/powerpc/memmoveloop/.gitignore > > @@ -0,0 +1,2 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +memmove_64 > > diff --git a/tools/testing/selftests/powerpc/memmoveloop/Makefile > > b/tools/testing/selftests/powerpc/memmoveloop/Makefile > > new file mode 100644 > > index ..d58d8c100099 > > --- /dev/null > > +++ b/tools/testing/selftests/powerpc/memmoveloop/Makefile > > @@ -0,0 +1,19 @@ > > +# SPDX-License-Identifier: GPL-2.0 > > +CFLAGS += -m64 > > +CFLAGS += -I$(CURDIR) > > +CFLAGS += -D SELFTEST > > +CFLAGS += -maltivec > > + > > +ASFLAGS = $(CFLAGS) -Wa,-mpower4 > > + > > +TEST_GEN_PROGS := memmove_64 > > +EXTRA_SOURCES := validate.c ../harness.c stubs.S > > +CPPFLAGS += -D TEST_MEMMOVE=test_memmove > > + > > +top_srcdir = ../../../../.. > > +include ../../lib.mk > > + > > +$(OUTPUT)/memmove_64: mem_64.S memcpy_64.S $(EXTRA_SOURCES) > > + $(CC) $(CPPFLAGS) $(CFLAGS) \ > > + -D TEST_MEMMOVE=test_memmove \ > > + -o $@ $^ > > diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h > > b/tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h > > new file mo
Re: [PATCH 1/1] selftests/powerpc: Add memmove_64 test
Gentle ping! -ritesh
[PATCH 1/1] selftests/powerpc: Add memmove_64 test
While debugging an issue, we wanted to check whether the arch specific kernel memmove implementation is correct. This selftest could help test that. Suggested-by: Aneesh Kumar K.V Suggested-by: Vaibhav Jain Signed-off-by: Ritesh Harjani --- tools/testing/selftests/powerpc/Makefile | 1 + .../selftests/powerpc/memmoveloop/.gitignore | 2 + .../selftests/powerpc/memmoveloop/Makefile| 19 +++ .../powerpc/memmoveloop/asm/asm-compat.h | 0 .../powerpc/memmoveloop/asm/export.h | 4 ++ .../powerpc/memmoveloop/asm/feature-fixups.h | 0 .../selftests/powerpc/memmoveloop/asm/kasan.h | 0 .../powerpc/memmoveloop/asm/ppc_asm.h | 39 + .../powerpc/memmoveloop/asm/processor.h | 0 .../selftests/powerpc/memmoveloop/mem_64.S| 1 + .../selftests/powerpc/memmoveloop/memcpy_64.S | 1 + .../selftests/powerpc/memmoveloop/stubs.S | 8 +++ .../selftests/powerpc/memmoveloop/validate.c | 56 +++ 13 files changed, 131 insertions(+) create mode 100644 tools/testing/selftests/powerpc/memmoveloop/.gitignore create mode 100644 tools/testing/selftests/powerpc/memmoveloop/Makefile create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/export.h create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/feature-fixups.h create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/kasan.h create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h create mode 100644 tools/testing/selftests/powerpc/memmoveloop/asm/processor.h create mode 12 tools/testing/selftests/powerpc/memmoveloop/mem_64.S create mode 12 tools/testing/selftests/powerpc/memmoveloop/memcpy_64.S create mode 100644 tools/testing/selftests/powerpc/memmoveloop/stubs.S create mode 100644 tools/testing/selftests/powerpc/memmoveloop/validate.c diff --git a/tools/testing/selftests/powerpc/Makefile b/tools/testing/selftests/powerpc/Makefile index 0830e63818c1..d110b3e5cbcd 100644 --- a/tools/testing/selftests/powerpc/Makefile +++ b/tools/testing/selftests/powerpc/Makefile @@ -16,6 +16,7 @@ export CFLAGS SUB_DIRS = alignment \ benchmarks \ cache_shape \ + memmoveloop \ copyloops\ dscr \ mm \ diff --git a/tools/testing/selftests/powerpc/memmoveloop/.gitignore b/tools/testing/selftests/powerpc/memmoveloop/.gitignore new file mode 100644 index ..56c1426013d5 --- /dev/null +++ b/tools/testing/selftests/powerpc/memmoveloop/.gitignore @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +memmove_64 diff --git a/tools/testing/selftests/powerpc/memmoveloop/Makefile b/tools/testing/selftests/powerpc/memmoveloop/Makefile new file mode 100644 index ..d58d8c100099 --- /dev/null +++ b/tools/testing/selftests/powerpc/memmoveloop/Makefile @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: GPL-2.0 +CFLAGS += -m64 +CFLAGS += -I$(CURDIR) +CFLAGS += -D SELFTEST +CFLAGS += -maltivec + +ASFLAGS = $(CFLAGS) -Wa,-mpower4 + +TEST_GEN_PROGS := memmove_64 +EXTRA_SOURCES := validate.c ../harness.c stubs.S +CPPFLAGS += -D TEST_MEMMOVE=test_memmove + +top_srcdir = ../../../../.. +include ../../lib.mk + +$(OUTPUT)/memmove_64: mem_64.S memcpy_64.S $(EXTRA_SOURCES) + $(CC) $(CPPFLAGS) $(CFLAGS) \ + -D TEST_MEMMOVE=test_memmove \ + -o $@ $^ diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h b/tools/testing/selftests/powerpc/memmoveloop/asm/asm-compat.h new file mode 100644 index ..e69de29bb2d1 diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/export.h b/tools/testing/selftests/powerpc/memmoveloop/asm/export.h new file mode 100644 index ..e6b80d5fbd14 --- /dev/null +++ b/tools/testing/selftests/powerpc/memmoveloop/asm/export.h @@ -0,0 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#define EXPORT_SYMBOL(x) +#define EXPORT_SYMBOL_GPL(x) +#define EXPORT_SYMBOL_KASAN(x) diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/feature-fixups.h b/tools/testing/selftests/powerpc/memmoveloop/asm/feature-fixups.h new file mode 100644 index ..e69de29bb2d1 diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/kasan.h b/tools/testing/selftests/powerpc/memmoveloop/asm/kasan.h new file mode 100644 index ..e69de29bb2d1 diff --git a/tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h b/tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h new file mode 100644 index ..117005c56e19 --- /dev/null +++ b/tools/testing/selftests/powerpc/memmoveloop/asm/ppc_asm.h @@ -0,0 +1,39 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __SELFTESTS_POWERPC_PPC_ASM_H +#define __SELFTESTS_POWERPC_PPC_ASM_H +#include + +#define CONFIG_ALTIVEC + +#define r1 1 + +#define R14 r14 +#define
