* Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses
From: Khalid Aziz @ 2019-06-21 15:35 UTC (permalink / raw)
To: Jason Gunthorpe, Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, linux-mips, Nicholas Piggin, linux-kernel, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller
In-Reply-To: <20190621133911.GL19891@ziepe.ca>
On 6/21/19 7:39 AM, Jason Gunthorpe wrote:
> On Tue, Jun 11, 2019 at 04:40:47PM +0200, Christoph Hellwig wrote:
>> This will allow sparc64 to override its ADI tags for
>> get_user_pages and get_user_pages_fast.
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> mm/gup.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index ddde097cf9e4..6bb521db67ec 100644
>> +++ b/mm/gup.c
>> @@ -2146,7 +2146,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
>> unsigned long flags;
>> int nr = 0;
>>
>> - start &= PAGE_MASK;
>> + start = untagged_addr(start) & PAGE_MASK;
>> len = (unsigned long) nr_pages << PAGE_SHIFT;
>> end = start + len;
>
> Hmm, this function, and the other, goes on to do:
>
> if (unlikely(!access_ok((void __user *)start, len)))
> return 0;
>
> and I thought that access_ok takes in the tagged pointer?
>
> How about re-order it a bit?
access_ok() can handle tagged or untagged pointers. It just strips the
tag bits from the top bits. Current order doesn't really matter from
functionality point of view. There might be minor gain in delaying
untagging in __get_user_pages_fast() but I could go either way.
--
Khalid
>
> diff --git a/mm/gup.c b/mm/gup.c
> index ddde097cf9e410..f48747ced4723b 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2148,11 +2148,12 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
>
> start &= PAGE_MASK;
> len = (unsigned long) nr_pages << PAGE_SHIFT;
> - end = start + len;
> -
> if (unlikely(!access_ok((void __user *)start, len)))
> return 0;
>
> + start = untagged_ptr(start);
> + end = start + len;
> +
> /*
> * Disable interrupts. We use the nested form as we can already have
> * interrupts disabled by get_futex_key.
>
^ permalink raw reply
* Re: [PATCH v3 5/6] mm/memory_hotplug: Move and simplify walk_memory_blocks()
From: David Hildenbrand @ 2019-06-21 15:26 UTC (permalink / raw)
To: linux-kernel
Cc: Oscar Salvador, Stephen Rothwell, Michal Hocko, Pavel Tatashin,
linux-mm, mike.travis@hpe.com, Greg Kroah-Hartman,
Rafael J. Wysocki, Wei Yang, linux-acpi, Andrew Banman, Arun KS,
Qian Cai, Dan Williams, linuxppc-dev, Andrew Morton
In-Reply-To: <20190620183139.4352-6-david@redhat.com>
On 20.06.19 20:31, David Hildenbrand wrote:
> Let's move walk_memory_blocks() to the place where memory block logic
> resides and simplify it. While at it, add a type for the callback function.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
> Cc: Andrew Banman <andrew.banman@hpe.com>
> Cc: "mike.travis@hpe.com" <mike.travis@hpe.com>
> Cc: Oscar Salvador <osalvador@suse.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Arun KS <arunks@codeaurora.org>
> Cc: Qian Cai <cai@lca.pw>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> drivers/base/memory.c | 42 ++++++++++++++++++++++++++
> include/linux/memory.h | 3 ++
> include/linux/memory_hotplug.h | 2 --
> mm/memory_hotplug.c | 55 ----------------------------------
> 4 files changed, 45 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index c54e80fd25a8..0204384b4d1d 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -44,6 +44,11 @@ static inline unsigned long pfn_to_block_id(unsigned long pfn)
> return base_memory_block_id(pfn_to_section_nr(pfn));
> }
>
> +static inline unsigned long phys_to_block_id(unsigned long phys)
> +{
> + return pfn_to_block_id(PFN_DOWN(phys));
> +}
> +
> static int memory_subsys_online(struct device *dev);
> static int memory_subsys_offline(struct device *dev);
>
> @@ -851,3 +856,40 @@ int __init memory_dev_init(void)
> printk(KERN_ERR "%s() failed: %d\n", __func__, ret);
> return ret;
> }
> +
> +/**
> + * walk_memory_blocks - walk through all present memory blocks overlapped
> + * by the range [start, start + size)
> + *
> + * @start: start address of the memory range
> + * @size: size of the memory range
> + * @arg: argument passed to func
> + * @func: callback for each memory section walked
> + *
> + * This function walks through all present memory blocks overlapped by the
> + * range [start, start + size), calling func on each memory block.
> + *
> + * In case func() returns an error, walking is aborted and the error is
> + * returned.
> + */
> +int walk_memory_blocks(unsigned long start, unsigned long size,
> + void *arg, walk_memory_blocks_func_t func)
> +{
> + const unsigned long start_block_id = phys_to_block_id(start);
> + const unsigned long end_block_id = phys_to_block_id(start + size - 1);
> + struct memory_block *mem;
> + unsigned long block_id;
> + int ret = 0;
I *guess* the stall we are seeing is when size = 0.
(via ACPI, if info->length is 0)
if (!size)
return 0;
... but that is just a wild guess. Will have a look after my vacation.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 0/6] mm: Further memory block device cleanups
From: David Hildenbrand @ 2019-06-21 15:22 UTC (permalink / raw)
To: Qian Cai, linux-kernel
Cc: Oscar Salvador, Michal Hocko, Rafael J. Wysocki, Wei Yang,
Keith Busch, linux-mm, Arun KS, Rashmica Gupta, Thomas Gleixner,
Stephen Rothwell, Michael Neuling, Baoquan He, Pavel Tatashin,
linux-acpi, Len Brown, Pavel Tatashin, Pavel Tatashin,
Anshuman Khandual, mike.travis@hpe.com, linuxppc-dev,
Mike Rapoport, Dan Williams, Vlastimil Babka, Oscar Salvador,
Juergen Gross, Andrew Banman, Greg Kroah-Hartman,
Rafael J. Wysocki, Johannes Weiner, Paul Mackerras, Andrew Morton,
Mel Gorman
In-Reply-To: <1561130120.5154.47.camel@lca.pw>
On 21.06.19 17:15, Qian Cai wrote:
> On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
>> @Andrew: Only patch 1, 4 and 6 changed compared to v1.
>>
>> Some further cleanups around memory block devices. Especially, clean up
>> and simplify walk_memory_range(). Including some other minor cleanups.
>>
>> Compiled + tested on x86 with DIMMs under QEMU. Compile-tested on ppc64.
>>
>> v2 -> v3:
>> - "mm/memory_hotplug: Rename walk_memory_range() and pass start+size .."
>> -- Avoid warning on ppc.
>> - "drivers/base/memory.c: Get rid of find_memory_block_hinted()"
>> -- Fixup a comment regarding hinted devices.
>>
>> v1 -> v2:
>> - "mm: Section numbers use the type "unsigned long""
>> -- "unsigned long i" -> "unsigned long nr", in one case -> "int i"
>> - "drivers/base/memory.c: Get rid of find_memory_block_hinted("
>> -- Fix compilation error
>> -- Get rid of the "hint" parameter completely
>>
>> David Hildenbrand (6):
>> mm: Section numbers use the type "unsigned long"
>> drivers/base/memory: Use "unsigned long" for block ids
>> mm: Make register_mem_sect_under_node() static
>> mm/memory_hotplug: Rename walk_memory_range() and pass start+size
>> instead of pfns
>> mm/memory_hotplug: Move and simplify walk_memory_blocks()
>> drivers/base/memory.c: Get rid of find_memory_block_hinted()
>>
>> arch/powerpc/platforms/powernv/memtrace.c | 23 ++---
>> drivers/acpi/acpi_memhotplug.c | 19 +---
>> drivers/base/memory.c | 120 +++++++++++++---------
>> drivers/base/node.c | 8 +-
>> include/linux/memory.h | 5 +-
>> include/linux/memory_hotplug.h | 2 -
>> include/linux/mmzone.h | 4 +-
>> include/linux/node.h | 7 --
>> mm/memory_hotplug.c | 57 +---------
>> mm/sparse.c | 12 +--
>> 10 files changed, 106 insertions(+), 151 deletions(-)
>>
>
> This series causes a few machines are unable to boot triggering endless soft
> lockups. Reverted those commits fixed the issue.
>
> 97f4217d1da0 Revert "mm/memory_hotplug: rename walk_memory_range() and pass
> start+size instead of pfns"
> c608eebf33c6 Revert "mm-memory_hotplug-rename-walk_memory_range-and-pass-
> startsize-instead-of-pfns-fix"
> 34b5e4ab7558 Revert "mm/memory_hotplug: move and simplify walk_memory_blocks()"
> 59a9f3eec5d1 Revert "drivers/base/memory.c: Get rid of
> find_memory_block_hinted()"
> 5cfcd52288b6 Revert "drivers-base-memoryc-get-rid-of-find_memory_block_hinted-
> v3"
>
> [ 4.582081][ T1] ACPI FADT declares the system doesn't support PCIe ASPM,
> so disable it
> [ 4.590405][ T1] ACPI: bus type PCI registered
> [ 4.592908][ T1] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
> 0x80000000-0x8fffffff] (base 0x80000000)
> [ 4.601860][ T1] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in
> E820
> [ 4.601860][ T1] PCI: Using configuration type 1 for base access
> [ 28.661336][ C16] watchdog: BUG: soft lockup - CPU#16 stuck for 22s!
> [swapper/0:1]
> [ 28.671351][ C16] Modules linked in:
> [ 28.671354][ C16] CPU: 16 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5-
> next-20190621+ #1
> [ 28.681366][ C16] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
> Gen10, BIOS A40 03/09/2018
> [ 28.691334][ C16] RIP: 0010:_raw_spin_unlock_irqrestore+0x2f/0x40
> [ 28.701334][ C16] Code: 55 48 89 e5 41 54 49 89 f4 be 01 00 00 00 53 48 8b
> 55 08 48 89 fb 48 8d 7f 18 e8 4c 89 7d ff 48 89 df e8 94 f9 7d ff 41 54 9d <65>
> ff 0d c2 44 8d 48 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00
> [ 28.711354][ C16] RSP: 0018:ffff888205b27bf8 EFLAGS: 00000246 ORIG_RAX:
> ffffffffffffff13
> [ 28.721372][ C16] RAX: 0000000000000000 RBX: ffff8882053d6138 RCX:
> ffffffffb6f2a3b8
> [ 28.731371][ C16] RDX: 1ffff11040a7ac27 RSI: dffffc0000000000 RDI:
> ffff8882053d6138
> [ 28.741371][ C16] RBP: ffff888205b27c08 R08: ffffed1040a7ac28 R09:
> ffffed1040a7ac27
> [ 28.751334][ C16] R10: ffffed1040a7ac27 R11: ffff8882053d613b R12:
> 0000000000000246
> [ 28.751370][ C16] R13: ffff888205b27c98 R14: ffff8884504d0a20 R15:
> 0000000000000000
> [ 28.761368][ C16] FS: 0000000000000000(0000) GS:ffff888454500000(0000)
> knlGS:0000000000000000
> [ 28.771373][ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 28.781334][ C16] CR2: 0000000000000000 CR3: 00000007c9012000 CR4:
> 00000000001406a0
> [ 28.791333][ C16] Call Trace:
> [ 28.791374][ C16] klist_next+0xd8/0x1c0
> [ 28.791374][ C16] subsys_find_device_by_id+0x13b/0x1f0
> [ 28.801334][ C16] ? bus_find_device_by_name+0x20/0x20
> [ 28.801370][ C16] ? kobject_put+0x23/0x250
> [ 28.811333][ C16] walk_memory_blocks+0x6c/0xb8
> [ 28.811353][ C16] ? write_policy_show+0x40/0x40
> [ 28.821334][ C16] link_mem_sections+0x7e/0xa0
> [ 28.821369][ C16] ? unregister_memory_block_under_nodes+0x210/0x210
> [ 28.831353][ C16] ? __register_one_node+0x3bd/0x600
> [ 28.831353][ C16] topology_init+0xbf/0x126
> [ 28.841364][ C16] ? enable_cpu0_hotplug+0x1a/0x1a
> [ 28.841368][ C16] do_one_initcall+0xfe/0x45a
> [ 28.851334][ C16] ? initcall_blacklisted+0x150/0x150
> [ 28.851353][ C16] ? kasan_check_write+0x14/0x20
> [ 28.861333][ C16] ? up_write+0x75/0x140
> [ 28.861369][ C16] kernel_init_freeable+0x619/0x6ac
> [ 28.871333][ C16] ? rest_init+0x188/0x188
> [ 28.871353][ C16] kernel_init+0x11/0x138
> [ 28.881363][ C16] ? rest_init+0x188/0x188
> [ 28.881363][ C16] ret_from_fork+0x22/0x40
> [ 56.661336][ C16] watchdog: BUG: soft lockup - CPU#16 stuck for 22s!
> [swapper/0:1]
> [ 56.671352][ C16] Modules linked in:
> [ 56.671354][ C16] CPU: 16 PID: 1 Comm: swapper/0 Tainted:
> G L 5.2.0-rc5-next-20190621+ #1
> [ 56.681357][ C16] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
> Gen10, BIOS A40 03/09/2018
> [ 56.691356][ C16] RIP: 0010:subsys_find_device_by_id+0x168/0x1f0
> [ 56.701334][ C16] Code: 48 85 c0 74 3e 48 8d 78 58 e8 14 77 ca ff 4d 8b 7e
> 58 4d 85 ff 74 2c 49 8d bf a0 03 00 00 e8 bf 75 ca ff 45 39 a7 a0 03 00 00 <75>
> c9 4c 89 ff e8 0e 89 ff ff 48 85 c0 74 bc 48 89 df e8 21 3b 24
> [ 56.721333][ C16] RSP: 0018:ffff888205b27c68 EFLAGS: 00000287 ORIG_RAX:
> ffffffffffffff13
> [ 56.721370][ C16] RAX: 0000000000000000 RBX: ffff888205b27c90 RCX:
> ffffffffb74c9dc1
> [ 56.731370][ C16] RDX: 0000000000000003 RSI: dffffc0000000000 RDI:
> ffff8888774ec3e0
> [ 56.741371][ C16] RBP: ffff888205b27cf8 R08: ffffed1040a7ac28 R09:
> ffffed1040a7ac27
> [ 56.751335][ C16] R10: ffffed1040a7ac27 R11: ffff8882053d613b R12:
> 0000000000085c1b
> [ 56.761334][ C16] R13: 1ffff11040b64f8e R14: ffff888450de4a20 R15:
> ffff8888774ec040
> [ 56.761372][ C16] FS: 0000000000000000(0000) GS:ffff888454500000(0000)
> knlGS:0000000000000000
> [ 56.771374][ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 56.781370][ C16] CR2: 0000000000000000 CR3: 00000007c9012000 CR4:
> 00000000001406a0
> [ 56.791373][ C16] Call Trace:
> [ 56.791373][ C16] ? bus_find_device_by_name+0x20/0x20
> [ 56.801334][ C16] ? kobject_put+0x23/0x250
> [ 56.801334][ C16] walk_memory_blocks+0x6c/0xb8
> [ 56.811333][ C16] ? write_policy_show+0x40/0x40
> [ 56.811353][ C16] link_mem_sections+0x7e/0xa0
> [ 56.811353][ C16] ? unregister_memory_block_under_nodes+0x210/0x210
> [ 56.821333][ C16] ? __register_one_node+0x3bd/0x600
> [ 56.831333][ C16] topology_init+0xbf/0x126
> [ 56.831355][ C16] ? enable_cpu0_hotplug+0x1a/0x1a
> [ 56.841334][ C16] do_one_initcall+0xfe/0x45a
> [ 56.841334][ C16] ? initcall_blacklisted+0x150/0x150
> [ 56.851333][ C16] ? kasan_check_write+0x14/0x20
> [ 56.851354][ C16] ? up_write+0x75/0x140
> [ 56.861333][ C16] kernel_init_freeable+0x619/0x6ac
> [ 56.861333][ C16] ? rest_init+0x188/0x188
> [ 56.861369][ C16] kernel_init+0x11/0x138
> [ 56.871333][ C16] ? rest_init+0x188/0x188
> [ 56.871354][ C16] ret_from_fork+0x22/0x40
> [ 64.601362][ C16] rcu: INFO: rcu_sched self-detected stall on CPU
> [ 64.611335][ C16] rcu: 16-....: (5958 ticks this GP)
> idle=37e/1/0x4000000000000002 softirq=27/27 fqs=3000
> [ 64.621334][ C16] (t=6002 jiffies g=-1079 q=25)
> [ 64.621334][ C16] NMI backtrace for cpu 16
> [ 64.621374][ C16] CPU: 16 PID: 1 Comm: swapper/0 Tainted:
> G L 5.2.0-rc5-next-20190621+ #1
> [ 64.631372][ C16] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
> Gen10, BIOS A40 03/09/2018
> [ 64.641371][ C16] Call Trace:
> [ 64.651337][ C16] <IRQ>
> [ 64.651376][ C16] dump_stack+0x62/0x9a
> [ 64.651376][ C16] nmi_cpu_backtrace.cold.0+0x2e/0x33
> [ 64.661337][ C16] ? nmi_cpu_backtrace_handler+0x20/0x20
> [ 64.661337][ C16] nmi_trigger_cpumask_backtrace+0x1a6/0x1b9
> [ 64.671353][ C16] arch_trigger_cpumask_backtrace+0x19/0x20
> [ 64.681366][ C16] rcu_dump_cpu_stacks+0x18b/0x1d6
> [ 64.681366][ C16] rcu_sched_clock_irq.cold.64+0x368/0x791
> [ 64.691336][ C16] ? kasan_check_read+0x11/0x20
> [ 64.691354][ C16] ? __raise_softirq_irqoff+0x66/0x150
> [ 64.701336][ C16] update_process_times+0x2f/0x60
> [ 64.701362][ C16] tick_periodic+0x38/0xe0
> [ 64.711334][ C16] tick_handle_periodic+0x2e/0x80
> [ 64.711353][ C16] smp_apic_timer_interrupt+0xfb/0x370
> [ 64.721367][ C16] apic_timer_interrupt+0xf/0x20
> [ 64.721367][ C16] </IRQ>
> [ 64.721367][ C16] RIP: 0010:_raw_spin_unlock_irqrestore+0x2f/0x40
> [ 64.731370][ C16] Code: 55 48 89 e5 41 54 49 89 f4 be 01 00 00 00 53
>
Thanks for the report. Man, this series is nastier than I thought. This
is making more noise than I was hoping for.
@Andrew can you revert patch 4-6 for now? I'll be on vacation soon and
don't want cleanups to constantly break things. Just nasty.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 0/6] mm: Further memory block device cleanups
From: Qian Cai @ 2019-06-21 15:15 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: Oscar Salvador, Michal Hocko, Rafael J. Wysocki, Wei Yang,
Keith Busch, linux-mm, Arun KS, Rashmica Gupta, Thomas Gleixner,
Stephen Rothwell, Michael Neuling, Baoquan He, Pavel Tatashin,
linux-acpi, Len Brown, Pavel Tatashin, Pavel Tatashin,
Anshuman Khandual, mike.travis@hpe.com, linuxppc-dev,
Mike Rapoport, Dan Williams, Vlastimil Babka, Oscar Salvador,
Juergen Gross, Andrew Banman, Greg Kroah-Hartman,
Rafael J. Wysocki, Johannes Weiner, Paul Mackerras, Andrew Morton,
Mel Gorman
In-Reply-To: <20190620183139.4352-1-david@redhat.com>
On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
> @Andrew: Only patch 1, 4 and 6 changed compared to v1.
>
> Some further cleanups around memory block devices. Especially, clean up
> and simplify walk_memory_range(). Including some other minor cleanups.
>
> Compiled + tested on x86 with DIMMs under QEMU. Compile-tested on ppc64.
>
> v2 -> v3:
> - "mm/memory_hotplug: Rename walk_memory_range() and pass start+size .."
> -- Avoid warning on ppc.
> - "drivers/base/memory.c: Get rid of find_memory_block_hinted()"
> -- Fixup a comment regarding hinted devices.
>
> v1 -> v2:
> - "mm: Section numbers use the type "unsigned long""
> -- "unsigned long i" -> "unsigned long nr", in one case -> "int i"
> - "drivers/base/memory.c: Get rid of find_memory_block_hinted("
> -- Fix compilation error
> -- Get rid of the "hint" parameter completely
>
> David Hildenbrand (6):
> mm: Section numbers use the type "unsigned long"
> drivers/base/memory: Use "unsigned long" for block ids
> mm: Make register_mem_sect_under_node() static
> mm/memory_hotplug: Rename walk_memory_range() and pass start+size
> instead of pfns
> mm/memory_hotplug: Move and simplify walk_memory_blocks()
> drivers/base/memory.c: Get rid of find_memory_block_hinted()
>
> arch/powerpc/platforms/powernv/memtrace.c | 23 ++---
> drivers/acpi/acpi_memhotplug.c | 19 +---
> drivers/base/memory.c | 120 +++++++++++++---------
> drivers/base/node.c | 8 +-
> include/linux/memory.h | 5 +-
> include/linux/memory_hotplug.h | 2 -
> include/linux/mmzone.h | 4 +-
> include/linux/node.h | 7 --
> mm/memory_hotplug.c | 57 +---------
> mm/sparse.c | 12 +--
> 10 files changed, 106 insertions(+), 151 deletions(-)
>
This series causes a few machines are unable to boot triggering endless soft
lockups. Reverted those commits fixed the issue.
97f4217d1da0 Revert "mm/memory_hotplug: rename walk_memory_range() and pass
start+size instead of pfns"
c608eebf33c6 Revert "mm-memory_hotplug-rename-walk_memory_range-and-pass-
startsize-instead-of-pfns-fix"
34b5e4ab7558 Revert "mm/memory_hotplug: move and simplify walk_memory_blocks()"
59a9f3eec5d1 Revert "drivers/base/memory.c: Get rid of
find_memory_block_hinted()"
5cfcd52288b6 Revert "drivers-base-memoryc-get-rid-of-find_memory_block_hinted-
v3"
[ 4.582081][ T1] ACPI FADT declares the system doesn't support PCIe ASPM,
so disable it
[ 4.590405][ T1] ACPI: bus type PCI registered
[ 4.592908][ T1] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem
0x80000000-0x8fffffff] (base 0x80000000)
[ 4.601860][ T1] PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in
E820
[ 4.601860][ T1] PCI: Using configuration type 1 for base access
[ 28.661336][ C16] watchdog: BUG: soft lockup - CPU#16 stuck for 22s!
[swapper/0:1]
[ 28.671351][ C16] Modules linked in:
[ 28.671354][ C16] CPU: 16 PID: 1 Comm: swapper/0 Not tainted 5.2.0-rc5-
next-20190621+ #1
[ 28.681366][ C16] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 03/09/2018
[ 28.691334][ C16] RIP: 0010:_raw_spin_unlock_irqrestore+0x2f/0x40
[ 28.701334][ C16] Code: 55 48 89 e5 41 54 49 89 f4 be 01 00 00 00 53 48 8b
55 08 48 89 fb 48 8d 7f 18 e8 4c 89 7d ff 48 89 df e8 94 f9 7d ff 41 54 9d <65>
ff 0d c2 44 8d 48 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00
[ 28.711354][ C16] RSP: 0018:ffff888205b27bf8 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffff13
[ 28.721372][ C16] RAX: 0000000000000000 RBX: ffff8882053d6138 RCX:
ffffffffb6f2a3b8
[ 28.731371][ C16] RDX: 1ffff11040a7ac27 RSI: dffffc0000000000 RDI:
ffff8882053d6138
[ 28.741371][ C16] RBP: ffff888205b27c08 R08: ffffed1040a7ac28 R09:
ffffed1040a7ac27
[ 28.751334][ C16] R10: ffffed1040a7ac27 R11: ffff8882053d613b R12:
0000000000000246
[ 28.751370][ C16] R13: ffff888205b27c98 R14: ffff8884504d0a20 R15:
0000000000000000
[ 28.761368][ C16] FS: 0000000000000000(0000) GS:ffff888454500000(0000)
knlGS:0000000000000000
[ 28.771373][ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 28.781334][ C16] CR2: 0000000000000000 CR3: 00000007c9012000 CR4:
00000000001406a0
[ 28.791333][ C16] Call Trace:
[ 28.791374][ C16] klist_next+0xd8/0x1c0
[ 28.791374][ C16] subsys_find_device_by_id+0x13b/0x1f0
[ 28.801334][ C16] ? bus_find_device_by_name+0x20/0x20
[ 28.801370][ C16] ? kobject_put+0x23/0x250
[ 28.811333][ C16] walk_memory_blocks+0x6c/0xb8
[ 28.811353][ C16] ? write_policy_show+0x40/0x40
[ 28.821334][ C16] link_mem_sections+0x7e/0xa0
[ 28.821369][ C16] ? unregister_memory_block_under_nodes+0x210/0x210
[ 28.831353][ C16] ? __register_one_node+0x3bd/0x600
[ 28.831353][ C16] topology_init+0xbf/0x126
[ 28.841364][ C16] ? enable_cpu0_hotplug+0x1a/0x1a
[ 28.841368][ C16] do_one_initcall+0xfe/0x45a
[ 28.851334][ C16] ? initcall_blacklisted+0x150/0x150
[ 28.851353][ C16] ? kasan_check_write+0x14/0x20
[ 28.861333][ C16] ? up_write+0x75/0x140
[ 28.861369][ C16] kernel_init_freeable+0x619/0x6ac
[ 28.871333][ C16] ? rest_init+0x188/0x188
[ 28.871353][ C16] kernel_init+0x11/0x138
[ 28.881363][ C16] ? rest_init+0x188/0x188
[ 28.881363][ C16] ret_from_fork+0x22/0x40
[ 56.661336][ C16] watchdog: BUG: soft lockup - CPU#16 stuck for 22s!
[swapper/0:1]
[ 56.671352][ C16] Modules linked in:
[ 56.671354][ C16] CPU: 16 PID: 1 Comm: swapper/0 Tainted:
G L 5.2.0-rc5-next-20190621+ #1
[ 56.681357][ C16] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 03/09/2018
[ 56.691356][ C16] RIP: 0010:subsys_find_device_by_id+0x168/0x1f0
[ 56.701334][ C16] Code: 48 85 c0 74 3e 48 8d 78 58 e8 14 77 ca ff 4d 8b 7e
58 4d 85 ff 74 2c 49 8d bf a0 03 00 00 e8 bf 75 ca ff 45 39 a7 a0 03 00 00 <75>
c9 4c 89 ff e8 0e 89 ff ff 48 85 c0 74 bc 48 89 df e8 21 3b 24
[ 56.721333][ C16] RSP: 0018:ffff888205b27c68 EFLAGS: 00000287 ORIG_RAX:
ffffffffffffff13
[ 56.721370][ C16] RAX: 0000000000000000 RBX: ffff888205b27c90 RCX:
ffffffffb74c9dc1
[ 56.731370][ C16] RDX: 0000000000000003 RSI: dffffc0000000000 RDI:
ffff8888774ec3e0
[ 56.741371][ C16] RBP: ffff888205b27cf8 R08: ffffed1040a7ac28 R09:
ffffed1040a7ac27
[ 56.751335][ C16] R10: ffffed1040a7ac27 R11: ffff8882053d613b R12:
0000000000085c1b
[ 56.761334][ C16] R13: 1ffff11040b64f8e R14: ffff888450de4a20 R15:
ffff8888774ec040
[ 56.761372][ C16] FS: 0000000000000000(0000) GS:ffff888454500000(0000)
knlGS:0000000000000000
[ 56.771374][ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 56.781370][ C16] CR2: 0000000000000000 CR3: 00000007c9012000 CR4:
00000000001406a0
[ 56.791373][ C16] Call Trace:
[ 56.791373][ C16] ? bus_find_device_by_name+0x20/0x20
[ 56.801334][ C16] ? kobject_put+0x23/0x250
[ 56.801334][ C16] walk_memory_blocks+0x6c/0xb8
[ 56.811333][ C16] ? write_policy_show+0x40/0x40
[ 56.811353][ C16] link_mem_sections+0x7e/0xa0
[ 56.811353][ C16] ? unregister_memory_block_under_nodes+0x210/0x210
[ 56.821333][ C16] ? __register_one_node+0x3bd/0x600
[ 56.831333][ C16] topology_init+0xbf/0x126
[ 56.831355][ C16] ? enable_cpu0_hotplug+0x1a/0x1a
[ 56.841334][ C16] do_one_initcall+0xfe/0x45a
[ 56.841334][ C16] ? initcall_blacklisted+0x150/0x150
[ 56.851333][ C16] ? kasan_check_write+0x14/0x20
[ 56.851354][ C16] ? up_write+0x75/0x140
[ 56.861333][ C16] kernel_init_freeable+0x619/0x6ac
[ 56.861333][ C16] ? rest_init+0x188/0x188
[ 56.861369][ C16] kernel_init+0x11/0x138
[ 56.871333][ C16] ? rest_init+0x188/0x188
[ 56.871354][ C16] ret_from_fork+0x22/0x40
[ 64.601362][ C16] rcu: INFO: rcu_sched self-detected stall on CPU
[ 64.611335][ C16] rcu: 16-....: (5958 ticks this GP)
idle=37e/1/0x4000000000000002 softirq=27/27 fqs=3000
[ 64.621334][ C16] (t=6002 jiffies g=-1079 q=25)
[ 64.621334][ C16] NMI backtrace for cpu 16
[ 64.621374][ C16] CPU: 16 PID: 1 Comm: swapper/0 Tainted:
G L 5.2.0-rc5-next-20190621+ #1
[ 64.631372][ C16] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 03/09/2018
[ 64.641371][ C16] Call Trace:
[ 64.651337][ C16] <IRQ>
[ 64.651376][ C16] dump_stack+0x62/0x9a
[ 64.651376][ C16] nmi_cpu_backtrace.cold.0+0x2e/0x33
[ 64.661337][ C16] ? nmi_cpu_backtrace_handler+0x20/0x20
[ 64.661337][ C16] nmi_trigger_cpumask_backtrace+0x1a6/0x1b9
[ 64.671353][ C16] arch_trigger_cpumask_backtrace+0x19/0x20
[ 64.681366][ C16] rcu_dump_cpu_stacks+0x18b/0x1d6
[ 64.681366][ C16] rcu_sched_clock_irq.cold.64+0x368/0x791
[ 64.691336][ C16] ? kasan_check_read+0x11/0x20
[ 64.691354][ C16] ? __raise_softirq_irqoff+0x66/0x150
[ 64.701336][ C16] update_process_times+0x2f/0x60
[ 64.701362][ C16] tick_periodic+0x38/0xe0
[ 64.711334][ C16] tick_handle_periodic+0x2e/0x80
[ 64.711353][ C16] smp_apic_timer_interrupt+0xfb/0x370
[ 64.721367][ C16] apic_timer_interrupt+0xf/0x20
[ 64.721367][ C16] </IRQ>
[ 64.721367][ C16] RIP: 0010:_raw_spin_unlock_irqrestore+0x2f/0x40
[ 64.731370][ C16] Code: 55 48 89 e5 41 54 49 89 f4 be 01 00 00 00 53
^ permalink raw reply
* Re: [PATCH 7/7] powerpc/kprobes: Allow probing on any ftrace address
From: Masami Hiramatsu @ 2019-06-21 14:50 UTC (permalink / raw)
To: Naveen N. Rao
Cc: linux-kernel, Nicholas Piggin, Steven Rostedt, linuxppc-dev,
Ingo Molnar
In-Reply-To: <d26f5467577ff0aeecea55e7035ea64e303bdf17.1560868106.git.naveen.n.rao@linux.vnet.ibm.com>
On Tue, 18 Jun 2019 20:17:06 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> With KPROBES_ON_FTRACE, kprobe is allowed to be inserted on instructions
> that branch to _mcount (referred to as ftrace location). With
> -mprofile-kernel, we now include the preceding 'mflr r0' as being part
> of the ftrace location.
>
> However, by default, probing on an instruction that is not actually the
> branch to _mcount() is prohibited, as that is considered to not be at an
> instruction boundary. This is not the case on powerpc, so allow the same
> by overriding arch_check_ftrace_location()
>
> In addition, we update kprobe_ftrace_handler() to detect this scenarios
> and to pass the proper nip to the pre and post probe handlers.
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/kprobes-ftrace.c | 30 ++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/arch/powerpc/kernel/kprobes-ftrace.c b/arch/powerpc/kernel/kprobes-ftrace.c
> index 972cb28174b2..6a0bd3c16cb6 100644
> --- a/arch/powerpc/kernel/kprobes-ftrace.c
> +++ b/arch/powerpc/kernel/kprobes-ftrace.c
> @@ -12,14 +12,34 @@
> #include <linux/preempt.h>
> #include <linux/ftrace.h>
>
> +/*
> + * With -mprofile-kernel, we patch two instructions -- the branch to _mcount
> + * as well as the preceding 'mflr r0'. Both these instructions are claimed
> + * by ftrace and we should allow probing on either instruction.
> + */
> +int arch_check_ftrace_location(struct kprobe *p)
> +{
> + if (ftrace_location((unsigned long)p->addr))
> + p->flags |= KPROBE_FLAG_FTRACE;
> + return 0;
> +}
> +
> /* Ftrace callback handler for kprobes */
> void kprobe_ftrace_handler(unsigned long nip, unsigned long parent_nip,
> struct ftrace_ops *ops, struct pt_regs *regs)
> {
> struct kprobe *p;
> + int mflr_kprobe = 0;
> struct kprobe_ctlblk *kcb;
>
> p = get_kprobe((kprobe_opcode_t *)nip);
> + if (unlikely(!p)) {
Hmm, is this really unlikely? If we put a kprobe on the second instruction address,
we will see p == NULL always.
> + p = get_kprobe((kprobe_opcode_t *)(nip - MCOUNT_INSN_SIZE));
> + if (!p)
Here will be unlikely, because we can not find kprobe at both of nip and
nip - MCOUNT_INSN_SIZE.
> + return;
> + mflr_kprobe = 1;
> + }
> +
> if (unlikely(!p) || kprobe_disabled(p))
"unlikely(!p)" is not needed here.
Thank you,
> return;
>
> @@ -33,6 +53,9 @@ void kprobe_ftrace_handler(unsigned long nip, unsigned long parent_nip,
> */
> regs->nip -= MCOUNT_INSN_SIZE;
>
> + if (mflr_kprobe)
> + regs->nip -= MCOUNT_INSN_SIZE;
> +
> __this_cpu_write(current_kprobe, p);
> kcb->kprobe_status = KPROBE_HIT_ACTIVE;
> if (!p->pre_handler || !p->pre_handler(p, regs)) {
> @@ -45,6 +68,8 @@ void kprobe_ftrace_handler(unsigned long nip, unsigned long parent_nip,
> kcb->kprobe_status = KPROBE_HIT_SSDONE;
> p->post_handler(p, regs, 0);
> }
> + if (mflr_kprobe)
> + regs->nip += MCOUNT_INSN_SIZE;
> }
> /*
> * If pre_handler returns !0, it changes regs->nip. We have to
> @@ -57,6 +82,11 @@ NOKPROBE_SYMBOL(kprobe_ftrace_handler);
>
> int arch_prepare_kprobe_ftrace(struct kprobe *p)
> {
> + if ((unsigned long)p->addr & 0x03) {
> + printk("Attempt to register kprobe at an unaligned address\n");
> + return -EILSEQ;
> + }
> +
> p->ainsn.insn = NULL;
> p->ainsn.boostable = -1;
> return 0;
> --
> 2.22.0
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: switch the remaining architectures to use generic GUP v3
From: Jason Gunthorpe @ 2019-06-21 14:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-1-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:46PM +0200, Christoph Hellwig wrote:
> Hi Linus and maintainers,
>
> below is a series to switch mips, sh and sparc64 to use the generic
> GUP code so that we only have one codebase to touch for further
> improvements to this code. I don't have hardware for any of these
> architectures, and generally no clue about their page table
> management, so handle with care.
I like this series, ther are alot of people talking about work for GUP
and this will make any of that so much easier to do.
Jason
^ permalink raw reply
* Re: [PATCH 6/7] kprobes/ftrace: Use ftrace_location() when [dis]arming probes
From: Masami Hiramatsu @ 2019-06-21 14:41 UTC (permalink / raw)
To: Naveen N. Rao
Cc: linux-kernel, Nicholas Piggin, Steven Rostedt, linuxppc-dev,
Ingo Molnar
In-Reply-To: <4fedad69107b7fd81b9324315ce4fbf6287e5084.1560868106.git.naveen.n.rao@linux.vnet.ibm.com>
On Tue, 18 Jun 2019 20:17:05 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:
> Ftrace location could include more than a single instruction in case of
> some architectures (powerpc64, for now). In this case, kprobe is
> permitted on any of those instructions, and uses ftrace infrastructure
> for functioning.
>
> However, [dis]arm_kprobe_ftrace() uses the kprobe address when setting
> up ftrace filter IP. This won't work if the address points to any
> instruction apart from the one that has a branch to _mcount(). To
> resolve this, have [dis]arm_kprobe_ftrace() use ftrace_function() to
> identify the filter IP.
This looks good to me.
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you!
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> kernel/kprobes.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 445337c107e0..282ee704e2d8 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -978,10 +978,10 @@ static int prepare_kprobe(struct kprobe *p)
> /* Caller must lock kprobe_mutex */
> static int arm_kprobe_ftrace(struct kprobe *p)
> {
> + unsigned long ftrace_ip = ftrace_location((unsigned long)p->addr);
> int ret = 0;
>
> - ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
> - (unsigned long)p->addr, 0, 0);
> + ret = ftrace_set_filter_ip(&kprobe_ftrace_ops, ftrace_ip, 0, 0);
> if (ret) {
> pr_debug("Failed to arm kprobe-ftrace at %pS (%d)\n",
> p->addr, ret);
> @@ -1005,13 +1005,14 @@ static int arm_kprobe_ftrace(struct kprobe *p)
> * non-empty filter_hash for IPMODIFY ops, we're safe from an accidental
> * empty filter_hash which would undesirably trace all functions.
> */
> - ftrace_set_filter_ip(&kprobe_ftrace_ops, (unsigned long)p->addr, 1, 0);
> + ftrace_set_filter_ip(&kprobe_ftrace_ops, ftrace_ip, 1, 0);
> return ret;
> }
>
> /* Caller must lock kprobe_mutex */
> static int disarm_kprobe_ftrace(struct kprobe *p)
> {
> + unsigned long ftrace_ip = ftrace_location((unsigned long)p->addr);
> int ret = 0;
>
> if (kprobe_ftrace_enabled == 1) {
> @@ -1022,8 +1023,7 @@ static int disarm_kprobe_ftrace(struct kprobe *p)
>
> kprobe_ftrace_enabled--;
>
> - ret = ftrace_set_filter_ip(&kprobe_ftrace_ops,
> - (unsigned long)p->addr, 1, 0);
> + ret = ftrace_set_filter_ip(&kprobe_ftrace_ops, ftrace_ip, 1, 0);
> WARN_ONCE(ret < 0, "Failed to disarm kprobe-ftrace at %pS (%d)\n",
> p->addr, ret);
> return ret;
> --
> 2.22.0
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH 11/16] mm: consolidate the get_user_pages* implementations
From: Jason Gunthorpe @ 2019-06-21 14:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-12-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:57PM +0200, Christoph Hellwig wrote:
> @@ -2168,7 +2221,7 @@ static void gup_pgd_range(unsigned long addr, unsigned long end,
> */
> static bool gup_fast_permitted(unsigned long start, unsigned long end)
> {
> - return true;
> + return IS_ENABLED(CONFIG_HAVE_FAST_GUP) ? true : false;
The ?: is needed with IS_ENABLED?
> }
> #endif
Oh, you fixed the util.c this way instead of the headerfile
#ifdef..
I'd suggest to revise this block a tiny bit:
-#ifndef gup_fast_permitted
+#if !IS_ENABLED(CONFIG_HAVE_FAST_GUP) || !defined(gup_fast_permitted)
/*
* Check if it's allowed to use __get_user_pages_fast() for the range, or
* we need to fall back to the slow version:
*/
-bool gup_fast_permitted(unsigned long start, int nr_pages)
+static bool gup_fast_permitted(unsigned long start, int nr_pages)
{
Just in case some future arch code mismatches the header and kconfig..
Regards,
Jason
^ permalink raw reply
* Re: [PATCH 10/16] mm: rename CONFIG_HAVE_GENERIC_GUP to CONFIG_HAVE_FAST_GUP
From: Jason Gunthorpe @ 2019-06-21 14:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-11-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:56PM +0200, Christoph Hellwig wrote:
> We only support the generic GUP now, so rename the config option to
> be more clear, and always use the mm/Kconfig definition of the
> symbol and select it from the arch Kconfigs.
Looks OK to me
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
But could you also roll something like this in to the series? There is
no longer any reason for the special __weak stuff that I can see -
just follow the normal pattern for stubbing config controlled
functions through the header file.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0e8834ac32b76c..13b1cb573383d5 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1561,8 +1561,17 @@ long get_user_pages_locked(unsigned long start, unsigned long nr_pages,
long get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
struct page **pages, unsigned int gup_flags);
+#ifdef CONFIG_HAVE_FAST_GUP
int get_user_pages_fast(unsigned long start, int nr_pages,
unsigned int gup_flags, struct page **pages);
+#else
+static inline int get_user_pages_fast(unsigned long start, int nr_pages,
+ unsigned int gup_flags,
+ struct page **pages)
+{
+ return get_user_pages_unlocked(start, nr_pages, pages, gup_flags);
+}
+#endif
/* Container for pinned pfns / pages */
struct frame_vector {
@@ -1668,8 +1677,17 @@ extern int mprotect_fixup(struct vm_area_struct *vma,
/*
* doesn't attempt to fault and will return short.
*/
+#ifdef CONFIG_HAVE_FAST_GUP
int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct page **pages);
+#else
+static inline int __get_user_pages_fast(unsigned long start, int nr_pages,
+ int write, struct page **pages)
+{
+ return 0;
+}
+#endif
+
/*
* per-process(per-mm_struct) statistics.
*/
diff --git a/mm/util.c b/mm/util.c
index 9834c4ab7d8e86..68575a315dc5ad 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -300,53 +300,6 @@ void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
}
#endif
-/*
- * Like get_user_pages_fast() except its IRQ-safe in that it won't fall
- * back to the regular GUP.
- * Note a difference with get_user_pages_fast: this always returns the
- * number of pages pinned, 0 if no pages were pinned.
- * If the architecture does not support this function, simply return with no
- * pages pinned.
- */
-int __weak __get_user_pages_fast(unsigned long start,
- int nr_pages, int write, struct page **pages)
-{
- return 0;
-}
-EXPORT_SYMBOL_GPL(__get_user_pages_fast);
-
-/**
- * get_user_pages_fast() - pin user pages in memory
- * @start: starting user address
- * @nr_pages: number of pages from start to pin
- * @gup_flags: flags modifying pin behaviour
- * @pages: array that receives pointers to the pages pinned.
- * Should be at least nr_pages long.
- *
- * get_user_pages_fast provides equivalent functionality to get_user_pages,
- * operating on current and current->mm, with force=0 and vma=NULL. However
- * unlike get_user_pages, it must be called without mmap_sem held.
- *
- * get_user_pages_fast may take mmap_sem and page table locks, so no
- * assumptions can be made about lack of locking. get_user_pages_fast is to be
- * implemented in a way that is advantageous (vs get_user_pages()) when the
- * user memory area is already faulted in and present in ptes. However if the
- * pages have to be faulted in, it may turn out to be slightly slower so
- * callers need to carefully consider what to use. On many architectures,
- * get_user_pages_fast simply falls back to get_user_pages.
- *
- * Return: number of pages pinned. This may be fewer than the number
- * requested. If nr_pages is 0 or negative, returns 0. If no pages
- * were pinned, returns -errno.
- */
-int __weak get_user_pages_fast(unsigned long start,
- int nr_pages, unsigned int gup_flags,
- struct page **pages)
-{
- return get_user_pages_unlocked(start, nr_pages, pages, gup_flags);
-}
-EXPORT_SYMBOL_GPL(get_user_pages_fast);
-
unsigned long vm_mmap_pgoff(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot,
unsigned long flag, unsigned long pgoff)
^ permalink raw reply related
* Re: [PATCH 04/16] MIPS: use the generic get_user_pages_fast code
From: Jason Gunthorpe @ 2019-06-21 14:05 UTC (permalink / raw)
To: Christoph Hellwig, Kamal Dasu, Ralf Baechle
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-5-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:50PM +0200, Christoph Hellwig wrote:
> diff --git a/arch/mips/include/asm/pgtable.h b/arch/mips/include/asm/pgtable.h
> index 4ccb465ef3f2..7d27194e3b45 100644
> +++ b/arch/mips/include/asm/pgtable.h
> @@ -20,6 +20,7 @@
> #include <asm/cmpxchg.h>
> #include <asm/io.h>
> #include <asm/pgtable-bits.h>
> +#include <asm/cpu-features.h>
>
> struct mm_struct;
> struct vm_area_struct;
> @@ -626,6 +627,8 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
>
> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>
> +#define gup_fast_permitted(start, end) (!cpu_has_dc_aliases)
> +
Today this check is only being done on the get_user_pages_fast() -
after this patch it is also done for __get_user_pages_fast().
Which means __get_user_pages_fast is now non-functional on a range of
MIPS CPUs, but that seems OK as far as I can tell, so:
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
However, looks to me like this patch is also a bug fix for this:
commit 5b167c123b3c3582f62cf1896465019bc40fe526
Author: Kamal Dasu <kdasu.kdev@gmail.com>
Date: Fri Jun 14 17:10:03 2013 +0000
MIPS: Fix get_user_page_fast() for mips with cache alias
get_user_pages_fast() is missing cache flushes for MIPS platforms with
cache aliases. Filesystem failures observed with DirectIO operations due
to missing flush_anon_page() that use page coloring logic to work with
cache aliases. This fix falls through to take slow_irqon path that calls
get_user_pages() that has required logic for platforms where
cpu_has_dc_aliases is true.
> - pgdp = pgd_offset(mm, addr);
> - do {
> - pgd_t pgd = *pgdp;
> -
> - next = pgd_addr_end(addr, end);
> - if (pgd_none(pgd))
> - goto slow;
> - if (!gup_pud_range(pgd, addr, next, gup_flags & FOLL_WRITE,
> - pages, &nr))
This is different too, the core code has a p4d layer, but I see that
whole thing gets NOP'd by the compiler as mips uses pgtable-nop4d.h -
right?
Jason
^ permalink raw reply
* Re: [PATCH 03/16] mm: lift the x86_32 PAE version of gup_get_pte to common code
From: Jason Gunthorpe @ 2019-06-21 13:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-4-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:49PM +0200, Christoph Hellwig wrote:
> The split low/high access is the only non-READ_ONCE version of
> gup_get_pte that did show up in the various arch implemenations.
> Lift it to common code and drop the ifdef based arch override.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/pgtable-3level.h | 47 ------------------------
> arch/x86/kvm/mmu.c | 2 +-
> mm/Kconfig | 3 ++
> mm/gup.c | 51 ++++++++++++++++++++++++---
> 5 files changed, 52 insertions(+), 52 deletions(-)
Yep, the sh and mips conversions look right too.
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
> diff --git a/mm/Kconfig b/mm/Kconfig
> index f0c76ba47695..fe51f104a9e0 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -762,6 +762,9 @@ config GUP_BENCHMARK
>
> See tools/testing/selftests/vm/gup_benchmark.c
>
> +config GUP_GET_PTE_LOW_HIGH
> + bool
> +
The config name seems a bit out of place though, should it be prefixed
with GENERIC_ or ARCH_?
Jason
^ permalink raw reply
* Re: [PATCH 02/16] mm: simplify gup_fast_permitted
From: Jason Gunthorpe @ 2019-06-21 13:40 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-3-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:48PM +0200, Christoph Hellwig wrote:
> Pass in the already calculated end value instead of recomputing it, and
> leave the end > start check in the callers instead of duplicating them
> in the arch code.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/s390/include/asm/pgtable.h | 8 +-------
> arch/x86/include/asm/pgtable_64.h | 8 +-------
> mm/gup.c | 17 +++++++----------
> 3 files changed, 9 insertions(+), 24 deletions(-)
Much cleaner
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
Jason
^ permalink raw reply
* Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses
From: Jason Gunthorpe @ 2019-06-21 13:39 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-2-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:47PM +0200, Christoph Hellwig wrote:
> This will allow sparc64 to override its ADI tags for
> get_user_pages and get_user_pages_fast.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> mm/gup.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index ddde097cf9e4..6bb521db67ec 100644
> +++ b/mm/gup.c
> @@ -2146,7 +2146,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
> unsigned long flags;
> int nr = 0;
>
> - start &= PAGE_MASK;
> + start = untagged_addr(start) & PAGE_MASK;
> len = (unsigned long) nr_pages << PAGE_SHIFT;
> end = start + len;
Hmm, this function, and the other, goes on to do:
if (unlikely(!access_ok((void __user *)start, len)))
return 0;
and I thought that access_ok takes in the tagged pointer?
How about re-order it a bit?
diff --git a/mm/gup.c b/mm/gup.c
index ddde097cf9e410..f48747ced4723b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2148,11 +2148,12 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
start &= PAGE_MASK;
len = (unsigned long) nr_pages << PAGE_SHIFT;
- end = start + len;
-
if (unlikely(!access_ok((void __user *)start, len)))
return 0;
+ start = untagged_ptr(start);
+ end = start + len;
+
/*
* Disable interrupts. We use the nested form as we can already have
* interrupts disabled by get_futex_key.
^ permalink raw reply related
* Re: [PATCH 01/16] mm: use untagged_addr() for get_user_pages_fast addresses
From: Jason Gunthorpe @ 2019-06-21 13:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: x86, Rich Felker, Yoshinori Sato, linux-sh, James Hogan,
linuxppc-dev, Khalid Aziz, Nicholas Piggin, linux-mips, linux-mm,
Paul Burton, Paul Mackerras, Andrey Konovalov, sparclinux,
Linus Torvalds, David S. Miller, linux-kernel
In-Reply-To: <20190611144102.8848-2-hch@lst.de>
On Tue, Jun 11, 2019 at 04:40:47PM +0200, Christoph Hellwig wrote:
> This will allow sparc64 to override its ADI tags for
> get_user_pages and get_user_pages_fast.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> mm/gup.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
^ permalink raw reply
* Re: [PATCH 11/13] powerpc/64s: Save r13 in machine_check_common_early
From: Mahesh J Salgaonkar @ 2019-06-21 11:47 UTC (permalink / raw)
To: Santosh Sivaraj
Cc: Aneesh Kumar K.V, linuxppc-dev, Nicholas Piggin,
Mahesh Salgaonkar, Chandan Rajendra, Reza Arbab
In-Reply-To: <d6ae7dd59966ee1c7593b8fd936774c0b13e6dd4.1561020760.git.santosh@fossix.org>
On 2019-06-21 06:27:15 Fri, Santosh Sivaraj wrote:
> From: Reza Arbab <arbab@linux.ibm.com>
>
> Testing my memcpy_mcsafe() work in progress with an injected UE, I get
> an error like this immediately after the function returns:
>
> BUG: Unable to handle kernel data access at 0x7fff84dec8f8
> Faulting instruction address: 0xc0080000009c00b0
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
> Modules linked in: mce(O+) vmx_crypto crc32c_vpmsum
> CPU: 0 PID: 1375 Comm: modprobe Tainted: G O 5.1.0-rc6 #267
> NIP: c0080000009c00b0 LR: c0080000009c00a8 CTR: c000000000095f90
> REGS: c0000000ee197790 TRAP: 0300 Tainted: G O (5.1.0-rc6)
> MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 88002826 XER: 00040000
> CFAR: c000000000095f8c DAR: 00007fff84dec8f8 DSISR: 40000000 IRQMASK: 0
> GPR00: 000000006c6c6568 c0000000ee197a20 c0080000009c8400 fffffffffffffff2
> GPR04: c0080000009c02e0 0000000000000006 0000000000000000 c000000003c834c8
> GPR08: 0080000000000000 776a6681b7fb5100 0000000000000000 c0080000009c01c8
> GPR12: c000000000095f90 00007fff84debc00 000000004d071440 0000000000000000
> GPR16: 0000000100000601 c0080000009e0000 c000000000c98dd8 c000000000c98d98
> GPR20: c000000003bba970 c0080000009c04d0 c0080000009c0618 c0000000001e5820
> GPR24: 0000000000000000 0000000000000100 0000000000000001 c000000003bba958
> GPR28: c0080000009c02e8 c0080000009c0318 c0080000009c02e0 0000000000000000
> NIP [c0080000009c00b0] cause_ue+0xa8/0xe8 [mce]
> LR [c0080000009c00a8] cause_ue+0xa0/0xe8 [mce]
>
> To fix, ensure that r13 is properly restored after an MCE.
>
> Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
> ---
> arch/powerpc/kernel/exceptions-64s.S | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 311f1392a2ec..932d8d05892c 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -265,6 +265,7 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
> EXC_REAL_END(machine_check, 0x200, 0x100)
> EXC_VIRT_NONE(0x4200, 0x100)
> TRAMP_REAL_BEGIN(machine_check_common_early)
> + SET_SCRATCH0(r13) /* save r13 */
> EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200)
> /*
> * Register contents:
We do save r13 before we call machine_check_common_early(). I don't
think I understood clearly how this change fixes the issue you are
seeing. What am I missing here ?
Above change will push the paca pointer to scratch0 overwriting the
original saved r13.
EXC_REAL_BEGIN(machine_check, 0x200, 0x100)
/* This is moved out of line as it can be patched by FW, but
* some code path might still want to branch into the original
* vector
*/
SET_SCRATCH0(r13) /* save r13 */
EXCEPTION_PROLOG_0(PACA_EXMC)
BEGIN_FTR_SECTION
b machine_check_common_early
Thanks,
-Mahesh.
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/powernv: remove the unused tunneling exports
From: Christoph Hellwig @ 2019-06-21 9:24 UTC (permalink / raw)
To: Frederic Barrat
Cc: Andrew Donnellan, Linux Kernel Mailing List,
Oliver O'Halloran, Paul Mackerras, linuxppc-dev,
Christoph Hellwig
In-Reply-To: <048e1242-a6ea-5d56-dc9a-e16f9eedf6d9@linux.ibm.com>
On Fri, Jun 21, 2019 at 11:21:38AM +0200, Frederic Barrat wrote:
> The as-notify can be used in both CAPI mode and PCI mode. In capi mode,
> it's integrated in the capi protocol, so the cxl driver doesn't need to do
> extra setup, compared to what's already done to activate capi.
> As mentioned in a previous iteration of that patchset, those APIs are to be
> used by the Mellanox CX5 driver. The in-tree driver is always a step behind
> their latest, but word is they are working on upstreaming those
> interactions.
We can review them together with the driver. Especially as we need to
consider if we even want to support it if there is no generic platform
independent inferface.
^ permalink raw reply
* Re: [PATCH 2/4] powerpc/powernv: remove the unused tunneling exports
From: Frederic Barrat @ 2019-06-21 9:21 UTC (permalink / raw)
To: Oliver O'Halloran, Christoph Hellwig
Cc: Andrew Donnellan, Linux Kernel Mailing List, Paul Mackerras,
linuxppc-dev
In-Reply-To: <CAOSf1CFu_T=7weW0eagzjTc8474ntVx1uCKdQh8sX85bfaPxCQ@mail.gmail.com>
Le 21/06/2019 à 03:47, Oliver O'Halloran a écrit :
> On Thu, May 23, 2019 at 5:51 PM Christoph Hellwig <hch@lst.de> wrote:
>>
>> These have been unused ever since they've been added to the kernel.
>>
>> Signed-off-by: Christoph Hellwig <hch@lst.de>
>> ---
>> arch/powerpc/include/asm/pnv-pci.h | 4 --
>> arch/powerpc/platforms/powernv/pci-ioda.c | 4 +-
>> arch/powerpc/platforms/powernv/pci.c | 71 -----------------------
>> arch/powerpc/platforms/powernv/pci.h | 1 -
>> 4 files changed, 3 insertions(+), 77 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/pnv-pci.h b/arch/powerpc/include/asm/pnv-pci.h
>> index 9fcb0bc462c6..1ab4b0111abc 100644
>> --- a/arch/powerpc/include/asm/pnv-pci.h
>> +++ b/arch/powerpc/include/asm/pnv-pci.h
>> @@ -27,12 +27,8 @@ extern int pnv_pci_get_power_state(uint64_t id, uint8_t *state);
>> extern int pnv_pci_set_power_state(uint64_t id, uint8_t state,
>> struct opal_msg *msg);
>>
>> -extern int pnv_pci_enable_tunnel(struct pci_dev *dev, uint64_t *asnind);
>> -extern int pnv_pci_disable_tunnel(struct pci_dev *dev);
>> extern int pnv_pci_set_tunnel_bar(struct pci_dev *dev, uint64_t addr,
>> int enable);
>> -extern int pnv_pci_get_as_notify_info(struct task_struct *task, u32 *lpid,
>> - u32 *pid, u32 *tid);
>
> IIRC as-notify was for CAPI which has an in-tree driver (cxl). Fred or
> Andrew (+cc), what's going on with this? Will it ever see the light of
> day?
The as-notify can be used in both CAPI mode and PCI mode. In capi mode,
it's integrated in the capi protocol, so the cxl driver doesn't need to
do extra setup, compared to what's already done to activate capi.
As mentioned in a previous iteration of that patchset, those APIs are to
be used by the Mellanox CX5 driver. The in-tree driver is always a step
behind their latest, but word is they are working on upstreaming those
interactions.
Fred
>> int pnv_phb_to_cxl_mode(struct pci_dev *dev, uint64_t mode);
>> int pnv_cxl_ioda_msi_setup(struct pci_dev *dev, unsigned int hwirq,
>> unsigned int virq);
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 126602b4e399..6b0caa2d0425 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -54,6 +54,8 @@
>> static const char * const pnv_phb_names[] = { "IODA1", "IODA2", "NPU_NVLINK",
>> "NPU_OCAPI" };
>>
>> +static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable);
>> +
>> void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
>> const char *fmt, ...)
>> {
>> @@ -2360,7 +2362,7 @@ static long pnv_pci_ioda2_set_window(struct iommu_table_group *table_group,
>> return 0;
>> }
>>
>> -void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
>> +static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
>> {
>> uint16_t window_id = (pe->pe_number << 1 ) + 1;
>> int64_t rc;
>> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
>> index 8d28f2932c3b..fc69f5611020 100644
>> --- a/arch/powerpc/platforms/powernv/pci.c
>> +++ b/arch/powerpc/platforms/powernv/pci.c
>> @@ -868,54 +868,6 @@ struct device_node *pnv_pci_get_phb_node(struct pci_dev *dev)
>> }
>> EXPORT_SYMBOL(pnv_pci_get_phb_node);
>>
>> -int pnv_pci_enable_tunnel(struct pci_dev *dev, u64 *asnind)
>> -{
>> - struct device_node *np;
>> - const __be32 *prop;
>> - struct pnv_ioda_pe *pe;
>> - uint16_t window_id;
>> - int rc;
>> -
>> - if (!radix_enabled())
>> - return -ENXIO;
>> -
>> - if (!(np = pnv_pci_get_phb_node(dev)))
>> - return -ENXIO;
>> -
>> - prop = of_get_property(np, "ibm,phb-indications", NULL);
>> - of_node_put(np);
>> -
>> - if (!prop || !prop[1])
>> - return -ENXIO;
>> -
>> - *asnind = (u64)be32_to_cpu(prop[1]);
>> - pe = pnv_ioda_get_pe(dev);
>> - if (!pe)
>> - return -ENODEV;
>> -
>> - /* Increase real window size to accept as_notify messages. */
>> - window_id = (pe->pe_number << 1 ) + 1;
>> - rc = opal_pci_map_pe_dma_window_real(pe->phb->opal_id, pe->pe_number,
>> - window_id, pe->tce_bypass_base,
>> - (uint64_t)1 << 48);
>> - return opal_error_code(rc);
>> -}
>> -EXPORT_SYMBOL_GPL(pnv_pci_enable_tunnel);
>> -
>> -int pnv_pci_disable_tunnel(struct pci_dev *dev)
>> -{
>> - struct pnv_ioda_pe *pe;
>> -
>> - pe = pnv_ioda_get_pe(dev);
>> - if (!pe)
>> - return -ENODEV;
>> -
>> - /* Restore default real window size. */
>> - pnv_pci_ioda2_set_bypass(pe, true);
>> - return 0;
>> -}
>> -EXPORT_SYMBOL_GPL(pnv_pci_disable_tunnel);
>> -
>> int pnv_pci_set_tunnel_bar(struct pci_dev *dev, u64 addr, int enable)
>> {
>> __be64 val;
>> @@ -970,29 +922,6 @@ int pnv_pci_set_tunnel_bar(struct pci_dev *dev, u64 addr, int enable)
>> }
>> EXPORT_SYMBOL_GPL(pnv_pci_set_tunnel_bar);
>>
>> -#ifdef CONFIG_PPC64 /* for thread.tidr */
>> -int pnv_pci_get_as_notify_info(struct task_struct *task, u32 *lpid, u32 *pid,
>> - u32 *tid)
>> -{
>> - struct mm_struct *mm = NULL;
>> -
>> - if (task == NULL)
>> - return -EINVAL;
>> -
>> - mm = get_task_mm(task);
>> - if (mm == NULL)
>> - return -EINVAL;
>> -
>> - *pid = mm->context.id;
>> - mmput(mm);
>> -
>> - *tid = task->thread.tidr;
>> - *lpid = mfspr(SPRN_LPID);
>> - return 0;
>> -}
>> -EXPORT_SYMBOL_GPL(pnv_pci_get_as_notify_info);
>> -#endif
>> -
>> void pnv_pci_shutdown(void)
>> {
>> struct pci_controller *hose;
>> diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
>> index 4f11c077af62..469c24463247 100644
>> --- a/arch/powerpc/platforms/powernv/pci.h
>> +++ b/arch/powerpc/platforms/powernv/pci.h
>> @@ -195,7 +195,6 @@ extern int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type);
>> extern void pnv_teardown_msi_irqs(struct pci_dev *pdev);
>> extern struct pnv_ioda_pe *pnv_ioda_get_pe(struct pci_dev *dev);
>> extern void pnv_set_msi_irq_chip(struct pnv_phb *phb, unsigned int virq);
>> -extern void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable);
>> extern unsigned long pnv_pci_ioda2_get_table_size(__u32 page_shift,
>> __u64 window_size, __u32 levels);
>> extern int pnv_eeh_post_init(void);
>> --
>> 2.20.1
>>
>
^ permalink raw reply
* [PATCH] powerpc/lib/xor_vmx: Relax frame size for clang
From: Mathieu Malaterre @ 2019-06-21 8:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: Mathieu Malaterre, linux-kernel, Paul Mackerras, Joel Stanley,
linuxppc-dev
When building with clang-8 the frame size limit is hit:
../arch/powerpc/lib/xor_vmx.c:119:6: error: stack frame size of 1200 bytes in function '__xor_altivec_5' [-Werror,-Wframe-larger-than=]
Follow the same approach as commit 9c87156cce5a ("powerpc/xmon: Relax
frame size for clang") until a proper fix is implemented upstream in
clang and relax requirement for clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/563
Cc: Joel Stanley <joel@jms.id.au>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
---
arch/powerpc/lib/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index c55f9c27bf79..b3f7d64caaf0 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -58,5 +58,9 @@ obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
obj-$(CONFIG_ALTIVEC) += xor_vmx.o xor_vmx_glue.o
CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
+ifdef CONFIG_CC_IS_CLANG
+# See https://github.com/ClangBuiltLinux/linux/issues/563
+CFLAGS_xor_vmx.o += -Wframe-larger-than=4096
+endif
obj-$(CONFIG_PPC64) += $(obj64-y)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in a structure
From: Nicholas Piggin @ 2019-06-21 8:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rich Felker, Yoshinori Sato, Linux-sh list, James Hogan,
the arch/x86 maintainers, Linux List Kernel Mailing,
David S. Miller, Linux-MM, Khalid Aziz, Paul Burton,
Andrey Konovalov, sparclinux, Paul Mackerras, linux-mips,
linuxppc-dev, Christoph Hellwig
In-Reply-To: <CAHk-=wh46y3x5O0HkR=R4ETh6e5pDCrEsJ94CtC0fyQiYYAf6A@mail.gmail.com>
Linus Torvalds's on June 21, 2019 3:21 am:
> On Thu, Jun 20, 2019 at 5:19 AM Nicholas Piggin <npiggin@gmail.com> wrote:
>>
>> The processor aliasing problem happens because the struct will
>> be initialised with stores using one base register (e.g., stack
>> register), and then same memory is loaded using a different
>> register (e.g., parameter register).
>
> Hmm. Honestly, I've never seen anything like that in any kernel profiles.
>
> Compared to the problems I _do_ see (which is usually the obvious
> cache misses, and locking), it must either be in the noise or it's
> some problem specific to whatever CPU you are doing performance work
> on?
No you're right, the performance hit from these flushes is not a
big hit that stands out in cycle counts. I just look at kernel code
for various flushes. Branches not surprisingly are usually the main
culprit, but they're normally not so interesting.
Static alias prediction seems to work well outside this case. It's
interesting, you need both a store ; load sequence that does not
predict well (e.g., using a different base register), and you also
need that load to be executed ahead of the store.
The small stack structure for arguments is the perfect case. Bad
pattern, and load executed right after store. Even then you also need
a reason to delay the store (e.g., source not ready or store queue
full), but those hazards do show up.
Now, even when all that goes wrong, there are dynamic heuristics that
can take over. So if you run a repetitive microbenchmark you won't
see it.
Some CPUs seem to be quite aggressive about giving up and turning off
the alias prediction globally if you take misses (Intel x86 used to do
that IIRC, not sure if they still do). So in that case you wouldn't
even see it show up in one place, everything will just run slightly
slower.
What I worry about is high rate direct IO workloads that see single
flushes in these paths as significant. Or if this thing creeps in to
the kernel too much and just slightly raises global misses enough,
then it will cause disambiguation to be significantly shut down.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in a structure
From: Christoph Hellwig @ 2019-06-21 8:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: sparclinux, Rich Felker, Yoshinori Sato, Linux-sh list,
Andrey Konovalov, the arch/x86 maintainers,
Linux List Kernel Mailing, Nicholas Piggin, David S. Miller,
Linux-MM, Khalid Aziz, Paul Burton, James Hogan, Paul Mackerras,
linux-mips, linuxppc-dev, Christoph Hellwig
In-Reply-To: <CAHk-=wh46y3x5O0HkR=R4ETh6e5pDCrEsJ94CtC0fyQiYYAf6A@mail.gmail.com>
On Thu, Jun 20, 2019 at 10:21:46AM -0700, Linus Torvalds wrote:
> Hmm. Honestly, I've never seen anything like that in any kernel profiles.
>
> Compared to the problems I _do_ see (which is usually the obvious
> cache misses, and locking), it must either be in the noise or it's
> some problem specific to whatever CPU you are doing performance work
> on?
>
> I've occasionally seen pipeline hiccups in profiles, but it's usually
> been either some serious glass jaw of the core, or it's been something
> really stupid we did (or occasionally that the compiler did: one in
> particular I remember was how there was a time when gcc would narrow
> stores when it could, so if you set a bit in a word, it would do it
> with a byte store, and then when you read the whole word afterwards
> you'd get a major pipeline stall and it happened to show up in some
> really hot paths).
I've not seen any difference in the GUP bench output here ar all.
But I'm fine with skipping this patch for now, I have a potential
series I'm looking into that would benefit a lot from it, but we
can discusss it in that context and make sure all the other works gets in
in time.
^ permalink raw reply
* Re: [PATCH 05/13] powerpc/mce: Allow notifier callback to handle MCE
From: Mahesh Jagannath Salgaonkar @ 2019-06-21 7:05 UTC (permalink / raw)
To: Santosh Sivaraj, linuxppc-dev
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <196df6a74f259c041a4269e6cba026a1248ed4af.1561020760.git.santosh@fossix.org>
On 6/21/19 6:27 AM, Santosh Sivaraj wrote:
> From: Reza Arbab <arbab@linux.ibm.com>
>
> If a notifier returns NOTIFY_STOP, consider the MCE handled, just as we
> do when machine_check_early() returns 1.
>
> Signed-off-by: Reza Arbab <arbab@linux.ibm.com>
> ---
> arch/powerpc/include/asm/asm-prototypes.h | 2 +-
> arch/powerpc/kernel/exceptions-64s.S | 3 +++
> arch/powerpc/kernel/mce.c | 28 ++++++++++++++++-------
> 3 files changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/asm-prototypes.h b/arch/powerpc/include/asm/asm-prototypes.h
> index f66f26ef3ce0..49ee8f08de2a 100644
> --- a/arch/powerpc/include/asm/asm-prototypes.h
> +++ b/arch/powerpc/include/asm/asm-prototypes.h
> @@ -72,7 +72,7 @@ void machine_check_exception(struct pt_regs *regs);
> void emulation_assist_interrupt(struct pt_regs *regs);
> long do_slb_fault(struct pt_regs *regs, unsigned long ea);
> void do_bad_slb_fault(struct pt_regs *regs, unsigned long ea, long err);
> -void machine_check_notify(struct pt_regs *regs);
> +long machine_check_notify(struct pt_regs *regs);
>
> /* signals, syscalls and interrupts */
> long sys_swapcontext(struct ucontext __user *old_ctx,
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 2e56014fca21..c83e38a403fd 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -460,6 +460,9 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
>
> addi r3,r1,STACK_FRAME_OVERHEAD
> bl machine_check_notify
> + ld r11,RESULT(r1)
> + or r3,r3,r11
> + std r3,RESULT(r1)
>
> ld r12,_MSR(r1)
> BEGIN_FTR_SECTION
> diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
> index 0ab171b41ede..912efe58e0b1 100644
> --- a/arch/powerpc/kernel/mce.c
> +++ b/arch/powerpc/kernel/mce.c
> @@ -647,16 +647,28 @@ long hmi_exception_realmode(struct pt_regs *regs)
> return 1;
> }
>
> -void machine_check_notify(struct pt_regs *regs)
> +long machine_check_notify(struct pt_regs *regs)
> {
> - struct machine_check_event evt;
> + int index = __this_cpu_read(mce_nest_count) - 1;
> + struct machine_check_event *evt;
> + int rc;
>
> - if (!get_mce_event(&evt, MCE_EVENT_DONTRELEASE))
> - return;
> + if (index < 0 || index >= MAX_MC_EVT)
> + return 0;
> +
> + evt = this_cpu_ptr(&mce_event[index]);
>
> - blocking_notifier_call_chain(&mce_notifier_list, 0, &evt);
> + rc = blocking_notifier_call_chain(&mce_notifier_list, 0, evt);
> + if (rc & NOTIFY_STOP_MASK) {
> + evt->disposition = MCE_DISPOSITION_RECOVERED;
> + regs->msr |= MSR_RI;
What is the reason for setting MSR_RI ? I don't think this is a good
idea. MSR_RI = 0 means system got MCE interrupt when SRR0 and SRR1
contents were live and was overwritten by MCE interrupt. Hence this
interrupt is unrecoverable irrespective of whether machine check handler
recovers from it or not.
Thanks,
-Mahesh.
^ permalink raw reply
* [PATCH] powerpc/rtas: retry when cpu offline races with suspend/migration
From: Nathan Lynch @ 2019-06-21 6:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: ego, mmc, julietk
The protocol for suspending or migrating an LPAR requires all present
processor threads to enter H_JOIN. So if we have threads offline, we
have to temporarily bring them up. This can race with administrator
actions such as SMT state changes. As of dfd718a2ed1f ("powerpc/rtas:
Fix a potential race between CPU-Offline & Migration"),
rtas_ibm_suspend_me() accounts for this, but errors out with -EBUSY
for what almost certainly is a transient condition in any reasonable
scenario.
Callers of rtas_ibm_suspend_me() already retry when -EAGAIN is
returned, and it is typical during a migration for that to happen
repeatedly for several minutes polling the H_VASI_STATE hcall result
before proceeding to the next stage.
So return -EAGAIN instead of -EBUSY when this race is
encountered. Additionally: logging this event is still appropriate but
use pr_info instead of pr_err; and remove use of unlikely() while here
as this is not a hot path at all.
Fixes: dfd718a2ed1f ("powerpc/rtas: Fix a potential race between CPU-Offline & Migration")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/kernel/rtas.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index fbc676160adf..9b4d2a2ffb4f 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -984,10 +984,9 @@ int rtas_ibm_suspend_me(u64 handle)
cpu_hotplug_disable();
/* Check if we raced with a CPU-Offline Operation */
- if (unlikely(!cpumask_equal(cpu_present_mask, cpu_online_mask))) {
- pr_err("%s: Raced against a concurrent CPU-Offline\n",
- __func__);
- atomic_set(&data.error, -EBUSY);
+ if (!cpumask_equal(cpu_present_mask, cpu_online_mask)) {
+ pr_info("%s: Raced against a concurrent CPU-Offline\n", __func__);
+ atomic_set(&data.error, -EAGAIN);
goto out_hotplug_enable;
}
--
2.20.1
^ permalink raw reply related
* [PATCH] powerpc/powernv: Rename pe_level_printk to pe_printk and embed KERN_LEVEL in format
From: Joe Perches @ 2019-06-21 5:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Remove the separate KERN_<LEVEL> from each pe_level_printk and
instead add the KERN_<LEVEL> to the format.
pfix in pe_level_printk could also be used uninitialized so
add a new else and set pfx to the hex value of pe->flags.
Rename pe_level_printk to pe_printk and update the pe_<level>
macros.
Signed-off-by: Joe Perches <joe@perches.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 14 ++++++++++++--
arch/powerpc/platforms/powernv/pci.h | 11 +++++------
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 10cc42b9e541..60fc36ae626a 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -50,15 +50,23 @@
static const char * const pnv_phb_names[] = { "IODA1", "IODA2", "NPU_NVLINK",
"NPU_OCAPI" };
-void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
- const char *fmt, ...)
+void pe_printk(const struct pnv_ioda_pe *pe, const char *fmt, ...)
{
struct va_format vaf;
va_list args;
char pfix[32];
+ char level[PRINTK_MAX_SINGLE_HEADER_LEN + 1] = "\0";
va_start(args, fmt);
+ while (printk_get_level(fmt)) {
+ size_t size = printk_skip_level(fmt) - fmt;
+
+ memcpy(level, fmt, size);
+ level[size] = '\0';
+ fmt += size;
+ }
+
vaf.fmt = fmt;
vaf.va = &args;
@@ -74,6 +82,8 @@ void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
(pe->rid & 0xff00) >> 8,
PCI_SLOT(pe->rid), PCI_FUNC(pe->rid));
#endif /* CONFIG_PCI_IOV*/
+ else
+ sprintf(pfix, "(flags: 0x%lx)", pe->flags);
printk("%spci %s: [PE# %.2x] %pV",
level, pfix, pe->pe_number, &vaf);
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index be26ab3d99e0..870b21f55b3f 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -205,15 +205,14 @@ extern unsigned long pnv_pci_ioda2_get_table_size(__u32 page_shift,
__u64 window_size, __u32 levels);
extern int pnv_eeh_post_init(void);
-__printf(3, 4)
-extern void pe_level_printk(const struct pnv_ioda_pe *pe, const char *level,
- const char *fmt, ...);
+__printf(2, 3)
+extern void pe_printk(const struct pnv_ioda_pe *pe, const char *fmt, ...);
#define pe_err(pe, fmt, ...) \
- pe_level_printk(pe, KERN_ERR, fmt, ##__VA_ARGS__)
+ pe_printk(pe, KERN_ERR fmt, ##__VA_ARGS__)
#define pe_warn(pe, fmt, ...) \
- pe_level_printk(pe, KERN_WARNING, fmt, ##__VA_ARGS__)
+ pe_printk(pe, KERN_WARNING fmt, ##__VA_ARGS__)
#define pe_info(pe, fmt, ...) \
- pe_level_printk(pe, KERN_INFO, fmt, ##__VA_ARGS__)
+ pe_printk(pe, KERN_INFO fmt, ##__VA_ARGS__)
/* Nvlink functions */
extern void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass);
^ permalink raw reply related
* [PATCH kernel] powerpc/of/pci: Rewrite pci_parse_of_flags
From: Alexey Kardashevskiy @ 2019-06-21 5:11 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Oliver O'Halloran, Paul Mackerras,
Sam Bobroff
The existing code uses bunch of hardcoded values from the PCI Bus Binding
to IEEE Std 1275 spec; and it does so in quite non-obvious way.
This defines fields from the cell#0 of the "reg" property of a PCI device
and uses them for parsing.
This should cause no behavioral change.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/kernel/pci_of_scan.c | 53 ++++++++++++++++++++++++++-----
1 file changed, 45 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 8078bce89bec..fc55ee710eb3 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -42,13 +42,50 @@ unsigned int pci_parse_of_flags(u32 addr0, int bridge)
{
unsigned int flags = 0;
- if (addr0 & 0x02000000) {
+/*
+ * PCI Bus Binding to IEEE Std 1275-1994
+ *
+ * Bit# 33222222 22221111 11111100 00000000
+ * 10987654 32109876 54321098 76543210
+ * phys.hi cell: npt000ss bbbbbbbb dddddfff rrrrrrrr
+ * phys.mid cell: hhhhhhhh hhhhhhhh hhhhhhhh hhhhhhhh
+ * phys.lo cell: llllllll llllllll llllllll llllllll
+ *
+ * where:
+ * n is 0 if the address is relocatable, 1 otherwise
+ * p is 1 if the addressable region is "prefetchable", 0 otherwise
+ * t is 1 if the address is aliased (for non-relocatable I/O),
+ * below 1 MB (for Memory),or below 64 KB (for relocatable I/O).
+ * ss is the space code, denoting the address space
+ * bbbbbbbb is the 8-bit Bus Number
+ * ddddd is the 5-bit Device Number
+ * fff is the 3-bit Function Number
+ * rrrrrrrr is the 8-bit Register Number
+ */
+#define OF_PCI_ADDR0_SPACE_CODE(ss) (((ss)&0x3UL)<<24)
+#define OF_PCI_ADDR0_SPACE_CFG OF_PCI_ADDR0_SPACE_CODE(0)
+#define OF_PCI_ADDR0_SPACE_IO OF_PCI_ADDR0_SPACE_CODE(1)
+#define OF_PCI_ADDR0_SPACE_MMIO32 OF_PCI_ADDR0_SPACE_CODE(2)
+#define OF_PCI_ADDR0_SPACE_MMIO64 OF_PCI_ADDR0_SPACE_CODE(3)
+#define OF_PCI_ADDR0_SPACE_MMIO (OF_PCI_ADDR0_SPACE_MMIO32 | \
+ OF_PCI_ADDR0_SPACE_MMIO64)
+#define OF_PCI_ADDR0_RELOC (1UL<<31)
+#define OF_PCI_ADDR0_PREFETCH (1UL<<30)
+#define OF_PCI_ADDR0_ALIAS (1UL<<29)
+#define OF_PCI_ADDR0_BUS 0x00FF0000UL
+#define OF_PCI_ADDR0_DEV 0x0000F800UL
+#define OF_PCI_ADDR0_FN 0x00000700UL
+#define OF_PCI_ADDR0_BARREG 0x000000FFUL
+
+ if (addr0 & OF_PCI_ADDR0_SPACE_MMIO) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
- flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
- if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
- flags |= IORESOURCE_MEM_64;
- flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
- if (addr0 & 0x40000000)
+ if ((addr0 & OF_PCI_ADDR0_SPACE_MMIO) ==
+ OF_PCI_ADDR0_SPACE_MMIO64)
+ flags |= PCI_BASE_ADDRESS_MEM_TYPE_64 |
+ IORESOURCE_MEM_64;
+ if (addr0 & OF_PCI_ADDR0_ALIAS)
+ flags |= PCI_BASE_ADDRESS_MEM_TYPE_1M;
+ if (addr0 & OF_PCI_ADDR0_PREFETCH)
flags |= IORESOURCE_PREFETCH
| PCI_BASE_ADDRESS_MEM_PREFETCH;
/* Note: We don't know whether the ROM has been left enabled
@@ -56,9 +93,9 @@ unsigned int pci_parse_of_flags(u32 addr0, int bridge)
* not set the IORESOURCE_ROM_ENABLE flag) for now rather than
* do a config space read, it will be force-enabled if needed
*/
- if (!bridge && (addr0 & 0xff) == 0x30)
+ if (!bridge && (addr0 & OF_PCI_ADDR0_BARREG) == PCI_ROM_ADDRESS)
flags |= IORESOURCE_READONLY;
- } else if (addr0 & 0x01000000)
+ } else if (addr0 & OF_PCI_ADDR0_SPACE_IO)
flags = IORESOURCE_IO | PCI_BASE_ADDRESS_SPACE_IO;
if (flags)
flags |= IORESOURCE_SIZEALIGN;
--
2.17.1
^ permalink raw reply related
* [PATCH 13/13] powerpc: add machine check safe copy_to_user
From: Santosh Sivaraj @ 2019-06-21 4:55 UTC (permalink / raw)
To: linuxppc-dev
Cc: Aneesh Kumar K.V, Mahesh Salgaonkar, Nicholas Piggin,
Chandan Rajendra, Reza Arbab
In-Reply-To: <cover.1561020760.git.santosh@fossix.org>
Use memcpy_mcsafe() implementation to define copy_to_user_mcsafe()
Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/uaccess.h | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c1c636308c8..a173b392c272 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -134,6 +134,7 @@ config PPC
select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !RELOCATABLE && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UACCESS_FLUSHCACHE if PPC64
+ select ARCH_HAS_UACCESS_MCSAFE if PPC64
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_HAS_ZONE_DEVICE if PPC_BOOK3S_64
select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 76f34346b642..f8fcaab4c5bc 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -386,6 +386,18 @@ static inline unsigned long raw_copy_to_user(void __user *to,
return ret;
}
+static __always_inline unsigned long __must_check
+copy_to_user_mcsafe(void __user *to, const void *from, unsigned long n)
+{
+ if (likely(check_copy_size(from, n, true))) {
+ allow_write_to_user(to, n);
+ n = memcpy_mcsafe(to, from, n);
+ prevent_write_to_user(to, n);
+ }
+
+ return n;
+}
+
extern unsigned long __clear_user(void __user *addr, unsigned long size);
static inline unsigned long clear_user(void __user *addr, unsigned long size)
--
2.20.1
^ permalink raw reply related
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