* [PATCH] ocxl: do not use C++ style comments in uapi header
From: Masahiro Yamada @ 2019-06-04 11:16 UTC (permalink / raw)
To: Frederic Barrat, Andrew Donnellan, linuxppc-dev
Cc: Arnd Bergmann, Greg KH, Randy Dunlap, linux-kernel,
Masahiro Yamada, Joe Perches, Thomas Gleixner
Linux kernel tolerates C++ style comments these days. Actually, the
SPDX License tags for .c files start with //.
On the other hand, uapi headers are written in more strict C, where
the C++ comment style is forbidden.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
include/uapi/misc/ocxl.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 97937cfa3baa..6d29a60a896a 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -33,23 +33,23 @@ struct ocxl_ioctl_attach {
};
struct ocxl_ioctl_metadata {
- __u16 version; // struct version, always backwards compatible
+ __u16 version; /* struct version, always backwards compatible */
- // Version 0 fields
+ /* Version 0 fields */
__u8 afu_version_major;
__u8 afu_version_minor;
- __u32 pasid; // PASID assigned to the current context
+ __u32 pasid; /* PASID assigned to the current context */
- __u64 pp_mmio_size; // Per PASID MMIO size
+ __u64 pp_mmio_size; /* Per PASID MMIO size */
__u64 global_mmio_size;
- // End version 0 fields
+ /* End version 0 fields */
- __u64 reserved[13]; // Total of 16*u64
+ __u64 reserved[13]; /* Total of 16*u64 */
};
struct ocxl_ioctl_p9_wait {
- __u16 thread_id; // The thread ID required to wake this thread
+ __u16 thread_id; /* The thread ID required to wake this thread */
__u16 reserved1;
__u32 reserved2;
__u64 reserved3[3];
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 01/16] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2019-06-04 11:46 UTC (permalink / raw)
To: Christoph Hellwig
Cc: the arch/x86 maintainers, Rich Felker, Catalin Marinas,
Yoshinori Sato, linux-sh, James Hogan, PowerPC, Paul Burton,
Nicholas Piggin, linux-mips, Linux Memory Management List,
Khalid Aziz, Paul Mackerras, sparclinux, Linus Torvalds,
David S. Miller, LKML
In-Reply-To: <20190604072706.GF15680@lst.de>
On Tue, Jun 4, 2019 at 9:27 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Jun 03, 2019 at 09:16:08AM -0600, Khalid Aziz wrote:
> > Could you reword above sentence? We are already starting off with
> > untagged_addr() not being no-op for arm64 and sparc64. It will expand
> > further potentially. So something more along the lines of "Define it as
> > noop for architectures that do not support memory tagging". The first
> > paragraph in the log can also be rewritten to be not specific to arm64.
>
> Well, as of this patch this actually is a no-op for everyone.
>
> Linus, what do you think of applying this patch (maybe with a slightly
> fixed up commit log) to 5.2-rc so that we remove a cross dependency
> between the series?
(I have adjusted the patch description and have just sent it out
separately from the series).
^ permalink raw reply
* Re: [PATCH] ocxl: do not use C++ style comments in uapi header
From: Frederic Barrat @ 2019-06-04 11:51 UTC (permalink / raw)
To: Masahiro Yamada, Andrew Donnellan, linuxppc-dev
Cc: Arnd Bergmann, Greg KH, Randy Dunlap, linux-kernel, Joe Perches,
Thomas Gleixner
In-Reply-To: <20190604111632.22479-1-yamada.masahiro@socionext.com>
Le 04/06/2019 à 13:16, Masahiro Yamada a écrit :
> Linux kernel tolerates C++ style comments these days. Actually, the
> SPDX License tags for .c files start with //.
>
> On the other hand, uapi headers are written in more strict C, where
> the C++ comment style is forbidden.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Thanks!
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
>
> include/uapi/misc/ocxl.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 97937cfa3baa..6d29a60a896a 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -33,23 +33,23 @@ struct ocxl_ioctl_attach {
> };
>
> struct ocxl_ioctl_metadata {
> - __u16 version; // struct version, always backwards compatible
> + __u16 version; /* struct version, always backwards compatible */
>
> - // Version 0 fields
> + /* Version 0 fields */
> __u8 afu_version_major;
> __u8 afu_version_minor;
> - __u32 pasid; // PASID assigned to the current context
> + __u32 pasid; /* PASID assigned to the current context */
>
> - __u64 pp_mmio_size; // Per PASID MMIO size
> + __u64 pp_mmio_size; /* Per PASID MMIO size */
> __u64 global_mmio_size;
>
> - // End version 0 fields
> + /* End version 0 fields */
>
> - __u64 reserved[13]; // Total of 16*u64
> + __u64 reserved[13]; /* Total of 16*u64 */
> };
>
> struct ocxl_ioctl_p9_wait {
> - __u16 thread_id; // The thread ID required to wake this thread
> + __u16 thread_id; /* The thread ID required to wake this thread */
> __u16 reserved1;
> __u32 reserved2;
> __u64 reserved3[3];
>
^ permalink raw reply
* Re: [PATCH] ocxl: do not use C++ style comments in uapi header
From: Masahiro Yamada @ 2019-06-04 12:12 UTC (permalink / raw)
To: Frederic Barrat
Cc: Andrew Donnellan, Arnd Bergmann, Greg KH, Randy Dunlap,
Linux Kernel Mailing List, Joe Perches, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <90aa6d91-7592-17b0-17fd-e33676bd0a46@linux.ibm.com>
On Tue, Jun 4, 2019 at 8:54 PM Frederic Barrat <fbarrat@linux.ibm.com> wrote:
>
>
>
> Le 04/06/2019 à 13:16, Masahiro Yamada a écrit :
> > Linux kernel tolerates C++ style comments these days. Actually, the
> > SPDX License tags for .c files start with //.
> >
> > On the other hand, uapi headers are written in more strict C, where
> > the C++ comment style is forbidden.
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > ---
>
> Thanks!
> Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
>
Please hold on this patch until
we get consensus about the C++ comment style.
Discussion just started here:
https://lore.kernel.org/patchwork/patch/1083801/
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [RFC PATCH] powerpc/book3e: KASAN Full support for 64bit
From: Christophe Leroy @ 2019-06-04 12:43 UTC (permalink / raw)
To: Daniel Axtens, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87woi2xm8l.fsf@dja-thinkpad.axtens.net>
On 06/03/2019 11:50 PM, Daniel Axtens wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>
>> Hi,
>>
>> Ok, can you share your .config ?
>
> Sure! This one is with kasan off as the last build I did was testing to
> see if the code reorgisation was the cause of the issues. (it was not)
>
>
>
>
> This was the kasan-enabled config that failed to boot:
>
>
Same issue with your .config under QEMU:
A go with gdb shows:
Breakpoint 3, 0xc000000000027b6c in exc_0x700_common ()
=> 0xc000000000027b6c <exc_0x700_common+0>: f8 01 00 70 std r0,112(r1)
(gdb) bt
#0 0xc000000000027b6c in exc_0x700_common ()
#1 0xc00000000136f80c in .udbg_init_memcons ()
Without CONFIG_PPC_EARLY_DEBUG, it boots fine for me. Can you check on
your side ?
Deactivating KASAN for arch/powerpc/kernel/udbg.o and
arch/powerpc/sysdev/udbg_memcons.o is not enough, we hit a call to
strstr() in register_early_udbg_console(), and once we get rid of it (in
the same way as in prom_init.c) the next issue is register_console() and
I don't know what to do about that one.
Christophe
>
>
> Regards,
> Daniel
>
>>
>> Christophe
>>
>> Le 31/05/2019 à 03:29, Daniel Axtens a écrit :
>>> Hi Christophe,
>>>
>>> I tried this on the t4240rdb and it fails to boot if KASAN is
>>> enabled. It does boot with the patch applied but KASAN disabled, so that
>>> narrows it down a little bit.
>>>
>>> I need to focus on 3s first so I'll just drop 3e from my patch set for
>>> now.
>>>
>>> Regards,
>>> Daniel
>>>
>>>> The KASAN shadow area is mapped into vmemmap space:
>>>> 0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
>>>> For this vmemmap has to be disabled.
>>>>
>>>> Cc: Daniel Axtens <dja@axtens.net>
>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> ---
>>>> arch/powerpc/Kconfig | 1 +
>>>> arch/powerpc/Kconfig.debug | 3 +-
>>>> arch/powerpc/include/asm/kasan.h | 11 +++
>>>> arch/powerpc/kernel/Makefile | 2 +
>>>> arch/powerpc/kernel/head_64.S | 3 +
>>>> arch/powerpc/kernel/setup_64.c | 20 +++---
>>>> arch/powerpc/mm/kasan/Makefile | 1 +
>>>> arch/powerpc/mm/kasan/kasan_init_64.c | 129 ++++++++++++++++++++++++++++++++++
>>>> 8 files changed, 159 insertions(+), 11 deletions(-)
>>>> create mode 100644 arch/powerpc/mm/kasan/kasan_init_64.c
>>>>
>>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>>> index 1a2fb50126b2..e0b7c45e4dc7 100644
>>>> --- a/arch/powerpc/Kconfig
>>>> +++ b/arch/powerpc/Kconfig
>>>> @@ -174,6 +174,7 @@ config PPC
>>>> select HAVE_ARCH_AUDITSYSCALL
>>>> select HAVE_ARCH_JUMP_LABEL
>>>> select HAVE_ARCH_KASAN if PPC32
>>>> + select HAVE_ARCH_KASAN if PPC_BOOK3E_64 && !SPARSEMEM_VMEMMAP
>>>> select HAVE_ARCH_KGDB
>>>> select HAVE_ARCH_MMAP_RND_BITS
>>>> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>>>> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
>>>> index 61febbbdd02b..b4140dd6b4e4 100644
>>>> --- a/arch/powerpc/Kconfig.debug
>>>> +++ b/arch/powerpc/Kconfig.debug
>>>> @@ -370,4 +370,5 @@ config PPC_FAST_ENDIAN_SWITCH
>>>> config KASAN_SHADOW_OFFSET
>>>> hex
>>>> depends on KASAN
>>>> - default 0xe0000000
>>>> + default 0xe0000000 if PPC32
>>>> + default 0x6800040000000000 if PPC64
>>>> diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
>>>> index 296e51c2f066..756b3d58f921 100644
>>>> --- a/arch/powerpc/include/asm/kasan.h
>>>> +++ b/arch/powerpc/include/asm/kasan.h
>>>> @@ -23,10 +23,21 @@
>>>>
>>>> #define KASAN_SHADOW_OFFSET ASM_CONST(CONFIG_KASAN_SHADOW_OFFSET)
>>>>
>>>> +#ifdef CONFIG_PPC32
>>>> #define KASAN_SHADOW_END 0UL
>>>>
>>>> #define KASAN_SHADOW_SIZE (KASAN_SHADOW_END - KASAN_SHADOW_START)
>>>>
>>>> +#else
>>>> +
>>>> +#include <asm/pgtable.h>
>>>> +
>>>> +#define KASAN_SHADOW_SIZE (KERN_VIRT_SIZE >> KASAN_SHADOW_SCALE_SHIFT)
>>>> +
>>>> +#define KASAN_SHADOW_END (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
>>>> +
>>>> +#endif /* CONFIG_PPC32 */
>>>> +
>>>> #ifdef CONFIG_KASAN
>>>> void kasan_early_init(void);
>>>> void kasan_mmu_init(void);
>>>> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
>>>> index 0ea6c4aa3a20..7f232c06f11d 100644
>>>> --- a/arch/powerpc/kernel/Makefile
>>>> +++ b/arch/powerpc/kernel/Makefile
>>>> @@ -35,6 +35,8 @@ KASAN_SANITIZE_early_32.o := n
>>>> KASAN_SANITIZE_cputable.o := n
>>>> KASAN_SANITIZE_prom_init.o := n
>>>> KASAN_SANITIZE_btext.o := n
>>>> +KASAN_SANITIZE_paca.o := n
>>>> +KASAN_SANITIZE_setup_64.o := n
>>>>
>>>> ifdef CONFIG_KASAN
>>>> CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
>>>> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
>>>> index 3fad8d499767..80fbd8024fb2 100644
>>>> --- a/arch/powerpc/kernel/head_64.S
>>>> +++ b/arch/powerpc/kernel/head_64.S
>>>> @@ -966,6 +966,9 @@ start_here_multiplatform:
>>>> * and SLB setup before we turn on relocation.
>>>> */
>>>>
>>>> +#ifdef CONFIG_KASAN
>>>> + bl kasan_early_init
>>>> +#endif
>>>> /* Restore parameters passed from prom_init/kexec */
>>>> mr r3,r31
>>>> bl early_setup /* also sets r13 and SPRG_PACA */
>>>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>>>> index ba404dd9ce1d..d2bf860dd966 100644
>>>> --- a/arch/powerpc/kernel/setup_64.c
>>>> +++ b/arch/powerpc/kernel/setup_64.c
>>>> @@ -311,6 +311,16 @@ void __init early_setup(unsigned long dt_ptr)
>>>> DBG(" -> early_setup(), dt_ptr: 0x%lx\n", dt_ptr);
>>>>
>>>> /*
>>>> + * Configure exception handlers. This include setting up trampolines
>>>> + * if needed, setting exception endian mode, etc...
>>>> + */
>>>> + configure_exceptions();
>>>> +
>>>> + /* Apply all the dynamic patching */
>>>> + apply_feature_fixups();
>>>> + setup_feature_keys();
>>>> +
>>>> + /*
>>>> * Do early initialization using the flattened device
>>>> * tree, such as retrieving the physical memory map or
>>>> * calculating/retrieving the hash table size.
>>>> @@ -325,16 +335,6 @@ void __init early_setup(unsigned long dt_ptr)
>>>> setup_paca(paca_ptrs[boot_cpuid]);
>>>> fixup_boot_paca();
>>>>
>>>> - /*
>>>> - * Configure exception handlers. This include setting up trampolines
>>>> - * if needed, setting exception endian mode, etc...
>>>> - */
>>>> - configure_exceptions();
>>>> -
>>>> - /* Apply all the dynamic patching */
>>>> - apply_feature_fixups();
>>>> - setup_feature_keys();
>>>> -
>>>> /* Initialize the hash table or TLB handling */
>>>> early_init_mmu();
>>>>
>>>> diff --git a/arch/powerpc/mm/kasan/Makefile b/arch/powerpc/mm/kasan/Makefile
>>>> index 6577897673dd..0bfbe3892808 100644
>>>> --- a/arch/powerpc/mm/kasan/Makefile
>>>> +++ b/arch/powerpc/mm/kasan/Makefile
>>>> @@ -3,3 +3,4 @@
>>>> KASAN_SANITIZE := n
>>>>
>>>> obj-$(CONFIG_PPC32) += kasan_init_32.o
>>>> +obj-$(CONFIG_PPC64) += kasan_init_64.o
>>>> diff --git a/arch/powerpc/mm/kasan/kasan_init_64.c b/arch/powerpc/mm/kasan/kasan_init_64.c
>>>> new file mode 100644
>>>> index 000000000000..7fd71b8e883b
>>>> --- /dev/null
>>>> +++ b/arch/powerpc/mm/kasan/kasan_init_64.c
>>>> @@ -0,0 +1,129 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +
>>>> +#define DISABLE_BRANCH_PROFILING
>>>> +
>>>> +#include <linux/kasan.h>
>>>> +#include <linux/printk.h>
>>>> +#include <linux/memblock.h>
>>>> +#include <linux/sched/task.h>
>>>> +#include <asm/pgalloc.h>
>>>> +
>>>> +static void __init kasan_populate_pte(pte_t *ptep, pgprot_t prot)
>>>> +{
>>>> + unsigned long va = (unsigned long)kasan_early_shadow_page;
>>>> + phys_addr_t pa = __pa(kasan_early_shadow_page);
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PTE; i++, ptep++)
>>>> + __set_pte_at(&init_mm, va, ptep, pfn_pte(PHYS_PFN(pa), prot), 0);
>>>> +}
>>>> +
>>>> +static void __init kasan_populate_pmd(pmd_t *pmdp)
>>>> +{
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PMD; i++)
>>>> + pmd_populate_kernel(&init_mm, pmdp + i, kasan_early_shadow_pte);
>>>> +}
>>>> +
>>>> +static void __init kasan_populate_pud(pud_t *pudp)
>>>> +{
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PUD; i++)
>>>> + pud_populate(&init_mm, pudp + i, kasan_early_shadow_pmd);
>>>> +}
>>>> +
>>>> +static void __init *kasan_alloc_pgtable(unsigned long size)
>>>> +{
>>>> + void *ptr = memblock_alloc_try_nid(size, size, MEMBLOCK_LOW_LIMIT,
>>>> + __pa(MAX_DMA_ADDRESS), NUMA_NO_NODE);
>>>> +
>>>> + if (!ptr)
>>>> + panic("%s: Failed to allocate %lu bytes align=0x%lx max_addr=%lx\n",
>>>> + __func__, size, size, __pa(MAX_DMA_ADDRESS));
>>>> +
>>>> + return ptr;
>>>> +}
>>>> +
>>>> +static int __init kasan_map_page(unsigned long va, unsigned long pa, pgprot_t prot)
>>>> +{
>>>> + pgd_t *pgdp = pgd_offset_k(va);
>>>> + pud_t *pudp;
>>>> + pmd_t *pmdp;
>>>> + pte_t *ptep;
>>>> +
>>>> + if (pgd_none(*pgdp) || (void *)pgd_page_vaddr(*pgdp) == kasan_early_shadow_pud) {
>>>> + pudp = kasan_alloc_pgtable(PUD_TABLE_SIZE);
>>>> + kasan_populate_pud(pudp);
>>>> + pgd_populate(&init_mm, pgdp, pudp);
>>>> + }
>>>> + pudp = pud_offset(pgdp, va);
>>>> + if (pud_none(*pudp) || (void *)pud_page_vaddr(*pudp) == kasan_early_shadow_pmd) {
>>>> + pmdp = kasan_alloc_pgtable(PMD_TABLE_SIZE);
>>>> + kasan_populate_pmd(pmdp);
>>>> + pud_populate(&init_mm, pudp, pmdp);
>>>> + }
>>>> + pmdp = pmd_offset(pudp, va);
>>>> + if (!pmd_present(*pmdp) || (void *)pmd_page_vaddr(*pmdp) == kasan_early_shadow_pte) {
>>>> + ptep = kasan_alloc_pgtable(PTE_TABLE_SIZE);
>>>> + kasan_populate_pte(ptep, PAGE_KERNEL);
>>>> + pmd_populate_kernel(&init_mm, pmdp, ptep);
>>>> + }
>>>> + ptep = pte_offset_kernel(pmdp, va);
>>>> +
>>>> + __set_pte_at(&init_mm, va, ptep, pfn_pte(pa >> PAGE_SHIFT, prot), 0);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static void __init kasan_init_region(struct memblock_region *reg)
>>>> +{
>>>> + void *start = __va(reg->base);
>>>> + void *end = __va(reg->base + reg->size);
>>>> + unsigned long k_start, k_end, k_cur;
>>>> +
>>>> + if (start >= end)
>>>> + return;
>>>> +
>>>> + k_start = (unsigned long)kasan_mem_to_shadow(start);
>>>> + k_end = (unsigned long)kasan_mem_to_shadow(end);
>>>> +
>>>> + for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE) {
>>>> + void *va = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
>>>> +
>>>> + kasan_map_page(k_cur, __pa(va), PAGE_KERNEL);
>>>> + }
>>>> + flush_tlb_kernel_range(k_start, k_end);
>>>> +}
>>>> +
>>>> +void __init kasan_init(void)
>>>> +{
>>>> + struct memblock_region *reg;
>>>> +
>>>> + for_each_memblock(memory, reg)
>>>> + kasan_init_region(reg);
>>>> +
>>>> + /* It's too early to use clear_page() ! */
>>>> + memset(kasan_early_shadow_page, 0, sizeof(kasan_early_shadow_page));
>>>> +
>>>> + /* Enable error messages */
>>>> + init_task.kasan_depth = 0;
>>>> + pr_info("KASAN init done\n");
>>>> +}
>>>> +
>>>> +/* The early shadow maps everything to a single page of zeroes */
>>>> +asmlinkage void __init kasan_early_init(void)
>>>> +{
>>>> + unsigned long addr = KASAN_SHADOW_START;
>>>> + unsigned long end = KASAN_SHADOW_END;
>>>> + pgd_t *pgdp = pgd_offset_k(addr);
>>>> +
>>>> + kasan_populate_pte(kasan_early_shadow_pte, PAGE_KERNEL);
>>>> + kasan_populate_pmd(kasan_early_shadow_pmd);
>>>> + kasan_populate_pud(kasan_early_shadow_pud);
>>>> +
>>>> + do {
>>>> + pgd_populate(&init_mm, pgdp, kasan_early_shadow_pud);
>>>> + } while (pgdp++, addr = pgd_addr_end(addr, end), addr != end);
>>>> +}
>>>> --
>>>> 2.13.3
^ permalink raw reply
* Re: [PATCH v5 1/3] powerpc: Fix vDSO clock_getres()
From: Sasha Levin @ 2019-06-04 12:50 UTC (permalink / raw)
To: Sasha Levin, Vincenzo Frascino, linux-arch, linuxppc-dev
Cc: stable, Paul Mackerras, vincenzo.frascino
In-Reply-To: <20190528120446.48911-2-vincenzo.frascino@arm.com>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: a7f290dad32e [PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel.
The bot has tested the following trees: v5.1.6, v5.0.20, v4.19.47, v4.14.123, v4.9.180, v4.4.180.
v5.1.6: Build OK!
v5.0.20: Build OK!
v4.19.47: Build OK!
v4.14.123: Failed to apply! Possible dependencies:
5c929885f1bb ("powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038")
v4.9.180: Failed to apply! Possible dependencies:
454656155110 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
5c929885f1bb ("powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
5d451a87e5eb ("powerpc/64: Retrieve number of L1 cache sets from device-tree")
7c5b06cadf27 ("KVM: PPC: Book3S HV: Adapt TLB invalidations to work on POWER9")
83677f551e0a ("KVM: PPC: Book3S HV: Adjust host/guest context switch for POWER9")
902e06eb86cd ("powerpc/32: Change the stack protector canary value per task")
b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038")
bd067f83b084 ("powerpc/64: Fix naming of cache block vs. cache line")
e2827fe5c156 ("powerpc/64: Clean up ppc64_caches using a struct per cache")
e9cf1e085647 ("KVM: PPC: Book3S HV: Add new POWER9 guest-accessible SPRs")
f4c51f841d2a ("KVM: PPC: Book3S HV: Modify guest entry/exit paths to handle radix guests")
v4.4.180: Failed to apply! Possible dependencies:
153086644fd1 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI")
3eb5d5888dc6 ("powerpc: Add ppc_strict_facility_enable boot option")
454656155110 ("powerpc/asm: Use OFFSET macro in asm-offsets.c")
579e633e764e ("powerpc: create flush_all_to_thread()")
5c929885f1bb ("powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE")
70fe3d980f5f ("powerpc: Restore FPU/VEC/VSX if previously used")
85baa095497f ("powerpc/livepatch: Add live patching support on ppc64le")
902e06eb86cd ("powerpc/32: Change the stack protector canary value per task")
b5b4453e7912 ("powerpc/vdso64: Fix CLOCK_MONOTONIC inconsistencies across Y2038")
bf76f73c5f65 ("powerpc: enable UBSAN support")
c208505900b2 ("powerpc: create giveup_all()")
d1e1cf2e38de ("powerpc: clean up asm/switch_to.h")
dc4fbba11e46 ("powerpc: Create disable_kernel_{fp,altivec,vsx,spe}()")
f17c4e01e906 ("powerpc/module: Mark module stubs with a magic value")
How should we proceed with this patch?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Christophe Leroy @ 2019-06-04 13:16 UTC (permalink / raw)
To: Vincenzo Frascino, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <afb7395f-43e9-c304-2db2-349e6727b687@arm.com>
Hi Vincenzo
Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
> Hi Michael,
>
> thank you for your reply.
>
> On 28/05/2019 07:19, Michael Ellerman wrote:
>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>
>>> The current version of the multiarch vDSO selftest verifies only
>>> gettimeofday.
>>>
>>> Extend the vDSO selftest to clock_getres, to verify that the
>>> syscall and the vDSO library function return the same information.
>>>
>>> The extension has been used to verify the hrtimer_resoltion fix.
>>
>> This is passing for me even without patch 1 applied, shouldn't it fail
>> without the fix? What am I missing?
>>
>
> This is correct, because during the refactoring process I missed an "n" :)
>
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>
> Should be:
>
> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>
> My mistake, I am going to fix the test and re-post v5 of this set.
>
> Without my patch if you pass "highres=off" to the kernel (as a command line
> parameter) it leads to a broken implementation of clock_getres since the value
> of CLOCK_REALTIME_RES does not change at runtime.
>
> Expected result (with highres=off):
>
> # uname -r
> 5.2.0-rc2
> # ./vdso_clock_getres
> clock_id: CLOCK_REALTIME [FAIL]
> clock_id: CLOCK_BOOTTIME [PASS]
> clock_id: CLOCK_TAI [PASS]
> clock_id: CLOCK_REALTIME_COARSE [PASS]
> clock_id: CLOCK_MONOTONIC [FAIL]
> clock_id: CLOCK_MONOTONIC_RAW [PASS]
> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>
> The reason of this behavior is that the only clocks supported by getres on
> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
> always syscalls.
vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
guess it should fail for them too ?
Or is your test done on vdso32 ?
Christophe
>
>> # uname -r
>> 5.2.0-rc2-gcc-8.2.0
>>
>> # ./vdso_clock_getres
>> clock_id: CLOCK_REALTIME [PASS]
>> clock_id: CLOCK_BOOTTIME [PASS]
>> clock_id: CLOCK_TAI [PASS]
>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>> clock_id: CLOCK_MONOTONIC [PASS]
>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>
>> cheers
>>
>>> Cc: Shuah Khan <shuah@kernel.org>
>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>> ---
>>>
>>> Note: This patch is independent from the others in this series, hence it
>>> can be merged singularly by the kselftest maintainers.
>>>
>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>> 2 files changed, 126 insertions(+)
>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Vincenzo Frascino @ 2019-06-04 13:32 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <5c99721a-ce6b-10a0-99f2-6c37c1da4542@c-s.fr>
Hi Christophe,
On 04/06/2019 14:16, Christophe Leroy wrote:
> Hi Vincenzo
>
> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>> Hi Michael,
>>
>> thank you for your reply.
>>
>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>
>>>> The current version of the multiarch vDSO selftest verifies only
>>>> gettimeofday.
>>>>
>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>> syscall and the vDSO library function return the same information.
>>>>
>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>
>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>> without the fix? What am I missing?
>>>
>>
>> This is correct, because during the refactoring process I missed an "n" :)
>>
>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>
>> Should be:
>>
>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>
>> My mistake, I am going to fix the test and re-post v5 of this set.
>>
>> Without my patch if you pass "highres=off" to the kernel (as a command line
>> parameter) it leads to a broken implementation of clock_getres since the value
>> of CLOCK_REALTIME_RES does not change at runtime.
>>
>> Expected result (with highres=off):
>>
>> # uname -r
>> 5.2.0-rc2
>> # ./vdso_clock_getres
>> clock_id: CLOCK_REALTIME [FAIL]
>> clock_id: CLOCK_BOOTTIME [PASS]
>> clock_id: CLOCK_TAI [PASS]
>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>> clock_id: CLOCK_MONOTONIC [FAIL]
>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>
>> The reason of this behavior is that the only clocks supported by getres on
>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>> always syscalls.
>
> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
> guess it should fail for them too ?
>
> Or is your test done on vdso32 ?
>
Based on what I can see in kernel/vdso64 in 5.2-rc3:
/*
* Exact prototype of clock_getres()
*
* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
*
*/
V_FUNCTION_BEGIN(__kernel_clock_getres)
.cfi_startproc
/* Check for supported clock IDs */
cmpwi cr0,r3,CLOCK_REALTIME
cmpwi cr1,r3,CLOCK_MONOTONIC
cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
li r3,0
cmpldi cr0,r4,0
crclr cr0*4+so
beqlr
lis r5,CLOCK_REALTIME_RES@h
ori r5,r5,CLOCK_REALTIME_RES@l
std r3,TSPC64_TV_SEC(r4)
std r5,TSPC64_TV_NSEC(r4)
blr
/*
* syscall fallback
*/
99:
li r0,__NR_clock_getres
sc
blr
.cfi_endproc
V_FUNCTION_END(__kernel_clock_getres)
it does not seem so for what concerns vdso64. I did run again the test both on
ppc and ppc64 qemu instances and the result is the same to what I reported in
this thread.
Am I missing something?
> Christophe
>
>>
>>> # uname -r
>>> 5.2.0-rc2-gcc-8.2.0
>>>
>>> # ./vdso_clock_getres
>>> clock_id: CLOCK_REALTIME [PASS]
>>> clock_id: CLOCK_BOOTTIME [PASS]
>>> clock_id: CLOCK_TAI [PASS]
>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>> clock_id: CLOCK_MONOTONIC [PASS]
>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>
>>> cheers
>>>
>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>> ---
>>>>
>>>> Note: This patch is independent from the others in this series, hence it
>>>> can be merged singularly by the kselftest maintainers.
>>>>
>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>> 2 files changed, 126 insertions(+)
>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>
--
Regards,
Vincenzo
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Christophe Leroy @ 2019-06-04 13:39 UTC (permalink / raw)
To: Vincenzo Frascino, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <b710d906-edac-f8a7-792b-e6822399187c@arm.com>
Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
> Hi Christophe,
>
> On 04/06/2019 14:16, Christophe Leroy wrote:
>> Hi Vincenzo
>>
>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>> Hi Michael,
>>>
>>> thank you for your reply.
>>>
>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>
>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>> gettimeofday.
>>>>>
>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>> syscall and the vDSO library function return the same information.
>>>>>
>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>
>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>> without the fix? What am I missing?
>>>>
>>>
>>> This is correct, because during the refactoring process I missed an "n" :)
>>>
>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>
>>> Should be:
>>>
>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>
>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>
>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>> parameter) it leads to a broken implementation of clock_getres since the value
>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>
>>> Expected result (with highres=off):
>>>
>>> # uname -r
>>> 5.2.0-rc2
>>> # ./vdso_clock_getres
>>> clock_id: CLOCK_REALTIME [FAIL]
>>> clock_id: CLOCK_BOOTTIME [PASS]
>>> clock_id: CLOCK_TAI [PASS]
>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>
>>> The reason of this behavior is that the only clocks supported by getres on
>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>> always syscalls.
>>
>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>> guess it should fail for them too ?
>>
>> Or is your test done on vdso32 ?
>>
>
> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>
> /*
> * Exact prototype of clock_getres()
> *
> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
> *
> */
> V_FUNCTION_BEGIN(__kernel_clock_getres)
> .cfi_startproc
> /* Check for supported clock IDs */
> cmpwi cr0,r3,CLOCK_REALTIME
> cmpwi cr1,r3,CLOCK_MONOTONIC
> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
> bne cr0,99f
>
> li r3,0
> cmpldi cr0,r4,0
> crclr cr0*4+so
> beqlr
> lis r5,CLOCK_REALTIME_RES@h
> ori r5,r5,CLOCK_REALTIME_RES@l
> std r3,TSPC64_TV_SEC(r4)
> std r5,TSPC64_TV_NSEC(r4)
> blr
>
> /*
> * syscall fallback
> */
> 99:
> li r0,__NR_clock_getres
> sc
> blr
> .cfi_endproc
> V_FUNCTION_END(__kernel_clock_getres)
>
> it does not seem so for what concerns vdso64. I did run again the test both on
> ppc and ppc64 qemu instances and the result is the same to what I reported in
> this thread.
>
> Am I missing something?
I was thinking about
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
but apparently clock_getres() was left aside. Should we do something
about it ?
Christophe
>
>> Christophe
>>
>>>
>>>> # uname -r
>>>> 5.2.0-rc2-gcc-8.2.0
>>>>
>>>> # ./vdso_clock_getres
>>>> clock_id: CLOCK_REALTIME [PASS]
>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>> clock_id: CLOCK_TAI [PASS]
>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>
>>>> cheers
>>>>
>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>> ---
>>>>>
>>>>> Note: This patch is independent from the others in this series, hence it
>>>>> can be merged singularly by the kselftest maintainers.
>>>>>
>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>> 2 files changed, 126 insertions(+)
>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>
>
^ permalink raw reply
* Re: [POWERPC][next-20190603] Boot failure : Kernel BUG at mm/vmalloc.c:470
From: Sachin Sant @ 2019-06-04 13:39 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-mm, linux-next, linuxppc-dev, linux-kernel,
Uladzislau Rezki (Sony)
In-Reply-To: <20190604202918.17a1e466@canb.auug.org.au>
> On 04-Jun-2019, at 3:59 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Sachin,
>
> On Tue, 4 Jun 2019 14:45:43 +0530 Sachin Sant <sachinp@linux.vnet.ibm.com> wrote:
>>
>> While booting linux-next [next-20190603] on a POWER9 LPAR following
>> BUG is encountered and the boot fails.
>>
>> If I revert the following 2 patches I no longer see this BUG message
>>
>> 07031d37b2f9 ( mm/vmalloc.c: switch to WARN_ON() and move it under unlink_va() )
>> 728e0fbf263e ( mm/vmalloc.c: get rid of one single unlink_va() when merge )
>
> This latter patch has been fixed in today's linux-next …
Thanks Stephen.
With today’s next (20190604) I no longer see this issue.
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Vincenzo Frascino @ 2019-06-04 13:43 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <dd8bf915-f438-74f0-494e-427d10fc0505@c-s.fr>
On 04/06/2019 14:39, Christophe Leroy wrote:
>
>
> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
>> Hi Christophe,
>>
>> On 04/06/2019 14:16, Christophe Leroy wrote:
>>> Hi Vincenzo
>>>
>>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>>> Hi Michael,
>>>>
>>>> thank you for your reply.
>>>>
>>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>>
>>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>>> gettimeofday.
>>>>>>
>>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>>> syscall and the vDSO library function return the same information.
>>>>>>
>>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>>
>>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>>> without the fix? What am I missing?
>>>>>
>>>>
>>>> This is correct, because during the refactoring process I missed an "n" :)
>>>>
>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>>
>>>> Should be:
>>>>
>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>>
>>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>>
>>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>>> parameter) it leads to a broken implementation of clock_getres since the value
>>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>>
>>>> Expected result (with highres=off):
>>>>
>>>> # uname -r
>>>> 5.2.0-rc2
>>>> # ./vdso_clock_getres
>>>> clock_id: CLOCK_REALTIME [FAIL]
>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>> clock_id: CLOCK_TAI [PASS]
>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>
>>>> The reason of this behavior is that the only clocks supported by getres on
>>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>>> always syscalls.
>>>
>>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>>> guess it should fail for them too ?
>>>
>>> Or is your test done on vdso32 ?
>>>
>>
>> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>>
>> /*
>> * Exact prototype of clock_getres()
>> *
>> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
>> *
>> */
>> V_FUNCTION_BEGIN(__kernel_clock_getres)
>> .cfi_startproc
>> /* Check for supported clock IDs */
>> cmpwi cr0,r3,CLOCK_REALTIME
>> cmpwi cr1,r3,CLOCK_MONOTONIC
>> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
>> bne cr0,99f
>>
>> li r3,0
>> cmpldi cr0,r4,0
>> crclr cr0*4+so
>> beqlr
>> lis r5,CLOCK_REALTIME_RES@h
>> ori r5,r5,CLOCK_REALTIME_RES@l
>> std r3,TSPC64_TV_SEC(r4)
>> std r5,TSPC64_TV_NSEC(r4)
>> blr
>>
>> /*
>> * syscall fallback
>> */
>> 99:
>> li r0,__NR_clock_getres
>> sc
>> blr
>> .cfi_endproc
>> V_FUNCTION_END(__kernel_clock_getres)
>>
>> it does not seem so for what concerns vdso64. I did run again the test both on
>> ppc and ppc64 qemu instances and the result is the same to what I reported in
>> this thread.
>>
>> Am I missing something?
>
> I was thinking about
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
> but apparently clock_getres() was left aside. Should we do something
> about it ?
>
Sure, but I would like this series to be merged first (since the topic is
different). I am happy, after that, to push a separate one on top that addresses
the problem.
Please let me know if it works for you and Michael.
> Christophe
>
>>
>>> Christophe
>>>
>>>>
>>>>> # uname -r
>>>>> 5.2.0-rc2-gcc-8.2.0
>>>>>
>>>>> # ./vdso_clock_getres
>>>>> clock_id: CLOCK_REALTIME [PASS]
>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>> clock_id: CLOCK_TAI [PASS]
>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>
>>>>> cheers
>>>>>
>>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>>> ---
>>>>>>
>>>>>> Note: This patch is independent from the others in this series, hence it
>>>>>> can be merged singularly by the kselftest maintainers.
>>>>>>
>>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>>> 2 files changed, 126 insertions(+)
>>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>>
>>
--
Regards,
Vincenzo
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Christophe Leroy @ 2019-06-04 13:52 UTC (permalink / raw)
To: Vincenzo Frascino, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <eacdc960-c344-9f9f-7f1b-ad770cb4a725@arm.com>
Le 04/06/2019 à 15:43, Vincenzo Frascino a écrit :
> On 04/06/2019 14:39, Christophe Leroy wrote:
>>
>>
>> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
>>> Hi Christophe,
>>>
>>> On 04/06/2019 14:16, Christophe Leroy wrote:
>>>> Hi Vincenzo
>>>>
>>>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>>>> Hi Michael,
>>>>>
>>>>> thank you for your reply.
>>>>>
>>>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>>>
>>>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>>>> gettimeofday.
>>>>>>>
>>>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>>>> syscall and the vDSO library function return the same information.
>>>>>>>
>>>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>>>
>>>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>>>> without the fix? What am I missing?
>>>>>>
>>>>>
>>>>> This is correct, because during the refactoring process I missed an "n" :)
>>>>>
>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>>>
>>>>> Should be:
>>>>>
>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>>>
>>>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>>>
>>>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>>>> parameter) it leads to a broken implementation of clock_getres since the value
>>>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>>>
>>>>> Expected result (with highres=off):
>>>>>
>>>>> # uname -r
>>>>> 5.2.0-rc2
>>>>> # ./vdso_clock_getres
>>>>> clock_id: CLOCK_REALTIME [FAIL]
>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>> clock_id: CLOCK_TAI [PASS]
>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>
>>>>> The reason of this behavior is that the only clocks supported by getres on
>>>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>>>> always syscalls.
>>>>
>>>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>>>> guess it should fail for them too ?
>>>>
>>>> Or is your test done on vdso32 ?
>>>>
>>>
>>> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>>>
>>> /*
>>> * Exact prototype of clock_getres()
>>> *
>>> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
>>> *
>>> */
>>> V_FUNCTION_BEGIN(__kernel_clock_getres)
>>> .cfi_startproc
>>> /* Check for supported clock IDs */
>>> cmpwi cr0,r3,CLOCK_REALTIME
>>> cmpwi cr1,r3,CLOCK_MONOTONIC
>>> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
>>> bne cr0,99f
>>>
>>> li r3,0
>>> cmpldi cr0,r4,0
>>> crclr cr0*4+so
>>> beqlr
>>> lis r5,CLOCK_REALTIME_RES@h
>>> ori r5,r5,CLOCK_REALTIME_RES@l
>>> std r3,TSPC64_TV_SEC(r4)
>>> std r5,TSPC64_TV_NSEC(r4)
>>> blr
>>>
>>> /*
>>> * syscall fallback
>>> */
>>> 99:
>>> li r0,__NR_clock_getres
>>> sc
>>> blr
>>> .cfi_endproc
>>> V_FUNCTION_END(__kernel_clock_getres)
>>>
>>> it does not seem so for what concerns vdso64. I did run again the test both on
>>> ppc and ppc64 qemu instances and the result is the same to what I reported in
>>> this thread.
>>>
>>> Am I missing something?
>>
>> I was thinking about
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
>> but apparently clock_getres() was left aside. Should we do something
>> about it ?
>>
>
> Sure, but I would like this series to be merged first (since the topic is
> different). I am happy, after that, to push a separate one on top that addresses
> the problem.
>
> Please let me know if it works for you and Michael.
No problem for myself.
By the way, next time (or next spin ?) I recommend you to handle your
patches independently and not as a series since they are all
independant. It would have avoided confusion and the need for you to
resend all 3 patches everytime you did a change in one of them.
Christophe
>
>> Christophe
>>
>>>
>>>> Christophe
>>>>
>>>>>
>>>>>> # uname -r
>>>>>> 5.2.0-rc2-gcc-8.2.0
>>>>>>
>>>>>> # ./vdso_clock_getres
>>>>>> clock_id: CLOCK_REALTIME [PASS]
>>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>>> clock_id: CLOCK_TAI [PASS]
>>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>>>> ---
>>>>>>>
>>>>>>> Note: This patch is independent from the others in this series, hence it
>>>>>>> can be merged singularly by the kselftest maintainers.
>>>>>>>
>>>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>>>> 2 files changed, 126 insertions(+)
>>>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>>>
>>>
>
^ permalink raw reply
* [PATCH v2 06/22] docs: mark orphan documents as such
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Maxime Ripard, dri-devel, platform-driver-x86, Paul Mackerras,
Mauro Carvalho Chehab, linux-stm32, Alexandre Torgue,
Jonathan Corbet, David Airlie, Andrew Donnellan, linux-pm,
Maarten Lankhorst, Matan Ziv-Av, Mauro Carvalho Chehab,
Daniel Vetter, Sean Paul, linux-arm-kernel, linux-kernel,
Maxime Coquelin, Frederic Barrat, linuxppc-dev, Georgi Djakov
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
Sphinx doesn't like orphan documents:
Documentation/accelerators/ocxl.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32f429-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32f746-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32f769-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32h743-overview.rst: WARNING: document isn't included in any toctree
Documentation/arm/stm32/stm32mp157-overview.rst: WARNING: document isn't included in any toctree
Documentation/gpu/msm-crash-dump.rst: WARNING: document isn't included in any toctree
Documentation/interconnect/interconnect.rst: WARNING: document isn't included in any toctree
Documentation/laptops/lg-laptop.rst: WARNING: document isn't included in any toctree
Documentation/powerpc/isa-versions.rst: WARNING: document isn't included in any toctree
Documentation/virtual/kvm/amd-memory-encryption.rst: WARNING: document isn't included in any toctree
Documentation/virtual/kvm/vcpu-requests.rst: WARNING: document isn't included in any toctree
So, while they aren't on any toctree, add :orphan: to them, in order
to silent this warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/accelerators/ocxl.rst | 2 ++
Documentation/arm/stm32/overview.rst | 2 ++
Documentation/arm/stm32/stm32f429-overview.rst | 2 ++
Documentation/arm/stm32/stm32f746-overview.rst | 2 ++
Documentation/arm/stm32/stm32f769-overview.rst | 2 ++
Documentation/arm/stm32/stm32h743-overview.rst | 2 ++
Documentation/arm/stm32/stm32mp157-overview.rst | 2 ++
Documentation/gpu/msm-crash-dump.rst | 2 ++
Documentation/interconnect/interconnect.rst | 2 ++
Documentation/laptops/lg-laptop.rst | 2 ++
Documentation/powerpc/isa-versions.rst | 2 ++
11 files changed, 22 insertions(+)
diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst
index 14cefc020e2d..b1cea19a90f5 100644
--- a/Documentation/accelerators/ocxl.rst
+++ b/Documentation/accelerators/ocxl.rst
@@ -1,3 +1,5 @@
+:orphan:
+
========================================================
OpenCAPI (Open Coherent Accelerator Processor Interface)
========================================================
diff --git a/Documentation/arm/stm32/overview.rst b/Documentation/arm/stm32/overview.rst
index 85cfc8410798..f7e734153860 100644
--- a/Documentation/arm/stm32/overview.rst
+++ b/Documentation/arm/stm32/overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
========================
STM32 ARM Linux Overview
========================
diff --git a/Documentation/arm/stm32/stm32f429-overview.rst b/Documentation/arm/stm32/stm32f429-overview.rst
index 18feda97f483..65bbb1c3b423 100644
--- a/Documentation/arm/stm32/stm32f429-overview.rst
+++ b/Documentation/arm/stm32/stm32f429-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32F429 Overview
==================
diff --git a/Documentation/arm/stm32/stm32f746-overview.rst b/Documentation/arm/stm32/stm32f746-overview.rst
index b5f4b6ce7656..42d593085015 100644
--- a/Documentation/arm/stm32/stm32f746-overview.rst
+++ b/Documentation/arm/stm32/stm32f746-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32F746 Overview
==================
diff --git a/Documentation/arm/stm32/stm32f769-overview.rst b/Documentation/arm/stm32/stm32f769-overview.rst
index 228656ced2fe..f6adac862b17 100644
--- a/Documentation/arm/stm32/stm32f769-overview.rst
+++ b/Documentation/arm/stm32/stm32f769-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32F769 Overview
==================
diff --git a/Documentation/arm/stm32/stm32h743-overview.rst b/Documentation/arm/stm32/stm32h743-overview.rst
index 3458dc00095d..c525835e7473 100644
--- a/Documentation/arm/stm32/stm32h743-overview.rst
+++ b/Documentation/arm/stm32/stm32h743-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32H743 Overview
==================
diff --git a/Documentation/arm/stm32/stm32mp157-overview.rst b/Documentation/arm/stm32/stm32mp157-overview.rst
index 62e176d47ca7..2c52cd020601 100644
--- a/Documentation/arm/stm32/stm32mp157-overview.rst
+++ b/Documentation/arm/stm32/stm32mp157-overview.rst
@@ -1,3 +1,5 @@
+:orphan:
+
STM32MP157 Overview
===================
diff --git a/Documentation/gpu/msm-crash-dump.rst b/Documentation/gpu/msm-crash-dump.rst
index 757cd257e0d8..240ef200f76c 100644
--- a/Documentation/gpu/msm-crash-dump.rst
+++ b/Documentation/gpu/msm-crash-dump.rst
@@ -1,3 +1,5 @@
+:orphan:
+
=====================
MSM Crash Dump Format
=====================
diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst
index c3e004893796..56e331dab70e 100644
--- a/Documentation/interconnect/interconnect.rst
+++ b/Documentation/interconnect/interconnect.rst
@@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
+:orphan:
+
=====================================
GENERIC SYSTEM INTERCONNECT SUBSYSTEM
=====================================
diff --git a/Documentation/laptops/lg-laptop.rst b/Documentation/laptops/lg-laptop.rst
index aa503ee9b3bc..f2c2ffe31101 100644
--- a/Documentation/laptops/lg-laptop.rst
+++ b/Documentation/laptops/lg-laptop.rst
@@ -1,5 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0+
+:orphan:
+
LG Gram laptop extra features
=============================
diff --git a/Documentation/powerpc/isa-versions.rst b/Documentation/powerpc/isa-versions.rst
index 812e20cc898c..66c24140ebf1 100644
--- a/Documentation/powerpc/isa-versions.rst
+++ b/Documentation/powerpc/isa-versions.rst
@@ -1,3 +1,5 @@
+:orphan:
+
CPU to ISA Version Mapping
==========================
--
2.21.0
^ permalink raw reply related
* [PATCH v2 18/22] docs: move protection-keys.rst to the core-api book
From: Mauro Carvalho Chehab @ 2019-06-04 14:17 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Michal Hocko, Dave Hansen, Paul Mackerras, linux-kselftest,
H. Peter Anvin, Mauro Carvalho Chehab, Shuah Khan,
Jonathan Corbet, x86, Matthew Wilcox, Ingo Molnar,
Kent Overstreet, Arnd Bergmann, Jonathan Neuschäfer,
Mauro Carvalho Chehab, Mike Rapoport, Borislav Petkov,
Thomas Gleixner, Randy Dunlap, linux-kernel, Changbin Du,
Andrew Morton, linuxppc-dev
In-Reply-To: <cover.1559656538.git.mchehab+samsung@kernel.org>
This document is used by multiple architectures:
$ echo $(git grep -l pkey_mprotect arch|cut -d'/' -f 2|sort|uniq)
alpha arm arm64 ia64 m68k microblaze mips parisc powerpc s390 sh sparc x86 xtensa
So, let's move it to the core book and adjust the links to it
accordingly.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/core-api/index.rst | 1 +
Documentation/{x86 => core-api}/protection-keys.rst | 0
Documentation/x86/index.rst | 1 -
arch/powerpc/Kconfig | 2 +-
arch/x86/Kconfig | 2 +-
tools/testing/selftests/x86/protection_keys.c | 2 +-
6 files changed, 4 insertions(+), 4 deletions(-)
rename Documentation/{x86 => core-api}/protection-keys.rst (100%)
diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst
index ee1bb8983a88..2466a4c51031 100644
--- a/Documentation/core-api/index.rst
+++ b/Documentation/core-api/index.rst
@@ -34,6 +34,7 @@ Core utilities
timekeeping
boot-time-mm
memory-hotplug
+ protection-keys
Interfaces for kernel debugging
diff --git a/Documentation/x86/protection-keys.rst b/Documentation/core-api/protection-keys.rst
similarity index 100%
rename from Documentation/x86/protection-keys.rst
rename to Documentation/core-api/protection-keys.rst
diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index ae36fc5fc649..f2de1b2d3ac7 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -19,7 +19,6 @@ x86-specific Documentation
tlb
mtrr
pat
- protection-keys
intel_mpx
amd-memory-encryption
pti
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1120ff8ac715..e437aa3e78b4 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -898,7 +898,7 @@ config PPC_MEM_KEYS
page-based protections, but without requiring modification of the
page tables when an application changes protection domains.
- For details, see Documentation/vm/protection-keys.rst
+ For details, see Documentation/core-api/protection-keys.rst
If unsure, say y.
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 23de3b9da480..61244bdb886f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1911,7 +1911,7 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
page-based protections, but without requiring modification of the
page tables when an application changes protection domains.
- For details, see Documentation/x86/protection-keys.txt
+ For details, see Documentation/core-api/protection-keys.rst
If unsure, say y.
diff --git a/tools/testing/selftests/x86/protection_keys.c b/tools/testing/selftests/x86/protection_keys.c
index 5d546dcdbc80..480995bceefa 100644
--- a/tools/testing/selftests/x86/protection_keys.c
+++ b/tools/testing/selftests/x86/protection_keys.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Tests x86 Memory Protection Keys (see Documentation/x86/protection-keys.txt)
+ * Tests x86 Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
*
* There are examples in here of:
* * how to set protection keys on memory
--
2.21.0
^ permalink raw reply related
* Re: [POWERPC][next-20190603] Boot failure : Kernel BUG at mm/vmalloc.c:470
From: Stephen Rothwell @ 2019-06-04 14:20 UTC (permalink / raw)
To: Sachin Sant
Cc: linux-mm, linux-next, linuxppc-dev, linux-kernel,
Uladzislau Rezki (Sony)
In-Reply-To: <88ADCAAE-4F1A-49FE-A454-BBAB12A88C70@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 232 bytes --]
Hi Sachin,
On Tue, 4 Jun 2019 19:09:26 +0530 Sachin Sant <sachinp@linux.vnet.ibm.com> wrote:
>
> With today’s next (20190604) I no longer see this issue.
Excellent, thanks for verifying.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/3] kselftest: Extend vDSO selftest to clock_getres
From: Vincenzo Frascino @ 2019-06-04 14:21 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, linux-arch, linuxppc-dev,
linux-s390, linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Paul Mackerras, Martin Schwidefsky,
Thomas Gleixner, Shuah Khan
In-Reply-To: <2389b7f2-288b-215e-994a-3b24be08e125@c-s.fr>
On 04/06/2019 14:52, Christophe Leroy wrote:
>
>
> Le 04/06/2019 à 15:43, Vincenzo Frascino a écrit :
>> On 04/06/2019 14:39, Christophe Leroy wrote:
>>>
>>>
>>> Le 04/06/2019 à 15:32, Vincenzo Frascino a écrit :
>>>> Hi Christophe,
>>>>
>>>> On 04/06/2019 14:16, Christophe Leroy wrote:
>>>>> Hi Vincenzo
>>>>>
>>>>> Le 28/05/2019 à 13:57, Vincenzo Frascino a écrit :
>>>>>> Hi Michael,
>>>>>>
>>>>>> thank you for your reply.
>>>>>>
>>>>>> On 28/05/2019 07:19, Michael Ellerman wrote:
>>>>>>> Vincenzo Frascino <vincenzo.frascino@arm.com> writes:
>>>>>>>
>>>>>>>> The current version of the multiarch vDSO selftest verifies only
>>>>>>>> gettimeofday.
>>>>>>>>
>>>>>>>> Extend the vDSO selftest to clock_getres, to verify that the
>>>>>>>> syscall and the vDSO library function return the same information.
>>>>>>>>
>>>>>>>> The extension has been used to verify the hrtimer_resoltion fix.
>>>>>>>
>>>>>>> This is passing for me even without patch 1 applied, shouldn't it fail
>>>>>>> without the fix? What am I missing?
>>>>>>>
>>>>>>
>>>>>> This is correct, because during the refactoring process I missed an "n" :)
>>>>>>
>>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_sec·!=·y.tv_sec))
>>>>>>
>>>>>> Should be:
>>>>>>
>>>>>> if·((x.tv_sec·!=·y.tv_sec)·||·(x.tv_nsec·!=·y.tv_nsec))
>>>>>>
>>>>>> My mistake, I am going to fix the test and re-post v5 of this set.
>>>>>>
>>>>>> Without my patch if you pass "highres=off" to the kernel (as a command line
>>>>>> parameter) it leads to a broken implementation of clock_getres since the value
>>>>>> of CLOCK_REALTIME_RES does not change at runtime.
>>>>>>
>>>>>> Expected result (with highres=off):
>>>>>>
>>>>>> # uname -r
>>>>>> 5.2.0-rc2
>>>>>> # ./vdso_clock_getres
>>>>>> clock_id: CLOCK_REALTIME [FAIL]
>>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>>> clock_id: CLOCK_TAI [PASS]
>>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC [FAIL]
>>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>>
>>>>>> The reason of this behavior is that the only clocks supported by getres on
>>>>>> powerpc are CLOCK_REALTIME and CLOCK_MONOTONIC, the rest on the clocks use
>>>>>> always syscalls.
>>>>>
>>>>> vdso64 is supposed to implement CLOCK_{REALTIME/MONOTONIC}_COARSE, so I
>>>>> guess it should fail for them too ?
>>>>>
>>>>> Or is your test done on vdso32 ?
>>>>>
>>>>
>>>> Based on what I can see in kernel/vdso64 in 5.2-rc3:
>>>>
>>>> /*
>>>> * Exact prototype of clock_getres()
>>>> *
>>>> * int __kernel_clock_getres(clockid_t clock_id, struct timespec *res);
>>>> *
>>>> */
>>>> V_FUNCTION_BEGIN(__kernel_clock_getres)
>>>> .cfi_startproc
>>>> /* Check for supported clock IDs */
>>>> cmpwi cr0,r3,CLOCK_REALTIME
>>>> cmpwi cr1,r3,CLOCK_MONOTONIC
>>>> cror cr0*4+eq,cr0*4+eq,cr1*4+eq
>>>> bne cr0,99f
>>>>
>>>> li r3,0
>>>> cmpldi cr0,r4,0
>>>> crclr cr0*4+so
>>>> beqlr
>>>> lis r5,CLOCK_REALTIME_RES@h
>>>> ori r5,r5,CLOCK_REALTIME_RES@l
>>>> std r3,TSPC64_TV_SEC(r4)
>>>> std r5,TSPC64_TV_NSEC(r4)
>>>> blr
>>>>
>>>> /*
>>>> * syscall fallback
>>>> */
>>>> 99:
>>>> li r0,__NR_clock_getres
>>>> sc
>>>> blr
>>>> .cfi_endproc
>>>> V_FUNCTION_END(__kernel_clock_getres)
>>>>
>>>> it does not seem so for what concerns vdso64. I did run again the test both on
>>>> ppc and ppc64 qemu instances and the result is the same to what I reported in
>>>> this thread.
>>>>
>>>> Am I missing something?
>>>
>>> I was thinking about
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5c929885f1bb
>>> but apparently clock_getres() was left aside. Should we do something
>>> about it ?
>>>
>>
>> Sure, but I would like this series to be merged first (since the topic is
>> different). I am happy, after that, to push a separate one on top that addresses
>> the problem.
>>
>> Please let me know if it works for you and Michael.
>
> No problem for myself.
>
> By the way, next time (or next spin ?) I recommend you to handle your
> patches independently and not as a series since they are all
> independant. It would have avoided confusion and the need for you to
> resend all 3 patches everytime you did a change in one of them.
>
Thanks for the advise, I will do next time.
> Christophe
>
>>
>>> Christophe
>>>
>>>>
>>>>> Christophe
>>>>>
>>>>>>
>>>>>>> # uname -r
>>>>>>> 5.2.0-rc2-gcc-8.2.0
>>>>>>>
>>>>>>> # ./vdso_clock_getres
>>>>>>> clock_id: CLOCK_REALTIME [PASS]
>>>>>>> clock_id: CLOCK_BOOTTIME [PASS]
>>>>>>> clock_id: CLOCK_TAI [PASS]
>>>>>>> clock_id: CLOCK_REALTIME_COARSE [PASS]
>>>>>>> clock_id: CLOCK_MONOTONIC [PASS]
>>>>>>> clock_id: CLOCK_MONOTONIC_RAW [PASS]
>>>>>>> clock_id: CLOCK_MONOTONIC_COARSE [PASS]
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>>> Cc: Shuah Khan <shuah@kernel.org>
>>>>>>>> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Note: This patch is independent from the others in this series, hence it
>>>>>>>> can be merged singularly by the kselftest maintainers.
>>>>>>>>
>>>>>>>> tools/testing/selftests/vDSO/Makefile | 2 +
>>>>>>>> .../selftests/vDSO/vdso_clock_getres.c | 124 ++++++++++++++++++
>>>>>>>> 2 files changed, 126 insertions(+)
>>>>>>>> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
>>>>>>
>>>>
>>
--
Regards,
Vincenzo
^ permalink raw reply
* Re: [PATCH v3 14/16] powerpc/32: implement fast entry for syscalls on BOOKE
From: Christophe Leroy @ 2019-06-04 16:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, Nicholas Piggin
In-Reply-To: <20190523061427.GA19655@blackberry>
Paul,
Le 23/05/2019 à 08:14, Paul Mackerras a écrit :
> On Tue, Apr 30, 2019 at 12:39:03PM +0000, Christophe Leroy wrote:
>> This patch implements a fast entry for syscalls.
>>
>> Syscalls don't have to preserve non volatile registers except LR.
>>
>> This patch then implement a fast entry for syscalls, where
>> volatile registers get clobbered.
>>
>> As this entry is dedicated to syscall it always sets MSR_EE
>> and warns in case MSR_EE was previously off
>>
>> It also assumes that the call is always from user, system calls are
>> unexpected from kernel.
>
> This is now upstream as commit 1a4b739bbb4f. On the e500mc test
> config that I use, I'm getting this build failure:
>
> arch/powerpc/kernel/head_fsl_booke.o: In function `SystemCall':
> arch/powerpc/kernel/head_fsl_booke.S:416: undefined reference to `kvmppc_handler_BOOKE_INTERRUPT_SYSCALL_SPRN_SRR1'
> Makefile:1052: recipe for target 'vmlinux' failed
Does my patch (https://patchwork.ozlabs.org/patch/1103909/) fixes the
issue for you ?
Thanks
Christophe
>
>> +.macro SYSCALL_ENTRY trapno intno
>> + mfspr r10, SPRN_SPRG_THREAD
>> +#ifdef CONFIG_KVM_BOOKE_HV
>> +BEGIN_FTR_SECTION
>> + mtspr SPRN_SPRG_WSCRATCH0, r10
>> + stw r11, THREAD_NORMSAVE(0)(r10)
>> + stw r13, THREAD_NORMSAVE(2)(r10)
>> + mfcr r13 /* save CR in r13 for now */
>> + mfspr r11, SPRN_SRR1
>> + mtocrf 0x80, r11 /* check MSR[GS] without clobbering reg */
>> + bf 3, 1975f
>> + b kvmppc_handler_BOOKE_INTERRUPT_\intno\()_SPRN_SRR1
>
> It seems to me that the "_SPRN_SRR1" on the end of this line
> isn't meant to be there... However, it still fails to link with that
> removed.
>
> Paul.
>
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/pseries: Simplify cpu readd to use drc_index
From: Nathan Lynch @ 2019-06-04 17:21 UTC (permalink / raw)
To: Tyrel Datwyler; +Cc: mingming.cao, linuxppc-dev
In-Reply-To: <69336ea3-7937-17cc-8082-d4ad782d7e8c@linux.vnet.ibm.com>
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> writes:
> On 05/20/2019 08:01 AM, Nathan Lynch wrote:
>> Kernel implementation details aside, how do you change the cpu-node
>> relationship at runtime without breaking NUMA-aware applications? Is
>> this not a fundamental issue to address before adding code like this?
>>
>
> If that is the concern then hotplug in general already breaks
> them. Take for example the removal of a faulty processor and then
> adding a new processor back. It is quite possible that the new
> processor is in a different NUMA node. Keep in mind that in this
> scenario the new processor and threads gets the same logical cpu ids
> as the faulty processor we just removed.
Yes, the problem is re-use of a logical CPU id with a node id that
differs from the one it was initially assigned, and there are several
ways to get into that situation on this platform. We probably need to be
more careful in how we allocate a spot in the CPU maps for a newly-added
processor. I believe the algorithm is simple first-fit right now, and it
doesn't take into account prior NUMA relationships.
> Now we have to ask the question who is right and who is wrong. In this
> case the kernel data structures reflect the correct NUMA
> topology. However, did the NUMA aware application or libnuma make an
> assumption that specific sets of logical cpu ids are always in the
> same NUMA node?
Yes, and that assumption is widespread because people tend to develop on
an architecture where this kind of stuff doesn't happen (at least not
yet).
And I don't really agree that the current behavior reflects what is
actually going on. When Linux running in a PowerVM LPAR receives a
notification to change the NUMA properties of a processor at runtime,
it's because the platform has changed the physical characteristics of
the partition. I.e. you're now using a different physical processor,
with different relationships to the other resources in the system. Even
if it didn't destabilize the kernel (by changing the result of
cpu_to_node() when various subsystems assume it will be static),
continuing to use the logical CPU ids on the new processor obscures what
has actually happened. And we have developers that have told us that
this behavior - changing the logical cpu<->node relationship at runtime
- is something their existing NUMA-aware applications cannot handle.
^ permalink raw reply
* Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation
From: Robin Murphy @ 2019-06-04 17:36 UTC (permalink / raw)
To: David Hildenbrand, Wei Yang
Cc: Mark Rutland, linux-s390, linux-ia64, Yu Zhao, Anshuman Khandual,
linux-sh, Catalin Marinas, Ard Biesheuvel, Will Deacon,
linux-kernel, Mike Rapoport, Jun Yao, linux-mm, Chintan Pandya,
Igor Mammedov, akpm, linuxppc-dev, Dan Williams, linux-arm-kernel
In-Reply-To: <5059f68d-45d2-784e-0770-ee67060773c7@redhat.com>
On 04/06/2019 07:56, David Hildenbrand wrote:
> On 03.06.19 23:41, Wei Yang wrote:
>> On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote:
>>> A proper arch_remove_memory() implementation is on its way, which also
>>> cleanly removes page tables in arch_add_memory() in case something goes
>>> wrong.
>>
>> Would this be better to understand?
>>
>> removes page tables created in arch_add_memory
>
> That's not what this sentence expresses. Have a look at
> arch_add_memory(), in case __add_pages() fails, the page tables are not
> removed. This will also be fixed by Anshuman in the same shot.
>
>>
>>>
>>> As we want to use arch_remove_memory() in case something goes wrong
>>> during memory hotplug after arch_add_memory() finished, let's add
>>> a temporary hack that is sufficient enough until we get a proper
>>> implementation that cleans up page table entries.
>>>
>>> We will remove CONFIG_MEMORY_HOTREMOVE around this code in follow up
>>> patches.
>>>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> Cc: Chintan Pandya <cpandya@codeaurora.org>
>>> Cc: Mike Rapoport <rppt@linux.ibm.com>
>>> Cc: Jun Yao <yaojun8558363@gmail.com>
>>> Cc: Yu Zhao <yuzhao@google.com>
>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>> ---
>>> arch/arm64/mm/mmu.c | 19 +++++++++++++++++++
>>> 1 file changed, 19 insertions(+)
>>>
>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>>> index a1bfc4413982..e569a543c384 100644
>>> --- a/arch/arm64/mm/mmu.c
>>> +++ b/arch/arm64/mm/mmu.c
>>> @@ -1084,4 +1084,23 @@ int arch_add_memory(int nid, u64 start, u64 size,
>>> return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
>>> restrictions);
>>> }
>>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>>> +void arch_remove_memory(int nid, u64 start, u64 size,
>>> + struct vmem_altmap *altmap)
>>> +{
>>> + unsigned long start_pfn = start >> PAGE_SHIFT;
>>> + unsigned long nr_pages = size >> PAGE_SHIFT;
>>> + struct zone *zone;
>>> +
>>> + /*
>>> + * FIXME: Cleanup page tables (also in arch_add_memory() in case
>>> + * adding fails). Until then, this function should only be used
>>> + * during memory hotplug (adding memory), not for memory
>>> + * unplug. ARCH_ENABLE_MEMORY_HOTREMOVE must not be
>>> + * unlocked yet.
>>> + */
>>> + zone = page_zone(pfn_to_page(start_pfn));
>>
>> Compared with arch_remove_memory in x86. If altmap is not NULL, zone will be
>> retrieved from page related to altmap. Not sure why this is not the same?
>
> This is a minimal implementation, sufficient for this use case here. A
> full implementation is in the works. For now, this function will not be
> used with an altmap (ZONE_DEVICE is not esupported for arm64 yet).
FWIW the other pieces of ZONE_DEVICE are now due to land in parallel,
but as long as we don't throw the ARCH_ENABLE_MEMORY_HOTREMOVE switch
then there should still be no issue. Besides, given that we should
consistently ignore the altmap everywhere at the moment, it may even
work out regardless.
One thing stands out about the failure path thing, though - if
__add_pages() did fail, can it still be guaranteed to have initialised
the memmap such that page_zone() won't return nonsense? Last time I
looked that was still a problem when removing memory which had been
successfully added, but never onlined (although I do know that
particular case was already being discussed at the time, and I've not
been paying the greatest attention since).
Robin.
^ permalink raw reply
* Re: [PATCH v3 04/11] arm64/mm: Add temporary arch_remove_memory() implementation
From: David Hildenbrand @ 2019-06-04 17:51 UTC (permalink / raw)
To: Robin Murphy, Wei Yang
Cc: Mark Rutland, linux-s390, linux-ia64, Yu Zhao, Anshuman Khandual,
linux-sh, Catalin Marinas, Ard Biesheuvel, Will Deacon,
linux-kernel, Mike Rapoport, Jun Yao, linux-mm, Chintan Pandya,
Igor Mammedov, akpm, linuxppc-dev, Dan Williams, linux-arm-kernel
In-Reply-To: <7a5b8c8d-f1bb-9c7e-9809-405af374fecd@arm.com>
On 04.06.19 19:36, Robin Murphy wrote:
> On 04/06/2019 07:56, David Hildenbrand wrote:
>> On 03.06.19 23:41, Wei Yang wrote:
>>> On Mon, May 27, 2019 at 01:11:45PM +0200, David Hildenbrand wrote:
>>>> A proper arch_remove_memory() implementation is on its way, which also
>>>> cleanly removes page tables in arch_add_memory() in case something goes
>>>> wrong.
>>>
>>> Would this be better to understand?
>>>
>>> removes page tables created in arch_add_memory
>>
>> That's not what this sentence expresses. Have a look at
>> arch_add_memory(), in case __add_pages() fails, the page tables are not
>> removed. This will also be fixed by Anshuman in the same shot.
>>
>>>
>>>>
>>>> As we want to use arch_remove_memory() in case something goes wrong
>>>> during memory hotplug after arch_add_memory() finished, let's add
>>>> a temporary hack that is sufficient enough until we get a proper
>>>> implementation that cleans up page table entries.
>>>>
>>>> We will remove CONFIG_MEMORY_HOTREMOVE around this code in follow up
>>>> patches.
>>>>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Will Deacon <will.deacon@arm.com>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>>> Cc: Chintan Pandya <cpandya@codeaurora.org>
>>>> Cc: Mike Rapoport <rppt@linux.ibm.com>
>>>> Cc: Jun Yao <yaojun8558363@gmail.com>
>>>> Cc: Yu Zhao <yuzhao@google.com>
>>>> Cc: Robin Murphy <robin.murphy@arm.com>
>>>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>> arch/arm64/mm/mmu.c | 19 +++++++++++++++++++
>>>> 1 file changed, 19 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>>>> index a1bfc4413982..e569a543c384 100644
>>>> --- a/arch/arm64/mm/mmu.c
>>>> +++ b/arch/arm64/mm/mmu.c
>>>> @@ -1084,4 +1084,23 @@ int arch_add_memory(int nid, u64 start, u64 size,
>>>> return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
>>>> restrictions);
>>>> }
>>>> +#ifdef CONFIG_MEMORY_HOTREMOVE
>>>> +void arch_remove_memory(int nid, u64 start, u64 size,
>>>> + struct vmem_altmap *altmap)
>>>> +{
>>>> + unsigned long start_pfn = start >> PAGE_SHIFT;
>>>> + unsigned long nr_pages = size >> PAGE_SHIFT;
>>>> + struct zone *zone;
>>>> +
>>>> + /*
>>>> + * FIXME: Cleanup page tables (also in arch_add_memory() in case
>>>> + * adding fails). Until then, this function should only be used
>>>> + * during memory hotplug (adding memory), not for memory
>>>> + * unplug. ARCH_ENABLE_MEMORY_HOTREMOVE must not be
>>>> + * unlocked yet.
>>>> + */
>>>> + zone = page_zone(pfn_to_page(start_pfn));
>>>
>>> Compared with arch_remove_memory in x86. If altmap is not NULL, zone will be
>>> retrieved from page related to altmap. Not sure why this is not the same?
>>
>> This is a minimal implementation, sufficient for this use case here. A
>> full implementation is in the works. For now, this function will not be
>> used with an altmap (ZONE_DEVICE is not esupported for arm64 yet).
>
> FWIW the other pieces of ZONE_DEVICE are now due to land in parallel,
> but as long as we don't throw the ARCH_ENABLE_MEMORY_HOTREMOVE switch
> then there should still be no issue. Besides, given that we should
> consistently ignore the altmap everywhere at the moment, it may even
> work out regardless.
Thanks for the info.
>
> One thing stands out about the failure path thing, though - if
> __add_pages() did fail, can it still be guaranteed to have initialised
> the memmap such that page_zone() won't return nonsense? Last time I
if __add_pages() fails, then arch_add_memory() fails and
arch_remove_memory() will not be called in the context of this series.
Only if it succeeded.
> looked that was still a problem when removing memory which had been
> successfully added, but never onlined (although I do know that
> particular case was already being discussed at the time, and I've not
> been paying the greatest attention since).
Yes, that part is next on my list. It works but is ugly. The memory
removal process should not care about zones at all.
Slowly moving into the right direction :)
>
> Robin.
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem
From: Nayna @ 2019-06-04 20:01 UTC (permalink / raw)
To: Daniel Axtens, Greg KH
Cc: nayna, cclaudio, Matthew Garrett, George Wilson, Mimi Zohar,
Elaine Palmer, linux-fsdevel, linuxppc-dev
In-Reply-To: <87tvd6xlx9.fsf@dja-thinkpad.axtens.net>
On 06/03/2019 07:56 PM, Daniel Axtens wrote:
>
>> I would just recommend putting this in sysfs. Make a new subsystem
>> (i.e. class) and away you go.
>>
>>> My hope with fwvarfs is to provide a generic place for firmware
>>> variables so that we don't need to expand the list of firmware-specific
>>> filesystems beyond efivarfs. I am also aiming to make things simple to
>>> use so that people familiar with firmware don't also have to become
>>> familiar with filesystem code in order to expose firmware variables to
>>> userspace.
>>> fwvarfs can also be used for variables that are not security relevant as
>>> well. For example, with the EFI backend (patch 3), both secure and
>>> insecure variables can be read.
>> I don't remember why efi variables were not put in sysfs, I think there
>> was some reasoning behind it originally. Perhaps look in the linux-efi
>> archives.
> I'll have a look: I suspect the appeal of efivarfs is that it allows for
> things like non-case-sensitive matching on the GUID part of the filename
> while retaining case-sensitivity on the part of the filename
> representing the variable name.
It seems efivars were first implemented in sysfs and then later
separated out as efivarfs.
Refer - Documentation/filesystems/efivarfs.txt.
So, the reason wasn't that sysfs should not be used for exposing
firmware variables,
but for the size limitations which seems to come from UEFI Specification.
Is this limitation valid for the new requirement of secure variables ?
Copying Matthew who can give us more insights...
Thanks & Regards,
- Nayna
^ permalink raw reply
* Re: [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem
From: Matthew Garrett @ 2019-06-04 20:05 UTC (permalink / raw)
To: Nayna
Cc: Greg KH, Nayna Jain, Claudio Carvalho, Mimi Zohar, George Wilson,
Elaine Palmer, linux-fsdevel, linuxppc-dev, Daniel Axtens
In-Reply-To: <b2312934-42a6-f2e7-61d2-3d95222a1699@linux.vnet.ibm.com>
On Tue, Jun 4, 2019 at 1:01 PM Nayna <nayna@linux.vnet.ibm.com> wrote:
> It seems efivars were first implemented in sysfs and then later
> separated out as efivarfs.
> Refer - Documentation/filesystems/efivarfs.txt.
>
> So, the reason wasn't that sysfs should not be used for exposing
> firmware variables,
> but for the size limitations which seems to come from UEFI Specification.
>
> Is this limitation valid for the new requirement of secure variables ?
I don't think the size restriction is an issue now, but there's a lot
of complex semantics around variable deletion and immutability that
need to be represented somehow.
^ permalink raw reply
* Re: [PATCH v3 0/6] soc/fsl/qe: cleanups and new DT binding
From: Li Yang @ 2019-06-04 20:29 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: Mark Rutland, devicetree@vger.kernel.org, Scott Wood,
linux-kernel@vger.kernel.org, Rasmus Villemoes, Rob Herring,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, Qiang Zhao
In-Reply-To: <20190513111442.25724-1-rasmus.villemoes@prevas.dk>
On Mon, May 13, 2019 at 6:17 AM Rasmus Villemoes
<rasmus.villemoes@prevas.dk> wrote:
>
> This small series consists of some small cleanups and simplifications
> of the QUICC engine driver, and introduces a new DT binding that makes
> it much easier to support other variants of the QUICC engine IP block
> that appears in the wild: There's no reason to expect in general that
> the number of valid SNUMs uniquely determines the set of such, so it's
> better to simply let the device tree specify the values (and,
> implicitly via the array length, also the count).
>
> Which tree should this go through?
>
> v3:
> - Move example from commit log into binding document (adapting to
> MPC8360 which the existing example pertains to).
> - Add more review tags.
> - Fix minor style issue.
>
> v2:
> - Address comments from Christophe Leroy
> - Add his Reviewed-by to 1/6 and 3/6
> - Split DT binding update to separate patch as per
> Documentation/devicetree/bindings/submitting-patches.txt
>
> Rasmus Villemoes (6):
> soc/fsl/qe: qe.c: drop useless static qualifier
> soc/fsl/qe: qe.c: reduce static memory footprint by 1.7K
> soc/fsl/qe: qe.c: introduce qe_get_device_node helper
> dt-bindings: soc/fsl: qe: document new fsl,qe-snums binding
> soc/fsl/qe: qe.c: support fsl,qe-snums property
> soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init
Series applied to soc/fsl for-next. Thanks!
Regards,
Leo
>
> .../devicetree/bindings/soc/fsl/cpm_qe/qe.txt | 13 +-
> drivers/soc/fsl/qe/qe.c | 163 +++++++-----------
> 2 files changed, 77 insertions(+), 99 deletions(-)
>
> --
> 2.20.1
>
^ permalink raw reply
* [Bug 203515] [crypto] alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test vector 3, cfg="uneven misaligned splits, may sleep"
From: bugzilla-daemon @ 2019-06-04 20:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-203515-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=203515
Erhard F. (erhard_f@mailbox.org) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |CODE_FIX
--- Comment #7 from Erhard F. (erhard_f@mailbox.org) ---
The fix trickled down from mainline to stable. 5.1.7 passes tests now:
$ dmesg | grep -i aes
[ 4.902294] crypto_register_alg 'aes' = 0
[ 4.928003] crypto_register_alg 'cbc(aes)' = 0
[ 4.944002] crypto_register_alg 'ctr(aes)' = 0
[ 5.011290] crypto_register_alg 'xts(aes)' = 0
Thanks!
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [WIP RFC PATCH 0/6] Generic Firmware Variable Filesystem
From: Nayna @ 2019-06-04 20:33 UTC (permalink / raw)
To: Greg KH, Daniel Axtens
Cc: nayna, cclaudio, Mimi Zohar, George Wilson, Matthew Garrett,
Elaine Palmer, linux-fsdevel, linuxppc-dev
In-Reply-To: <20190603072916.GA7545@kroah.com>
On 06/03/2019 03:29 AM, Greg KH wrote:
> On Mon, Jun 03, 2019 at 04:04:32PM +1000, Daniel Axtens wrote:
>> Hi Nayna,
>>
>>>> As PowerNV moves towards secure boot, we need a place to put secure
>>>> variables. One option that has been canvassed is to make our secure
>>>> variables look like EFI variables. This is an early sketch of another
>>>> approach where we create a generic firmware variable file system,
>>>> fwvarfs, and an OPAL Secure Variable backend for it.
>>> Is there a need of new filesystem ? I am wondering why can't these be
>>> exposed via sysfs / securityfs ?
>>> Probably, something like... /sys/firmware/secureboot or
>>> /sys/kernel/security/secureboot/ ?
>> I suppose we could put secure variables in sysfs, but I'm not sure
>> that's what sysfs was intended for. I understand sysfs as "a
>> filesystem-based view of kernel objects" (from
>> Documentation/filesystems/configfs/configfs.txt), and I don't think a
>> secure variable is really a kernel object in the same way most other
>> things in sysfs are... but I'm open to being convinced.
> What makes them more "secure" than anything else that is in sysfs today?
> I didn't see anything in this patchset that provided "additional
> security", did I miss it?
>
>> securityfs seems to be reserved for LSMs, I don't think we can put
>> things there.
> Yeah, I wouldn't mess with that.
Thanks Greg for clarifying!! I am curious, the TPM exposes the BIOS event log to userspace via securityfs. Is there a reason for not exposing these security variables to userspace via securityfs as well?
Thanks & Regards,
- Nayna
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox