Re: [PATCH 00/58] serial/sysrq: Cleanup ifdeffery

Le 13/12/2019 à 01:05, Dmitry Safonov a écrit : The original purpose of the patches set was to add a way to enable sysrq on a uart where currently it can be constantly either on or off (CONFIG_MAGIC_SYSRQ_SERIAL), see the last patch: "serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE" But to

PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

Le jeu. 12 déc. 2019 à 22:40, Andreas Schwab a écrit : > I'm using 4K pages, in case that matters Yes it does matter, as it seems to be the difference between "working" and "not working" :-) Thank you for the config & pointing out the culprit! With your config, my machine boots (though it's

[PATCH 49/58] serial/ucc_uart: Remove ifdef SUPPORT_SYSRQ

ucc_uart doesn't seem to support console over itself, so maybe it can be deleted with uart_handle_sysrq_char() from the file. Cc: Timur Tabi Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Dmitry Safonov --- drivers/tty/serial/ucc_uart.c | 2 -- 1 file changed, 2 deletions(-) diff --git

[PATCH] Fix vm selftest to run tests with make

The last patch overrides the ARCH env variable and hence runs using make fails with the following. $ make -C vm/ make: Entering directory '/home/harish/linux/tools/testing/selftests/vm' make --no-builtin-rules ARCH=ppc64le -C ../../../.. headers_install make[1]: Entering directory

Re: HPT allocation failures on POWER8 KVM hosts

On Mon, Nov 18, 2019 at 02:42:42PM +0300, Roman Bolshakov wrote: > On Mon, Nov 18, 2019 at 01:02:00PM +1100, Daniel Axtens wrote: > > Hi Roman, > > > > > We're running a lot of KVM virtual machines on POWER8 hosts and > > > sometimes new VMs can't be started because there are no contiguous > > >

[PATCH 05/58] tty/serial: Migrate 8250_fsl to use has_sysrq

The SUPPORT_SYSRQ ifdeffery is not nice as: - May create misunderstanding about sizeof(struct uart_port) between different objects - Prevents moving functions from serial_core.h - Reduces readability (well, it's ifdeffery - it's hard to follow) In order to remove SUPPORT_SYSRQ, has_sysrq

[PATCH 00/58] serial/sysrq: Cleanup ifdeffery

The original purpose of the patches set was to add a way to enable sysrq on a uart where currently it can be constantly either on or off (CONFIG_MAGIC_SYSRQ_SERIAL), see the last patch: "serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE" But to do that, I had to add uart_try_toggle_sysrq() and I

[PATCH 31/58] tty/serial: Migrate pmac_zilog to use has_sysrq

The SUPPORT_SYSRQ ifdeffery is not nice as: - May create misunderstanding about sizeof(struct uart_port) between different objects - Prevents moving functions from serial_core.h - Reduces readability (well, it's ifdeffery - it's hard to follow) In order to remove SUPPORT_SYSRQ, has_sysrq

Re: [PATCH v4 1/2] powerpc/vcpu: Assume dedicated processors as non-preempt

Srikar Dronamraju writes: > With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted > vCPUs"), scheduler avoids preempted vCPUs to schedule tasks on wakeup. > This leads to wrong choice of CPU, which in-turn leads to larger wakeup > latencies. Eventually, it leads to

Re: [PATCH v5 2/2] powerpc/pseries/iommu: Use dma_iommu_ops for Secure VM.

Quoting Ram Pai (2019-12-12 00:45:02) > On Tue, Dec 10, 2019 at 07:43:24PM -0600, Michael Roth wrote: > > Quoting Ram Pai (2019-12-06 19:12:39) > > > Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on > > > secure guests") > > > disabled dma_iommu_ops path, for

[PATCH v5 1/2] powerpc/vcpu: Assume dedicated processors as non-preempt

From: Srikar Dronamraju With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs"), the scheduler avoids preempted vCPUs to schedule tasks on wakeup. This leads to wrong choice of CPU, which in-turn leads to larger wakeup latencies. Eventually, it leads to performance

Re: [PATCH v5 1/2] powerpc/vcpu: Assume dedicated processors as non-preempt

* Michael Ellerman [2019-12-13 14:50:35]: > Waiman Long suggested using static_keys. > > Fixes: 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs") > Cc: sta...@vger.kernel.org # v4.18+ > Reported-by: Parth Shah > Reported-by: Ihor Pasichnyk > Tested-by: Juri Lelli >

Re: [PATCH v5 1/2] powerpc/pseries/iommu: Share the per-cpu TCE page with the hypervisor.

Quoting Alexey Kardashevskiy (2019-12-11 16:47:30) > > > On 12/12/2019 07:31, Michael Roth wrote: > > Quoting Alexey Kardashevskiy (2019-12-11 02:15:44) > >> > >> > >> On 11/12/2019 02:35, Ram Pai wrote: > >>> On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote: > > >

Isn't LD=ld.lld enough to get a kernel build started?

Hi, Or should I set the LD with the full path to the LLD linker?

[PATCH v5 2/2] powerpc/shared: Use static key to detect shared processor

From: Srikar Dronamraju With the static key shared processor available, is_shared_processor() can return without having to query the lppaca structure. Signed-off-by: Srikar Dronamraju Acked-by: Phil Auld Acked-by: Waiman Long Signed-off-by: Michael Ellerman Link:

Re: [PATCH v3 3/3] powerpc: Book3S 64-bit "heavyweight" KASAN support

On Fri, Dec 13, 2019 at 2:19 AM Daniel Axtens wrote: > > KASAN support on Book3S is a bit tricky to get right: > > - It would be good to support inline instrumentation so as to be able to >catch stack issues that cannot be caught with outline mode. > > - Inline instrumentation requires a

[PATCH v10 22/25] mm, tree-wide: rename put_user_page*() to unpin_user_page*()

In order to provide a clearer, more symmetric API for pinning and unpinning DMA pages. This way, pin_user_pages*() calls match up with unpin_user_pages*() calls, and the API is a lot closer to being self-explanatory. Reviewed-by: Jan Kara Signed-off-by: John Hubbard ---

Re: [PATCH v10 23/25] mm/gup: track FOLL_PIN pages

On Thu 12-12-19 00:19:15, John Hubbard wrote: > Add tracking of pages that were pinned via FOLL_PIN. > > As mentioned in the FOLL_PIN documentation, callers who effectively set > FOLL_PIN are required to ultimately free such pages via unpin_user_page(). > The effect is similar to FOLL_GET, and

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 10:07:56AM +, Will Deacon wrote: > > So your proposed change _should_ be fine. Will, I'm assuming you never > > saw this on your ARGH64 builds when you did this code ? > > I did see it, but (a) looking at the code out-of-line makes it look a lot > worse than it

Re: [PATCH v5] powerpc/irq: inline call_do_irq() and call_do_softirq() on PPC32

On Sat, Dec 07, 2019 at 05:20:04PM +, Christophe Leroy wrote: > call_do_irq() and call_do_softirq() are simple enough to be > worth inlining. > > Inlining them avoids an mflr/mtlr pair plus a save/reload on stack. > It also allows GCC to keep the saved ksp_limit in an nonvolatile reg. > >

Re: [PATCH V2 08/13] powerpc/vas: Update CSB and notify process for fault CRBs

On Sun, Dec 08, 2019 at 07:33:37PM -0800, Haren Myneni wrote: > +static void notify_process(pid_t pid, u64 fault_addr) > +{ > + int rc; > + struct kernel_siginfo info; > + > + memset(, 0, sizeof(info)); > + > + info.si_signo = SIGSEGV; > + info.si_errno = EFAULT; > +

Re: [PATCH] powerpc/irq: don't use current_stack_pointer() in do_IRQ()

Why can't current_stack_pointer be turned into an inline function using inline assembly? That would reduce the overhead for all callers.

Re: [PATCH V2 04/13] powerpc/vas: Setup fault window per VAS instance

On Sun, Dec 08, 2019 at 07:30:33PM -0800, Haren Myneni wrote: > +static int vas_irq_fault_window_setup(struct vas_instance *vinst) > +{ > + int rc = 0; > + > + rc = vas_setup_fault_window(vinst); > + > + return rc; > +} No real need for the local variable here.

Re: [PATCH V2 07/13] powerpc/vas: Take reference to PID and mm for user space windows

> + if (txwin->user_win) { > + /* > + * Window opened by child thread may not be closed when > + * it exits. So take reference to its pid and release it > + * when the window is free by parent thread. > + * Acquire a reference to

Re: [PATCH v2 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support

Hi Christophe, I think I've covered everything you've mentioned in the v3 I'm about to send, except for: >> +/* mark early shadow region as RO and wipe */ >> +pte = __pte(__pa(kasan_early_shadow_page) | >> +pgprot_val(PAGE_KERNEL_RO) | _PAGE_PTE); > > Any reason for

Re: [PATCH V2 05/13] powerpc/vas: Setup thread IRQ handler per VAS instance

On Sun, Dec 08, 2019 at 07:31:24PM -0800, Haren Myneni wrote: > > Setup thread IRQ handler per each VAS instance. When NX sees a fault > on CRB, kernel gets an interrupt and vas_fault_handler will be > executed to process fault CRBs. Read all valid CRBs from fault FIFO, > determine the

Re: Call for report - G5/PPC970 status

On 12/12/19 9:00 AM, Romain Dolbeau wrote: > Could you share the screen/log of the crash? > > For my G5 with 5.5rc1 I have one, but the photo is terrible: > > Timestamps overlap, as after the 'crash' (backtrace) there was > more messages from

[PATCH v10 11/25] goldish_pipe: convert to pin_user_pages() and put_user_page()

1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). In this case, do so via put_user_pages_dirty_lock(). That has the side effect of calling set_page_dirty_lock(), instead of set_page_dirty(). This

[PATCH v10 16/25] net/xdp: set FOLL_PIN via pin_user_pages()

Convert net/xdp to use the new pin_longterm_pages() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. In partial anticipation of this work, the net/xdp code was already calling put_user_page() instead of put_page(). Therefore, in order to

[PATCH v10 12/25] IB/{core, hw, umem}: set FOLL_PIN via pin_user_pages*(), fix up ODP

Convert infiniband to use the new pin_user_pages*() calls. Also, revert earlier changes to Infiniband ODP that had it using put_user_page(). ODP is "Case 3" in Documentation/core-api/pin_user_pages.rst, which is to say, normal get_user_pages() and put_page() is the API to use there. The new

[PATCH v10 24/25] mm/gup_benchmark: support pin_user_pages() and related calls

Up until now, gup_benchmark supported testing of the following kernel functions: * get_user_pages(): via the '-U' command line option * get_user_pages_longterm(): via the '-L' command line option * get_user_pages_fast(): as the default (no options required) Add test coverage for the new

[PATCH v4 1/2] powerpc/vcpu: Assume dedicated processors as non-preempt

With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs"), scheduler avoids preempted vCPUs to schedule tasks on wakeup. This leads to wrong choice of CPU, which in-turn leads to larger wakeup latencies. Eventually, it leads to performance regression in latency sensitive

Re: [PATCH v2 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support

On 12/11/19 5:24 PM, Daniel Axtens wrote: > Hi Balbir, > > +Discontiguous memory can occur when you have a machine with memory spread > +across multiple nodes. For example, on a Talos II with 64GB of RAM: > + > + - 32GB runs from 0x0 to 0x_0008__, > + - then

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 09:01:05AM +0100, Peter Zijlstra wrote: > On Thu, Dec 12, 2019 at 04:42:13PM +1100, Michael Ellerman wrote: > > Peter Zijlstra writes: > > > On Fri, Dec 06, 2019 at 11:46:11PM +1100, Michael Ellerman wrote: > > Some of the generic versions don't generate good code compared

Re: [RESEND PATCH v5 5/5] Documentation/vmcoreinfo: Add documentation for 'TCR_EL1.T1SZ'

Hi Bhupesh, On 29/11/2019 19:59, Bhupesh Sharma wrote: > Add documentation for TCR_EL1.T1SZ variable being added to > vmcoreinfo. > > It indicates the size offset of the memory region addressed by TTBR1_EL1 > and hence can be used for determining the vabits_actual value. used for determining

Re: Call for report - G5/PPC970 status

Le jeu. 12 déc. 2019 à 08:32, jjhdiederen a écrit : > PowerMac 7,3 G5 2.5 DP PCI-X Mid-2004 is affected with this bug. The > machine freezes at boot due to the new ppc64 kernel. Thanks for the reports! So it's not all G5, but it's across generations - the iMac is PCIe. Perhaps multiprocessors?

[PATCH v10 01/25] mm/gup: factor out duplicate code from four routines

There are four locations in gup.c that have a fair amount of code duplication. This means that changing one requires making the same changes in four places, not to mention reading the same code four times, and wondering if there are subtle differences. Factor out the common code into static

[PATCH v10 18/25] media/v4l2-core: pin_user_pages (FOLL_PIN) and put_user_page() conversion

1. Change v4l2 from get_user_pages() to pin_user_pages(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Acked-by: Hans Verkuil Cc: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH v10 14/25] drm/via: set FOLL_PIN via pin_user_pages_fast()

Convert drm/via to use the new pin_user_pages_fast() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages, and therefore for any code that calls put_user_page(). In partial anticipation of this work, the drm/via driver was already calling

[PATCH v10 03/25] mm: Cleanup __put_devmap_managed_page() vs ->page_free()

From: Dan Williams After the removal of the device-public infrastructure there are only 2 ->page_free() call backs in the kernel. One of those is a device-private callback in the nouveau driver, the other is a generic wakeup needed in the DAX case. In the hopes that all ->page_free() callbacks

[PATCH v10 23/25] mm/gup: track FOLL_PIN pages

Add tracking of pages that were pinned via FOLL_PIN. As mentioned in the FOLL_PIN documentation, callers who effectively set FOLL_PIN are required to ultimately free such pages via unpin_user_page(). The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET for DIO and/or RDMA use".

Re: [PATCH v2 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support

Le 12/12/2019 à 08:42, Balbir Singh a écrit : On 12/12/19 1:24 am, Daniel Axtens wrote: Hi Balbir, +Discontiguous memory can occur when you have a machine with memory spread +across multiple nodes. For example, on a Talos II with 64GB of RAM: + + - 32GB runs from 0x0 to

[PATCH v10 05/25] goldish_pipe: rename local pin_user_pages() routine

1. Avoid naming conflicts: rename local static function from "pin_user_pages()" to "goldfish_pin_pages()". An upcoming patch will introduce a global pin_user_pages() function. Reviewed-by: Jan Kara Reviewed-by: Jérôme Glisse Reviewed-by: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH v10 25/25] selftests/vm: run_vmtests: invoke gup_benchmark with basic FOLL_PIN coverage

It's good to have basic unit test coverage of the new FOLL_PIN behavior. Fortunately, the gup_benchmark unit test is extremely fast (a few milliseconds), so adding it the the run_vmtests suite is going to cause no noticeable change in running time. So, add two new invocations to run_vmtests: 1)

Re: [RESEND PATCH v5 2/5] arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo

Hi Bhupesh, On 29/11/2019 19:59, Bhupesh Sharma wrote: > vabits_actual variable on arm64 indicates the actual VA space size, > and allows a single binary to support both 48-bit and 52-bit VA > spaces. > > If the ARMv8.2-LVA optional feature is present, and we are running > with a 64KB page size;

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 04:42:13PM +1100, Michael Ellerman wrote: > [ trimmed CC a bit ] > > Peter Zijlstra writes: > > On Fri, Dec 06, 2019 at 11:46:11PM +1100, Michael Ellerman wrote: > ... > > you write: > > > > "Currently bitops-instrumented.h assumes that the architecture provides > >

[PATCH v10 13/25] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()

Convert process_vm_access to use the new pin_user_pages_remote() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. Also, release the pages via put_user_page*(). Also, rename "pages" to "pinned_pages", as this makes for easier reading of

[PATCH v10 10/25] mm/gup: introduce pin_user_pages*() and FOLL_PIN

Introduce pin_user_pages*() variations of get_user_pages*() calls, and also pin_longterm_pages*() variations. For now, these are placeholder calls, until the various call sites are converted to use the correct get_user_pages*() or pin_user_pages*() API. These variants will eventually all set

[PATCH v10 19/25] vfio, mm: pin_user_pages (FOLL_PIN) and put_user_page() conversion

1. Change vfio from get_user_pages_remote(), to pin_user_pages_remote(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Note that this effectively changes the code's behavior in

[PATCH v10 09/25] IB/umem: use get_user_pages_fast() to pin DMA pages

And get rid of the mmap_sem calls, as part of that. Note that get_user_pages_fast() will, if necessary, fall back to __gup_longterm_unlocked(), which takes the mmap_sem as needed. Reviewed-by: Leon Romanovsky Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Jason Gunthorpe

[PATCH v10 02/25] mm/gup: move try_get_compound_head() to top, fix minor issues

An upcoming patch uses try_get_compound_head() more widely, so move it to the top of gup.c. Also fix a tiny spelling error and a checkpatch.pl warning. Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Ira Weiny Signed-off-by: John Hubbard --- mm/gup.c | 29

[PATCH v10 15/25] fs/io_uring: set FOLL_PIN via pin_user_pages()

Convert fs/io_uring to use the new pin_user_pages() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages, and therefore for any code that calls put_user_page(). In partial anticipation of this work, the io_uring code was already calling

[PATCH v10 21/25] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1"

Fix the gup benchmark flags to use the symbolic FOLL_WRITE, instead of a hard-coded "1" value. Also, clean up the filtering of gup flags a little, by just doing it once before issuing any of the get_user_pages*() calls. This makes it harder to overlook, instead of having little "gup_flags & 1"

[PATCH v10 04/25] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages

An upcoming patch changes and complicates the refcounting and especially the "put page" aspects of it. In order to keep everything clean, refactor the devmap page release routines: * Rename put_devmap_managed_page() to page_is_devmap_managed(), and limit the functionality to "read only": return

[PATCH v10 08/25] mm/gup: allow FOLL_FORCE for get_user_pages_fast()

Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast(). This, combined with the fact that get_user_pages_fast() falls back to "slow gup", which *does* accept FOLL_FORCE, leads to an odd situation: if you need

[PATCH v10 07/25] vfio: fix FOLL_LONGTERM use, simplify get_user_pages_remote() call

Update VFIO to take advantage of the recently loosened restriction on FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it wasn't setting FOLL_LONGTERM. Also, remove an unnessary pair of calls that were

[PATCH v10 17/25] media/v4l2-core: set pages dirty upon releasing DMA buffers

After DMA is complete, and the device and CPU caches are synchronized, it's still required to mark the CPU pages as dirty, if the data was coming from the device. However, this driver was just issuing a bare put_page() call, without any set_page_dirty*() call. Fix the problem, by calling

[PATCH v10 20/25] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

1. Convert from get_user_pages() to pin_user_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). Reviewed-by: Jan Kara Signed-off-by: John Hubbard --- arch/powerpc/mm/book3s64/iommu_api.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

[PATCH v10 00/25] mm/gup: track dma-pinned pages: FOLL_PIN

Hi, This implements an API naming change (put_user_page*() --> unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It extends that tracking to a few select subsystems. More subsystems will be added in follow up work. Christoph Hellwig, a point of interest: a) I've moved the

[PATCH v10 06/25] mm: fix get_user_pages_remote()'s handling of FOLL_LONGTERM

As it says in the updated comment in gup.c: current FOLL_LONGTERM behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the FS DAX check requirement on vmas. However, the corresponding restriction in get_user_pages_remote() was slightly stricter than is actually required: it forbade all

[PATCH v3 0/3] KASAN for powerpc64 radix

Building on the work of Christophe, Aneesh and Balbir, I've ported KASAN to 64-bit Book3S kernels running on the Radix MMU. This provides full inline instrumentation on radix, but does require that you be able to specify the amount of physically contiguous memory on the system at compile time.

Re: [PATCH v3 1/3] kasan: define and use MAX_PTRS_PER_* for early shadow tables

Le 12/12/2019 à 16:16, Daniel Axtens a écrit : powerpc has a variable number of PTRS_PER_*, set at runtime based on the MMU that the kernel is booted under. This means the PTRS_PER_* are no longer constants, and therefore breaks the build. Define default MAX_PTRS_PER_*s in the same style as

Re: [PATCH] powerpc/irq: don't use current_stack_pointer() in do_IRQ()

Le 12/12/2019 à 13:51, Christoph Hellwig a écrit : Why can't current_stack_pointer be turned into an inline function using inline assembly? That would reduce the overhead for all callers. In the old days, it was a macro, and it was changed into an assembly function by commit

Re: [PATCH v5] powerpc/irq: inline call_do_irq() and call_do_softirq() on PPC32

Le 12/12/2019 à 13:52, Christoph Hellwig a écrit : On Sat, Dec 07, 2019 at 05:20:04PM +, Christophe Leroy wrote: call_do_irq() and call_do_softirq() are simple enough to be worth inlining. Inlining them avoids an mflr/mtlr pair plus a save/reload on stack. It also allows GCC to keep the

[PATCH v3 1/3] kasan: define and use MAX_PTRS_PER_* for early shadow tables

powerpc has a variable number of PTRS_PER_*, set at runtime based on the MMU that the kernel is booted under. This means the PTRS_PER_* are no longer constants, and therefore breaks the build. Define default MAX_PTRS_PER_*s in the same style as MAX_PTRS_PER_P4D. As KASAN is the only user at the

[PATCH v3 3/3] powerpc: Book3S 64-bit "heavyweight" KASAN support

KASAN support on Book3S is a bit tricky to get right: - It would be good to support inline instrumentation so as to be able to catch stack issues that cannot be caught with outline mode. - Inline instrumentation requires a fixed offset. - Book3S runs code in real mode after booting. Most

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

Hi, On Thu, Dec 12, 2019 at 04:42:13PM +1100, Michael Ellerman wrote: > Some of the generic versions don't generate good code compared to our > versions, but that's because READ_ONCE() is triggering stack protector > to be enabled. The *big* difference is the generic code has a special path that

[PATCH v3 2/3] kasan: Document support on 32-bit powerpc

KASAN is supported on 32-bit powerpc and the docs should reflect this. Suggested-by: Christophe Leroy Reviewed-by: Christophe Leroy Signed-off-by: Daniel Axtens --- Documentation/dev-tools/kasan.rst | 3 ++- Documentation/powerpc/kasan.txt | 12 2 files changed, 14

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 11:46:10AM +0100, Peter Zijlstra wrote: > On Thu, Dec 12, 2019 at 10:07:56AM +, Will Deacon wrote: > > > > So your proposed change _should_ be fine. Will, I'm assuming you never > > > saw this on your ARGH64 builds when you did this code ? > > > > I did see it, but

Re: Call for report - G5/PPC970 status

Le jeu. 12 déc. 2019 à 09:08, John Paul Adrian Glaubitz a écrit : > I suggest booting the machine with a netconsole to get a dump of the crash > over the network, see [1]. I added netconsole (not as a module, directly in the kernel), but I get nothing on my receiver 'nc'. I don't see the network

Re: Call for report - G5/PPC970 status

On Dez 11 2019, Romain Dolbeau wrote: > Same question to anyone else with a G5 / PPC970 - what is it and does > it boot recent PPC64 Linux kernel ? My PowerMac7,3 (DP 2.0GHz) can boot 5.5-rc1 without issues. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47

[PATCH 1/3] soc: fsl: dpio: Adding QMAN multiple enqueue interface.

Update of QMAN the interface to enqueue frame. We now support multiple enqueue (qbman_swp_enqueue_multiple) and multiple enqueue with a table of descriptor (qbman_swp_enqueue_multiple_desc). Signed-off-by: Youri Querry --- drivers/soc/fsl/dpio/dpio-service.c | 69 --

[PATCH 3/3] soc: fsl: dpio: Replace QMAN array mode by ring mode enqueue.

This change of algorithm will enable faster bulk enqueue. This will grately benefit XDP bulk enqueue. Signed-off-by: Youri Querry --- drivers/soc/fsl/dpio/qbman-portal.c | 410 +++- drivers/soc/fsl/dpio/qbman-portal.h | 13 ++ 2 files changed, 328 insertions(+),

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 05:04:27PM +, Will Deacon wrote: > On Thu, Dec 12, 2019 at 11:46:10AM +0100, Peter Zijlstra wrote: > > On Thu, Dec 12, 2019 at 10:07:56AM +, Will Deacon wrote: > > > > > > So your proposed change _should_ be fine. Will, I'm assuming you never > > > > saw this on

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 09:41:32AM -0800, Linus Torvalds wrote: > Yeah, I know, but this really wants a comment. Sadly it looks like gcc > bugzilla is down, so > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 > > currently gives an "Internal Server Error" for me. We're being DoSsed

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 09:41:32AM -0800, Linus Torvalds wrote: > On Thu, Dec 12, 2019 at 2:46 AM Peter Zijlstra wrote: > > > > +#ifdef GCC_VERSION < 40800 > > Where does that 4.8 version check come from, and why? > > Yeah, I know, but this really wants a comment. Sadly it looks like gcc >

[PATCH 2/3] soc: fsl: dpio: QMAN performance improvement. Function pointer indirection.

We are making the access decision in the initialization and setting the function pointers accordingly. Signed-off-by: Youri Querry --- drivers/soc/fsl/dpio/qbman-portal.c | 451 +++- drivers/soc/fsl/dpio/qbman-portal.h | 129 ++- 2 files changed, 507

Re: Call for report - G5/PPC970 status

Le jeu. 12 déc. 2019 à 19:20, Andreas Schwab a écrit : > My PowerMac7,3 (DP 2.0GHz) can boot 5.5-rc1 without issues. This is weird, as except for the frequency it should be the same system as Jeroen's crashing G5! Can you share your kernel config, compiler version, and other details? Perhaps

[PATCH 0/3] soc: fsl: dpio: Enable QMAN batch enqueuing

This patch set consists of: - We added an interface to enqueue several packets at a time and improve performance. - Make the algorithm decisions once at initialization and use function pointers to improve performance. - Replaced the QMAN enqueue array mode algorithm with a ring mode

[PATCH] spi: fsl: use platform_get_irq() instead of of_irq_to_resource()

Unlike irq_of_parse_and_map() which has a dummy definition on SPARC, of_irq_to_resource() hasn't. But as platform_get_irq() can be used instead and is generic, use it. Reported-by: kbuild test robot Suggested-by: Mark Brown Fixes: 3194d2533eff ("spi: fsl: don't map irq during probe") Cc:

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 2:46 AM Peter Zijlstra wrote: > > +#ifdef GCC_VERSION < 40800 Where does that 4.8 version check come from, and why? Yeah, I know, but this really wants a comment. Sadly it looks like gcc bugzilla is down, so https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On 12.12.19 19:06, Will Deacon wrote: > On Thu, Dec 12, 2019 at 09:41:32AM -0800, Linus Torvalds wrote: >> On Thu, Dec 12, 2019 at 2:46 AM Peter Zijlstra wrote: >>> >>> +#ifdef GCC_VERSION < 40800 >> >> Where does that 4.8 version check come from, and why? >> >> Yeah, I know, but this really

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 10:06 AM Will Deacon wrote: > > I'm currently trying to solve the issue by removing volatile from the bitop > function signatures I really think that's the wrong thing to do. The bitop signature really should be "volatile" (and it should be "const volatile" for test_bit,

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 11:34 AM Will Deacon wrote: > > The root of my concern in all of this, and what started me looking at it in > the first place, is the interaction with 'typeof()'. Inheriting 'volatile' > for a pointer means that local variables in macros declared using typeof() > suddenly

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 09:21:57PM +0100, Peter Zijlstra wrote: > On Thu, Dec 12, 2019 at 07:34:01PM +, Will Deacon wrote: > > void ool_store_release(volatile unsigned long *ptr, unsigned long val) > > { > > smp_store_release(ptr, val); > > } > > > > : > >0:

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

Hi Linus, On Thu, Dec 12, 2019 at 10:43:05AM -0800, Linus Torvalds wrote: > On Thu, Dec 12, 2019 at 10:06 AM Will Deacon wrote: > > > > I'm currently trying to solve the issue by removing volatile from the bitop > > function signatures > > I really think that's the wrong thing to do. > > The

Re: READ_ONCE() + STACKPROTECTOR_STRONG == :/ (was Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.5-2 tag (topic/kasan-bitops))

On Thu, Dec 12, 2019 at 07:34:01PM +, Will Deacon wrote: > void ool_store_release(volatile unsigned long *ptr, unsigned long val) > { > smp_store_release(ptr, val); > } > > : >0: a9be7bfdstp x29, x30, [sp, #-32]! >4: 9002adrpx2, 0

Re: Call for report - G5/PPC970 status

On Dez 12 2019, Romain Dolbeau wrote: > Can you share your kernel config, compiler version, and other details? I'm using 4K pages, in case that matters, and gcc 4.8. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And

[PATCH v2 1/1] KVM: PPC: Implement H_SVM_INIT_ABORT hcall

This patch is based on Bharata's v11 KVM patches for secure guests: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-November/200918.html --- >From c0826bac72a658312f3d87e0bb18ecaf08ac2b2e Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Fri, 27 Sep 2019 14:30:36 -0500 Subject: