- Linux-kselftest-mirror - lists.linaro.org

[PATCH V4 00/10] PKS Add Protection Key Supervisor support

by ira.weiny＠intel.com

From: Ira Weiny <ira.weiny(a)intel.com> Introduce a new page protection mechanism for supervisor pages, Protection Key Supervisor (PKS). Generally PKS enables protections on 'domains' of supervisor pages to limit supervisor mode access to pages beyond the normal paging protections. PKS works in a similar fashion to user space pkeys, PKU. As with PKU, supervisor pkeys are checked in addition to normal paging protections and Access or Writes can be disabled via a MSR update without TLB flushes when permissions change. Also like PKU, a page mapping is assigned to a domain by setting pkey bits in the page table entry for that mapping. Access is controlled through a PKRS register which is updated via WRMSR/RDMSR. XSAVE is not supported for the PKRS MSR. Therefore the implementation saves/restores the MSR across context switches and during exceptions. Nested exceptions are supported by each exception getting a new PKS state. For consistent behavior with current paging protections, pkey 0 is reserved and configured to allow full access via the pkey mechanism, thus preserving the default paging protections on mappings with the default pkey value of 0. Other keys, (1-15) are allocated by an allocator which prepares us for key contention from day one. Kernel users should be prepared for the allocator to fail either because of key exhaustion or due to PKS not being supported on the CPU instance. The following are key attributes of PKS. 1) Fast switching of permissions 1a) Prevents access without page table manipulations 1b) No TLB flushes required 2) Works on a per thread basis PKS is available with 4 and 5 level paging. Like PKRU it consumes 4 bits from the PTE to store the pkey within the entry. All code to support PKS is configured via ARCH_ENABLE_SUPERVISOR_PKEYS which is designed to only be turned on when a user is configured on in the kernel. Those users must depend on ARCH_HAS_SUPERVISOR_PKEYS to properly work with other architectures which do not yet support PKS. Originally this series was submitted as part of a large patch set which converted the kmap call sites.[1] Many follow on discussions revealed a few problems. The first of which was that some callers leak a kmap mapping across threads rather than containing it to a critical section. Attempts were made to see if these 'global kmaps' could be supported.[2] However, supporting global kmaps had many problems. Work is being done in parallel on converting as many kmap calls to the new kmap_local_page().[3] Changes from V3 [4] Add ARCH_ENABLE_SUPERVISOR_PKEYS config which is selected by kernel users to add the functionality to the core. However, they should only select this if ARCH_HAS_SUPERVISOR_PKEYS is available. Clean up test code for context switching Adjust for extended_pt_regs Reduce output unless --debug is specified Address internal review comments from Dan Williams and Dave Hansen Help with macros and assembly coding Change names of various functions Clean up documentation Move all #ifdefery into header files. Clean up cover letter. Make extended_pt_regs handling a macro rather than coding around every call to C Add macross for PKS shift/mask New patch : x86/pks: Add additional PKEY helper macros Preserve pkrs_cache as static when PKS_TEST is not configured Remove unnecessary pr_* prints Clarify pks_key_alloc flags parameter Change CONFIG_PKS_TESTING to CONFIG_PKS_TEST Clean up test code separation from main code in fault.c Remove module boilerplate from test code Clean up all commit messages Address comments from Thomas Gleixner Provide a warning and fallback to no protection if a global mapping is requested. Fix context switch. Fix where pks_sched_in() is called. Fix test to actually do a context switch Remove unecessary noinstr's From Andy Lutomirski Use extended_pt_regs idea to stash pks values on the stack Drop patches 5/10 and 7/10 And use extended_pt_regs to print pkey info on fault Adjust tests Comments from Randy Dunlap: Fix gramatical errors in doc Clean up kernel docs Rebase to 5.12 [1] https://lore.kernel.org/lkml/20201009195033.3208459-1-ira.weiny@intel.com/ [2] https://lore.kernel.org/lkml/87mtycqcjf.fsf@nanos.tec.linutronix.de/ [3] https://lore.kernel.org/lkml/20210128061503.1496847-1-ira.weiny@intel.com/ https://lore.kernel.org/lkml/20210210062221.3023586-1-ira.weiny@intel.com/ https://lore.kernel.org/lkml/20210205170030.856723-1-ira.weiny@intel.com/ https://lore.kernel.org/lkml/20210217024826.3466046-1-ira.weiny@intel.com/ [4] https://lore.kernel.org/lkml/20201106232908.364581-1-ira.weiny@intel.com/ </proposed cover letter> Fenghua Yu (1): x86/pks: Add PKS kernel API Ira Weiny (9): x86/pkeys: Create pkeys_common.h x86/fpu: Refactor arch_set_user_pkey_access() for PKS support x86/pks: Add additional PKEY helper macros x86/pks: Add PKS defines and Kconfig options x86/pks: Add PKS setup code x86/fault: Adjust WARN_ON for PKey fault x86/pks: Preserve the PKRS MSR on context switch x86/entry: Preserve PKRS MSR across exceptions x86/pks: Add PKS test code Documentation/core-api/protection-keys.rst | 111 +++- arch/x86/Kconfig | 1 + arch/x86/entry/calling.h | 26 + arch/x86/entry/common.c | 58 ++ arch/x86/entry/entry_64.S | 22 +- arch/x86/entry/entry_64_compat.S | 6 +- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/asm/pgtable.h | 10 +- arch/x86/include/asm/pgtable_types.h | 12 + arch/x86/include/asm/pkeys.h | 4 + arch/x86/include/asm/pkeys_common.h | 34 + arch/x86/include/asm/pks.h | 54 ++ arch/x86/include/asm/processor-flags.h | 2 + arch/x86/include/asm/processor.h | 43 +- arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/cpu/common.c | 2 + arch/x86/kernel/fpu/xstate.c | 22 +- arch/x86/kernel/head_64.S | 7 +- arch/x86/kernel/process.c | 3 + arch/x86/kernel/process_64.c | 2 + arch/x86/mm/fault.c | 27 +- arch/x86/mm/pkeys.c | 218 +++++- include/linux/pgtable.h | 4 + include/linux/pkeys.h | 34 + kernel/entry/common.c | 14 +- lib/Kconfig.debug | 11 + lib/Makefile | 3 + lib/pks/Makefile | 3 + lib/pks/pks_test.c | 693 ++++++++++++++++++++ mm/Kconfig | 5 + tools/testing/selftests/x86/Makefile | 3 +- tools/testing/selftests/x86/test_pks.c | 150 +++++ 34 files changed, 1519 insertions(+), 77 deletions(-) create mode 100644 arch/x86/include/asm/pkeys_common.h create mode 100644 arch/x86/include/asm/pks.h create mode 100644 lib/pks/Makefile create mode 100644 lib/pks/pks_test.c create mode 100644 tools/testing/selftests/x86/test_pks.c -- 2.28.0.rc0.12.gb6a658bd00c9

