Re: [PATCH] powerpc: Enhance pmem DMA bypass handling

On 10/26/21 01:40, Brian King wrote: > On 10/23/21 7:18 AM, Alexey Kardashevskiy wrote: >> >> >> On 23/10/2021 07:18, Brian King wrote: >>> On 10/22/21 7:24 AM, Alexey Kardashevskiy wrote: On 22/10/2021 04:44, Brian King wrote: > If ibm,pmemory is installed in the system, it

[PATCH 3/3] powerpc/fsl_booke: Fix setting of exec flag when setting TLBCAMs

Building tqm8541_defconfig results in: arch/powerpc/mm/nohash/fsl_book3e.c: In function 'settlbcam': arch/powerpc/mm/nohash/fsl_book3e.c:126:40: error: '_PAGE_BAP_SX' undeclared (first use in this function) 126 | TLBCAM[index].MAS3 |= (flags & _PAGE_BAP_SX) ?

[PATCH 2/3] powerpc/book3e: Fix set_memory_x() and set_memory_nx()

set_memory_x() calls pte_mkexec() which sets _PAGE_EXEC. set_memory_nx() calls pte_exprotec() which clears _PAGE_EXEC. Book3e has 2 bits, UX and SX, which defines the exec rights resp. for user (PR=1) and for kernel (PR=0). _PAGE_EXEC is defined as UX only. An executable kernel page is set with

[PATCH 1/3] powerpc/nohash: Fix __ptep_set_access_flags() and ptep_set_wrprotect()

Commit 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code") changed those two functions to use pte helpers to determine which bits to clear and which bits to set. This change was based on the assumption that bits to be set/cleared are always the same and can be determined by applying the

Re: [PATCH v11 2/3] tty: hvc: pass DMA capable memory to put_chars()

On 15. 10. 21, 4:46, Xianting Tian wrote: @@ -151,9 +142,11 @@ static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] = static void hvc_console_print(struct console *co, const char *b, unsigned count) { - char c[N_OUTBUF] __ALIGNED__; + char *c;

[PATCH v2] macintosh/via-pmu-led: make disk activity usage a parameter.

Whether to use the LED as a disk activity is a user preference. Some like this usage while others find the LED too bright. So it might be a good idea to make this choice a runtime parameter rather than compile-time config. The default is set to disabled as OS X does not use the LED as a disk

[PATCH v5 2/2] ftrace: do CPU checking after preemption disabled

With CONFIG_DEBUG_PREEMPT we observed reports like: BUG: using smp_processor_id() in preemptible caller is perf_ftrace_function_call+0x6f/0x2e0 CPU: 1 PID: 680 Comm: a.out Not tainted Call Trace: dump_stack_lvl+0x8d/0xcf check_preemption_disabled+0x104/0x110 ?

[PATCH v5 1/2] ftrace: disable preemption when recursion locked

As the documentation explained, ftrace_test_recursion_trylock() and ftrace_test_recursion_unlock() were supposed to disable and enable preemption properly, however currently this work is done outside of the function, which could be missing by mistake. And since the internal using of

[PATCH v5 0/2] fix & prevent the missing preemption disabling

The testing show that perf_ftrace_function_call() are using smp_processor_id() with preemption enabled, all the checking on CPU could be wrong after preemption. As Peter point out, the section between ftrace_test_recursion_trylock/unlock() pair require the preemption to be disabled as

Re: [PATCH v4 0/2] fix & prevent the missing preemption disabling

On 2021/10/26 上午10:42, Steven Rostedt wrote: > On Tue, 26 Oct 2021 10:09:12 +0800 > 王贇 wrote: > >> Just a ping, to see if there are any more comments :-P > > I guess you missed what went into mainline (and your name found a bug > in my perl script for importing patches ;-) > >

Re: [PATCH v4 0/2] fix & prevent the missing preemption disabling

On Tue, 26 Oct 2021 10:09:12 +0800 王贇 wrote: > Just a ping, to see if there are any more comments :-P I guess you missed what went into mainline (and your name found a bug in my perl script for importing patches ;-) https://lore.kernel.org/all/20211019091344.65629...@gandalf.local.home/

Re: [PATCH] mm/migrate.c: Remove MIGRATE_PFN_LOCKED

On 10/24/21 21:16, Alistair Popple wrote: MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a source page was already locked during migrate_vma_collect(). If it wasn't then the a second attempt is made to lock the page. However if the first attempt failed it's unlikely a

linux-next: manual merge of the audit tree with the powerpc tree

Hi all, Today's linux-next merge of the audit tree got conflicts in: arch/powerpc/kernel/audit.c arch/powerpc/kernel/compat_audit.c between commit: 566af8cda399 ("powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC") from the powerpc tree and commits: 42f355ef59a2 ("audit:

Re: [PATCH v4 0/2] fix & prevent the missing preemption disabling

Just a ping, to see if there are any more comments :-P Regards, Michael Wang On 2021/10/18 上午11:38, 王贇 wrote: > The testing show that perf_ftrace_function_call() are using smp_processor_id() > with preemption enabled, all the checking on CPU could be wrong after > preemption. > > As Peter

Re: [PATCH] macintosh/via-pmu-led: make disk activity usage a parameter.

Hi Hill, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.15-rc7 next-20211025] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented

[powerpc:fixes-test] BUILD SUCCESS d853adc7adf601d7d6823afe3ed396065a3e08d1

configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig i386 randconfig-c001-20211025 mips

Re: [PATCH] powerpc/bpf: fix write protecting JIT code

On 10/25/21 8:15 AM, Naveen N. Rao wrote: Hari Bathini wrote: Running program with bpf-to-bpf function calls results in data access exception (0x300) with the below call trace:     [c0113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)     [c037d2f8] bpf_check+0x2008/0x2710    

Re: [PATCH v1 3/8] powerpc/fsl_booke: Take exec flag into account when setting TLBCAMs

On 22/10/2021 08:36, kernel test robot wrote: Hi Christophe, I love your patch! Yet something to improve: [auto build test ERROR on powerpc/next] [also build test ERROR on v5.15-rc6 next-20211021] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting

Re: [PATCH v2 02/10] powerpc/book3e: Fix set_memory_x() and set_memory_nx()

On 23/10/2021 13:47, Christophe Leroy wrote: set_memory_x() calls pte_mkexec() which sets _PAGE_EXEC. set_memory_nx() calls pte_exprotec() which clears _PAGE_EXEC. Book3e has 2 bits, UX and SX, which defines the exec rights resp. for user (PR=1) and for kernel (PR=0). _PAGE_EXEC is defined

[PATCH v3 02/10] powerpc/book3e: Fix set_memory_x() and set_memory_nx()

set_memory_x() calls pte_mkexec() which sets _PAGE_EXEC. set_memory_nx() calls pte_exprotec() which clears _PAGE_EXEC. Book3e has 2 bits, UX and SX, which defines the exec rights resp. for user (PR=1) and for kernel (PR=0). _PAGE_EXEC is defined as UX only. An executable kernel page is set with

[PATCH v3 07/10] powerpc/fsl_booke: Tell map_mem_in_cams() if init is done

In order to be able to call map_mem_in_cams() once more after init for STRICT_KERNEL_RWX, add an argument. For now, map_mem_in_cams() is always called only during init. Signed-off-by: Christophe Leroy --- v3: No change v2: No change --- arch/powerpc/mm/mmu_decl.h | 2 +-

[PATCH v3 01/10] powerpc/nohash: Fix __ptep_set_access_flags() and ptep_set_wrprotect()

Commit 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code") changed those two functions to use pte helpers to determine which bits to clear and which bits to set. This change was based on the assumption that bits to be set/cleared are always the same and can be determined by applying the

[PATCH v3 10/10] powerpc/fsl_booke: Enable STRICT_KERNEL_RWX

Enable STRICT_KERNEL_RWX on fsl_booke. For that, we need additional TLBCAMs dedicated to linear mapping, based on the alignment of _sinittext. By default, up to 768 Mbytes of memory are mapped. It uses 3 TLBCAMs of size 256 Mbytes. With a data alignment of 16, we need up to 9 TLBCAMs:

[PATCH v3 09/10] powerpc/fsl_booke: Update of TLBCAMs after init

After init, set readonly memory as ROX and set readwrite memory as RWX, if STRICT_KERNEL_RWX is enabled. Signed-off-by: Christophe Leroy --- v3: No change v2: No change --- arch/powerpc/mm/mmu_decl.h | 2 +- arch/powerpc/mm/nohash/fsl_book3e.c | 32 + 2

[PATCH v3 03/10] powerpc/booke: Disable STRICT_KERNEL_RWX, DEBUG_PAGEALLOC and KFENCE

fsl_booke and 44x are not able to map kernel linear memory with pages, so they can't support DEBUG_PAGEALLOC and KFENCE, and STRICT_KERNEL_RWX is also a problem for now. Enable those only on book3s (both 32 and 64 except KFENCE), 8xx and 40x. Fixes: 88df6e90fa97 ("[POWERPC] DEBUG_PAGEALLOC for

[PATCH v3 08/10] powerpc/fsl_booke: Allocate separate TLBCAMs for readonly memory

Reorganise TLBCAM allocation so that when STRICT_KERNEL_RWX is enabled, TLBCAMs are allocated such that readonly memory uses different TLBCAMs. This results in an allocation looking like: Memory CAM mapping: 4/4/4/1/1/1/1/16/16/16/64/64/64/256/256 Mb, residual: 256Mb Signed-off-by: Christophe

[PATCH v3 05/10] powerpc/fsl_booke: Take exec flag into account when setting TLBCAMs

Don't force MAS3_SX and MAS3_UX at all time. Take into account the exec flag. While at it, fix a couple of closeby style problems (indent with space and unnecessary parenthesis), it keeps more readability. Signed-off-by: Christophe Leroy --- v3: No change v2: Use the new _PAGE_EXEC to check

[PATCH v3 06/10] powerpc/fsl_booke: Enable reloading of TLBCAM without switching to AS1

Avoid switching to AS1 when reloading TLBCAM after init for STRICT_KERNEL_RWX. When we setup AS1 we expect the entire accessible memory to be mapped through one entry, this is not the case anymore at the end of init. We are not changing the size of TLBCAMs, only flags, so no need to switch to

[PATCH v3 04/10] powerpc/fsl_booke: Rename fsl_booke.c to fsl_book3e.c

We have a myriad of CONFIG symbols around different variants of BOOKEs, which would be worth tidying up one day. But at least, make file names and CONFIG option match: We have CONFIG_FSL_BOOKE and CONFIG_PPC_FSL_BOOK3E. fsl_booke.c is selected by and only by CONFIG_PPC_FSL_BOOK3E. So rename it

Re: [PATCH V2] powerpc/perf: Enable PMU counters post partition migration if PMU is active

> On 21-Oct-2021, at 11:03 PM, Nathan Lynch wrote: > > Nicholas Piggin mailto:npig...@gmail.com>> writes: >> Excerpts from Athira Rajeev's message of July 11, 2021 10:25 pm: >>> During Live Partition Migration (LPM), it is observed that perf >>> counter values reports zero post migration

Re: [PATCH V2] powerpc/perf: Enable PMU counters post partition migration if PMU is active

> On 21-Oct-2021, at 10:47 PM, Nathan Lynch wrote: > > Athira Rajeev > writes: >> During Live Partition Migration (LPM), it is observed that perf >> counter values reports zero post migration completion. However >> 'perf stat' with workload continues to

Re: [PATCH V2] powerpc/perf: Enable PMU counters post partition migration if PMU is active

> On 21-Oct-2021, at 4:24 PM, Nicholas Piggin wrote: > > Excerpts from Athira Rajeev's message of July 11, 2021 10:25 pm: >> During Live Partition Migration (LPM), it is observed that perf >> counter values reports zero post migration completion. However >> 'perf stat' with workload continues

Re: [PATCH] locking: remove spin_lock_flags() etc

On 10/25/21 11:44 AM, Arnd Bergmann wrote: On Mon, Oct 25, 2021 at 5:28 PM Waiman Long wrote: On 10/25/21 9:06 AM, Arnd Bergmann wrote: On s390, we pick between the cmpxchg() based directed-yield when running on virtualized CPUs, and a normal qspinlock when running on a dedicated CPU. I am

[PATCH v5 5/5] PCI/AER: Include DEVCTL in aer_print_error()

Print the contents of Device Control Register of the device which detected the error. This might help in faster error diagnosis. It is easy to test this by using aer-inject: $ aer-inject -s 00:03:0 corr-err-file The content of the corr-err-file is as below: AER COR_STATUS BAD_TLP

[PATCH v5 4/5] PCI/AER: Clear error device AER registers in aer_irq()

Converge the APEI path and native AER path of clearing the AER registers of the error device. In APEI path, the system firmware clears the AER registers before handing off the record to OS. But in "native AER" path, the execution path of clearing the AER register is as follows:

[PATCH v5 3/5] PCI/DPC: Initialize info.id in dpc_process_error()

In the dpc_process_error() path, info.id isn't initialized before being passed to aer_print_error(). In the corresponding AER path, it is initialized in aer_isr_one_error(). The error message shown during Coverity Scan is: Coverity #1461602 CID 1461602 (#1 of 1): Uninitialized scalar

[PATCH v5 2/5] PCI: Cleanup struct aer_err_info

The id, status and the mask fields of the struct aer_err_info comes directly from the registers, hence their sizes should be explicit. The length of these registers are: - id: 16 bits - Represents the Error Source Requester ID - status: 32 bits - COR/UNCOR Error Status - mask: 32 bits -

[PATCH v5 1/5] PCI/AER: Remove ID from aer_agent_string[]

Currently, we do not print the "id" field in the AER error logs. Yet the aer_agent_string[] has the word "id" in it. The AER error log looks like: pcieport :00:03.0: PCIe Bus Error: severity=Corrected, type=Data Link Layer, (Receiver ID) Without the "id" field in the error log, The

[PATCH v5 0/5] Fix long standing AER Error Handling Issues

This patch series aims at fixing some of the AER error handling issues we have. Currently we have the following issues: 1. Confusing message in aer_print_error() 2. aer_err_info not being initialized completely in DPC path before we print the AER logs 3. A bug [1] in clearing of

Re: [PATCH 08/13] zram: add error handling support for add_disk()

On Fri, Oct 15, 2021 at 04:52:14PM -0700, Luis Chamberlain wrote: > We never checked for errors on add_disk() as this function > returned void. Now that this is fixed, use the shiny new > error handling. > > Signed-off-by: Luis Chamberlain Acked-by: Minchan Kim

Re: [PATCH 00/13] block: add_disk() error handling stragglers

ranch has so many changes applied on top of the base v5.15-rc4 > that the patches I need to apply to test on PS3 with don't apply. > > Do you have something closer to say v5.15-rc5? Preferred would be > just your add_disk() error handling patches plus what they depend > on. If you j

Re: [PATCH] locking: remove spin_lock_flags() etc

On Mon, Oct 25, 2021 at 5:28 PM Waiman Long wrote: > On 10/25/21 9:06 AM, Arnd Bergmann wrote: > > > > On s390, we pick between the cmpxchg() based directed-yield when > > running on virtualized CPUs, and a normal qspinlock when running on a > > dedicated CPU. > > I am not aware that s390 is

Re: [PATCH] locking: remove spin_lock_flags() etc

On 10/25/21 9:06 AM, Arnd Bergmann wrote: On Mon, Oct 25, 2021 at 11:57 AM Peter Zijlstra wrote: On Sat, Oct 23, 2021 at 06:04:57PM +0200, Arnd Bergmann wrote: On Sat, Oct 23, 2021 at 3:37 AM Waiman Long wrote: On 10/22/21 7:59 AM, Arnd Bergmann wrote: From: Arnd Bergmann As this is all

Re: [PATCH] powerpc: Enhance pmem DMA bypass handling

On 10/23/21 7:18 AM, Alexey Kardashevskiy wrote: > > > On 23/10/2021 07:18, Brian King wrote: >> On 10/22/21 7:24 AM, Alexey Kardashevskiy wrote: >>> >>> >>> On 22/10/2021 04:44, Brian King wrote: If ibm,pmemory is installed in the system, it can appear anywhere in the address space.

Re: [PATCH] locking: remove spin_lock_flags() etc

On Mon, Oct 25, 2021 at 03:06:24PM +0200, Arnd Bergmann wrote: > On Mon, Oct 25, 2021 at 11:57 AM Peter Zijlstra wrote: > > On Sat, Oct 23, 2021 at 06:04:57PM +0200, Arnd Bergmann wrote: > > > On Sat, Oct 23, 2021 at 3:37 AM Waiman Long wrote: > > > >> On 10/22/21 7:59 AM, Arnd Bergmann wrote: >

Re: [PATCH] locking: remove spin_lock_flags() etc

On Mon, Oct 25, 2021 at 11:57 AM Peter Zijlstra wrote: > On Sat, Oct 23, 2021 at 06:04:57PM +0200, Arnd Bergmann wrote: > > On Sat, Oct 23, 2021 at 3:37 AM Waiman Long wrote: > > >> On 10/22/21 7:59 AM, Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > > > > > As this is all dead code,

Re: [PATCH v2] perf vendor events power10: Add metric events json file for power10 platform

On Mon, Oct 25, 2021 at 02:23:15PM +1100, Michael Ellerman wrote: > "Paul A. Clarke" writes: > > Thanks for the changes! > > More nits below (many left over from prior review)... > > > > On Fri, Oct 22, 2021 at 11:55:05AM +0530, Kajol Jain wrote: > >> Add pmu metric json file for power10

Linux kernel: powerpc: KVM guest can trigger host crash on Power8

The Linux kernel for powerpc since v5.2 has a bug which allows a malicious KVM guest to crash the host, when the host is running on Power8. Only machines using Linux as the hypervisor, aka. KVM, powernv or bare metal, are affected by the bug. Machines running PowerVM are not affected. The bug

[PATCH] selftests/powerpc: Use date instead of EPOCHSECONDS in mitigation-patching.sh

The EPOCHSECONDS environment variable was added in bash 5.0 (released 2019). Some distributions of the "stable" and "long-term" variety ship older versions of bash than this, so swap to using the date command instead. "%s" was added to coreutils `date` in 1993 so we should be good, but who

Re: [PATCH] locking: remove spin_lock_flags() etc

On Mon, Oct 25, 2021 at 11:57:28AM +0200, Peter Zijlstra wrote: > On Sat, Oct 23, 2021 at 06:04:57PM +0200, Arnd Bergmann wrote: > > On Sat, Oct 23, 2021 at 3:37 AM Waiman Long wrote: > > >> On 10/22/21 7:59 AM, Arnd Bergmann wrote: > > > > From: Arnd Bergmann > > > > > > > > As this is all dead

Re: [PATCH] locking: remove spin_lock_flags() etc

On Sat, Oct 23, 2021 at 06:04:57PM +0200, Arnd Bergmann wrote: > On Sat, Oct 23, 2021 at 3:37 AM Waiman Long wrote: > >> On 10/22/21 7:59 AM, Arnd Bergmann wrote: > > > From: Arnd Bergmann > > > > > > As this is all dead code, just remove it and the helper functions built > > > around it. For

[Bug 206669] Little-endian kernel crashing on POWER8 on heavy big-endian PowerKVM load

https://bugzilla.kernel.org/show_bug.cgi?id=206669 --- Comment #18 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de) --- There seems to be a related discussion: > https://yhbt.net/lore/all/20200831091523.gc29...@kitsune.suse.cz/T/ This suspects

[PATCH] macintosh/via-pmu-led: make disk activity usage a parameter.

Whether to use the LED as a disk activity is a user preference. Some like this usage while others find the LED too bright. So it might be a good idea to make this choice a runtime parameter rather than compile-time config. The default is set to disabled as OS X does not use the LED as a disk

Re: [PATCH] powerpc/bpf: fix write protecting JIT code

Hari Bathini wrote: Running program with bpf-to-bpf function calls results in data access exception (0x300) with the below call trace: [c0113f28] bpf_int_jit_compile+0x238/0x750 (unreliable) [c037d2f8] bpf_check+0x2008/0x2710 [c0360050]