* Re: Linux 5.1-rc5
From: Martin Schwidefsky @ 2019-04-16 12:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Christoph Hellwig, linuxppc-dev, Linux List Kernel Mailing,
linux-s390
In-Reply-To: <20190416110906.6c773aff@mschwideX1>
On Tue, 16 Apr 2019 11:09:06 +0200
Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
> On Mon, 15 Apr 2019 09:17:10 -0700
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > On Sun, Apr 14, 2019 at 10:19 PM Christoph Hellwig <hch@infradead.org> wrote:
> > >
> > > Can we please have the page refcount overflow fixes out on the list
> > > for review, even if it is after the fact?
> >
> > They were actually on a list for review long before the fact, but it
> > was the security mailing list. The issue actually got discussed back
> > in January along with early versions of the patches, but then we
> > dropped the ball because it just wasn't on anybody's radar and it got
> > resurrected late March. Willy wrote a rather bigger patch-series, and
> > review of that is what then resulted in those commits. So they may
> > look recent, but that's just because the original patches got
> > seriously edited down and rewritten.
>
> First time I hear about this, thanks for the heads up.
>
> > That said, powerpc and s390 should at least look at maybe adding a
> > check for the page ref in their gup paths too. Powerpc has the special
> > gup_hugepte() case, and s390 has its own version of gup entirely. I
> > was actually hoping the s390 guys would look at using the generic gup
> > code.
>
> We did look at converting the s390 gup code to CONFIG_HAVE_GENERIC_GUP,
> there are some details that need careful consideration. The top one
> is access_ok(), for s390 we always return true. The generic gup code
> relies on the fact that a page table walk with a specific address is
> doable if access_ok() returned true, the s390 specific check is slightly
> different:
>
> if ((end <= start) || (end > mm->context.asce_limit))
> return 0;
>
> The obvious approach would be to modify access_ok() to check against
> the asce_limit. I will try and see if anything breaks, e.g. the automatic
> page table upgrade.
I tested the waters in regard to access_ok() and the generic gup code.
The good news is that mm/gup.c with CONFIG_HAVE_GENERIC_GUP=y seems to
work just fine if the access_ok() issue is taken care of. But..
Bloat-o-meter with a non-empty uaccess_ok() that checks against
current->mm->context.asce_limit:
add/remove: 8/2 grow/shrink: 611/11 up/down: 61352/-1914 (59438)
with CONFIG_HAVE_GENERIC_GUP on top of that
add/remove: 10/2 grow/shrink: 612/12 up/down: 63568/-3280 (60288)
This is not nice, would a patch like the following be acceptable?
--
Subject: [PATCH] mm: introduce mm_pgd_walk_ok
Add the architecture overrideable function mm_pgd_walk_ok() to check
if a block of memory is inside the limits of the page table hierarchy
of a given mm struct.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
include/asm-generic/pgtable.h | 4 ++++
mm/gup.c | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index fa782fba51ee..7d2a8a58f1c1 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1186,4 +1186,8 @@ static inline bool arch_has_pfn_modify_check(void)
#define mm_pmd_folded(mm) __is_defined(__PAGETABLE_PMD_FOLDED)
#endif
+#ifndef mm_pgd_walk_ok
+#define mm_pgd_walk_ok(mm, addr, size) access_ok(addr, size)
+#endif
+
#endif /* _ASM_GENERIC_PGTABLE_H */
diff --git a/mm/gup.c b/mm/gup.c
index 91819b8ad9cc..b3eb3f45d237 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1990,7 +1990,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
len = (unsigned long) nr_pages << PAGE_SHIFT;
end = start + len;
- if (unlikely(!access_ok((void __user *)start, len)))
+ if (unlikely(!mm_pgd_walk_ok(current->mm, (void __user *)start, len)))
return 0;
/*
@@ -2044,7 +2044,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages, int write,
if (nr_pages <= 0)
return 0;
- if (unlikely(!access_ok((void __user *)start, len)))
+ if (unlikely(!mm_pgd_walk_ok(current->mm, (void __user *)start, len)))
return -EFAULT;
if (gup_fast_permitted(start, nr_pages)) {
--
2.16.4
With an empty access_ok() but a "real" mm_pgd_walk_ok() the results are
much more reasonable:
add/remove: 2/0 grow/shrink: 2/1 up/down: 2186/-1382 (804)
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply related
* Re: [PATCH] Linux: Define struct termios2 in <termios.h> under _GNU_SOURCE [BZ #10339]
From: Adhemerval Zanella @ 2019-04-16 12:11 UTC (permalink / raw)
To: Florian Weimer, hpa; +Cc: linux-api, libc-alpha, linuxppc-dev
In-Reply-To: <87lg0az2xk.fsf@oldenburg2.str.redhat.com>
On 16/04/2019 06:59, Florian Weimer wrote:
> * hpa:
>
>> Using symbol versioning doesn't really help much since the real
>> problem is that struct termios can be passed around in userspace, and
>> the interfaces between user space libraries don't have any
>> versioning. However, my POC code deals with that too by only seeing
>> BOTHER when necessary, so if the structure is extended garbage in the
>> extra fields will be ignored unless new baud rates are in use.
>
> That still doesn't solve the problem of changing struct offsets after a
> struct field of type struct termios.
We will need symbol versioning at least on sparc, since currently it
defines NCSS 17 and termios-c_cc.h defines 16 control characters (there
is no space to squeeze more fields one termios). ANd The WIP branch
gratuitously change the termios struct size on the architecture.
I am not sure which would be the best option to avoid the the user space
libraries compatibility issue. It is unlikely to happen, it would require
one to use old libraries along with newer libraries build against a newer
glibc. Not sure how often this scenarios arises in realworld (specially
on sparc).
I think MIPS would be fine to lower NCSS to 24, as WIP branch does. And
alpha is also fine since it already provides the c_* fields.
>
>> Exporting termios2 to user space feels a bit odd at this stage as it
>> would only be usable as a fallback on old glibc. Call it
>> kernel_termios2 at least.
>
> I'm not sure why we should do that? The kernel calls it struct termios2
> in its UAPI headers. If that name is not appropriate, it should be
> changed first in the UAPI headers.
>
> Thanks,
> Florian
>
^ permalink raw reply
* Re: [PATCH 1/5] arm64: Fix vDSO clock_getres()
From: Vincenzo Frascino @ 2019-04-16 12:42 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, linux-s390, Shuah Khan, Arnd Bergmann, Heiko Carstens,
Will Deacon, Paul Mackerras, Greentime Hu, Martin Schwidefsky,
Thomas Gleixner, Vincent Chen, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190415173521.GA901@arrakis.emea.arm.com>
Hi Catalin,
On 15/04/2019 18:35, Catalin Marinas wrote:
> On Mon, Apr 01, 2019 at 12:51:48PM +0100, Vincenzo Frascino wrote:
>> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
>> index 2d419006ad43..47ba72345739 100644
>> --- a/arch/arm64/kernel/vdso.c
>> +++ b/arch/arm64/kernel/vdso.c
>> @@ -245,6 +245,8 @@ void update_vsyscall(struct timekeeper *tk)
>> vdso_data->cs_shift = tk->tkr_mono.shift;
>> }
>>
>> + vdso_data->hrtimer_res = hrtimer_resolution;
>> +
>> smp_wmb();
>> ++vdso_data->tb_seq_count;
>> }
>> diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
>> index c39872a7b03c..7a2cd2f8e13a 100644
>> --- a/arch/arm64/kernel/vdso/gettimeofday.S
>> +++ b/arch/arm64/kernel/vdso/gettimeofday.S
>> @@ -296,32 +296,35 @@ ENDPROC(__kernel_clock_gettime)
>> /* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res); */
>> ENTRY(__kernel_clock_getres)
>> .cfi_startproc
>> + adr vdso_data, _vdso_data
>> cmp w0, #CLOCK_REALTIME
>> ccmp w0, #CLOCK_MONOTONIC, #0x4, ne
>> ccmp w0, #CLOCK_MONOTONIC_RAW, #0x4, ne
>> - b.ne 1f
>> + b.ne 2f
>>
>> - ldr x2, 5f
>> - b 2f
>> -1:
>> +1: /* Get hrtimer_res */
>> + seqcnt_acquire
>> + syscall_check fail=5f
>> + ldr x2, [vdso_data, #CLOCK_REALTIME_RES]
>> + seqcnt_check fail=1b
>> + b 3f
>> +2:
>
> We talked briefly but I'm still confused why we need the fallback to the
> syscall here if archdata.vdso_direct is false. Is it because if the
> timer driver code sets vdso_direct to false, we don't don't support
> highres timers? If my understanding is correct, you may want to move the
> hrtimer_res setting in update_vsyscall() to the !use_syscall block.
>
Ok, so let me try to provide more details on what I mentioned yesterday:
- clock_getres syscall follows the rules of what defined in posix-timers.c
- based on the clock_id that, for this purpose, can be separated in coarse and
non-coarse calls either posix_get_coarse_res() or posix_get_hrtimer_res().
- if clock id is set to a coarse clock and posix_get_coarse_res() is invoked,
happens what follows:
static int posix_get_coarse_res(const clockid_t which_clock,
struct timespec64 *tp)
{
*tp = ktime_to_timespec64(KTIME_LOW_RES);
return 0;
}
Note that since CONFIG_1HZ seems not supported (jiffies.h) by the kernel in this
case we do not need rounding in our vDSO implementation.
- if clock id is set to non-coarse and posix_get_hrtimer_res() is invoked,
happens the following:
static int posix_get_hrtimer_res(clockid_t which_clock, struct timespec64 *tp)
{
tp->tv_sec = 0;
tp->tv_nsec = hrtimer_resolution;
return 0;
}
hrtimer_resolution can be high res or low res depending on the call of
hrtimer_switch_to_hres(). For us the only way to preserve the correct value is
to keep it in the vdso data page.
- The assembly code mimics exactly the same behaviour detailed above, with one
difference: the one related to the use_syscall parameter which is specific to arm64.
The use_syscall parameter is set by arm_arch_timer and consumed by
update_vsyscall(). To mirror what update_vsyscall does in update_vsyscall() I
check "syscall_check fail=5f" in clock_getres vdso function.
Said that, even if functionally it is the same thing, I think it is logically
more correct to have hrtimer_res setting inside the !use_syscall block, hence I
am going to change it in the next iteration.
Please let me know your thoughts.
--
Regards,
Vincenzo
^ permalink raw reply
* Re: [PATCH v3 7/8] powerpc/mm: Consolidate radix and hash address map details
From: Nicholas Piggin @ 2019-04-16 14:03 UTC (permalink / raw)
To: Aneesh Kumar K.V, mpe, paulus; +Cc: linuxppc-dev
In-Reply-To: <20190416100722.10324-8-aneesh.kumar@linux.ibm.com>
Aneesh Kumar K.V's on April 16, 2019 8:07 pm:
> We now have
>
> 4K page size config
>
> kernel_region_map_size = 16TB
> kernel vmalloc start = 0xc000100000000000
> kernel IO start = 0xc000200000000000
> kernel vmemmap start = 0xc000300000000000
>
> with 64K page size config:
>
> kernel_region_map_size = 512TB
> kernel vmalloc start = 0xc008000000000000
> kernel IO start = 0xc00a000000000000
> kernel vmemmap start = 0xc00c000000000000
Hey Aneesh,
I like the series, I like consolidating the address spaces into 0xc,
and making the layouts match or similar isn't a bad thing. I don't
see any real reason to force limitations on one layout or another --
you could make the argument that 4k radix should match 64k radix
as much as matching 4k hash IMO.
I wouldn't like to tie them too strongly to the same base defines
that force them to stay in sync.
Can we drop this patch? Or at least keep the users of the H_ and R_
defines and set them to the same thing in map.h?
> diff --git a/arch/powerpc/include/asm/book3s/64/map.h b/arch/powerpc/include/asm/book3s/64/map.h
> new file mode 100644
> index 000000000000..5c01f8c18d61
> --- /dev/null
> +++ b/arch/powerpc/include/asm/book3s/64/map.h
> @@ -0,0 +1,80 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_POWERPC_BOOK3S_64_MAP_H_
> +#define _ASM_POWERPC_BOOK3S_64_MAP_H_
> +
> +/*
> + * We use MAX_EA_BITS_PER_CONTEXT (hash specific) here just to make sure we pick
> + * the same value for hash and radix.
> + */
> +#ifdef CONFIG_PPC_64K_PAGES
> +
> +/*
> + * Each context is 512TB size. SLB miss for first context/default context
> + * is handled in the hotpath.
Now everything is handled in the slowpath :P I guess that's a copy
paste of the comment which my SLB miss patch should have fixed it.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2 1/5] cpu/speculation: Add 'mitigations=' cmdline option
From: Borislav Petkov @ 2019-04-16 14:13 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Steven Price, Linus Torvalds, Catalin Marinas, Waiman Long,
linux-arch, Jon Masters, Jiri Kosina, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Phil Auld, Greg Kroah-Hartman,
Randy Dunlap, linux-kernel, Tyler Hicks, Martin Schwidefsky,
linuxppc-dev
In-Reply-To: <b07a8ef9b7c5055c3a4637c87d07c296d5016fe0.1555085500.git.jpoimboe@redhat.com>
On Fri, Apr 12, 2019 at 03:39:28PM -0500, Josh Poimboeuf wrote:
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index 38890f62f9a8..aed9083f8eac 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -2320,3 +2320,18 @@ void __init boot_cpu_hotplug_init(void)
> #endif
> this_cpu_write(cpuhp_state.state, CPUHP_ONLINE);
> }
> +
> +enum cpu_mitigations cpu_mitigations __ro_after_init = CPU_MITIGATIONS_AUTO;
> +
> +static int __init mitigations_cmdline(char *arg)
Forgot the verb: "mitigations_parse_cmdline".
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH 1/5] arm64: Fix vDSO clock_getres()
From: Will Deacon @ 2019-04-16 14:23 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, linux-s390, Shuah Khan, Arnd Bergmann,
Catalin Marinas, Heiko Carstens, Paul Mackerras,
Martin Schwidefsky, Thomas Gleixner, Vincent Chen, linuxppc-dev,
linux-arm-kernel, Greentime Hu
In-Reply-To: <efaafc72-79da-b25a-78b7-36424d9350ad@arm.com>
On Tue, Apr 16, 2019 at 01:42:58PM +0100, Vincenzo Frascino wrote:
> On 15/04/2019 18:35, Catalin Marinas wrote:
> > On Mon, Apr 01, 2019 at 12:51:48PM +0100, Vincenzo Frascino wrote:
> >> +1: /* Get hrtimer_res */
> >> + seqcnt_acquire
> >> + syscall_check fail=5f
> >> + ldr x2, [vdso_data, #CLOCK_REALTIME_RES]
> >> + seqcnt_check fail=1b
> >> + b 3f
> >> +2:
> >
> > We talked briefly but I'm still confused why we need the fallback to the
> > syscall here if archdata.vdso_direct is false. Is it because if the
> > timer driver code sets vdso_direct to false, we don't don't support
> > highres timers? If my understanding is correct, you may want to move the
> > hrtimer_res setting in update_vsyscall() to the !use_syscall block.
> >
>
> Ok, so let me try to provide more details on what I mentioned yesterday:
> - clock_getres syscall follows the rules of what defined in posix-timers.c
> - based on the clock_id that, for this purpose, can be separated in coarse and
> non-coarse calls either posix_get_coarse_res() or posix_get_hrtimer_res().
> - if clock id is set to a coarse clock and posix_get_coarse_res() is invoked,
> happens what follows:
>
> static int posix_get_coarse_res(const clockid_t which_clock,
> struct timespec64 *tp)
> {
> *tp = ktime_to_timespec64(KTIME_LOW_RES);
> return 0;
> }
>
> Note that since CONFIG_1HZ seems not supported (jiffies.h) by the kernel in this
> case we do not need rounding in our vDSO implementation.
>
> - if clock id is set to non-coarse and posix_get_hrtimer_res() is invoked,
> happens the following:
>
> static int posix_get_hrtimer_res(clockid_t which_clock, struct timespec64 *tp)
> {
> tp->tv_sec = 0;
> tp->tv_nsec = hrtimer_resolution;
> return 0;
> }
>
> hrtimer_resolution can be high res or low res depending on the call of
> hrtimer_switch_to_hres(). For us the only way to preserve the correct value is
> to keep it in the vdso data page.
>
> - The assembly code mimics exactly the same behaviour detailed above, with one
> difference: the one related to the use_syscall parameter which is specific to arm64.
> The use_syscall parameter is set by arm_arch_timer and consumed by
> update_vsyscall(). To mirror what update_vsyscall does in update_vsyscall() I
> check "syscall_check fail=5f" in clock_getres vdso function.
>
> Said that, even if functionally it is the same thing, I think it is logically
> more correct to have hrtimer_res setting inside the !use_syscall block, hence I
> am going to change it in the next iteration.
>
> Please let me know your thoughts.
I think you can ignore the syscall_check, just like we seem to do for
CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE in clock_gettime().
Will
^ permalink raw reply
* Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
From: Mark Rutland @ 2019-04-16 14:27 UTC (permalink / raw)
To: Laurent Dufour
Cc: jack, sergey.senozhatsky.work, peterz, Will Deacon, mhocko,
linux-mm, paulus, Punit Agrawal, hpa, Michel Lespinasse,
Alexei Starovoitov, Andrea Arcangeli, ak, Minchan Kim,
aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan, Ingo Molnar,
David Rientjes, paulmck, Haiyan Song, npiggin, sj38.park,
Jerome Glisse, dave, kemi.wang, kirill, Thomas Gleixner,
zhong jiang, Ganesh Mahendran, Yang Shi, Mike Rapoport,
linuxppc-dev, linux-kernel, Sergey Senozhatsky, vinayak menon,
akpm, Tim Chen, haren
In-Reply-To: <20190416134522.17540-5-ldufour@linux.ibm.com>
On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote:
> From: Mahendran Ganesh <opensource.ganesh@gmail.com>
>
> Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This
> enables Speculative Page Fault handler.
>
> Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
This is missing your S-o-B.
The first patch noted that the ARCH_SUPPORTS_* option was there because
the arch code had to make an explicit call to try to handle the fault
speculatively, but that isn't addeed until patch 30.
Why is this separate from that code?
Thanks,
Mark.
> ---
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 870ef86a64ed..8e86934d598b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -174,6 +174,7 @@ config ARM64
> select SWIOTLB
> select SYSCTL_EXCEPTION_TRACE
> select THREAD_INFO_IN_TASK
> + select ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
> help
> ARM 64-bit (AArch64) Linux support.
>
> --
> 2.21.0
>
^ permalink raw reply
* Re: [PATCH v12 04/31] arm64/mm: define ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT
From: Mark Rutland @ 2019-04-16 14:41 UTC (permalink / raw)
To: Laurent Dufour
Cc: jack, sergey.senozhatsky.work, peterz, Will Deacon, mhocko,
linux-mm, paulus, Punit Agrawal, hpa, Michel Lespinasse,
Alexei Starovoitov, Andrea Arcangeli, ak, Minchan Kim,
aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan, Ingo Molnar,
David Rientjes, paulmck, Haiyan Song, npiggin, sj38.park,
Jerome Glisse, dave, kemi.wang, kirill, Thomas Gleixner,
zhong jiang, Ganesh Mahendran, Yang Shi, Mike Rapoport,
linuxppc-dev, linux-kernel, Sergey Senozhatsky, vinayak menon,
akpm, Tim Chen, haren
In-Reply-To: <4ef9ff4b-2230-0644-2254-c1de22d41e6c@linux.ibm.com>
On Tue, Apr 16, 2019 at 04:31:27PM +0200, Laurent Dufour wrote:
> Le 16/04/2019 à 16:27, Mark Rutland a écrit :
> > On Tue, Apr 16, 2019 at 03:44:55PM +0200, Laurent Dufour wrote:
> > > From: Mahendran Ganesh <opensource.ganesh@gmail.com>
> > >
> > > Set ARCH_SUPPORTS_SPECULATIVE_PAGE_FAULT for arm64. This
> > > enables Speculative Page Fault handler.
> > >
> > > Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
> >
> > This is missing your S-o-B.
>
> You're right, I missed that...
>
> > The first patch noted that the ARCH_SUPPORTS_* option was there because
> > the arch code had to make an explicit call to try to handle the fault
> > speculatively, but that isn't addeed until patch 30.
> >
> > Why is this separate from that code?
>
> Andrew was recommended this a long time ago for bisection purpose. This
> allows to build the code with CONFIG_SPECULATIVE_PAGE_FAULT before the code
> that trigger the spf handler is added to the per architecture's code.
Ok. I think it would be worth noting that in the commit message, to
avoid anyone else asking the same question. :)
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v5 1/6] iommu: add generic boot option iommu.dma_mode
From: Will Deacon @ 2019-04-16 15:21 UTC (permalink / raw)
To: Robin Murphy
Cc: linux-ia64, Sebastian Ott, linux-doc, Hanjun Guo, Heiko Carstens,
Paul Mackerras, H . Peter Anvin, linux-s390, Jonathan Corbet,
Jean-Philippe Brucker, Joerg Roedel, x86, Ingo Molnar, Fenghua Yu,
John Garry, Borislav Petkov, Zhen Lei, Thomas Gleixner,
Gerald Schaefer, Tony Luck, linuxppc-dev, linux-kernel, iommu,
Martin Schwidefsky, David Woodhouse
In-Reply-To: <222946ee-adcc-1311-82a7-6afc9ffbc846@arm.com>
On Fri, Apr 12, 2019 at 02:11:31PM +0100, Robin Murphy wrote:
> On 12/04/2019 11:26, John Garry wrote:
> > On 09/04/2019 13:53, Zhen Lei wrote:
> > > +static int __init iommu_dma_mode_setup(char *str)
> > > +{
> > > + if (!str)
> > > + goto fail;
> > > +
> > > + if (!strncmp(str, "passthrough", 11))
> > > + iommu_default_dma_mode = IOMMU_DMA_MODE_PASSTHROUGH;
> > > + else if (!strncmp(str, "lazy", 4))
> > > + iommu_default_dma_mode = IOMMU_DMA_MODE_LAZY;
> > > + else if (!strncmp(str, "strict", 6))
> > > + iommu_default_dma_mode = IOMMU_DMA_MODE_STRICT;
> > > + else
> > > + goto fail;
> > > +
> > > + pr_info("Force dma mode to be %d\n", iommu_default_dma_mode);
> >
> > What happens if the cmdline option iommu.dma_mode is passed multiple
> > times? We get mutliple - possibily conflicting - prints, right?
>
> Indeed; we ended up removing such prints for the existing options here,
> specifically because multiple messages seemed more likely to be confusing
> than useful.
>
> > And do we need to have backwards compatibility, such that the setting
> > for iommu.strict or iommu.passthrough trumps iommu.dma_mode, regardless
> > of order?
>
> As above I think it would be preferable to just keep using the existing
> options anyway. The current behaviour works out as:
>
> iommu.passthrough | Y | N
> iommu.strict | x | Y N
> ------------------|-------------|---------|--------
> MODE | PASSTHROUGH | STRICT | LAZY
>
> which seems intuitive enough that a specific dma_mode option doesn't add
> much value, and would more likely just overcomplicate things for users as
> well as our implementation.
Agreed. We can't remove the existing options, and they do the job perfectly
well so I don't see the need to add more options on top.
Will
^ permalink raw reply
* Re: [PATCH v2 1/5] cpu/speculation: Add 'mitigations=' cmdline option
From: Josh Poimboeuf @ 2019-04-16 15:32 UTC (permalink / raw)
To: Borislav Petkov
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Steven Price, Linus Torvalds, Catalin Marinas, Waiman Long,
linux-arch, Jon Masters, Jiri Kosina, Andy Lutomirski,
Thomas Gleixner, linux-arm-kernel, Phil Auld, Greg Kroah-Hartman,
Randy Dunlap, linux-kernel, Tyler Hicks, Martin Schwidefsky,
linuxppc-dev
In-Reply-To: <20190416141335.GH31772@zn.tnic>
On Tue, Apr 16, 2019 at 04:13:35PM +0200, Borislav Petkov wrote:
> On Fri, Apr 12, 2019 at 03:39:28PM -0500, Josh Poimboeuf wrote:
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index 38890f62f9a8..aed9083f8eac 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -2320,3 +2320,18 @@ void __init boot_cpu_hotplug_init(void)
> > #endif
> > this_cpu_write(cpuhp_state.state, CPUHP_ONLINE);
> > }
> > +
> > +enum cpu_mitigations cpu_mitigations __ro_after_init = CPU_MITIGATIONS_AUTO;
> > +
> > +static int __init mitigations_cmdline(char *arg)
>
> Forgot the verb: "mitigations_parse_cmdline".
Sure.
diff --git a/kernel/cpu.c b/kernel/cpu.c
index aed9083f8eac..cf9fea42d8fc 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2323,7 +2323,7 @@ void __init boot_cpu_hotplug_init(void)
enum cpu_mitigations cpu_mitigations __ro_after_init = CPU_MITIGATIONS_AUTO;
-static int __init mitigations_cmdline(char *arg)
+static int __init mitigations_parse_cmdline(char *arg)
{
if (!strcmp(arg, "off"))
cpu_mitigations = CPU_MITIGATIONS_OFF;
@@ -2334,4 +2334,4 @@ static int __init mitigations_cmdline(char *arg)
return 0;
}
-early_param("mitigations", mitigations_cmdline);
+early_param("mitigations", mitigations_parse_cmdline);
^ permalink raw reply related
* [PATCH v2 0/5] Fix vDSO clock_getres()
From: Vincenzo Frascino @ 2019-04-16 16:14 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linuxppc-dev, linux-s390,
linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Catalin Marinas, Will Deacon,
Paul Mackerras, Greentime Hu, Martin Schwidefsky, Thomas Gleixner,
Vincent Chen, Shuah Khan
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.
A possible fix is to change the vdso implementation of clock_getres,
keeping a copy of hrtimer_resolution in vdso data and using that
directly [1].
This patchset implements the proposed fix for arm64, powerpc, s390,
nds32 and adds a test to verify that the syscall and the vdso library
implementation of clock_getres return the same values.
Even if these patches are unified by the same topic, there is no
dependency between them, hence they can be merged singularly by each
arch maintainer.
[1] https://marc.info/?l=linux-arm-kernel&m=155110381930196&w=2
Changes:
--------
v2:
- Rebased on 5.1-rc5.
- Addressed review comments.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Vincenzo Frascino (5):
arm64: Fix vDSO clock_getres()
powerpc: Fix vDSO clock_getres()
s390: Fix vDSO clock_getres()
nds32: Fix vDSO clock_getres()
kselftest: Extend vDSO selftest to clock_getres
arch/arm64/include/asm/vdso_datapage.h | 1 +
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/vdso.c | 2 +
arch/arm64/kernel/vdso/gettimeofday.S | 22 ++--
arch/nds32/include/asm/vdso_datapage.h | 1 +
arch/nds32/kernel/vdso.c | 1 +
arch/nds32/kernel/vdso/gettimeofday.c | 4 +-
arch/powerpc/include/asm/vdso_datapage.h | 2 +
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kernel/time.c | 1 +
arch/powerpc/kernel/vdso32/gettimeofday.S | 7 +-
arch/powerpc/kernel/vdso64/gettimeofday.S | 7 +-
arch/s390/include/asm/vdso.h | 1 +
arch/s390/kernel/asm-offsets.c | 2 +-
arch/s390/kernel/time.c | 1 +
arch/s390/kernel/vdso32/clock_getres.S | 12 +-
arch/s390/kernel/vdso64/clock_getres.S | 10 +-
tools/testing/selftests/vDSO/Makefile | 2 +
.../selftests/vDSO/vdso_clock_getres.c | 108 ++++++++++++++++++
19 files changed, 159 insertions(+), 29 deletions(-)
create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
--
2.21.0
^ permalink raw reply
* [PATCH v2 1/5] arm64: Fix vDSO clock_getres()
From: Vincenzo Frascino @ 2019-04-16 16:14 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linuxppc-dev, linux-s390,
linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Catalin Marinas, Will Deacon,
Paul Mackerras, Greentime Hu, Martin Schwidefsky, Thomas Gleixner,
Vincent Chen, Shuah Khan
In-Reply-To: <20190416161434.32691-1-vincenzo.frascino@arm.com>
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.
Fix the arm64 vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
arch/arm64/include/asm/vdso_datapage.h | 1 +
arch/arm64/kernel/asm-offsets.c | 2 +-
arch/arm64/kernel/vdso.c | 2 ++
arch/arm64/kernel/vdso/gettimeofday.S | 22 +++++++++++-----------
4 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/vdso_datapage.h b/arch/arm64/include/asm/vdso_datapage.h
index 2b9a63771eda..f89263c8e11a 100644
--- a/arch/arm64/include/asm/vdso_datapage.h
+++ b/arch/arm64/include/asm/vdso_datapage.h
@@ -38,6 +38,7 @@ struct vdso_data {
__u32 tz_minuteswest; /* Whacky timezone stuff */
__u32 tz_dsttime;
__u32 use_syscall;
+ __u32 hrtimer_res;
};
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c
index 7f40dcbdd51d..e10e2a5d9ddc 100644
--- a/arch/arm64/kernel/asm-offsets.c
+++ b/arch/arm64/kernel/asm-offsets.c
@@ -94,7 +94,7 @@ int main(void)
DEFINE(CLOCK_REALTIME, CLOCK_REALTIME);
DEFINE(CLOCK_MONOTONIC, CLOCK_MONOTONIC);
DEFINE(CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC_RAW);
- DEFINE(CLOCK_REALTIME_RES, MONOTONIC_RES_NSEC);
+ DEFINE(CLOCK_REALTIME_RES, offsetof(struct vdso_data, hrtimer_res));
DEFINE(CLOCK_REALTIME_COARSE, CLOCK_REALTIME_COARSE);
DEFINE(CLOCK_MONOTONIC_COARSE,CLOCK_MONOTONIC_COARSE);
DEFINE(CLOCK_COARSE_RES, LOW_RES_NSEC);
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 2d419006ad43..5f5759d51c33 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -245,6 +245,8 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data->cs_shift = tk->tkr_mono.shift;
}
+ vdso_data->hrtimer_res = hrtimer_resolution;
+
smp_wmb();
++vdso_data->tb_seq_count;
}
diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
index c39872a7b03c..e2e9dfe9ba4a 100644
--- a/arch/arm64/kernel/vdso/gettimeofday.S
+++ b/arch/arm64/kernel/vdso/gettimeofday.S
@@ -296,32 +296,32 @@ ENDPROC(__kernel_clock_gettime)
/* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res); */
ENTRY(__kernel_clock_getres)
.cfi_startproc
+ adr vdso_data, _vdso_data
cmp w0, #CLOCK_REALTIME
ccmp w0, #CLOCK_MONOTONIC, #0x4, ne
ccmp w0, #CLOCK_MONOTONIC_RAW, #0x4, ne
- b.ne 1f
+ b.ne 2f
- ldr x2, 5f
- b 2f
-1:
+1: /* Get hrtimer_res */
+ ldr x2, [vdso_data, #CLOCK_REALTIME_RES]
+ b 3f
+2:
cmp w0, #CLOCK_REALTIME_COARSE
ccmp w0, #CLOCK_MONOTONIC_COARSE, #0x4, ne
- b.ne 4f
+ b.ne 5f
ldr x2, 6f
-2:
- cbz x1, 3f
+3:
+ cbz x1, 4f
stp xzr, x2, [x1]
-3: /* res == NULL. */
+4: /* res == NULL. */
mov w0, wzr
ret
-4: /* Syscall fallback. */
+5: /* Syscall fallback. */
mov x8, #__NR_clock_getres
svc #0
ret
-5:
- .quad CLOCK_REALTIME_RES
6:
.quad CLOCK_COARSE_RES
.cfi_endproc
--
2.21.0
^ permalink raw reply related
* [PATCH v2 2/5] powerpc: Fix vDSO clock_getres()
From: Vincenzo Frascino @ 2019-04-16 16:14 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linuxppc-dev, linux-s390,
linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Catalin Marinas, Will Deacon,
Paul Mackerras, Greentime Hu, Martin Schwidefsky, Thomas Gleixner,
Vincent Chen, Shuah Khan
In-Reply-To: <20190416161434.32691-1-vincenzo.frascino@arm.com>
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.
Fix the powerpc vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
arch/powerpc/include/asm/vdso_datapage.h | 2 ++
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kernel/time.c | 1 +
arch/powerpc/kernel/vdso32/gettimeofday.S | 7 +++++--
arch/powerpc/kernel/vdso64/gettimeofday.S | 7 +++++--
5 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/vdso_datapage.h b/arch/powerpc/include/asm/vdso_datapage.h
index bbc06bd72b1f..4333b9a473dc 100644
--- a/arch/powerpc/include/asm/vdso_datapage.h
+++ b/arch/powerpc/include/asm/vdso_datapage.h
@@ -86,6 +86,7 @@ struct vdso_data {
__s32 wtom_clock_nsec; /* Wall to monotonic clock nsec */
__s64 wtom_clock_sec; /* Wall to monotonic clock sec */
struct timespec stamp_xtime; /* xtime as at tb_orig_stamp */
+ __u32 hrtimer_res; /* hrtimer resolution */
__u32 syscall_map_64[SYSCALL_MAP_SIZE]; /* map of syscalls */
__u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
};
@@ -107,6 +108,7 @@ struct vdso_data {
__s32 wtom_clock_nsec;
struct timespec stamp_xtime; /* xtime as at tb_orig_stamp */
__u32 stamp_sec_fraction; /* fractional seconds of stamp_xtime */
+ __u32 hrtimer_res; /* hrtimer resolution */
__u32 syscall_map_32[SYSCALL_MAP_SIZE]; /* map of syscalls */
__u32 dcache_block_size; /* L1 d-cache block size */
__u32 icache_block_size; /* L1 i-cache block size */
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 86a61e5f8285..52e4b98a8492 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -383,6 +383,7 @@ int main(void)
OFFSET(WTOM_CLOCK_NSEC, vdso_data, wtom_clock_nsec);
OFFSET(STAMP_XTIME, vdso_data, stamp_xtime);
OFFSET(STAMP_SEC_FRAC, vdso_data, stamp_sec_fraction);
+ OFFSET(CLOCK_REALTIME_RES, vdso_data, hrtimer_res);
OFFSET(CFG_ICACHE_BLOCKSZ, vdso_data, icache_block_size);
OFFSET(CFG_DCACHE_BLOCKSZ, vdso_data, dcache_block_size);
OFFSET(CFG_ICACHE_LOGBLOCKSZ, vdso_data, icache_log_block_size);
@@ -413,7 +414,6 @@ int main(void)
DEFINE(CLOCK_REALTIME_COARSE, CLOCK_REALTIME_COARSE);
DEFINE(CLOCK_MONOTONIC_COARSE, CLOCK_MONOTONIC_COARSE);
DEFINE(NSEC_PER_SEC, NSEC_PER_SEC);
- DEFINE(CLOCK_REALTIME_RES, MONOTONIC_RES_NSEC);
#ifdef CONFIG_BUG
DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry));
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index bc0503ef9c9c..62c04a6746d8 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -955,6 +955,7 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data->wtom_clock_nsec = tk->wall_to_monotonic.tv_nsec;
vdso_data->stamp_xtime = xt;
vdso_data->stamp_sec_fraction = frac_sec;
+ vdso_data->hrtimer_res = hrtimer_resolution;
smp_wmb();
++(vdso_data->tb_update_count);
}
diff --git a/arch/powerpc/kernel/vdso32/gettimeofday.S b/arch/powerpc/kernel/vdso32/gettimeofday.S
index afd516b572f8..2b5f9e83c610 100644
--- a/arch/powerpc/kernel/vdso32/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso32/gettimeofday.S
@@ -160,12 +160,15 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
+ mflr r12
+ .cfi_register lr,r12
+ bl __get_datapage@local
+ lwz r5,CLOCK_REALTIME_RES(r3)
+ mtlr r12
li r3,0
cmpli cr0,r4,0
crclr cr0*4+so
beqlr
- lis r5,CLOCK_REALTIME_RES@h
- ori r5,r5,CLOCK_REALTIME_RES@l
stw r3,TSPC32_TV_SEC(r4)
stw r5,TSPC32_TV_NSEC(r4)
blr
diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S b/arch/powerpc/kernel/vdso64/gettimeofday.S
index 1f324c28705b..f07730f73d5e 100644
--- a/arch/powerpc/kernel/vdso64/gettimeofday.S
+++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
@@ -190,12 +190,15 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
cror cr0*4+eq,cr0*4+eq,cr1*4+eq
bne cr0,99f
+ mflr r12
+ .cfi_register lr,r12
+ bl V_LOCAL_FUNC(__get_datapage)
+ lwz r5,CLOCK_REALTIME_RES(r3)
+ mtlr r12
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
--
2.21.0
^ permalink raw reply related
* [PATCH v2 3/5] s390: Fix vDSO clock_getres()
From: Vincenzo Frascino @ 2019-04-16 16:14 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linuxppc-dev, linux-s390,
linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Catalin Marinas, Will Deacon,
Paul Mackerras, Greentime Hu, Martin Schwidefsky, Thomas Gleixner,
Vincent Chen, Shuah Khan
In-Reply-To: <20190416161434.32691-1-vincenzo.frascino@arm.com>
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.
Fix the s390 vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/include/asm/vdso.h | 1 +
arch/s390/kernel/asm-offsets.c | 2 +-
arch/s390/kernel/time.c | 1 +
arch/s390/kernel/vdso32/clock_getres.S | 12 +++++++-----
arch/s390/kernel/vdso64/clock_getres.S | 10 +++++-----
5 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/s390/include/asm/vdso.h b/arch/s390/include/asm/vdso.h
index 169d7604eb80..f3ba84fa9bd1 100644
--- a/arch/s390/include/asm/vdso.h
+++ b/arch/s390/include/asm/vdso.h
@@ -36,6 +36,7 @@ struct vdso_data {
__u32 tk_shift; /* Shift used for xtime_nsec 0x60 */
__u32 ts_dir; /* TOD steering direction 0x64 */
__u64 ts_end; /* TOD steering end 0x68 */
+ __u32 hrtimer_res; /* hrtimer resolution 0x70 */
};
struct vdso_per_cpu_data {
diff --git a/arch/s390/kernel/asm-offsets.c b/arch/s390/kernel/asm-offsets.c
index 164bec175628..36db4a9ee703 100644
--- a/arch/s390/kernel/asm-offsets.c
+++ b/arch/s390/kernel/asm-offsets.c
@@ -75,6 +75,7 @@ int main(void)
OFFSET(__VDSO_TK_SHIFT, vdso_data, tk_shift);
OFFSET(__VDSO_TS_DIR, vdso_data, ts_dir);
OFFSET(__VDSO_TS_END, vdso_data, ts_end);
+ OFFSET(__VDSO_CLOCK_REALTIME_RES, vdso_data, hrtimer_res);
OFFSET(__VDSO_ECTG_BASE, vdso_per_cpu_data, ectg_timer_base);
OFFSET(__VDSO_ECTG_USER, vdso_per_cpu_data, ectg_user_time);
OFFSET(__VDSO_CPU_NR, vdso_per_cpu_data, cpu_nr);
@@ -86,7 +87,6 @@ int main(void)
DEFINE(__CLOCK_REALTIME_COARSE, CLOCK_REALTIME_COARSE);
DEFINE(__CLOCK_MONOTONIC_COARSE, CLOCK_MONOTONIC_COARSE);
DEFINE(__CLOCK_THREAD_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID);
- DEFINE(__CLOCK_REALTIME_RES, MONOTONIC_RES_NSEC);
DEFINE(__CLOCK_COARSE_RES, LOW_RES_NSEC);
BLANK();
/* idle data offsets */
diff --git a/arch/s390/kernel/time.c b/arch/s390/kernel/time.c
index e8766beee5ad..8ea9db599d38 100644
--- a/arch/s390/kernel/time.c
+++ b/arch/s390/kernel/time.c
@@ -310,6 +310,7 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data->tk_mult = tk->tkr_mono.mult;
vdso_data->tk_shift = tk->tkr_mono.shift;
+ vdso_data->hrtimer_res = hrtimer_resolution;
smp_wmb();
++vdso_data->tb_update_count;
}
diff --git a/arch/s390/kernel/vdso32/clock_getres.S b/arch/s390/kernel/vdso32/clock_getres.S
index eaf9cf1417f6..fecd7684c645 100644
--- a/arch/s390/kernel/vdso32/clock_getres.S
+++ b/arch/s390/kernel/vdso32/clock_getres.S
@@ -18,20 +18,22 @@
__kernel_clock_getres:
CFI_STARTPROC
basr %r1,0
- la %r1,4f-.(%r1)
+10: al %r1,4f-10b(%r1)
+ l %r0,__VDSO_CLOCK_REALTIME_RES(%r1)
chi %r2,__CLOCK_REALTIME
je 0f
chi %r2,__CLOCK_MONOTONIC
je 0f
- la %r1,5f-4f(%r1)
+ basr %r1,0
+ la %r1,5f-.(%r1)
+ l %r0,0(%r1)
chi %r2,__CLOCK_REALTIME_COARSE
je 0f
chi %r2,__CLOCK_MONOTONIC_COARSE
jne 3f
0: ltr %r3,%r3
jz 2f /* res == NULL */
-1: l %r0,0(%r1)
- xc 0(4,%r3),0(%r3) /* set tp->tv_sec to zero */
+1: xc 0(4,%r3),0(%r3) /* set tp->tv_sec to zero */
st %r0,4(%r3) /* store tp->tv_usec */
2: lhi %r2,0
br %r14
@@ -39,6 +41,6 @@ __kernel_clock_getres:
svc 0
br %r14
CFI_ENDPROC
-4: .long __CLOCK_REALTIME_RES
+4: .long _vdso_data - 10b
5: .long __CLOCK_COARSE_RES
.size __kernel_clock_getres,.-__kernel_clock_getres
diff --git a/arch/s390/kernel/vdso64/clock_getres.S b/arch/s390/kernel/vdso64/clock_getres.S
index 081435398e0a..022b58c980db 100644
--- a/arch/s390/kernel/vdso64/clock_getres.S
+++ b/arch/s390/kernel/vdso64/clock_getres.S
@@ -17,12 +17,14 @@
.type __kernel_clock_getres,@function
__kernel_clock_getres:
CFI_STARTPROC
- larl %r1,4f
+ larl %r1,3f
+ lg %r0,0(%r1)
cghi %r2,__CLOCK_REALTIME_COARSE
je 0f
cghi %r2,__CLOCK_MONOTONIC_COARSE
je 0f
- larl %r1,3f
+ larl %r1,_vdso_data
+ l %r0,__VDSO_CLOCK_REALTIME_RES(%r1)
cghi %r2,__CLOCK_REALTIME
je 0f
cghi %r2,__CLOCK_MONOTONIC
@@ -36,7 +38,6 @@ __kernel_clock_getres:
jz 2f
0: ltgr %r3,%r3
jz 1f /* res == NULL */
- lg %r0,0(%r1)
xc 0(8,%r3),0(%r3) /* set tp->tv_sec to zero */
stg %r0,8(%r3) /* store tp->tv_usec */
1: lghi %r2,0
@@ -45,6 +46,5 @@ __kernel_clock_getres:
svc 0
br %r14
CFI_ENDPROC
-3: .quad __CLOCK_REALTIME_RES
-4: .quad __CLOCK_COARSE_RES
+3: .quad __CLOCK_COARSE_RES
.size __kernel_clock_getres,.-__kernel_clock_getres
--
2.21.0
^ permalink raw reply related
* [PATCH v2 4/5] nds32: Fix vDSO clock_getres()
From: Vincenzo Frascino @ 2019-04-16 16:14 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linuxppc-dev, linux-s390,
linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Catalin Marinas, Will Deacon,
Paul Mackerras, Greentime Hu, Martin Schwidefsky, Thomas Gleixner,
Vincent Chen, Shuah Khan
In-Reply-To: <20190416161434.32691-1-vincenzo.frascino@arm.com>
clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().
In particular, posix_get_hrtimer_res() does:
sec = 0;
ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.
Fix the nds32 vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
arch/nds32/include/asm/vdso_datapage.h | 1 +
arch/nds32/kernel/vdso.c | 1 +
arch/nds32/kernel/vdso/gettimeofday.c | 4 +++-
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/nds32/include/asm/vdso_datapage.h b/arch/nds32/include/asm/vdso_datapage.h
index 79db5a12ca5e..34d80548297f 100644
--- a/arch/nds32/include/asm/vdso_datapage.h
+++ b/arch/nds32/include/asm/vdso_datapage.h
@@ -20,6 +20,7 @@ struct vdso_data {
u32 xtime_clock_sec; /* CLOCK_REALTIME - seconds */
u32 cs_mult; /* clocksource multiplier */
u32 cs_shift; /* Cycle to nanosecond divisor (power of two) */
+ u32 hrtimer_res; /* hrtimer resolution */
u64 cs_cycle_last; /* last cycle value */
u64 cs_mask; /* clocksource mask */
diff --git a/arch/nds32/kernel/vdso.c b/arch/nds32/kernel/vdso.c
index 016f15891f6d..90bcae6f8554 100644
--- a/arch/nds32/kernel/vdso.c
+++ b/arch/nds32/kernel/vdso.c
@@ -220,6 +220,7 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data->xtime_coarse_sec = tk->xtime_sec;
vdso_data->xtime_coarse_nsec = tk->tkr_mono.xtime_nsec >>
tk->tkr_mono.shift;
+ vdso_data->hrtimer_res = hrtimer_resolution;
vdso_write_end(vdso_data);
}
diff --git a/arch/nds32/kernel/vdso/gettimeofday.c b/arch/nds32/kernel/vdso/gettimeofday.c
index 038721af40e3..b02581891c33 100644
--- a/arch/nds32/kernel/vdso/gettimeofday.c
+++ b/arch/nds32/kernel/vdso/gettimeofday.c
@@ -208,6 +208,8 @@ static notrace int clock_getres_fallback(clockid_t _clk_id,
notrace int __vdso_clock_getres(clockid_t clk_id, struct timespec *res)
{
+ struct vdso_data *vdata = __get_datapage();
+
if (res == NULL)
return 0;
switch (clk_id) {
@@ -215,7 +217,7 @@ notrace int __vdso_clock_getres(clockid_t clk_id, struct timespec *res)
case CLOCK_MONOTONIC:
case CLOCK_MONOTONIC_RAW:
res->tv_sec = 0;
- res->tv_nsec = CLOCK_REALTIME_RES;
+ res->tv_nsec = vdata->hrtimer_res;
break;
case CLOCK_REALTIME_COARSE:
case CLOCK_MONOTONIC_COARSE:
--
2.21.0
^ permalink raw reply related
* [PATCH v2 5/5] kselftest: Extend vDSO selftest to clock_getres
From: Vincenzo Frascino @ 2019-04-16 16:14 UTC (permalink / raw)
To: linux-arch, linux-arm-kernel, linuxppc-dev, linux-s390,
linux-kselftest
Cc: Arnd Bergmann, Heiko Carstens, Catalin Marinas, Will Deacon,
Paul Mackerras, Greentime Hu, Martin Schwidefsky, Thomas Gleixner,
Vincent Chen, Shuah Khan
In-Reply-To: <20190416161434.32691-1-vincenzo.frascino@arm.com>
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.
Cc: Shuah Khan <shuah@kernel.org>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
---
tools/testing/selftests/vDSO/Makefile | 2 +
.../selftests/vDSO/vdso_clock_getres.c | 108 ++++++++++++++++++
2 files changed, 110 insertions(+)
create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
diff --git a/tools/testing/selftests/vDSO/Makefile b/tools/testing/selftests/vDSO/Makefile
index 9e03d61f52fd..d5c5bfdf1ac1 100644
--- a/tools/testing/selftests/vDSO/Makefile
+++ b/tools/testing/selftests/vDSO/Makefile
@@ -5,6 +5,7 @@ uname_M := $(shell uname -m 2>/dev/null || echo not)
ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
TEST_GEN_PROGS := $(OUTPUT)/vdso_test
+TEST_GEN_PROGS += $(OUTPUT)/vdso_clock_getres
ifeq ($(ARCH),x86)
TEST_GEN_PROGS += $(OUTPUT)/vdso_standalone_test_x86
endif
@@ -18,6 +19,7 @@ endif
all: $(TEST_GEN_PROGS)
$(OUTPUT)/vdso_test: parse_vdso.c vdso_test.c
+$(OUTPUT)/vdso_clock_getres: vdso_clock_getres.c
$(OUTPUT)/vdso_standalone_test_x86: vdso_standalone_test_x86.c parse_vdso.c
$(CC) $(CFLAGS) $(CFLAGS_vdso_standalone_test_x86) \
vdso_standalone_test_x86.c parse_vdso.c \
diff --git a/tools/testing/selftests/vDSO/vdso_clock_getres.c b/tools/testing/selftests/vDSO/vdso_clock_getres.c
new file mode 100644
index 000000000000..b1b9652972eb
--- /dev/null
+++ b/tools/testing/selftests/vDSO/vdso_clock_getres.c
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * vdso_clock_getres.c: Sample code to test clock_getres.
+ * Copyright (c) 2019 Arm Ltd.
+ *
+ * Compile with:
+ * gcc -std=gnu99 vdso_clock_getres.c
+ *
+ * Tested on ARM, ARM64, MIPS32, x86 (32-bit and 64-bit),
+ * Power (32-bit and 64-bit), S390x (32-bit and 64-bit).
+ * Might work on other architectures.
+ */
+
+#define _GNU_SOURCE
+#include <elf.h>
+#include <err.h>
+#include <fcntl.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <time.h>
+#include <sys/auxv.h>
+#include <sys/mman.h>
+#include <sys/time.h>
+#include <unistd.h>
+#include <sys/syscall.h>
+
+#include "../kselftest.h"
+
+static long syscall_clock_getres(clockid_t _clkid, struct timespec *_ts)
+{
+ long ret;
+
+ ret = syscall(SYS_clock_getres, _clkid, _ts);
+
+ return ret;
+}
+
+const char *vdso_clock_name[12] = {
+ "CLOCK_REALTIME",
+ "CLOCK_MONOTONIC",
+ "CLOCK_PROCESS_CPUTIME_ID",
+ "CLOCK_THREAD_CPUTIME_ID",
+ "CLOCK_MONOTONIC_RAW",
+ "CLOCK_REALTIME_COARSE",
+ "CLOCK_MONOTONIC_COARSE",
+ "CLOCK_BOOTTIME",
+ "CLOCK_REALTIME_ALARM",
+ "CLOCK_BOOTTIME_ALARM",
+ "CLOCK_SGI_CYCLE",
+ "CLOCK_TAI",
+};
+
+/*
+ * Macro to call clock_getres in vdso and by system call
+ * with different values for clock_id.
+ */
+#define vdso_test_clock(clock_id) \
+do { \
+ struct timespec x, y; \
+ printf("clock_id: %s", vdso_clock_name[clock_id]); \
+ clock_getres(clock_id, &x); \
+ syscall_clock_getres(clock_id, &y); \
+ if ((x.tv_sec != y.tv_sec) || (x.tv_sec != y.tv_sec)) { \
+ printf(" [FAIL]\n"); \
+ return KSFT_SKIP; \
+ } else { \
+ printf(" [PASS]\n"); \
+ } \
+} while (0)
+
+int main(int argc, char **argv)
+{
+
+#if _POSIX_TIMERS > 0
+
+#ifdef CLOCK_REALTIME
+ vdso_test_clock(CLOCK_REALTIME);
+#endif
+
+#ifdef CLOCK_BOOTTIME
+ vdso_test_clock(CLOCK_BOOTTIME);
+#endif
+
+#ifdef CLOCK_TAI
+ vdso_test_clock(CLOCK_TAI);
+#endif
+
+#ifdef CLOCK_REALTIME_COARSE
+ vdso_test_clock(CLOCK_REALTIME_COARSE);
+#endif
+
+#ifdef CLOCK_MONOTONIC
+ vdso_test_clock(CLOCK_MONOTONIC);
+#endif
+
+#ifdef CLOCK_MONOTONIC_RAW
+ vdso_test_clock(CLOCK_MONOTONIC_RAW);
+#endif
+
+#ifdef CLOCK_MONOTONIC_COARSE
+ vdso_test_clock(CLOCK_MONOTONIC_COARSE);
+#endif
+
+#endif
+
+ return 0;
+}
--
2.21.0
^ permalink raw reply related
* Re: Linux 5.1-rc5
From: Linus Torvalds @ 2019-04-16 16:16 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Christoph Hellwig, linuxppc-dev, Linux List Kernel Mailing,
linux-s390
In-Reply-To: <20190416140658.2cb73a3f@mschwideX1>
On Tue, Apr 16, 2019 at 5:08 AM Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
>
> This is not nice, would a patch like the following be acceptable?
Umm.
We actually already *have* this function.
It's called "gup_fast_permitted()" and it's used by x86-64 to verify
the proper address range. Exactly like s390 needs..
Could you please use that instead?
Linus
^ permalink raw reply
* Re: [PATCH v2 1/5] arm64: Fix vDSO clock_getres()
From: Catalin Marinas @ 2019-04-16 16:24 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, linux-s390, Shuah Khan, Arnd Bergmann, Heiko Carstens,
Will Deacon, Paul Mackerras, Greentime Hu, linux-kselftest,
Martin Schwidefsky, Thomas Gleixner, Vincent Chen, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20190416161434.32691-2-vincenzo.frascino@arm.com>
On Tue, Apr 16, 2019 at 05:14:30PM +0100, Vincenzo Frascino wrote:
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index 2d419006ad43..5f5759d51c33 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -245,6 +245,8 @@ void update_vsyscall(struct timekeeper *tk)
> vdso_data->cs_shift = tk->tkr_mono.shift;
> }
>
> + vdso_data->hrtimer_res = hrtimer_resolution;
This should be a WRITE_ONCE(), just in case.
> +
> smp_wmb();
> ++vdso_data->tb_seq_count;
> }
> diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
> index c39872a7b03c..e2e9dfe9ba4a 100644
> --- a/arch/arm64/kernel/vdso/gettimeofday.S
> +++ b/arch/arm64/kernel/vdso/gettimeofday.S
> @@ -296,32 +296,32 @@ ENDPROC(__kernel_clock_gettime)
> /* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res); */
> ENTRY(__kernel_clock_getres)
> .cfi_startproc
> + adr vdso_data, _vdso_data
> cmp w0, #CLOCK_REALTIME
> ccmp w0, #CLOCK_MONOTONIC, #0x4, ne
> ccmp w0, #CLOCK_MONOTONIC_RAW, #0x4, ne
> - b.ne 1f
> + b.ne 2f
>
> - ldr x2, 5f
> - b 2f
> -1:
> +1: /* Get hrtimer_res */
> + ldr x2, [vdso_data, #CLOCK_REALTIME_RES]
And here we need an "ldr w2, ..." since hrtimer_res is u32.
With the above (which Will can fix up):
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: Linux 5.1-rc5
From: Linus Torvalds @ 2019-04-16 16:49 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Christoph Hellwig, linuxppc-dev, Linux List Kernel Mailing,
linux-s390
In-Reply-To: <CAHk-=wjKi5C+Onhp5Vs5BQxHbaBud9M3cTS-S6Tr9yDY4dS-Sw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
On Tue, Apr 16, 2019 at 9:16 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> We actually already *have* this function.
>
> It's called "gup_fast_permitted()" and it's used by x86-64 to verify
> the proper address range. Exactly like s390 needs..
>
> Could you please use that instead?
IOW, something like the attached.
Obviously untested. And maybe 'current' isn't declared in
<asm/pgtable.h>, in which case you'd need to modify it to instead make
the inline function be "s390_gup_fast_permitted()" that takes a
pointer to the mm, and do something like
#define gup_fast_permitted(start, pages) \
s390_gup_fast_permitted(current->mm, start, pages)
instead.
But I think you get the idea..
Linus
[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 724 bytes --]
arch/s390/include/asm/pgtable.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/s390/include/asm/pgtable.h b/arch/s390/include/asm/pgtable.h
index 76dc344edb8c..a08248995f50 100644
--- a/arch/s390/include/asm/pgtable.h
+++ b/arch/s390/include/asm/pgtable.h
@@ -1659,4 +1659,16 @@ static inline void check_pgt_cache(void) { }
#include <asm-generic/pgtable.h>
+static inline bool gup_fast_permitted(unsigned long start, int nr_pages)
+{
+ unsigned long len, end;
+
+ len = (unsigned long)nr_pages << PAGE_SHIFT;
+ end = start + len;
+ if (end < start)
+ return false;
+ return end <= current->mm->context.asce_limit;
+}
+#define gup_fast_permitted gup_fast_permitted
+
#endif /* _S390_PAGE_H */
^ permalink raw reply related
* Re: [PATCH v2 5/5] kselftest: Extend vDSO selftest to clock_getres
From: Will Deacon @ 2019-04-16 17:08 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, linux-s390, Shuah Khan, Arnd Bergmann,
Catalin Marinas, Heiko Carstens, Paul Mackerras, linux-kselftest,
Martin Schwidefsky, Thomas Gleixner, Vincent Chen, linuxppc-dev,
linux-arm-kernel, Greentime Hu
In-Reply-To: <20190416161434.32691-6-vincenzo.frascino@arm.com>
On Tue, Apr 16, 2019 at 05:14:34PM +0100, Vincenzo Frascino wrote:
> 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.
>
> Cc: Shuah Khan <shuah@kernel.org>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> ---
> tools/testing/selftests/vDSO/Makefile | 2 +
> .../selftests/vDSO/vdso_clock_getres.c | 108 ++++++++++++++++++
> 2 files changed, 110 insertions(+)
> create mode 100644 tools/testing/selftests/vDSO/vdso_clock_getres.c
Assuming this will go via Shuah's tree.
Will
^ permalink raw reply
* Re: [PATCH v2 1/5] arm64: Fix vDSO clock_getres()
From: Will Deacon @ 2019-04-16 17:09 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, linux-s390, Shuah Khan, Vincent Chen, Arnd Bergmann,
Heiko Carstens, Paul Mackerras, Greentime Hu, linux-kselftest,
Martin Schwidefsky, Thomas Gleixner, Vincenzo Frascino,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190416162432.GI28994@arrakis.emea.arm.com>
On Tue, Apr 16, 2019 at 05:24:33PM +0100, Catalin Marinas wrote:
> On Tue, Apr 16, 2019 at 05:14:30PM +0100, Vincenzo Frascino wrote:
> > diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> > index 2d419006ad43..5f5759d51c33 100644
> > --- a/arch/arm64/kernel/vdso.c
> > +++ b/arch/arm64/kernel/vdso.c
> > @@ -245,6 +245,8 @@ void update_vsyscall(struct timekeeper *tk)
> > vdso_data->cs_shift = tk->tkr_mono.shift;
> > }
> >
> > + vdso_data->hrtimer_res = hrtimer_resolution;
>
> This should be a WRITE_ONCE(), just in case.
>
> > +
> > smp_wmb();
> > ++vdso_data->tb_seq_count;
> > }
> > diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
> > index c39872a7b03c..e2e9dfe9ba4a 100644
> > --- a/arch/arm64/kernel/vdso/gettimeofday.S
> > +++ b/arch/arm64/kernel/vdso/gettimeofday.S
> > @@ -296,32 +296,32 @@ ENDPROC(__kernel_clock_gettime)
> > /* int __kernel_clock_getres(clockid_t clock_id, struct timespec *res); */
> > ENTRY(__kernel_clock_getres)
> > .cfi_startproc
> > + adr vdso_data, _vdso_data
> > cmp w0, #CLOCK_REALTIME
> > ccmp w0, #CLOCK_MONOTONIC, #0x4, ne
> > ccmp w0, #CLOCK_MONOTONIC_RAW, #0x4, ne
> > - b.ne 1f
> > + b.ne 2f
> >
> > - ldr x2, 5f
> > - b 2f
> > -1:
> > +1: /* Get hrtimer_res */
> > + ldr x2, [vdso_data, #CLOCK_REALTIME_RES]
>
> And here we need an "ldr w2, ..." since hrtimer_res is u32.
>
> With the above (which Will can fix up):
>
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Applied, with the above and a few extra cleanups.
Will
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64/speculation: Support 'mitigations=' cmdline option
From: Thomas Gleixner @ 2019-04-16 19:26 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Steven Price, Linus Torvalds, Catalin Marinas, Waiman Long,
linux-arch, Jon Masters, Jiri Kosina, Borislav Petkov,
Andy Lutomirski, linux-arm-kernel, Phil Auld, Greg Kroah-Hartman,
Randy Dunlap, linux-kernel, Tyler Hicks, Martin Schwidefsky,
linuxppc-dev
In-Reply-To: <24039e1370ed57e8075730c0b88c505afd9e0ab7.1555085500.git.jpoimboe@redhat.com>
On Fri, 12 Apr 2019, Josh Poimboeuf wrote:
> Configure arm64 runtime CPU speculation bug mitigations in accordance
> with the 'mitigations=' cmdline option. This affects Meltdown, Spectre
> v2, and Speculative Store Bypass.
>
> The default behavior is unchanged.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
> NOTE: This is based on top of Jeremy Linton's patches:
> https://lkml.kernel.org/r/20190410231237.52506-1-jeremy.linton@arm.com
So I keep that out and we have to revisit that once the ARM64 stuff hits a
tree, right? I can have a branch with just the 4 first patches applied
which ARM64 folks can pull in when they apply Jeremy's patches before te
merge window.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 00/21] Convert hwmon documentation to ReST
From: Jonathan Corbet @ 2019-04-16 20:19 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-hwmon, Jean Delvare, linux-aspeed, Linux Doc Mailing List,
Andrew Jeffery, Sudeep Holla, Liviu Dudau, linux-kernel,
Mauro Carvalho Chehab, Lorenzo Pieralisi, Paul Mackerras,
Joel Stanley, Mauro Carvalho Chehab, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <f900adea-d231-c00d-847c-33e66e79ea30@roeck-us.net>
On Fri, 12 Apr 2019 20:09:16 -0700
Guenter Roeck <linux@roeck-us.net> wrote:
> The big real-world question is: Is the series good enough for you to accept,
> or do you expect some level of user/kernel separation ?
I guess it can go in; it's forward progress, even if it doesn't make the
improvements I would like to see.
The real question, I guess, is who should take it. I've been seeing a
fair amount of activity on hwmon, so I suspect that the potential for
conflicts is real. Perhaps things would go smoother if it went through
your tree?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64/speculation: Support 'mitigations=' cmdline option
From: Josh Poimboeuf @ 2019-04-16 20:21 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Peter Zijlstra, Heiko Carstens, Paul Mackerras, H . Peter Anvin,
Ingo Molnar, Andrea Arcangeli, linux-s390, x86, Will Deacon,
Steven Price, Linus Torvalds, Catalin Marinas, Waiman Long,
linux-arch, Jon Masters, Jiri Kosina, Borislav Petkov,
Andy Lutomirski, linux-arm-kernel, Phil Auld, Greg Kroah-Hartman,
Randy Dunlap, linux-kernel, Tyler Hicks, Martin Schwidefsky,
linuxppc-dev
In-Reply-To: <alpine.DEB.2.21.1904162124020.1780@nanos.tec.linutronix.de>
On Tue, Apr 16, 2019 at 09:26:13PM +0200, Thomas Gleixner wrote:
> On Fri, 12 Apr 2019, Josh Poimboeuf wrote:
>
> > Configure arm64 runtime CPU speculation bug mitigations in accordance
> > with the 'mitigations=' cmdline option. This affects Meltdown, Spectre
> > v2, and Speculative Store Bypass.
> >
> > The default behavior is unchanged.
> >
> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > ---
> > NOTE: This is based on top of Jeremy Linton's patches:
> > https://lkml.kernel.org/r/20190410231237.52506-1-jeremy.linton@arm.com
>
> So I keep that out and we have to revisit that once the ARM64 stuff hits a
> tree, right? I can have a branch with just the 4 first patches applied
> which ARM64 folks can pull in when they apply Jeremy's patches before te
> merge window.
Sounds good to me (though I guess it's up to the arm64 maintainers how
they want to handle the dependencies).
--
Josh
^ permalink raw reply
* [PATCH v3 00/26] compat_ioctl: cleanups
From: Arnd Bergmann @ 2019-04-16 20:19 UTC (permalink / raw)
To: Alexander Viro
Cc: linux-fbdev, linux-iio, linux-remoteproc, alsa-devel, dri-devel,
platform-driver-x86, linux-ide, linux-mtd, sparclinux,
linux1394-devel, devel, linux-s390, linux-scsi, linux-bluetooth,
y2038, qat-linux, amd-gfx, linux-input, Marcel Holtmann,
linux-media, linux-rtc, Arnd Bergmann, James E.J. Bottomley,
linux-nvme, ceph-devel, linux-arm-kernel, Karsten Keil,
Martin K. Petersen, Greg Kroah-Hartman, linux-usb, linux-wireless,
linux-kernel, linux-rdma, linux-crypto, netdev, linux-fsdevel,
linux-integrity, linuxppc-dev, David S. Miller, linux-btrfs,
linux-ppp
Hi Al,
It took me way longer than I had hoped to revisit this series, see
https://lore.kernel.org/lkml/20180912150142.157913-1-arnd@arndb.de/
for the previously posted version.
I've come to the point where all conversion handlers and most
COMPATIBLE_IOCTL() entries are gone from this file, but for
now, this series only has the parts that have either been reviewed
previously, or that are simple enough to include.
The main missing piece is the SG_IO/SG_GET_REQUEST_TABLE conversion.
I'll post the patches I made for that later, as they need more
testing and review from the scsi maintainers.
I hope you can still take these for the coming merge window, unless
new problems come up.
Arnd
Arnd Bergmann (26):
compat_ioctl: pppoe: fix PPPOEIOCSFWD handling
compat_ioctl: move simple ppp command handling into driver
compat_ioctl: avoid unused function warning for do_ioctl
compat_ioctl: move PPPIOCSCOMPRESS32 to ppp-generic.c
compat_ioctl: move PPPIOCSPASS32/PPPIOCSACTIVE32 to ppp_generic.c
compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t
compat_ioctl: move rtc handling into rtc-dev.c
compat_ioctl: add compat_ptr_ioctl()
compat_ioctl: move drivers to compat_ptr_ioctl
compat_ioctl: use correct compat_ptr() translation in drivers
ceph: fix compat_ioctl for ceph_dir_operations
compat_ioctl: move more drivers to compat_ptr_ioctl
compat_ioctl: move tape handling into drivers
compat_ioctl: move ATYFB_CLK handling to atyfb driver
compat_ioctl: move isdn/capi ioctl translation into driver
compat_ioctl: move rfcomm handlers into driver
compat_ioctl: move hci_sock handlers into driver
compat_ioctl: remove HCIUART handling
compat_ioctl: remove HIDIO translation
compat_ioctl: remove translation for sound ioctls
compat_ioctl: remove IGNORE_IOCTL()
compat_ioctl: remove /dev/random commands
compat_ioctl: remove joystick ioctl translation
compat_ioctl: remove PCI ioctl translation
compat_ioctl: remove /dev/raw ioctl translation
compat_ioctl: remove last RAID handling code
Documentation/networking/ppp_generic.txt | 2 +
arch/um/drivers/hostaudio_kern.c | 1 +
drivers/android/binder.c | 2 +-
drivers/char/ppdev.c | 12 +-
drivers/char/random.c | 1 +
drivers/char/tpm/tpm_vtpm_proxy.c | 12 +-
drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
drivers/dma-buf/dma-buf.c | 4 +-
drivers/dma-buf/sw_sync.c | 2 +-
drivers/dma-buf/sync_file.c | 2 +-
drivers/firewire/core-cdev.c | 12 +-
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
drivers/hid/hidraw.c | 4 +-
drivers/hid/usbhid/hiddev.c | 11 +-
drivers/hwtracing/stm/core.c | 12 +-
drivers/ide/ide-tape.c | 31 +-
drivers/iio/industrialio-core.c | 2 +-
drivers/infiniband/core/uverbs_main.c | 4 +-
drivers/isdn/capi/capi.c | 31 +
drivers/isdn/i4l/isdn_ppp.c | 14 +-
drivers/media/rc/lirc_dev.c | 4 +-
drivers/mfd/cros_ec_dev.c | 4 +-
drivers/misc/cxl/flash.c | 8 +-
drivers/misc/genwqe/card_dev.c | 23 +-
drivers/misc/mei/main.c | 22 +-
drivers/misc/vmw_vmci/vmci_host.c | 2 +-
drivers/mtd/ubi/cdev.c | 36 +-
drivers/net/ppp/ppp_generic.c | 99 +++-
drivers/net/ppp/pppoe.c | 7 +
drivers/net/ppp/pptp.c | 3 +
drivers/net/tap.c | 12 +-
drivers/nvdimm/bus.c | 4 +-
drivers/nvme/host/core.c | 2 +-
drivers/pci/switch/switchtec.c | 2 +-
drivers/platform/x86/wmi.c | 2 +-
drivers/rpmsg/rpmsg_char.c | 4 +-
drivers/rtc/dev.c | 13 +-
drivers/rtc/rtc-vr41xx.c | 10 +
drivers/s390/char/tape_char.c | 41 +-
drivers/sbus/char/display7seg.c | 2 +-
drivers/sbus/char/envctrl.c | 4 +-
drivers/scsi/3w-xxxx.c | 4 +-
drivers/scsi/cxlflash/main.c | 2 +-
drivers/scsi/esas2r/esas2r_main.c | 2 +-
drivers/scsi/megaraid/megaraid_mm.c | 28 +-
drivers/scsi/osst.c | 34 +-
drivers/scsi/pmcraid.c | 4 +-
drivers/scsi/st.c | 35 +-
drivers/staging/android/ion/ion.c | 4 +-
drivers/staging/pi433/pi433_if.c | 12 +-
drivers/staging/vme/devices/vme_user.c | 2 +-
drivers/tee/tee_core.c | 2 +-
drivers/usb/class/cdc-wdm.c | 2 +-
drivers/usb/class/usbtmc.c | 4 +-
drivers/usb/core/devio.c | 16 +-
drivers/usb/gadget/function/f_fs.c | 12 +-
drivers/vfio/vfio.c | 39 +-
drivers/vhost/net.c | 12 +-
drivers/vhost/scsi.c | 12 +-
drivers/vhost/test.c | 12 +-
drivers/vhost/vsock.c | 12 +-
drivers/video/fbdev/aty/atyfb_base.c | 12 +-
drivers/virt/fsl_hypervisor.c | 2 +-
fs/btrfs/super.c | 2 +-
fs/ceph/dir.c | 1 +
fs/ceph/file.c | 2 +-
fs/compat_ioctl.c | 602 +-------------------
fs/fat/file.c | 13 +-
fs/fuse/dev.c | 2 +-
fs/notify/fanotify/fanotify_user.c | 2 +-
fs/userfaultfd.c | 2 +-
include/linux/fs.h | 7 +
include/linux/if_pppox.h | 2 +
include/linux/mtio.h | 58 ++
include/uapi/linux/ppp-ioctl.h | 2 +
include/uapi/linux/ppp_defs.h | 14 +
net/bluetooth/hci_sock.c | 21 +-
net/bluetooth/rfcomm/sock.c | 14 +-
net/l2tp/l2tp_ppp.c | 3 +
net/rfkill/core.c | 2 +-
sound/core/oss/pcm_oss.c | 4 +
sound/oss/dmasound/dmasound_core.c | 2 +
82 files changed, 452 insertions(+), 1034 deletions(-)
create mode 100644 include/linux/mtio.h
--
2.20.0
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devel@driverdev.osuosl.org
Cc: linux-integrity@vger.kernel.org
Cc: qat-linux@intel.com
Cc: linux-crypto@vger.kernel.org
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux1394-devel@lists.sourceforge.net
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-input@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-ide@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-ppp@vger.kernel.org
Cc: linux-nvme@lists.infradead.org
Cc: platform-driver-x86@vger.kernel.org
Cc: linux-remoteproc@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org
Cc: ceph-devel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-bluetooth@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: y2038@lists.linaro.org
^ 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