4 years, 3 months

3
15
0 0

BUG: key ffff000800eba398 has not been registered!

by Naresh Kamboju

While running kselftest recently added gpio gpio-sim.sh test case the following warning was triggered on Linux next tag 20210330 tag running on arm64 juno and hikey devices. GOOD: next-20210326 BAD: next-20210330 # selftests: gpio: gpio-sim.sh # 1. chip_name and dev_name attributes # 1.1. Chip name is communicated to user [ 143.081193] BUG: key ffff000800eba398 has not been registered! [ 143.087326] ------------[ cut here ]------------ [ 143.091987] DEBUG_LOCKS_WARN_ON(1) [ 143.092005] WARNING: CPU: 1 PID: 1821 at /usr/src/kernel/kernel/locking/lockdep.c:4688 lockdep_init_map_type+0xf0/0x298 [ 143.106223] Modules linked in: gpio_sim rfkill tda998x cec drm_kms_helper drm crct10dif_ce fuse [last unloaded: gpio_mockup] [ 143.117495] CPU: 1 PID: 1821 Comm: mv Not tainted 5.12.0-rc5-next-20210330 #1 [ 143.124645] Hardware name: ARM Juno development board (r2) (DT) [ 143.130572] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) [ 143.136589] pc : lockdep_init_map_type+0xf0/0x298 [ 143.141302] lr : lockdep_init_map_type+0xf0/0x298 [ 143.146014] sp : ffff800013fb3560 [ 143.149330] x29: ffff800013fb3560 x28: 00000000ffffee4b [ 143.154655] x27: 00000000000011b4 x26: 0000000000001000 [ 143.159979] x25: ffff000800eba380 x24: 0000000000000000 [ 143.165303] x23: 0000000000000000 x22: 0000000000000000 [ 143.170626] x21: ffff80001382b000 x20: ffff000800eba398 [ 143.175949] x19: ffff000827ac32a8 x18: ffffffffffffffff [ 143.181273] x17: 0000000000000000 x16: 0000000000000000 [ 143.186595] x15: ffff800012900a88 x14: ffff800093fb3167 [ 143.191918] x13: ffff800013fb3175 x12: 000000000000a0ec [ 143.197241] x11: 0000000005f5e0ff x10: ffff800013fb30c0 [ 143.202565] x9 : ffff800013fb3560 x8 : 4e5241575f534b43 [ 143.207888] x7 : ffff800012989ad8 x6 : ffff800013fb3180 [ 143.213211] x5 : 0000000000000001 x4 : 0000000000000001 [ 143.218534] x3 : ffff800012901000 x2 : 0000000000000000 [ 143.223856] x1 : b4b7acac5f71bc00 x0 : 0000000000000000 [ 143.229180] Call trace: [ 143.231625] lockdep_init_map_type+0xf0/0x298 [ 143.235989] __kernfs_create_file+0xa8/0x1d0 [ 143.240268] sysfs_add_file_mode_ns+0xa8/0x1f8 [ 143.244718] internal_create_group+0x118/0x420 [ 143.249169] sysfs_create_group+0x2c/0x38 [ 143.253185] gpio_sim_probe+0x358/0x3c0 [gpio_sim] [ 143.257995] platform_probe+0x6c/0xd8 [ 143.261663] really_probe+0x16c/0x508 [ 143.265332] driver_probe_device+0x104/0x178 [ 143.269610] __device_attach_driver+0xa4/0x130 [ 143.274062] bus_for_each_drv+0x78/0xd8 [ 143.277903] __device_attach+0xf0/0x178 [ 143.281745] device_initial_probe+0x24/0x30 [ 143.285935] bus_probe_device+0xa0/0xa8 [ 143.289776] device_add+0x424/0x810 [ 143.293270] platform_device_add+0x12c/0x2c0 [ 143.297545] platform_device_register_full+0x124/0x150 [ 143.302692] gpio_sim_config_commit_item+0x160/0x1e0 [gpio_sim] [ 143.308628] configfs_rename+0x1dc/0x220 [ 143.312557] vfs_rename+0x394/0x960 [ 143.316051] do_renameat2+0x408/0x4c0 [ 143.319718] __arm64_sys_renameat+0x5c/0x70 [ 143.323908] el0_svc_common+0x7c/0x158 [ 143.327665] do_el0_svc+0x38/0x90 [ 143.330985] el0_svc+0x20/0x30 [ 143.334045] el0_sync_handler+0x8c/0xb0 [ 143.337886] el0_sync+0x13c/0x140 [ 143.341204] irq event stamp: 5607 [ 143.344520] hardirqs last enabled at (5607): [<ffff800011462dd8>] _raw_spin_unlock_irq+0x48/0x90 [ 143.353410] hardirqs last disabled at (5606): [<ffff8000114586c4>] __schedule+0x364/0x950 [ 143.361605] softirqs last enabled at (5602): [<ffff800010010958>] __do_softirq+0x510/0x63c [ 143.369971] softirqs last disabled at (5577): [<ffff8000100a7474>] irq_exit+0x1b4/0x1c0 [ 143.377992] ---[ end trace bc3c86ef609281aa ]--- # 1.2. chip_name returns 'none' if the chip is still pending Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> metadata: git branch: master git repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git git describe: next-20210330 kernel-config: http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/juno/lkft/linux-nex… Full test log link, https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20210330/te… git log --oneline next-20210326..next-20210330 -- tools/testing/selftests/gpio/ 9d940ab72645 selftests: gpio: add test cases for gpio-sim 8a4cb2823240 selftests: gpio: add a helper for reading GPIO line names ab1dbed6f4e8 selftests: gpio: provide a helper for reading chip info -- Linaro LKFT https://lkft.linaro.org

4 years, 3 months

1
0
0 0

[PATCH v8 1/4] lib: vsprintf: scanf: Negative number must have field width > 1

by Richard Fitzgerald

If a signed number field starts with a '-' the field width must be > 1, or unlimited, to allow at least one digit after the '-'. This patch adds a check for this. If a signed field starts with '-' and field_width == 1 the scanf will quit. It is ok for a signed number field to have a field width of 1 if it starts with a digit. In that case the single digit can be converted. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Reviewed-by: Petr Mladek <pmladek(a)suse.com> Acked-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> --- lib/vsprintf.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lib/vsprintf.c b/lib/vsprintf.c index 41ddc353ebb8..f78651e9b030 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -3466,8 +3466,12 @@ int vsscanf(const char *buf, const char *fmt, va_list args) str = skip_spaces(str); digit = *str; - if (is_sign && digit == '-') + if (is_sign && digit == '-') { + if (field_width == 1) + break; + digit = *(str + 1); + } if (!digit || (base == 16 && !isxdigit(digit)) -- 2.20.1

4 years, 3 months

1
3
0 0

[PATCH v2] userfaultfd/shmem: fix MCOPY_ATOMIC_CONTNUE behavior

by Axel Rasmussen

Previously, we shared too much of the code with COPY and ZEROPAGE, so we manipulated things in various invalid ways: - Previously, we unconditionally called shmem_inode_acct_block. In the continue case, we're looking up an existing page which would have been accounted for properly when it was allocated. So doing it twice results in double-counting, and eventually leaking. - Previously, we made the pte writable whenever the VMA was writable. However, for continue, consider this case: 1. A tmpfs file was created 2. The non-UFFD-registered side mmap()-s with MAP_SHARED 3. The UFFD-registered side mmap()-s with MAP_PRIVATE In this case, even though the UFFD-registered VMA may be writable, we still want CoW behavior. So, check for this case and don't make the pte writable. - The offset / max_off checking doesn't necessarily hurt anything, but it's not needed in the CONTINUE case, so skip it. - Previously, we unconditionally called ClearPageDirty() in the error path. In the continue case though, since this is an existing page, it might have already been dirty before we started touching it. So, remember whether or not it was dirty before we set_page_dirty(), and only clear the bit if it wasn't dirty before. - Previously, we unconditionally removed the page from the page cache in the error path. But in the continue case, we didn't add it - it was already there because the page is present in some second (non-UFFD-registered) mapping. So, removing it is invalid. Because the error handling issues are easy to exercise in the selftest, make a small modification there to do so. Finally, refactor shmem_mcopy_atomic_pte a bit. By this point, we've added a lot of "if (!is_continue)"-s everywhere. It's cleaner to just check for that mode first thing, and then "goto" down to where the parts we actually want are. This leaves the code in between cleaner. Changes since v1: - Refactor to skip ahead with goto, instead of adding several more "if (!is_continue)". - Fix unconditional ClearPageDirty(). - Don't pte_mkwrite() when is_continue && !VM_SHARED. Fixes: 00da60b9d0a0 ("userfaultfd: support minor fault handling for shmem") Signed-off-by: Axel Rasmussen <axelrasmussen(a)google.com> --- mm/shmem.c | 67 ++++++++++++++---------- tools/testing/selftests/vm/userfaultfd.c | 12 +++++ 2 files changed, 51 insertions(+), 28 deletions(-) diff --git a/mm/shmem.c b/mm/shmem.c index d2e0e81b7d2e..8ab1f1f29987 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -2378,17 +2378,22 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, pte_t _dst_pte, *dst_pte; int ret; pgoff_t offset, max_off; - - ret = -ENOMEM; - if (!shmem_inode_acct_block(inode, 1)) - goto out; + int writable; + bool was_dirty; if (is_continue) { ret = -EFAULT; page = find_lock_page(mapping, pgoff); if (!page) - goto out_unacct_blocks; - } else if (!*pagep) { + goto out; + goto install_ptes; + } + + ret = -ENOMEM; + if (!shmem_inode_acct_block(inode, 1)) + goto out; + + if (!*pagep) { page = shmem_alloc_page(gfp, info, pgoff); if (!page) goto out_unacct_blocks; @@ -2415,13 +2420,11 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, *pagep = NULL; } - if (!is_continue) { - VM_BUG_ON(PageSwapBacked(page)); - VM_BUG_ON(PageLocked(page)); - __SetPageLocked(page); - __SetPageSwapBacked(page); - __SetPageUptodate(page); - } + VM_BUG_ON(PageSwapBacked(page)); + VM_BUG_ON(PageLocked(page)); + __SetPageLocked(page); + __SetPageSwapBacked(page); + __SetPageUptodate(page); ret = -EFAULT; offset = linear_page_index(dst_vma, dst_addr); @@ -2429,16 +2432,18 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, if (unlikely(offset >= max_off)) goto out_release; - /* If page wasn't already in the page cache, add it. */ - if (!is_continue) { - ret = shmem_add_to_page_cache(page, mapping, pgoff, NULL, - gfp & GFP_RECLAIM_MASK, dst_mm); - if (ret) - goto out_release; - } + ret = shmem_add_to_page_cache(page, mapping, pgoff, NULL, + gfp & GFP_RECLAIM_MASK, dst_mm); + if (ret) + goto out_release; +install_ptes: _dst_pte = mk_pte(page, dst_vma->vm_page_prot); - if (dst_vma->vm_flags & VM_WRITE) + /* For CONTINUE on a non-shared VMA, don't pte_mkwrite for CoW. */ + writable = is_continue && !(dst_vma->vm_flags & VM_SHARED) + ? 0 + : dst_vma->vm_flags & VM_WRITE; + if (writable) _dst_pte = pte_mkwrite(pte_mkdirty(_dst_pte)); else { /* @@ -2448,15 +2453,18 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, * unconditionally before unlock_page(), but doing it * only if VM_WRITE is not set is faster. */ + was_dirty = PageDirty(page); set_page_dirty(page); } dst_pte = pte_offset_map_lock(dst_mm, dst_pmd, dst_addr, &ptl); - ret = -EFAULT; - max_off = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); - if (unlikely(offset >= max_off)) - goto out_release_unlock; + if (!is_continue) { + ret = -EFAULT; + max_off = DIV_ROUND_UP(i_size_read(inode), PAGE_SIZE); + if (unlikely(offset >= max_off)) + goto out_release_unlock; + } ret = -EEXIST; if (!pte_none(*dst_pte)) @@ -2485,13 +2493,16 @@ int shmem_mcopy_atomic_pte(struct mm_struct *dst_mm, pmd_t *dst_pmd, return ret; out_release_unlock: pte_unmap_unlock(dst_pte, ptl); - ClearPageDirty(page); - delete_from_page_cache(page); + if (!was_dirty) + ClearPageDirty(page); + if (!is_continue) + delete_from_page_cache(page); out_release: unlock_page(page); put_page(page); out_unacct_blocks: - shmem_inode_unacct_blocks(inode, 1); + if (!is_continue) + shmem_inode_unacct_blocks(inode, 1); goto out; } #endif /* CONFIG_USERFAULTFD */ diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c index f6c86b036d0f..d8541a59dae5 100644 --- a/tools/testing/selftests/vm/userfaultfd.c +++ b/tools/testing/selftests/vm/userfaultfd.c @@ -485,6 +485,7 @@ static void wp_range(int ufd, __u64 start, __u64 len, bool wp) static void continue_range(int ufd, __u64 start, __u64 len) { struct uffdio_continue req; + int ret; req.range.start = start; req.range.len = len; @@ -493,6 +494,17 @@ static void continue_range(int ufd, __u64 start, __u64 len) if (ioctl(ufd, UFFDIO_CONTINUE, &req)) err("UFFDIO_CONTINUE failed for address 0x%" PRIx64, (uint64_t)start); + + /* + * Error handling within the kernel for continue is subtly different + * from copy or zeropage, so it may be a source of bugs. Trigger an + * error (-EEXIST) on purpose, to verify doing so doesn't cause a BUG. + */ + req.mapped = 0; + ret = ioctl(ufd, UFFDIO_CONTINUE, &req); + if (ret >= 0 || req.mapped != -EEXIST) + err("failed to exercise UFFDIO_CONTINUE error handling, ret=%d, mapped=%" PRId64, + ret, req.mapped); } static void *locking_thread(void *arg) -- 2.31.0.291.g576ba9dcdaf-goog

4 years, 3 months

2
1
0 0

[PATCH AUTOSEL 5.10 27/33] selftests/vm: fix out-of-tree build

by Sasha Levin

From: Rong Chen <rong.a.chen(a)intel.com> [ Upstream commit 19ec368cbc7ee1915e78c120b7a49c7f14734192 ] When building out-of-tree, attempting to make target from $(OUTPUT) directory: make[1]: *** No rule to make target '$(OUTPUT)/protection_keys.c', needed by '$(OUTPUT)/protection_keys_32'. Link: https://lkml.kernel.org/r/20210315094700.522753-1-rong.a.chen@intel.com Signed-off-by: Rong Chen <rong.a.chen(a)intel.com> Reported-by: kernel test robot <lkp(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/vm/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile index e63f31632708..2cf32e6b376e 100644 --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -99,7 +99,7 @@ endef ifeq ($(CAN_BUILD_I386),1) $(BINARIES_32): CFLAGS += -m32 $(BINARIES_32): LDLIBS += -lrt -ldl -lm -$(BINARIES_32): %_32: %.c +$(BINARIES_32): $(OUTPUT)/%_32: %.c $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-32,$(t)))) endif @@ -107,7 +107,7 @@ endif ifeq ($(CAN_BUILD_X86_64),1) $(BINARIES_64): CFLAGS += -m64 $(BINARIES_64): LDLIBS += -lrt -ldl -$(BINARIES_64): %_64: %.c +$(BINARIES_64): $(OUTPUT)/%_64: %.c $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-64,$(t)))) endif -- 2.30.1

4 years, 3 months

1
0
0 0

[PATCH AUTOSEL 5.10 20/33] kselftest/arm64: sve: Do not use non-canonical FFR register value

by Sasha Levin

From: Andre Przywara <andre.przywara(a)arm.com> [ Upstream commit 7011d72588d16a9e5f5d85acbc8b10019809599c ] The "First Fault Register" (FFR) is an SVE register that mimics a predicate register, but clears bits when a load or store fails to handle an element of a vector. The supposed usage scenario is to initialise this register (using SETFFR), then *read* it later on to learn about elements that failed to load or store. Explicit writes to this register using the WRFFR instruction are only supposed to *restore* values previously read from the register (for context-switching only). As the manual describes, this register holds only certain values, it: "... contains a monotonic predicate value, in which starting from bit 0 there are zero or more 1 bits, followed only by 0 bits in any remaining bit positions." Any other value is UNPREDICTABLE and is not supposed to be "restored" into the register. The SVE test currently tries to write a signature pattern into the register, which is *not* a canonical FFR value. Apparently the existing setups treat UNPREDICTABLE as "read-as-written", but a new implementation actually only stores canonical values. As a consequence, the sve-test fails immediately when comparing the FFR value: ----------- # ./sve-test Vector length: 128 bits PID: 207 Mismatch: PID=207, iteration=0, reg=48 Expected [cf00] Got [0f00] Aborted ----------- Fix this by only populating the FFR with proper canonical values. Effectively the requirement described above limits us to 17 unique values over 16 bits worth of FFR, so we condense our signature down to 4 bits (2 bits from the PID, 2 bits from the generation) and generate the canonical pattern from it. Any bits describing elements above the minimum 128 bit are set to 0. This aligns the FFR usage to the architecture and fixes the test on microarchitectures implementing FFR in a more restricted way. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> Reviwed-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20210319120128.29452-1-andre.przywara@arm.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/arm64/fp/sve-test.S | 22 ++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/arm64/fp/sve-test.S b/tools/testing/selftests/arm64/fp/sve-test.S index f95074c9b48b..07f14e279a90 100644 --- a/tools/testing/selftests/arm64/fp/sve-test.S +++ b/tools/testing/selftests/arm64/fp/sve-test.S @@ -284,16 +284,28 @@ endfunction // Set up test pattern in the FFR // x0: pid // x2: generation +// +// We need to generate a canonical FFR value, which consists of a number of +// low "1" bits, followed by a number of zeros. This gives us 17 unique values +// per 16 bits of FFR, so we create a 4 bit signature out of the PID and +// generation, and use that as the initial number of ones in the pattern. +// We fill the upper lanes of FFR with zeros. // Beware: corrupts P0. function setup_ffr mov x4, x30 - bl pattern + and w0, w0, #0x3 + bfi w0, w2, #2, #2 + mov w1, #1 + lsl w1, w1, w0 + sub w1, w1, #1 + ldr x0, =ffrref - ldr x1, =scratch - rdvl x2, #1 - lsr x2, x2, #3 - bl memcpy + strh w1, [x0], 2 + rdvl x1, #1 + lsr x1, x1, #3 + sub x1, x1, #2 + bl memclr mov x0, #0 ldr x1, =ffrref -- 2.30.1

4 years, 3 months

1
0
0 0

[PATCH AUTOSEL 5.10 07/33] kunit: tool: Fix a python tuple typing error

by Sasha Levin

From: David Gow <davidgow(a)google.com> [ Upstream commit 7421b1a4d10c633ca5f14c8236d3e2c1de07e52b ] The first argument to namedtuple() should match the name of the type, which wasn't the case for KconfigEntryBase. Fixing this is enough to make mypy show no python typing errors again. Fixes 97752c39bd ("kunit: kunit_tool: Allow .kunitconfig to disable config items") Signed-off-by: David Gow <davidgow(a)google.com> Reviewed-by: Daniel Latypov <dlatypov(a)google.com> Acked-by: Brendan Higgins <brendanhiggins(a)google.com> Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/kunit/kunit_config.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/kunit/kunit_config.py b/tools/testing/kunit/kunit_config.py index 02ffc3a3e5dc..b30e9d6db6b4 100644 --- a/tools/testing/kunit/kunit_config.py +++ b/tools/testing/kunit/kunit_config.py @@ -12,7 +12,7 @@ import re CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$' CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+|".*")$' -KconfigEntryBase = collections.namedtuple('KconfigEntry', ['name', 'value']) +KconfigEntryBase = collections.namedtuple('KconfigEntryBase', ['name', 'value']) class KconfigEntry(KconfigEntryBase): -- 2.30.1

4 years, 3 months

1
0
0 0

[PATCH AUTOSEL 5.11 32/38] selftests/vm: fix out-of-tree build

by Sasha Levin

From: Rong Chen <rong.a.chen(a)intel.com> [ Upstream commit 19ec368cbc7ee1915e78c120b7a49c7f14734192 ] When building out-of-tree, attempting to make target from $(OUTPUT) directory: make[1]: *** No rule to make target '$(OUTPUT)/protection_keys.c', needed by '$(OUTPUT)/protection_keys_32'. Link: https://lkml.kernel.org/r/20210315094700.522753-1-rong.a.chen@intel.com Signed-off-by: Rong Chen <rong.a.chen(a)intel.com> Reported-by: kernel test robot <lkp(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/vm/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile index d42115e4284d..8b0cd421ebd3 100644 --- a/tools/testing/selftests/vm/Makefile +++ b/tools/testing/selftests/vm/Makefile @@ -101,7 +101,7 @@ endef ifeq ($(CAN_BUILD_I386),1) $(BINARIES_32): CFLAGS += -m32 $(BINARIES_32): LDLIBS += -lrt -ldl -lm -$(BINARIES_32): %_32: %.c +$(BINARIES_32): $(OUTPUT)/%_32: %.c $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-32,$(t)))) endif @@ -109,7 +109,7 @@ endif ifeq ($(CAN_BUILD_X86_64),1) $(BINARIES_64): CFLAGS += -m64 $(BINARIES_64): LDLIBS += -lrt -ldl -$(BINARIES_64): %_64: %.c +$(BINARIES_64): $(OUTPUT)/%_64: %.c $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(notdir $^) $(LDLIBS) -o $@ $(foreach t,$(TARGETS),$(eval $(call gen-target-rule-64,$(t)))) endif -- 2.30.1

4 years, 3 months

1
0
0 0

[PATCH AUTOSEL 5.11 23/38] kselftest/arm64: sve: Do not use non-canonical FFR register value

by Sasha Levin

