Le 06/02/2023 à 03:17, Rohan McLure a écrit :
> Add Kernel Concurrency Sanitiser support for PPC64. Doing so involves
> exclusion of a number of compilation units from instrumentation, as was
> done with KASAN.
>
> KCSAN uses watchpoints on memory accesses to enforce the semantics of
> the Linux
Le 06/02/2023 à 03:18, Rohan McLure a écrit :
> Enable HAVE_ARCH_KCSAN on all powerpc platforms, permitting use of the
> kernel concurrency sanitiser through the CONFIG_KCSAN_* kconfig options.
> KCSAN requires compiler builtins __atomic_* 64-bit values, and so only
> report support on PPC64.
>
Josh Poimboeuf writes:
> start_secondary_resume() doesn't return. Annotate it as such. By
> extension this also makes arch_cpu_idle_dead() noreturn.
Can we also mark arch_cpu_idle_dead() (the C function) __noreturn ?
Seems like it would be good documentation, even if it's not required
once the
From: Pali Rohár
The "pci-OF-bus-map" property was declared deprecated in 2006 [1] and to
the best of everyone's knowledge is not used by anything anymore [2].
The creation of the property was disabled on powermac (arch/powerpc) in
2005 by commit 35499c0195e4 ("powerpc: Merge in 64-bit powermac
On Mon, 6 Feb 2023, Geert Uytterhoeven wrote:
JFYI, when comparing v6.2-rc7[1] to v6.2-rc6[3], the summaries are:
- build errors: +1/-1
+ /kisskb/src/arch/powerpc/kexec/file_load_64.c: error: implicit declaration of
function 'memory_hotplug_max' [-Werror=implicit-function-declaration]: =>
> On 05-Jan-2023, at 6:24 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Thu, Jan 05, 2023 at 05:47:42PM +0530, Athira Rajeev escreveu:
>> Perf BPF filter test fails in environment where "kernel-debuginfo"
>> is not installed.
>
> I'll apply this to perf/core, for the next merge window, as its mo
Em Mon, Feb 06, 2023 at 09:27:13AM +0530, Athira Rajeev escreveu:
> > On 02-Feb-2023, at 6:27 AM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Tue, Jan 31, 2023 at 07:20:01PM +0530, Athira Rajeev escreveu:
> >> "bpf" tests fails in environment with missing libtraceevent
> >> support as below:
Em Mon, Feb 06, 2023 at 07:28:49PM +0530, Athira Rajeev escreveu:
>
>
> > On 05-Jan-2023, at 6:24 PM, Arnaldo Carvalho de Melo
> > wrote:
> >
> > Em Thu, Jan 05, 2023 at 05:47:42PM +0530, Athira Rajeev escreveu:
> >> Perf BPF filter test fails in environment where "kernel-debuginfo"
> >> is no
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again. read_24x7_sys_info()
ignores this, allowing transient failures in reporting processor
module information.
Move the RTAS call into a coventional rtas_busy_delay()-
From: Nathan Lynch
The new papr_sysparm API handles the details of system parameter
retrieval. Use that instead of open-coding the RTAS call, work area
management, and retries.
Signed-off-by: Nathan Lynch
---
arch/powerpc/perf/hv-24x7.c | 37 +++--
1 file change
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again.
lparcfg's parse_system_parameter_string() ignores this, making it
possible to intermittently report incorrect SPLPAR characteristics.
Move the RTAS call into a c
From: Nathan Lynch
The core RTAS support code and its clients perform two types of lookup
for RTAS firmware function information.
First, mapping a known function name to a token. The typical use case
invokes rtas_token() to retrieve the token value to pass to
rtas_call(). rtas_token() relies on
From: Nathan Lynch
Make do_enter_rtas() take a pointer to struct rtas_args and do the
__pa() conversion in one place instead of leaving it to callers. This
also makes it possible to introduce enter/exit tracepoints that access
the rtas_args struct fields.
There's no apparent reason to force inli
From: Nathan Lynch
Hold a work area object for the duration of the RTAS
ibm,configure-connector sequence, eliminating locking and copying
around each RTAS call.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/dlpar.c | 27 +--
1 file changed, 9 insertions
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again.
pSeries_cmo_feature_init() ignores this, making it possible to fail to
detect cooperative memory overcommit capabilities during boot.
Move the RTAS call into a c
From: Nathan Lynch
The ibm,get-system-parameter RTAS function may return -2 or 990x,
which indicate that the caller should try again.
pseries_lpar_read_hblkrm_characteristics() ignores this, making it
possible to incorrectly detect TLB block invalidation characteristics
at boot.
Move the RTAS c
From: Nathan Lynch
Some code that runs early in boot calls RTAS functions that can return
-2 or 990x statuses, which mean the caller should retry. An example is
pSeries_cmo_feature_init(), which invokes ibm,get-system-parameter but
treats these benign statuses as errors instead of retrying.
pSer
Proposed changes for the RTAS subsystem and client code.
Fixes that are subject to backporting are at the front of the queue.
The rest of the queue is roughly ordered with respect to maturity:
i.e. patches that have already garnered some review and discussion
precede newer, more experimental chang
From: Nathan Lynch
Add two sets of tracepoints to be used around RTAS entry:
* rtas_input/rtas_output, which emit the function name, its inputs,
the returned status, and any other outputs. These produce an API-level
record of OS<->RTAS activity.
* rtas_ll_entry/rtas_ll_exit, which are lower
From: Nathan Lynch
Decompose the RTAS entry C code into tracing and non-tracing variants,
calling the just-added tracepoints in the tracing-enabled path. Skip
tracing in contexts known to be unsafe (real mode, CPU offline).
Signed-off-by: Nathan Lynch
---
arch/powerpc/kernel/rtas.c | 59 ++
From: Nathan Lynch
Users of rtas_token() supply a string argument that can't be validated
at build time. A typo or misspelling has to be caught by inspection or
by observing wrong behavior at runtime.
Since the core RTAS code now has consolidated the names of all
possible RTAS functions and mapp
From: Nathan Lynch
Convert the direct invocation of the ibm,get-system-parameter RTAS
function to papr_sysparm_get().
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/setup.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc
From: Nathan Lynch
The pseries platform has been LPAR-only for several generations, and
the PAPR spec:
* Guarantees that timebase synchronization is performed by
the platform ("The timebase registers are synchronized by the
platform before CPUs are given to the OS" - 7.3.8 SMP Support).
* C
From: Nathan Lynch
Most callers of RTAS functions that take a temporary "work area"
parameter use the statically allocated rtas_data_buf buffer as the
argument. This buffer is protected by a global spinlock. So users of
rtas_data_buf cannot perform sleeping operations while accessing the
buffer.
From: Nathan Lynch
/proc/powerpc/lparcfg derives the LPAR name and SPLPAR characteristics
it reports using bare calls to the RTAS ibm,get-system-parameter
function. Convert these to the higher-level papr_sysparm API, which
handles the tedious details.
While the SPLPAR string parsing code could s
From: Nathan Lynch
Introduce a set of APIs for retrieving and updating PAPR system
parameters. This encapsulates the toil of temporary RTAS work area
management, RTAS function call retries, and translation of RTAS call
statuses to conventional error values.
There are several places in the kernel
From: Nathan Lynch
Convert the TLB block invalidate characteristics discovery to the new
papr_sysparm API. This occurs too early in boot to use
papr_sysparm_buf_alloc(), so use a static buffer.
Signed-off-by: Nathan Lynch
---
arch/powerpc/platforms/pseries/lpar.c | 37 +
From: Nathan Lynch
With the tokens for all implemented RTAS functions now available via
rtas_function_token(), which is optimal and safe for arbitrary
contexts, there is no need to use rtas_token() or cache its result.
Most conversions are trivial, but a few are worth describing in more
detail:
On Mon, Feb 06, 2023 at 10:10:22PM +1100, Michael Ellerman wrote:
> Josh Poimboeuf writes:
> > start_secondary_resume() doesn't return. Annotate it as such. By
> > extension this also makes arch_cpu_idle_dead() noreturn.
>
> Can we also mark arch_cpu_idle_dead() (the C function) __noreturn ?
>
On 2/3/23 14:05, Josh Poimboeuf wrote:
Include to make sure play_dead() matches its prototype going
forward.
Signed-off-by: Josh Poimboeuf
Acked-by: Florian Fainelli
--
Florian
On 2/3/23 14:05, Josh Poimboeuf wrote:
play_dead() doesn't return. Make that more explicit with a BUG().
BUG() is preferable to unreachable() because BUG() is a more explicit
failure mode and avoids undefined behavior like falling off the edge of
the function into whatever code happens to be ne
On 2/3/23 14:05, Josh Poimboeuf wrote:
play_dead() doesn't return. Annotate it as such. By extension this
also makes arch_cpu_idle_dead() noreturn.
Signed-off-by: Josh Poimboeuf
Acked-by: Florian Fainelli
--
Florian
On Monday 06 February 2023 22:39:02 Michael Ellerman wrote:
> From: Pali Rohár
>
> The "pci-OF-bus-map" property was declared deprecated in 2006 [1] and to
> the best of everyone's knowledge is not used by anything anymore [2].
>
> The creation of the property was disabled on powermac (arch/powe
On 2/2/23 10:14 PM, Kajol Jain wrote:
Testcase stat_all_metrics.sh fails in powerpc:
92: perf all metrics test : FAILED!
Logs with verbose:
[command]# ./perf test 92 -vv
92: perf all metrics test :
--- start ---
test child forked, pid 13262
Te
On 1/31/23 7:20 PM, Athira Rajeev wrote:
"bpf" tests fails in environment with missing libtraceevent
support as below:
# ./perf test 36
36: BPF filter :
36.1: Basic BPF filtering : FAILED!
36.
Hi Thomas,
On 2/3/23 8:42 PM, Thomas Huth wrote:
This function only returns normal integer values, so there is
no need to declare its return value as "long".
Signed-off-by: Thomas Huth
---
arch/arm64/include/asm/kvm_host.h | 4 ++--
arch/arm64/kvm/guest.c| 4 ++--
2 files chang
only has 64M of RAM
so there will be some memory pressure, especially during boot. The
exact point things fall over seems to vary a little.
A sample failing job with the full log is here:
https://lava.sirena.org.uk/scheduler/job/262719
Full bisect log:
git bisect start
# bad: [129af770823407ee
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
fixes-test
branch HEAD: 97e45d469eb180a7bd2809e4e079331552c73e42 powerpc/kexec_file: fix
implicit decl error
elapsed time: 721m
configs tested: 16
configs skipped: 111
The following configs have been built successf
fconfig
um x86_64_defconfig
powerpc allnoconfig
s390defconfig
s390 allmodconfig
i386 randconfig-a011-20230206
x86_64 rhel-8.3-bpf
i386 randconfig-a014-202
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
next-test
branch HEAD: e870dcd0076521fc3f082b248314c376574ac709 powerpc/pci: Add option
for using pci_to_OF_bus_map
elapsed time: 728m
configs tested: 2
configs skipped: 111
The following configs have been built su
There are issues on ppc64 with using patch_instruction() for arbitrary data.
Add dedicated functions for patching data. More details in the first patch.
Just to explain a couple of quirks:
* ppc32 patch_instruction() is noinline to prevent a mis-optimisation where
patch_memory() is inlined into
patch_instruction() is designed for patching instructions in otherwise
readonly memory. Other consumers also sometimes need to patch readonly
memory, so have abused patch_instruction() for arbitrary data patches.
This is a problem on ppc64 as patch_instruction() decides on the patch
width using th
These changes are for patch_instruction() uses on data. Unlike ppc64
these should not be incorrect as-is, but using the patch_uint() alias
better reflects what kind of data being patched and allows for
benchmarking the effect of different patch_* implementations (e.g.,
skipping instruction flushing
This use of patch_instruction() is working on 32 bit data, and can fail
if the data looks like a prefixed instruction and the extra write
crosses a page boundary. Use patch_u32() to fix the write size.
Signed-off-by: Benjamin Gray
---
patch_u64() should be more efficient, but judging from the b
> On 06-Feb-2023, at 8:10 PM, Arnaldo Carvalho de Melo wrote:
>
> Em Mon, Feb 06, 2023 at 09:27:13AM +0530, Athira Rajeev escreveu:
>>> On 02-Feb-2023, at 6:27 AM, Arnaldo Carvalho de Melo
>>> wrote:
>>>
>>> Em Tue, Jan 31, 2023 at 07:20:01PM +0530, Athira Rajeev escreveu:
"bpf" tests
On Tue, 2023-01-31 at 11:38 -0500, Stefan Berger wrote:
>
>
> On 1/31/23 01:39, Andrew Donnellan wrote:
> > Currently, plpks_read_var() allocates a buffer to pass to the
> > H_PKS_READ_OBJECT hcall, then allocates another buffer, of the
> > caller's
>
>
> -> buffer of the (no comma)
I'll just
46 matches
Mail list logo
