* Re: [PATCH v3 02/10] include: Move compat_timespec/ timeval to compat_time.h
From: Steven Rostedt @ 2018-01-16 15:34 UTC (permalink / raw)
To: Deepa Dinamani
Cc: tglx, john.stultz, linux-kernel, arnd, y2038, acme, benh,
borntraeger, catalin.marinas, cmetcalf, cohuck, davem, deller,
devel, gerald.schaefer, gregkh, heiko.carstens, hoeppner, hpa,
jejb, jwi, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
mark.rutland, mingo, mpe, oberpar, oprofile-list, paulus, peterz,
ralf, rric, schwidefsky, sebott, sparclinux, sth, ubraun,
will.deacon, x86
In-Reply-To: <20180116021818.24791-3-deepa.kernel@gmail.com>
On Mon, 15 Jan 2018 18:18:10 -0800
Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index 09ad88572746..db25aa15b705 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
> @@ -49,7 +49,7 @@ int ftrace_int3_handler(struct pt_regs *regs);
> #if !defined(__ASSEMBLY__) && !defined(COMPILE_OFFSETS)
>
> #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_IA32_EMULATION)
> -#include <asm/compat.h>
> +#include <linux/compat.h>
>
> /*
> * Because ia32 syscalls do not map to x86_64 syscall numbers
^ permalink raw reply
* Re: [PATCH v3 00/10] posix_clocks: Prepare syscalls for 64 bit time_t conversion
From: Arnd Bergmann @ 2018-01-16 15:18 UTC (permalink / raw)
To: Deepa Dinamani
Cc: Thomas Gleixner, John Stultz, Linux Kernel Mailing List,
y2038 Mailman List, Arnaldo Carvalho de Melo,
Benjamin Herrenschmidt, Christian Borntraeger, Catalin Marinas,
Chris Metcalf, cohuck, David Miller, Helge Deller, devel,
gerald.schaefer, gregkh, Heiko Carstens, Jan Hoeppner,
H. Peter Anvin, James E.J. Bottomley, Julian Wiedmann, Linux API,
linux-arch, open list:RALINK MIPS ARCHITECTURE, Parisc List,
linuxppc-dev, linux-s390, Mark Rutland, Ingo Molnar,
Michael Ellerman, oberpar, oprofile-list, Paul Mackerras,
Peter Zijlstra, Ralf Baechle, Steven Rostedt, Robert Richter,
Martin Schwidefsky, sebott, sparclinux, Stefan Haberland,
Ursula Braun, Will Deacon, the arch/x86 maintainers
In-Reply-To: <20180116021818.24791-1-deepa.kernel@gmail.com>
On Tue, Jan 16, 2018 at 3:18 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
> The series is a preparation series for individual architectures
> to use 64 bit time_t syscalls in compat and 32 bit emulation modes.
>
> This is a follow up to the series Arnd Bergmann posted:
> https://sourceware.org/ml/libc-alpha/2015-05/msg00070.html [1]
>
> Big picture is as per the lwn article:
> https://lwn.net/Articles/643234/ [2]
>
> The series is directed at converting posix clock syscalls:
> clock_gettime, clock_settime, clock_getres and clock_nanosleep
> to use a new data structure __kernel_timespec at syscall boundaries.
> __kernel_timespec maintains 64 bit time_t across all execution modes.
>
> vdso will be handled as part of each architecture when they enable
> support for 64 bit time_t.
>
> The compat syscalls are repurposed to provide backward compatibility
> by using them as native syscalls as well for 32 bit architectures.
> They will continue to use timespec at syscall boundaries.
>
> CONFIG_64_BIT_TIME controls whether the syscalls use __kernel_timespec
> or timespec at syscall boundaries.
>
> The series does the following:
> 1. Enable compat syscalls on 32 bit architectures.
> 2. Add a new __kernel_timespec type to be used as the data structure
> for all the new syscalls.
> 3. Add new config CONFIG_64BIT_TIME(intead of the CONFIG_COMPAT_TIME in
> [1] and [2] to switch to new definition of __kernel_timespec. It is
> the same as struct timespec otherwise.
> 4. Add new CONFIG_32BIT_TIME to conditionally compile compat syscalls.
This looks all good to me. I think we should have this included in linux-next as
soon as possible, but this probably means after -rc1 at the current point, since
it's a bit late for 4.16.
I'll pick up the series into my randconfig build tree again to find
possible build
time regressions. Otherwise the way I'd stage it out is to put it into my y2038
branch after -rc1 and then send a pull request to Thomas for the tip tree
a week later. It seems unlikely that any major problems come up, so we could
plan to address additional requests for changes by adding commits on top
once it's in linux-next.
Arnd
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Andrew Lunn @ 2018-01-16 14:38 UTC (permalink / raw)
To: Joakim Tjernlund
Cc: linuxppc-dev@lists.ozlabs.org, madalin.bucur@nxp.com,
madskateman@gmail.com, netdev@vger.kernel.org
In-Reply-To: <1516035556.18795.71.camel@infinera.com>
> Hi, just saw this and thought of a small patch I just wrote for mdio bus, o idea
> if it is relevant but here goes:
>
> From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <joakim.tjernlund@infinera.com>
> Date: Sun, 14 Jan 2018 21:27:20 +0100
> Subject: [PATCH] of_mdiobus_register: Continue after error
>
> of_mdiobus_register unregister itself if one phy fails to register
> which is bad for system having all its PHYs on the same MDIO bus.
> Just log the error and continue with the remaining PHYs instead.
>
> Signed-off-by: Joakim Tjernlund <joakim.tjernlund@infinera.com>
Hi Joakim
You appear to be using an old kernel. Take a look at:
commit 95f566de0269a0c59fd6a737a147731302136429
Author: Madalin Bucur <madalin.bucur@nxp.com>
Date: Tue Jan 9 14:43:34 2018 +0200
of_mdio: avoid MDIO bus removal when a PHY is missing
If one of the child devices is missing the of_mdiobus_register_phy()
call will return -ENODEV. When a missing device is encountered the
registration of the remaining PHYs is stopped and the MDIO bus will
fail to register. Propagate all errors except ENODEV to avoid it.
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Andrew
^ permalink raw reply
* Re: [PATCH v6 00/24] Speculative page faults
From: Kirill A. Shutemov @ 2018-01-16 15:11 UTC (permalink / raw)
To: Laurent Dufour
Cc: paulmck, peterz, akpm, ak, mhocko, dave, jack, Matthew Wilcox,
benh, mpe, paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <1515777968-867-1-git-send-email-ldufour@linux.vnet.ibm.com>
On Fri, Jan 12, 2018 at 06:25:44PM +0100, Laurent Dufour wrote:
> ------------------
> Benchmarks results
>
> Base kernel is 4.15-rc6-mmotm-2018-01-04-16-19
> SPF is BASE + this series
Do you have THP=always here? Lack of THP support worries me.
What is performance in the worst case scenario? Like when we go far enough into
speculative code path on every page fault and then fallback to normal page
fault?
--
Kirill A. Shutemov
^ permalink raw reply
* Re: DPAA Ethernet traffice troubles with Linux kernel
From: Andrew Lunn @ 2018-01-16 15:04 UTC (permalink / raw)
To: mad skateman
Cc: Christian Zigotzky, Joakim Tjernlund,
linuxppc-dev@lists.ozlabs.org, madalin.bucur@nxp.com,
netdev@vger.kernel.org
In-Reply-To: <CAHkrCmFwMRh7+9ijRhgpqm_dQmE7uH8pv8ZQvLY1rxk1hjhfzw@mail.gmail.com>
> When i use mii-tool too Kick the tranceiver... it comes alive.. i can
> ping the eth0 itself
>
> root@X5000LNX:/home/skateman# mii-tool -R eth0
> resetting the transceiver...
> root@X5000LNX:/home/skateman# ping 192.168.22.44
> PING 192.168.22.44 (192.168.22.44) 56(84) bytes of data.
> 64 bytes from 192.168.22.44: icmp_seq=1 ttl=64 time=0.045 ms
> 64 bytes from 192.168.22.44: icmp_seq=2 ttl=64 time=0.046 ms
> 64 bytes from 192.168.22.44: icmp_seq=3 ttl=64 time=0.047 ms
> 64 bytes from 192.168.22.44: icmp_seq=4 ttl=64 time=0.048 ms
What PHY driver are you using?
This smells a bit like an RGMII-ID problem.
Andrew
^ permalink raw reply
* Re: [PATCH v6 22/24] mm: Speculative page fault handler return VMA
From: Matthew Wilcox @ 2018-01-16 14:58 UTC (permalink / raw)
To: Laurent Dufour
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack, benh, mpe,
paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <6d958348-bece-2c21-e8dc-4e5a65e82f9b@linux.vnet.ibm.com>
On Tue, Jan 16, 2018 at 03:47:51PM +0100, Laurent Dufour wrote:
> On 13/01/2018 05:23, Matthew Wilcox wrote:
> > Of course, we don't need to change them all. Try this:
>
> That would be good candidate for a clean up but I'm not sure this should be
> part of this already too long series.
>
> If you don't mind, unless a global agreement is stated on that, I'd prefer
> to postpone such a change once the initial series is accepted.
Actually, I think this can go in first, independently of the speculative
fault series. It's a win in memory savings, and probably shaves a
cycle or two off the fault handler due to less argument marshalling in
the call-stack.
^ permalink raw reply
* Re: [PATCH v6 22/24] mm: Speculative page fault handler return VMA
From: Laurent Dufour @ 2018-01-16 14:47 UTC (permalink / raw)
To: Matthew Wilcox
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack, benh, mpe,
paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <20180113042354.GA24241@bombadil.infradead.org>
On 13/01/2018 05:23, Matthew Wilcox wrote:
> On Fri, Jan 12, 2018 at 11:02:51AM -0800, Matthew Wilcox wrote:
>> On Fri, Jan 12, 2018 at 06:26:06PM +0100, Laurent Dufour wrote:
>>> @@ -1354,7 +1354,10 @@ extern int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
>>> unsigned int flags);
>>> #ifdef CONFIG_SPF
>>> extern int handle_speculative_fault(struct mm_struct *mm,
>>> + unsigned long address, unsigned int flags,
>>> + struct vm_area_struct **vma);
>>
>> I think this shows that we need to create 'struct vm_fault' on the stack
>> in the arch code and then pass it to handle_speculative_fault(), followed
>> by handle_mm_fault(). That should be quite a nice cleanup actually.
>> I know that's only 30+ architectures to change ;-)
>
> Of course, we don't need to change them all. Try this:
That would be good candidate for a clean up but I'm not sure this should be
part of this already too long series.
If you don't mind, unless a global agreement is stated on that, I'd prefer
to postpone such a change once the initial series is accepted.
Cheers,
Laurent.
> Subject: [PATCH] Add vm_handle_fault
>
> For the speculative fault handler, we want to create the struct vm_fault
> on the stack in the arch code and pass it into the generic mm code.
> To avoid changing 30+ architectures, leave handle_mm_fault with its
> current function signature and move its guts into the new vm_handle_fault
> function. Even this saves a nice 172 bytes on the random x86-64 .config
> I happen to have around.
>
> Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 5eb3d2524bdc..403934297a3d 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3977,36 +3977,28 @@ static int handle_pte_fault(struct vm_fault *vmf)
> * The mmap_sem may have been released depending on flags and our
> * return value. See filemap_fault() and __lock_page_or_retry().
> */
> -static int __handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> - unsigned int flags)
> +static int __handle_mm_fault(struct vm_fault *vmf)
> {
> - struct vm_fault vmf = {
> - .vma = vma,
> - .address = address & PAGE_MASK,
> - .flags = flags,
> - .pgoff = linear_page_index(vma, address),
> - .gfp_mask = __get_fault_gfp_mask(vma),
> - };
> - unsigned int dirty = flags & FAULT_FLAG_WRITE;
> - struct mm_struct *mm = vma->vm_mm;
> + unsigned int dirty = vmf->flags & FAULT_FLAG_WRITE;
> + struct mm_struct *mm = vmf->vma->vm_mm;
> pgd_t *pgd;
> p4d_t *p4d;
> int ret;
>
> - pgd = pgd_offset(mm, address);
> - p4d = p4d_alloc(mm, pgd, address);
> + pgd = pgd_offset(mm, vmf->address);
> + p4d = p4d_alloc(mm, pgd, vmf->address);
> if (!p4d)
> return VM_FAULT_OOM;
>
> - vmf.pud = pud_alloc(mm, p4d, address);
> - if (!vmf.pud)
> + vmf->pud = pud_alloc(mm, p4d, vmf->address);
> + if (!vmf->pud)
> return VM_FAULT_OOM;
> - if (pud_none(*vmf.pud) && transparent_hugepage_enabled(vma)) {
> - ret = create_huge_pud(&vmf);
> + if (pud_none(*vmf->pud) && transparent_hugepage_enabled(vmf->vma)) {
> + ret = create_huge_pud(vmf);
> if (!(ret & VM_FAULT_FALLBACK))
> return ret;
> } else {
> - pud_t orig_pud = *vmf.pud;
> + pud_t orig_pud = *vmf->pud;
>
> barrier();
> if (pud_trans_huge(orig_pud) || pud_devmap(orig_pud)) {
> @@ -4014,50 +4006,51 @@ static int __handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> /* NUMA case for anonymous PUDs would go here */
>
> if (dirty && !pud_access_permitted(orig_pud, WRITE)) {
> - ret = wp_huge_pud(&vmf, orig_pud);
> + ret = wp_huge_pud(vmf, orig_pud);
> if (!(ret & VM_FAULT_FALLBACK))
> return ret;
> } else {
> - huge_pud_set_accessed(&vmf, orig_pud);
> + huge_pud_set_accessed(vmf, orig_pud);
> return 0;
> }
> }
> }
>
> - vmf.pmd = pmd_alloc(mm, vmf.pud, address);
> - if (!vmf.pmd)
> + vmf->pmd = pmd_alloc(mm, vmf->pud, vmf->address);
> + if (!vmf->pmd)
> return VM_FAULT_OOM;
> - if (pmd_none(*vmf.pmd) && transparent_hugepage_enabled(vma)) {
> - ret = create_huge_pmd(&vmf);
> + if (pmd_none(*vmf->pmd) && transparent_hugepage_enabled(vmf->vma)) {
> + ret = create_huge_pmd(vmf);
> if (!(ret & VM_FAULT_FALLBACK))
> return ret;
> } else {
> - pmd_t orig_pmd = *vmf.pmd;
> + pmd_t orig_pmd = *vmf->pmd;
>
> barrier();
> if (unlikely(is_swap_pmd(orig_pmd))) {
> VM_BUG_ON(thp_migration_supported() &&
> !is_pmd_migration_entry(orig_pmd));
> if (is_pmd_migration_entry(orig_pmd))
> - pmd_migration_entry_wait(mm, vmf.pmd);
> + pmd_migration_entry_wait(mm, vmf->pmd);
> return 0;
> }
> if (pmd_trans_huge(orig_pmd) || pmd_devmap(orig_pmd)) {
> - if (pmd_protnone(orig_pmd) && vma_is_accessible(vma))
> - return do_huge_pmd_numa_page(&vmf, orig_pmd);
> + if (pmd_protnone(orig_pmd) &&
> + vma_is_accessible(vmf->vma))
> + return do_huge_pmd_numa_page(vmf, orig_pmd);
>
> if (dirty && !pmd_access_permitted(orig_pmd, WRITE)) {
> - ret = wp_huge_pmd(&vmf, orig_pmd);
> + ret = wp_huge_pmd(vmf, orig_pmd);
> if (!(ret & VM_FAULT_FALLBACK))
> return ret;
> } else {
> - huge_pmd_set_accessed(&vmf, orig_pmd);
> + huge_pmd_set_accessed(vmf, orig_pmd);
> return 0;
> }
> }
> }
>
> - return handle_pte_fault(&vmf);
> + return handle_pte_fault(vmf);
> }
>
> /*
> @@ -4066,9 +4059,10 @@ static int __handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> * The mmap_sem may have been released depending on flags and our
> * return value. See filemap_fault() and __lock_page_or_retry().
> */
> -int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> - unsigned int flags)
> +int vm_handle_fault(struct vm_fault *vmf)
> {
> + unsigned int flags = vmf->flags;
> + struct vm_area_struct *vma = vmf->vma;
> int ret;
>
> __set_current_state(TASK_RUNNING);
> @@ -4092,9 +4086,9 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> mem_cgroup_oom_enable();
>
> if (unlikely(is_vm_hugetlb_page(vma)))
> - ret = hugetlb_fault(vma->vm_mm, vma, address, flags);
> + ret = hugetlb_fault(vma->vm_mm, vma, vmf->address, flags);
> else
> - ret = __handle_mm_fault(vma, address, flags);
> + ret = __handle_mm_fault(vmf);
>
> if (flags & FAULT_FLAG_USER) {
> mem_cgroup_oom_disable();
> @@ -4110,6 +4104,26 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
>
> return ret;
> }
> +
> +/*
> + * By the time we get here, we already hold the mm semaphore
> + *
> + * The mmap_sem may have been released depending on flags and our
> + * return value. See filemap_fault() and __lock_page_or_retry().
> + */
> +int handle_mm_fault(struct vm_area_struct *vma, unsigned long address,
> + unsigned int flags)
> +{
> + struct vm_fault vmf = {
> + .vma = vma,
> + .address = address & PAGE_MASK,
> + .flags = flags,
> + .pgoff = linear_page_index(vma, address),
> + .gfp_mask = __get_fault_gfp_mask(vma),
> + };
> +
> + return vm_handle_fault(&vmf);
> +}
> EXPORT_SYMBOL_GPL(handle_mm_fault);
>
> #ifndef __PAGETABLE_P4D_FOLDED
>
^ permalink raw reply
* Re: [PATCH] powerpc/64s: Allow control of RFI flush via debugfs
From: Nicholas Piggin @ 2018-01-16 14:41 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20180116112431.1737-1-mpe@ellerman.id.au>
On Tue, 16 Jan 2018 22:24:31 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:
> Expose the state of the RFI flush (enabled/disabled) via debugfs, and
> allow it to be enabled/disabled at runtime.
>
> eg: $ cat /sys/kernel/debug/powerpc/rfi_flush
> 1
> $ echo 0 > /sys/kernel/debug/powerpc/rfi_flush
> $ cat /sys/kernel/debug/powerpc/rfi_flush
> 0
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/setup_64.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 624d2a62d05d..e67413f4a8f0 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -38,6 +38,7 @@
> #include <linux/memory.h>
> #include <linux/nmi.h>
>
> +#include <asm/debugfs.h>
> #include <asm/io.h>
> #include <asm/kdump.h>
> #include <asm/prom.h>
> @@ -902,6 +903,35 @@ void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
> rfi_flush_enable(enable);
> }
>
> +#ifdef CONFIG_DEBUG_FS
> +static int rfi_flush_set(void *data, u64 val)
> +{
> + if (val == 1)
> + rfi_flush_enable(true);
> + else if (val == 0)
> + rfi_flush_enable(false);
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int rfi_flush_get(void *data, u64 *val)
> +{
> + *val = rfi_flush ? 1 : 0;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(fops_rfi_flush, rfi_flush_get, rfi_flush_set, "%llu\n");
> +
> +static __init int rfi_flush_debugfs_init(void)
> +{
> + debugfs_create_file("rfi_flush", 0600, powerpc_debugfs_root, NULL, &fops_rfi_flush);
> + return 0;
> +}
> +device_initcall(rfi_flush_debugfs_init);
> +#endif
> +
> ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, char *buf)
> {
> if (rfi_flush)
^ permalink raw reply
* Re: [PATCH v6 18/24] mm: Try spin lock in speculative path
From: Laurent Dufour @ 2018-01-16 13:24 UTC (permalink / raw)
To: Matthew Wilcox
Cc: paulmck, peterz, akpm, kirill, ak, mhocko, dave, jack, benh, mpe,
paulus, Thomas Gleixner, Ingo Molnar, hpa, Will Deacon,
Sergey Senozhatsky, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, sergey.senozhatsky.work, linux-kernel, linux-mm, haren,
khandual, npiggin, bsingharora, Tim Chen, linuxppc-dev, x86
In-Reply-To: <20180112181840.GA7590@bombadil.infradead.org>
On 12/01/2018 19:18, Matthew Wilcox wrote:
> On Fri, Jan 12, 2018 at 06:26:02PM +0100, Laurent Dufour wrote:
>> There is a deadlock when a CPU is doing a speculative page fault and
>> another one is calling do_unmap().
>>
>> The deadlock occurred because the speculative path try to spinlock the
>> pte while the interrupt are disabled. When the other CPU in the
>> unmap's path has locked the pte then is waiting for all the CPU to
>> invalidate the TLB. As the CPU doing the speculative fault have the
>> interrupt disable it can't invalidate the TLB, and can't get the lock.
>>
>> Since we are in a speculative path, we can race with other mm action.
>> So let assume that the lock may not get acquired and fail the
>> speculative page fault.
>
> It seems like you introduced this bug in the previous patch, and now
> you're fixing it in this patch? Why not merge the two?
You're right this is a fix from the previous patch. Initially my idea was
to keep the original Peter's patch as is, but sounds that this is not a
good idea.
I'll merge it in the previous one.
Thanks,
Laurent.
^ permalink raw reply
* [PATCH] powerpc/64s: Allow control of RFI flush via debugfs
From: Michael Ellerman @ 2018-01-16 11:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: npiggin
Expose the state of the RFI flush (enabled/disabled) via debugfs, and
allow it to be enabled/disabled at runtime.
eg: $ cat /sys/kernel/debug/powerpc/rfi_flush
1
$ echo 0 > /sys/kernel/debug/powerpc/rfi_flush
$ cat /sys/kernel/debug/powerpc/rfi_flush
0
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/setup_64.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 624d2a62d05d..e67413f4a8f0 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -38,6 +38,7 @@
#include <linux/memory.h>
#include <linux/nmi.h>
+#include <asm/debugfs.h>
#include <asm/io.h>
#include <asm/kdump.h>
#include <asm/prom.h>
@@ -902,6 +903,35 @@ void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
rfi_flush_enable(enable);
}
+#ifdef CONFIG_DEBUG_FS
+static int rfi_flush_set(void *data, u64 val)
+{
+ if (val == 1)
+ rfi_flush_enable(true);
+ else if (val == 0)
+ rfi_flush_enable(false);
+ else
+ return -EINVAL;
+
+ return 0;
+}
+
+static int rfi_flush_get(void *data, u64 *val)
+{
+ *val = rfi_flush ? 1 : 0;
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(fops_rfi_flush, rfi_flush_get, rfi_flush_set, "%llu\n");
+
+static __init int rfi_flush_debugfs_init(void)
+{
+ debugfs_create_file("rfi_flush", 0600, powerpc_debugfs_root, NULL, &fops_rfi_flush);
+ return 0;
+}
+device_initcall(rfi_flush_debugfs_init);
+#endif
+
ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, char *buf)
{
if (rfi_flush)
--
2.14.3
^ permalink raw reply related
* [PATCH] powerpc/64s: Wire up cpu_show_meltdown()
From: Michael Ellerman @ 2018-01-16 11:24 UTC (permalink / raw)
To: linuxppc-dev
The recent commit 87590ce6e373 ("sysfs/cpu: Add vulnerability folder")
added a generic folder and set of files for reporting information on
CPU vulnerabilities. One of those was for meltdown:
/sys/devices/system/cpu/vulnerabilities/meltdown
This commit wires up that file for 64-bit Book3S powerpc.
For now we default to "Vulnerable" unless the RFI flush is enabled.
That may not actually be true on all hardware, further patches will
refine the reporting based on the CPU/platform etc. But for now we
default to being pessimists.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/kernel/setup_64.c | 8 ++++++++
2 files changed, 9 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c51e6ce42e7a..2ed525a44734 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -166,6 +166,7 @@ config PPC
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
+ select GENERIC_CPU_VULNERABILITIES if PPC_BOOK3S_64
select GENERIC_IRQ_SHOW
select GENERIC_IRQ_SHOW_LEVEL
select GENERIC_SMP_IDLE_THREAD
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 491be4179ddd..624d2a62d05d 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -901,4 +901,12 @@ void __init setup_rfi_flush(enum l1d_flush_type types, bool enable)
if (!no_rfi_flush)
rfi_flush_enable(enable);
}
+
+ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ if (rfi_flush)
+ return sprintf(buf, "Mitigation: RFI Flush\n");
+
+ return sprintf(buf, "Vulnerable\n");
+}
#endif /* CONFIG_PPC_BOOK3S_64 */
--
2.14.3
^ permalink raw reply related
* Re: [PATCH 3/6] gpio: Add GPIO driver for Nintendo Wii
From: Linus Walleij @ 2018-01-16 9:42 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org list,
linux-gpio,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Albert Herranz, Segher Boessenkool
In-Reply-To: <20180115031401.19577-4-j.neuschaefer@gmx.net>
On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neusch=C3=A4fer
<j.neuschaefer@gmx.net> wrote:
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissimilar.
I'm impressed by this effort. As with all reverse engineering.
> This driver currently uses __raw_readl and __raw_writel to access the
> GPIO controller's MMIO registers. I wonder if readl/writel plus explicit
> byte-swapping would be more correct, because it could be independent of
> the CPU's endianness. That said, this hardware only exists in two
> big-endian machines (Wii and Wii U).
I don't know about PPC but I think you're supposed to use
ioread32be() and iowrite32be() to do explicit BE access.
But when I look at it, I think you can just use the gpio-mmio library
for this driver and cut down code cosiderably.
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Can't you just save a pointer to struct device *dev in the
state container and use dev_info(state->dev, ...) etc instead
of this?
> +#include <linux/of_gpio.h>
This include should not be needed.
> +/*
> + * Update the bit with the given bit offset in the given register to a g=
iven
> + * value
> + */
> +static void hlwd_gpio_update_bit(struct gpio_chip *gc, unsigned int reg,
> + int offset, int value)
> +{
> + struct hlwd_gpio *hlwd =3D gpiochip_get_data(gc);
> + unsigned long flags;
> + u32 bit =3D 1UL << offset;
#include <linux/bitops.h>
u32 bit =3D BIT(offset);
> + u32 tmp;
> +
> + spin_lock_irqsave(&hlwd->lock, flags);
> + tmp =3D __raw_readl(hlwd->regs + reg);
> + if (value)
> + __raw_writel(tmp | bit, hlwd->regs + reg);
> + else
> + __raw_writel(tmp & ~bit, hlwd->regs + reg);
> + spin_unlock_irqrestore(&hlwd->lock, flags);
> +}
This looks very much like it is reimplementing the stuff we already
have in drivers/gpio/gpio-mmio.h.
There is even a big endian access flag for the library.
And you get so much for free with gpio-mmio.
select GPIO_GENERIC
in Kconfig
the helpers come in from <linux/gpio/driver.h>
Look at other drivers for inspiration:
git grep bgpio_init
If you need IRQ support you should probably have your own file
for this driver, but it will be just a few lines of wrapper using
bgpio_init() and BGPIOF_BIG_ENDIAN and/or possibly
BGPIOF_BIG_ENDIAN_BYTE_ORDER.
See the other drivers.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] net: fs_enet: do not call phy_stop() in interrupts
From: Christophe Leroy @ 2018-01-16 9:33 UTC (permalink / raw)
To: Pantelis Antoniou, Vitaly Bordug, David Miller
Cc: linux-kernel, linuxppc-dev, netdev
In case of TX timeout, fs_timeout() calls phy_stop(), which
triggers the following BUG_ON() as we are in interrupt.
[92708.199889] kernel BUG at drivers/net/phy/mdio_bus.c:482!
[92708.204985] Oops: Exception in kernel mode, sig: 5 [#1]
[92708.210119] PREEMPT
[92708.212107] CMPC885
[92708.214216] CPU: 0 PID: 3 Comm: ksoftirqd/0 Tainted: G W 4.9.61 #39
[92708.223227] task: c60f0a40 task.stack: c6104000
[92708.227697] NIP: c02a84bc LR: c02a947c CTR: c02a93d8
[92708.232614] REGS: c6105c70 TRAP: 0700 Tainted: G W (4.9.61)
[92708.241193] MSR: 00021032 <ME,IR,DR,RI>[92708.244818] CR: 24000822 XER: 20000000
[92708.248767]
GPR00: c02a947c c6105d20 c60f0a40 c62b4c00 00000005 0000001f c069aad8 0001a688
GPR08: 00000007 00000100 c02a93d8 00000000 000005fc 00000000 c6213240 c06338e4
GPR16: 00000001 c06330d4 c0633094 00000000 c0680000 c6104000 c6104000 00000000
GPR24: 00000200 00000000 ffffffff 00000004 00000078 00009032 00000000 c62b4c00
NIP [c02a84bc] mdiobus_read+0x20/0x74
[92708.281517] LR [c02a947c] kszphy_config_intr+0xa4/0xc4
[92708.286547] Call Trace:
[92708.288980] [c6105d20] [c6104000] 0xc6104000 (unreliable)
[92708.294339] [c6105d40] [c02a947c] kszphy_config_intr+0xa4/0xc4
[92708.300098] [c6105d50] [c02a5330] phy_stop+0x60/0x9c
[92708.305007] [c6105d60] [c02c84d0] fs_timeout+0xdc/0x110
[92708.310197] [c6105d80] [c035cd48] dev_watchdog+0x268/0x2a0
[92708.315593] [c6105db0] [c0060288] call_timer_fn+0x34/0x17c
[92708.321014] [c6105dd0] [c00605f0] run_timer_softirq+0x21c/0x2e4
[92708.326887] [c6105e50] [c001e19c] __do_softirq+0xf4/0x2f4
[92708.332207] [c6105eb0] [c001e3c8] run_ksoftirqd+0x2c/0x40
[92708.337560] [c6105ec0] [c003b420] smpboot_thread_fn+0x1f0/0x258
[92708.343405] [c6105ef0] [c003745c] kthread+0xbc/0xd0
[92708.348217] [c6105f40] [c000c400] ret_from_kernel_thread+0x5c/0x64
[92708.354275] Instruction dump:
[92708.357207] 7c0803a6 bbc10018 38210020 4e800020 7c0802a6 9421ffe0 54290024 bfc10018
[92708.364865] 90010024 7c7f1b78 81290008 552902ee <0f090000> 3bc3002c 7fc3f378 90810008
[92708.372711] ---[ end trace 42b05441616fafd7 ]---
This patch moves fs_timeout() actions into an async worker.
Fixes: commit 48257c4f168e5 ("Add fs_enet ethernet network driver, for several embedded platforms")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 16 +++++++++++++---
drivers/net/ethernet/freescale/fs_enet/fs_enet.h | 1 +
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 7892f2f0c6b5..2c2976a2dda6 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -613,9 +613,11 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_OK;
}
-static void fs_timeout(struct net_device *dev)
+static void fs_timeout_work(struct work_struct *work)
{
- struct fs_enet_private *fep = netdev_priv(dev);
+ struct fs_enet_private *fep = container_of(work, struct fs_enet_private,
+ timeout_work);
+ struct net_device *dev = fep->ndev;
unsigned long flags;
int wake = 0;
@@ -627,7 +629,6 @@ static void fs_timeout(struct net_device *dev)
phy_stop(dev->phydev);
(*fep->ops->stop)(dev);
(*fep->ops->restart)(dev);
- phy_start(dev->phydev);
}
phy_start(dev->phydev);
@@ -639,6 +640,13 @@ static void fs_timeout(struct net_device *dev)
netif_wake_queue(dev);
}
+static void fs_timeout(struct net_device *dev)
+{
+ struct fs_enet_private *fep = netdev_priv(dev);
+
+ schedule_work(&fep->timeout_work);
+}
+
/*-----------------------------------------------------------------------------
* generic link-change handler - should be sufficient for most cases
*-----------------------------------------------------------------------------*/
@@ -759,6 +767,7 @@ static int fs_enet_close(struct net_device *dev)
netif_stop_queue(dev);
netif_carrier_off(dev);
napi_disable(&fep->napi);
+ cancel_work_sync(&fep->timeout_work);
phy_stop(dev->phydev);
spin_lock_irqsave(&fep->lock, flags);
@@ -1019,6 +1028,7 @@ static int fs_enet_probe(struct platform_device *ofdev)
ndev->netdev_ops = &fs_enet_netdev_ops;
ndev->watchdog_timeo = 2 * HZ;
+ INIT_WORK(&fep->timeout_work, fs_timeout_work);
netif_napi_add(ndev, &fep->napi, fs_enet_napi, fpi->napi_weight);
ndev->ethtool_ops = &fs_ethtool_ops;
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet.h b/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
index 92e06b37a199..195fae6aec4a 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
@@ -125,6 +125,7 @@ struct fs_enet_private {
spinlock_t lock; /* during all ops except TX pckt processing */
spinlock_t tx_lock; /* during fs_start_xmit and fs_tx */
struct fs_platform_info *fpi;
+ struct work_struct timeout_work;
const struct fs_ops *ops;
int rx_ring, tx_ring;
dma_addr_t ring_mem_addr;
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v3 02/10] include: Move compat_timespec/ timeval to compat_time.h
From: Catalin Marinas @ 2018-01-16 9:30 UTC (permalink / raw)
To: Deepa Dinamani
Cc: tglx, john.stultz, linux-kernel, arnd, y2038, acme, benh,
borntraeger, cmetcalf, cohuck, davem, deller, devel,
gerald.schaefer, gregkh, heiko.carstens, hoeppner, hpa, jejb, jwi,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, mark.rutland,
mingo, mpe, oberpar, oprofile-list, paulus, peterz, ralf, rostedt,
rric, schwidefsky, sebott, sparclinux, sth, ubraun, will.deacon,
x86
In-Reply-To: <20180116021818.24791-3-deepa.kernel@gmail.com>
On Mon, Jan 15, 2018 at 06:18:10PM -0800, Deepa Dinamani wrote:
> All the current architecture specific defines for these
> are the same. Refactor these common defines to a common
> header file.
>
> The new common linux/compat_time.h is also useful as it
> will eventually be used to hold all the defines that
> are needed for compat time types that support non y2038
> safe types. New architectures need not have to define these
> new types as they will only use new y2038 safe syscalls.
> This file can be deleted after y2038 when we stop supporting
> non y2038 safe syscalls.
For arm64:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
From: Linus Walleij @ 2018-01-16 9:28 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org list,
linux-gpio,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Mark Rutland, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
In-Reply-To: <20180115031401.19577-5-j.neuschaefer@gmx.net>
On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neusch=C3=A4fer
<j.neuschaefer@gmx.net> wrote:
maybe some small blurb here?
> Signed-off-by: Jonathan Neusch=C3=A4fer <j.neuschaefer@gmx.net>
It looks good, very standard bindings.
Yours,
Linus Walleij
^ permalink raw reply
* Re: consolidate swiotlb dma_map implementations
From: Christian König @ 2018-01-16 8:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Konrad Rzeszutek Wilk, Christoph Hellwig, iommu, linux-arch,
linux-mips, Michal Simek, linux-ia64, x86, linux-kernel,
Guan Xuetao, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20180116082827.GA9211@lst.de>
Am 16.01.2018 um 09:28 schrieb Christoph Hellwig:
> On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote:
>> Hi Konrad,
>>
>> can you send the first patch to Linus for inclusion in 4.15 if you haven't
>> already done so?
> It's in the 4.16 queue with a cc to stable. I guess we're ok with
> a duplicate commit if we have to.
Yeah, while it's only a false positive warning it would be really nice
to have in 4.15.
It affects all drivers using TTM in the system and not just the two I'm
the maintainer of.
Regards,
Christian.
^ permalink raw reply
* Re: consolidate swiotlb dma_map implementations
From: Christoph Hellwig @ 2018-01-16 8:28 UTC (permalink / raw)
To: christian.koenig
Cc: Konrad Rzeszutek Wilk, Christoph Hellwig, Christoph Hellwig,
iommu, linux-arch, linux-mips, Michal Simek, linux-ia64, x86,
linux-kernel, Guan Xuetao, linuxppc-dev, linux-arm-kernel
In-Reply-To: <76e47666-3de1-68cc-07ad-003491d26ef9@gmail.com>
On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote:
> Hi Konrad,
>
> can you send the first patch to Linus for inclusion in 4.15 if you haven't
> already done so?
It's in the 4.16 queue with a cc to stable. I guess we're ok with
a duplicate commit if we have to.
^ permalink raw reply
* Re: consolidate swiotlb dma_map implementations
From: Christian König @ 2018-01-16 8:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Christoph Hellwig, Christoph Hellwig, iommu, linux-arch,
linux-mips, Michal Simek, linux-ia64, x86, linux-kernel,
Guan Xuetao, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20180116075338.GB12693@infradead.org>
Hi Konrad,
can you send the first patch to Linus for inclusion in 4.15 if you
haven't already done so?
I'm still getting reports from people complaining about the error message.
Thanks,
Christian.
Am 16.01.2018 um 08:53 schrieb Christoph Hellwig:
> I've pulled this into the dma-mapping for-next tree, including the
> missing free_pages noted. I'd be fine to rebase another day or two
> for additional reviews or important fixes.
^ permalink raw reply
* Re: consolidate swiotlb dma_map implementations
From: Christoph Hellwig @ 2018-01-16 7:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: iommu, linux-arch, linux-mips, Michal Simek, linux-ia64,
Christian König, x86, linux-kernel, Konrad Rzeszutek Wilk,
Guan Xuetao, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20180110080932.14157-1-hch@lst.de>
I've pulled this into the dma-mapping for-next tree, including the
missing free_pages noted. I'd be fine to rebase another day or two
for additional reviews or important fixes.
^ permalink raw reply
* Re: consolidate direct dma mapping V4
From: Christoph Hellwig @ 2018-01-16 7:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: iommu, linux-mips, linux-ia64, linux-sh, sparclinux, Guan Xuetao,
linux-arch, linux-s390, linux-c6x-dev, linux-hexagon, x86,
Konrad Rzeszutek Wilk, linux-snps-arc, linux-m68k, patches,
linux-metag, linux-arm-kernel, Michal Simek, linux-parisc,
linux-cris-kernel, linux-kernel, linux-alpha, linuxppc-dev
In-Reply-To: <20180112084232.2857-1-hch@lst.de>
I've pulled this into the dma-mapping for-next branch so that we get
a few days exposure before then end of the merge window. If there is
anything important (e.g. the powerpc naming issue) please send
incremental patches.
^ permalink raw reply
* [PATCH] powerpc/8xx: do not select CONFIG_PPC_LIB_RHEAP
From: Christophe Leroy @ 2018-01-16 7:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood
Cc: linux-kernel, linuxppc-dev
Since commit 0e6e01ff694ee ("CPM/QE: use genalloc to manage CPM/QE
muram"), rheap is not used anymore.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/platforms/Kconfig.cputype | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 8944b24d2218..5a8b1bf1e819 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -33,7 +33,6 @@ config PPC_85xx
config PPC_8xx
bool "Freescale 8xx"
select FSL_SOC
- select PPC_LIB_RHEAP
select SYS_SUPPORTS_HUGETLBFS
config 40x
--
2.13.3
^ permalink raw reply related
* Re: [PATCH] EDAC, mv64x60: Remove some code duplication
From: Christophe JAILLET @ 2018-01-16 6:19 UTC (permalink / raw)
To: Michael Ellerman, Chris Packham, Borislav Petkov
Cc: mchehab@kernel.org, linux-edac@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <87bmhubvou.fsf@concordia.ellerman.id.au>
Le 15/01/2018 à 23:31, Michael Ellerman a écrit :
> Chris Packham <Chris.Packham@alliedtelesis.co.nz> writes:
>> On 14/01/18 06:17, Christophe JAILLET wrote:
>>> Le 13/01/2018 à 15:22, Borislav Petkov a écrit :
>>>> + Chris Packham who's been fixing some stuff in here too.
>>>>
>>>> On Sat, Jan 13, 2018 at 08:28:21AM +0100, Christophe JAILLET wrote:
>>>>> Reorder the error handling code in order to release the resources in
>>>>> reverse order than allocation.
>>>>>
>>>>> Introduce a new 'release_group' label in the error handling path and use
>>>>> it to void some code duplication.
>>>>>
>>>>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>>>>> ---
>>>>> drivers/edac/mv64x60_edac.c | 7 ++++---
>>>>> 1 file changed, 4 insertions(+), 3 deletions(-)
> ...
>>>>>
>>>>> --
>>>> Thanks, looks good. But looking at this driver, mv64x60_mc_err_probe()
>>>> and mv64x60_sram_err_probe() have the same problem too. Can you address them
>>>> with your patch too pls?
>>> Will do. mv64x60_pci_err_probe() also needs some tweaks.
>>>
>>>> Also, if you feel like fixing more stuff in this driver, it doesn't use
>>>> the edac_printk() infrastructure but naked printk() calls. It could be
>>>> converted to it.
>>> I will only propose to remove a useless message and improve another one,
>>> but won't convert the whole driver, sorry.
>>>
>> I take this you mean you have a system with a mv64x60 SoC? You might
>> want to make yourself known to the linuxppc-dev list. A while back the
>> prospects of dropping CONFIG_MV64X60 was raised[1]. I don't see anyone
>> actually following through on this yet but I'm not really following
>> linuxppc that closely.
> That's just because I haven't had time to do it and no one else took the
> hint :)
>
> So yes, Christophe if you have a machine that uses this driver please
> speak up, otherwise it will probably be removed.
>
> cheers
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi,
No I don't have.
I use static checker to find some potential issues in Linux (most of the
time, with my own coccinelle scripts).
Before proposing some patches, I check if the development on the
corresponding files is still active.
This driver looked active (i.e. there were several recent commits, even
if only cleanups).
If it is nearly dead, my small fixes/cleanups are useless, and I will
leave it as-is.
Thanks for pointing this out. I'll dig somewhere else :)
For the records, and if someone is interested, in order to search for
"active" files in what I've touched, I use:
(this is a slightly updated version of a script found on Internet)
# date of the last modification of updated files
git status -s -uno | while read mode file; do echo "$(git log -1
--date=format:'%Y%m%d_%H:%M:%S' --format=%cd $file) $file"; done |
sort -s -n -k 1,1 > last_modified.txt
When I find a potential candidate, I then have a look in its recent
history with 'git log' or with
'https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/...'
Best regards,
CJ
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: include linux/types.h in asm/hvcall.h
From: David Gibson @ 2018-01-16 4:53 UTC (permalink / raw)
To: Michael Ellerman
Cc: Michal Suchanek, Benjamin Herrenschmidt, Paul Mackerras,
Philippe Ombredanne, Cédric Le Goater, Thomas Falcon,
Tobin C. Harding, Michael Neuling, linuxppc-dev, linux-kernel
In-Reply-To: <87wp0ia3x1.fsf@concordia.ellerman.id.au>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On Tue, Jan 16, 2018 at 02:16:58PM +1100, Michael Ellerman wrote:
> Michal Suchanek <msuchanek@suse.de> writes:
>
> > Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> > settings") uses u64 in asm/hvcall.h without including linux/types.h
> >
> > This breaks hvcall.h users that do not include the header themselves.
> >
> > Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> > settings")
> >
> > Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> > ---
> > arch/powerpc/include/asm/hvcall.h | 1 +
> > 1 file changed, 1 insertion(+)
>
> Thanks. None of my ~250 defconfig test builds hit this, what config are
> you using?
I also hit this, but only when I backported the change to RH's 3.10
kernel. I assumed something since then had added an indirect include.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc/npu: Cleanup MMIO ATSD flushing
From: Alistair Popple @ 2018-01-16 4:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Balbir Singh, aneesh.kumar
In-Reply-To: <20171214011008.4388-1-bsingharora@gmail.com>
Thanks Balbir, one question below. I have no way of testing this at present but
it looks ok to me. Thanks!
On Thursday, 14 December 2017 12:10:08 PM AEDT Balbir Singh wrote:
> While reviewing the code I found that the flush assumes all
> pages are of mmu_linear_psize, which is not correct. The patch
> uses find_linux_pte to find the right page size and uses that
> for launching the ATSD invalidation. A new helper is added
> to abstract the invalidation from the various notifiers.
>
> The patch also cleans up a bit by removing AP size from PID
> flushes.
>
> Signed-off-by: Balbir Singh <bsingharora@gmail.com>
> ---
>
> Changelog:
> Refactor the handling of return values from find_linux_pte
> as suggested by Aneesh
>
> arch/powerpc/platforms/powernv/npu-dma.c | 55 ++++++++++++++++++++++----------
> 1 file changed, 38 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/npu-dma.c b/arch/powerpc/platforms/powernv/npu-dma.c
> index f6cbc1a71472..e8caa3e2019d 100644
> --- a/arch/powerpc/platforms/powernv/npu-dma.c
> +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> @@ -17,6 +17,7 @@
> #include <linux/pci.h>
> #include <linux/memblock.h>
> #include <linux/iommu.h>
> +#include <linux/huge_mm.h>
>
> #include <asm/tlb.h>
> #include <asm/powernv.h>
> @@ -27,6 +28,7 @@
> #include <asm/pnv-pci.h>
> #include <asm/msi_bitmap.h>
> #include <asm/opal.h>
> +#include <asm/pte-walk.h>
>
> #include "powernv.h"
> #include "pci.h"
> @@ -460,9 +462,6 @@ static int mmio_invalidate_pid(struct npu *npu, unsigned long pid, bool flush)
> /* PRS set to process-scoped */
> launch |= PPC_BIT(13);
>
> - /* AP */
> - launch |= (u64) mmu_get_ap(mmu_virtual_psize) << PPC_BITLSHIFT(17);
>
> /* PID */
> launch |= pid << PPC_BITLSHIFT(38);
>
> @@ -474,7 +473,8 @@ static int mmio_invalidate_pid(struct npu *npu, unsigned long pid, bool flush)
> }
>
> static int mmio_invalidate_va(struct npu *npu, unsigned long va,
> - unsigned long pid, bool flush)
> + unsigned long pid, bool flush,
> + unsigned int shift)
> {
> unsigned long launch;
>
> @@ -485,9 +485,8 @@ static int mmio_invalidate_va(struct npu *npu, unsigned long va,
> launch |= PPC_BIT(13);
>
> /* AP */
> - launch |= (u64) mmu_get_ap(mmu_virtual_psize) << PPC_BITLSHIFT(17);
> + launch |= (u64) mmu_get_ap(shift) << PPC_BITLSHIFT(17);
>
> - /* PID */
> launch |= pid << PPC_BITLSHIFT(38);
>
> /* No flush */
> @@ -504,7 +503,8 @@ struct mmio_atsd_reg {
> };
>
> static void mmio_invalidate_wait(
> - struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS], bool flush)
> + struct mmio_atsd_reg mmio_atsd_reg[NV_MAX_NPUS], bool flush,
> + unsigned int shift)
> {
> struct npu *npu;
> int i, reg;
> @@ -537,7 +537,8 @@ static void mmio_invalidate_wait(
> * the value of va.
> */
> static void mmio_invalidate(struct npu_context *npu_context, int va,
> - unsigned long address, bool flush)
> + unsigned long address, bool flush,
> + unsigned int shift)
> {
> int i, j;
> struct npu *npu;
> @@ -572,7 +573,7 @@ static void mmio_invalidate(struct npu_context *npu_context, int va,
> if (va)
> mmio_atsd_reg[i].reg =
> mmio_invalidate_va(npu, address, pid,
> - flush);
> + flush, shift);
> else
> mmio_atsd_reg[i].reg =
> mmio_invalidate_pid(npu, pid, flush);
> @@ -585,10 +586,32 @@ static void mmio_invalidate(struct npu_context *npu_context, int va,
> }
> }
>
> - mmio_invalidate_wait(mmio_atsd_reg, flush);
> + mmio_invalidate_wait(mmio_atsd_reg, flush, shift);
> if (flush)
> /* Wait for the flush to complete */
> - mmio_invalidate_wait(mmio_atsd_reg, false);
> + mmio_invalidate_wait(mmio_atsd_reg, false, shift);
> +}
> +
> +static void pnv_npu2_invalidate_helper(struct npu_context *npu_context,
> + struct mm_struct *mm, unsigned long start,
> + unsigned long end, bool flush)
> +{
> + unsigned long address;
> + unsigned int hshift = 0, shift;
> +
> + address = start;
> + do {
> + local_irq_disable();
> + find_linux_pte(mm->pgd, address, NULL, &hshift);
> + if (hshift)
> + shift = hshift;
> + else
> + shift = PAGE_SHIFT;
Looks better, thanks!
Also in future we might be able to futher optimise this as I don't think the
shift needs to match the actual page size as we are directly issuing ATSDs to
the GPU. ie. we could bump shift to cover the whole of (start, end) or to
invalidate larger chunks at a time - I don't think we need to limit it to
PAGE_SHIFT.
> + mmio_invalidate(npu_context, address > 0, address, flush,
> + shift);
If address == 0 we end up invalidating the entire PID rather than just the page
at address 0. Probably not a big issue though as I'm guessing we wouldn't
actually see invalidations for the page@0 very often?
> + local_irq_enable();
> + address += (1ull << shift);
> + } while (address < end);
> }
>
> static void pnv_npu2_mn_release(struct mmu_notifier *mn,
> @@ -604,7 +627,7 @@ static void pnv_npu2_mn_release(struct mmu_notifier *mn,
> * There should be no more translation requests for this PID, but we
> * need to ensure any entries for it are removed from the TLB.
> */
> - mmio_invalidate(npu_context, 0, 0, true);
> + pnv_npu2_invalidate_helper(npu_context, mm, 0, PAGE_SIZE, true);
> }
>
> static void pnv_npu2_mn_change_pte(struct mmu_notifier *mn,
> @@ -614,7 +637,7 @@ static void pnv_npu2_mn_change_pte(struct mmu_notifier *mn,
> {
> struct npu_context *npu_context = mn_to_npu_context(mn);
>
> - mmio_invalidate(npu_context, 1, address, true);
> + pnv_npu2_invalidate_helper(npu_context, mm, address, address, true);
> }
>
> static void pnv_npu2_mn_invalidate_range(struct mmu_notifier *mn,
> @@ -622,13 +645,11 @@ static void pnv_npu2_mn_invalidate_range(struct mmu_notifier *mn,
> unsigned long start, unsigned long end)
> {
> struct npu_context *npu_context = mn_to_npu_context(mn);
> - unsigned long address;
>
> - for (address = start; address < end; address += PAGE_SIZE)
> - mmio_invalidate(npu_context, 1, address, false);
> + pnv_npu2_invalidate_helper(npu_context, mm, start, end, false);
>
> /* Do the flush only on the final addess == end */
> - mmio_invalidate(npu_context, 1, address, true);
> + pnv_npu2_invalidate_helper(npu_context, mm, end, end, true);
> }
>
> static const struct mmu_notifier_ops nv_nmmu_notifier_ops = {
>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: include linux/types.h in asm/hvcall.h
From: Michael Ellerman @ 2018-01-16 3:16 UTC (permalink / raw)
To: Michal Suchanek, Benjamin Herrenschmidt, Paul Mackerras,
Philippe Ombredanne, Cédric Le Goater, David Gibson,
Thomas Falcon, Michal Suchanek, Tobin C. Harding, Michael Neuling,
linuxppc-dev, linux-kernel
In-Reply-To: <20180115133003.3447-1-msuchanek@suse.de>
Michal Suchanek <msuchanek@suse.de> writes:
> Commit 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> settings") uses u64 in asm/hvcall.h without including linux/types.h
>
> This breaks hvcall.h users that do not include the header themselves.
>
> Fixes: 6e032b350cd1 ("powerpc/powernv: Check device-tree for RFI flush
> settings")
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> ---
> arch/powerpc/include/asm/hvcall.h | 1 +
> 1 file changed, 1 insertion(+)
Thanks. None of my ~250 defconfig test builds hit this, what config are
you using?
cheers
> diff --git a/arch/powerpc/include/asm/hvcall.h b/arch/powerpc/include/asm/hvcall.h
> index f0461618bf7b..eca3f9c68907 100644
> --- a/arch/powerpc/include/asm/hvcall.h
> +++ b/arch/powerpc/include/asm/hvcall.h
> @@ -353,6 +353,7 @@
> #define PROC_TABLE_GTSE 0x01
>
> #ifndef __ASSEMBLY__
> +#include <linux/types.h>
>
> /**
> * plpar_hcall_norets: - Make a pseries hypervisor call with no return arguments
> --
> 2.13.6
^ 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