From: Andre Przywara <andre.przywara(a)arm.com> [ Upstream commit 7011d72588d16a9e5f5d85acbc8b10019809599c ] The "First Fault Register" (FFR) is an SVE register that mimics a predicate register, but clears bits when a load or store fails to handle an element of a vector. The supposed usage scenario is to initialise this register (using SETFFR), then *read* it later on to learn about elements that failed to load or store. Explicit writes to this register using the WRFFR instruction are only supposed to *restore* values previously read from the register (for context-switching only). As the manual describes, this register holds only certain values, it: "... contains a monotonic predicate value, in which starting from bit 0 there are zero or more 1 bits, followed only by 0 bits in any remaining bit positions." Any other value is UNPREDICTABLE and is not supposed to be "restored" into the register. The SVE test currently tries to write a signature pattern into the register, which is *not* a canonical FFR value. Apparently the existing setups treat UNPREDICTABLE as "read-as-written", but a new implementation actually only stores canonical values. As a consequence, the sve-test fails immediately when comparing the FFR value: ----------- # ./sve-test Vector length: 128 bits PID: 207 Mismatch: PID=207, iteration=0, reg=48 Expected [cf00] Got [0f00] Aborted ----------- Fix this by only populating the FFR with proper canonical values. Effectively the requirement described above limits us to 17 unique values over 16 bits worth of FFR, so we condense our signature down to 4 bits (2 bits from the PID, 2 bits from the generation) and generate the canonical pattern from it. Any bits describing elements above the minimum 128 bit are set to 0. This aligns the FFR usage to the architecture and fixes the test on microarchitectures implementing FFR in a more restricted way. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> Reviwed-by: Mark Brown <broonie(a)kernel.org> Link: https://lore.kernel.org/r/20210319120128.29452-1-andre.przywara@arm.com Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/arm64/fp/sve-test.S | 22 ++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/arm64/fp/sve-test.S b/tools/testing/selftests/arm64/fp/sve-test.S index 9210691aa998..e3e08d9c7020 100644 --- a/tools/testing/selftests/arm64/fp/sve-test.S +++ b/tools/testing/selftests/arm64/fp/sve-test.S @@ -284,16 +284,28 @@ endfunction // Set up test pattern in the FFR // x0: pid // x2: generation +// +// We need to generate a canonical FFR value, which consists of a number of +// low "1" bits, followed by a number of zeros. This gives us 17 unique values +// per 16 bits of FFR, so we create a 4 bit signature out of the PID and +// generation, and use that as the initial number of ones in the pattern. +// We fill the upper lanes of FFR with zeros. // Beware: corrupts P0. function setup_ffr mov x4, x30 - bl pattern + and w0, w0, #0x3 + bfi w0, w2, #2, #2 + mov w1, #1 + lsl w1, w1, w0 + sub w1, w1, #1 + ldr x0, =ffrref - ldr x1, =scratch - rdvl x2, #1 - lsr x2, x2, #3 - bl memcpy + strh w1, [x0], 2 + rdvl x1, #1 + lsr x1, x1, #3 + sub x1, x1, #2 + bl memclr mov x0, #0 ldr x1, =ffrref -- 2.30.1

4 years, 3 months

1
0
0 0

[PATCH AUTOSEL 5.11 08/38] kunit: tool: Fix a python tuple typing error

by Sasha Levin

From: David Gow <davidgow(a)google.com> [ Upstream commit 7421b1a4d10c633ca5f14c8236d3e2c1de07e52b ] The first argument to namedtuple() should match the name of the type, which wasn't the case for KconfigEntryBase. Fixing this is enough to make mypy show no python typing errors again. Fixes 97752c39bd ("kunit: kunit_tool: Allow .kunitconfig to disable config items") Signed-off-by: David Gow <davidgow(a)google.com> Reviewed-by: Daniel Latypov <dlatypov(a)google.com> Acked-by: Brendan Higgins <brendanhiggins(a)google.com> Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/kunit/kunit_config.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/kunit/kunit_config.py b/tools/testing/kunit/kunit_config.py index bdd60230764b..27fe086d2d0d 100644 --- a/tools/testing/kunit/kunit_config.py +++ b/tools/testing/kunit/kunit_config.py @@ -13,7 +13,7 @@ from typing import List, Set CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$' CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+|".*")$' -KconfigEntryBase = collections.namedtuple('KconfigEntry', ['name', 'value']) +KconfigEntryBase = collections.namedtuple('KconfigEntryBase', ['name', 'value']) class KconfigEntry(KconfigEntryBase): -- 2.30.1

4 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror