linux.git/arch/powerpc/lib, branch v6.8

powerpc/lib: Validate size for vector operations

2023-11-27T11:06:19+00:00

Some of the fp/vmx code in sstep.c assume a certain maximum size for the
instructions being emulated. The size of those operations however is
determined separately in analyse_instr().

Add a check to validate the assumption on the maximum size of the
operations, so as to prevent any unintended kernel stack corruption.

Signed-off-by: Naveen N Rao 
Reviewed-by: Gustavo A. R. Silva 
Build-tested-by: Gustavo A. R. Silva 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231123071705.397625-1-naveen@kernel.org

powerpc/lib: Avoid array bounds warnings in vec ops

2023-11-27T11:05:14+00:00

Building with GCC with -Warray-bounds enabled there are several warnings
in sstep.c along the lines of:

  In function ‘do_byte_reverse’,
      inlined from ‘do_vec_load’ at arch/powerpc/lib/sstep.c:691:3,
      inlined from ‘emulate_loadstore’ at arch/powerpc/lib/sstep.c:3439:9:
  arch/powerpc/lib/sstep.c:289:23: error: array subscript 2 is outside array bounds of ‘u8[16]’ {aka ‘unsigned char[16]’} [-Werror=array-bounds=]
    289 |                 up[2] = byterev_8(up[1]);
        |                 ~~~~~~^~~~~~~~~~~~~~~~~~
  arch/powerpc/lib/sstep.c: In function ‘emulate_loadstore’:
  arch/powerpc/lib/sstep.c:681:11: note: at offset 16 into object ‘u’ of size 16
    681 |         } u = {};
        |           ^

do_byte_reverse() supports a size up to 32 bytes, but in these cases the
caller is only passing a 16 byte buffer. In practice there is no bug,
do_vec_load() is only called from the LOAD_VMX case in emulate_loadstore().
That in turn is only reached when analyse_instr() recognises VMX ops,
and in all cases the size is no greater than 16:

  $ git grep -w LOAD_VMX arch/powerpc/lib/sstep.c
  arch/powerpc/lib/sstep.c:                        op->type = MKOP(LOAD_VMX, 0, 1);
  arch/powerpc/lib/sstep.c:                        op->type = MKOP(LOAD_VMX, 0, 2);
  arch/powerpc/lib/sstep.c:                        op->type = MKOP(LOAD_VMX, 0, 4);
  arch/powerpc/lib/sstep.c:                        op->type = MKOP(LOAD_VMX, 0, 16);

Similarly for do_vec_store().

Although the warning is incorrect, the code would be safer if it clamped
the size from the caller to the known size of the buffer. Do that using
min_t().

Reported-by: Bagas Sanjaya 
Closes: https://lore.kernel.org/linuxppc-dev/YpbUcPrm61RLIiZF@debian.me/
Reported-by: Jan-Benedict Glaw 
Closes: https://lore.kernel.org/linuxppc-dev/20221212215117.aa7255t7qd6yefk4@lug-owl.de/
Reported-by: "Gustavo A. R. Silva" 
Closes: https://lore.kernel.org/linuxppc-dev/6a8bf78c-aedb-4d5a-b0aa-82a51a17b884@embeddedor.com/
Reviewed-by: "Gustavo A. R. Silva" 
Build-tested-by: "Gustavo A. R. Silva" 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231120235436.1569255-1-mpe@ellerman.id.au

powerpc: add crtsavres.o to always-y instead of extra-y

2023-11-27T11:01:15+00:00

crtsavres.o is linked to modules. However, as explained in commit
d0e628cd817f ("kbuild: doc: clarify the difference between extra-y
and always-y"), 'make modules' does not build extra-y.

For example, the following command fails:

  $ make ARCH=powerpc LLVM=1 KBUILD_MODPOST_WARN=1 mrproper ps3_defconfig modules
    [snip]
    LD [M]  arch/powerpc/platforms/cell/spufs/spufs.ko
  ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or directory
  make[3]: *** [scripts/Makefile.modfinal:56: arch/powerpc/platforms/cell/spufs/spufs.ko] Error 1
  make[2]: *** [Makefile:1844: modules] Error 2
  make[1]: *** [/home/masahiro/workspace/linux-kbuild/Makefile:350: __build_one_by_one] Error 2
  make: *** [Makefile:234: __sub-make] Error 2

Signed-off-by: Masahiro Yamada 
Fixes: baa25b571a16 ("powerpc/64: Do not link crtsavres.o in vmlinux")
Reviewed-by: Nicholas Piggin 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231120232332.4100288-1-masahiroy@kernel.org

powerpc/code-patching: introduce patch_instructions()

2023-10-23T09:33:19+00:00

patch_instruction() entails setting up pte, patching the instruction,
clearing the pte and flushing the tlb. If multiple instructions need
to be patched, every instruction would have to go through the above
drill unnecessarily. Instead, introduce patch_instructions() function
that sets up the pte, clears the pte and flushes the tlb only once
per page range of instructions to be patched. Duplicate most of the
patch_instruction() code instead of merging with it, to avoid the
performance degradation observed on ppc32, for patch_instruction(),
with the code path merged. Also, setup poking_init() always as BPF
expects poking_init() to be setup even when STRICT_KERNEL_RWX is off.

Signed-off-by: Hari Bathini 
Acked-by: Song Liu 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231020141358.643575-2-hbathini@linux.ibm.com

powerpc/code-patching: Perform hwsync in __patch_instruction() in case of failure

2023-10-20T12:19:13+00:00

Commit c28c15b6d28a ("powerpc/code-patching: Use temporary mm for
Radix MMU") added a hwsync for when __patch_instruction() fails,
we results in a quite odd unbalanced logic.

Instead of calling mb() when __patch_instruction() returns an error,
call mb() in the __patch_instruction()'s error path directly.

Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/e88b154eaf2efd9ff177d472d3411dcdec8ff4f5.1696675567.git.christophe.leroy@csgroup.eu

powerpc/qspinlock: Rename yield_propagate_owner tunable

2023-10-20T11:43:34+00:00

Rename yield_propagate_owner to yield_sleepy_owner, which better
describes what it does (what, not how).

Signed-off-by: Nicholas Piggin 
Tested-by: Shrikanth Hegde 
Reviewed-by: "Nysal Jan K.A" 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231016124305.139923-7-npiggin@gmail.com

powerpc/qspinlock: Propagate sleepy if previous waiter is preempted

2023-10-20T11:43:34+00:00

The sleepy (aka lock-owner-is-preempted) condition is propagated down
the queue by each waiter. If a waiter becomes preempted, it can no
longer propagate sleepy. To allow subsequent waiters to yield to the
lock owner, also check the lock owner in this case.

Signed-off-by: Nicholas Piggin 
Tested-by: Shrikanth Hegde 
Reviewed-by: "Nysal Jan K.A" 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231016124305.139923-6-npiggin@gmail.com

powerpc/qspinlock: don't propagate the not-sleepy state

2023-10-20T11:43:34+00:00

To simplify things, don't propagate the not-sleepy condition back down
the queue. Instead, have the waiters clear their own node->sleepy when
finding the lock owner is not preempted.

Signed-off-by: Nicholas Piggin 
Tested-by: Shrikanth Hegde 
Reviewed-by: "Nysal Jan K.A" 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231016124305.139923-5-npiggin@gmail.com

powerpc/qspinlock: propagate owner preemptedness rather than CPU number

2023-10-20T11:43:34+00:00

Rather than propagating the CPU number of the preempted lock owner,
just propagate whether the owner was preempted. Waiters must read the
lock value when yielding to it to prevent races anyway, so might as
well always load the owner CPU from the lock.

To further simplify the code, also don't propagate the -1 (or
sleepy=false in the new scheme) down the queue. Instead, have the
waiters clear it themselves when finding the lock owner is not
preempted.

Signed-off-by: Nicholas Piggin 
Tested-by: Shrikanth Hegde 
Reviewed-by: "Nysal Jan K.A" 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231016124305.139923-4-npiggin@gmail.com

powerpc/qspinlock: stop queued waiters trying to set lock sleepy

2023-10-20T11:43:34+00:00

If a queued waiter notices the lock owner or the previous waiter has
been preempted, it attempts to mark the lock sleepy, but it does this
as a try-set operation using the original lock value it got when
queueing, which will become stale as the queue progresses, and the
try-set will fail. Drop this and just set the sleepy seen clock.

Signed-off-by: Nicholas Piggin 
Tested-by: Shrikanth Hegde 
Reviewed-by: "Nysal Jan K.A" 
Signed-off-by: Michael Ellerman 
Link: https://msgid.link/20231016124305.139923-3-npiggin@gmail.com