https://bugzilla.kernel.org/show_bug.cgi?id=216715
--- Comment #1 from Christophe Leroy (christophe.le...@csgroup.eu) ---
I have no problem booting 6.1-rc5 on QEMU with your config.
What happens if you remove CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT and instead
pass debug_pagealloc=on as parameter t
On IBM Power9, perf watchpoint tests fail since no hardware breakpoints
are available. Detect this by checking the error returned by
perf_event_open() and skip the tests in that case.
Reported-by: Disha Goel
Signed-off-by: Naveen N. Rao
---
tools/perf/tests/wp.c | 12 +++-
1 file change
On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
> On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
> > On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:
> > >
> > > On 11/17/22 16:27, Greg Kroah-Hartman wrote:
> > > > On Mon, Nov 14, 2022 at 06:03:43PM -0500, Nayn
Hello Powerpc folks,
I encounter an kdump bug, which I bisect and pin commit 174db9e7f775
("powerpc/pseries/pci: Add support of MSI domains to PHB hotplug")
In that case, using Fedora 36 as host, the mentioned commit as the
guest kernel, and virto-block disk, the kdump kernel will hang:
[0.0
Sorry that forget a subject.
On Mon, Nov 21, 2022 at 7:54 PM Pingfan Liu wrote:
>
> Hello Powerpc folks,
>
> I encounter an kdump bug, which I bisect and pin commit 174db9e7f775
> ("powerpc/pseries/pci: Add support of MSI domains to PHB hotplug")
>
> In that case, using Fedora 36 as host, the men
built successfully.
More configs may be tested in the coming days.
gcc tested configs:
alpha defconfig
arc defconfig
s390defconfig
x86_64 randconfig-a012-20221121
x86_64
On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
> > On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
> > > On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:
> > > >
> > > > On 11/17/22 16:27, Greg Kroa
On 11/21/22 12:57, Pingfan Liu wrote:
Sorry that forget a subject.
On Mon, Nov 21, 2022 at 7:54 PM Pingfan Liu wrote:
Hello Powerpc folks,
I encounter an kdump bug, which I bisect and pin commit 174db9e7f775
("powerpc/pseries/pci: Add support of MSI domains to PHB hotplug")
In that case, usi
On Mon, Nov 21, 2022 at 09:03:18AM -0500, James Bottomley wrote:
> On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> > On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
> > > On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
> > > > On Sat, Nov 19, 2022 at 01:
On 11/18/22 12:14 PM, Song Liu wrote:
> Hi Petr,
>
> On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
>>
>> On Thu 2022-09-01 10:12:52, Song Liu wrote:
> [...]
>>>
>>> arch/powerpc/kernel/module_32.c | 10
>>> arch/powerpc/kernel/module_64.c | 49 +++
>>> arch/s390/kernel/mo
get_function_0() calls pci_get_domain_bus_and_slot(), as comment
says, it returns a pci device with refcount increment, so after
using it, pci_dev_put() needs be called.
Get the device reference when get_function_0() is not called, so
pci_dev_put() can be called in the error path and callers
uncon
From: James Bottomley
> Sent: 21 November 2022 14:03
...
> > Then how does the networking code handle the namespace stuff in
> > sysfs?
> > That seems to work today, or am I missing something?
>
> have you actually tried?
>
> jejb@lingrow:~> sudo unshare --net bash
> lingrow:/home/jejb # ls /sys/
On Mon, Nov 21, 2022 at 8:32 AM Joe Lawrence wrote:
>
> On 11/18/22 12:14 PM, Song Liu wrote:
> > Hi Petr,
> >
> > On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek wrote:
> >>
> >> On Thu 2022-09-01 10:12:52, Song Liu wrote:
> > [...]
> >>>
> >>> arch/powerpc/kernel/module_32.c | 10
> >>> arch
On Mon, 2022-11-21 at 16:05 +0100, Greg Kroah-Hartman wrote:
> On Mon, Nov 21, 2022 at 09:03:18AM -0500, James Bottomley wrote:
> > On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> > > On Sun, Nov 20, 2022 at 10:14:26PM -0500, James Bottomley wrote:
[...]
> > > > I already explained i
> On 14-Nov-2022, at 2:25 PM, Athira Rajeev wrote:
>
> In perf stat with CSV output option, number of fields
> in metrics output is not matching with number of fields
> in other event output lines.
>
> Sample output below after applying patch to fix
> printing os->prefix.
>
> # ./perf
On Mon, Nov 21, 2022 at 12:33:55PM -0500, James Bottomley wrote:
> On Mon, 2022-11-21 at 16:05 +0100, Greg Kroah-Hartman wrote:
> > On Mon, Nov 21, 2022 at 09:03:18AM -0500, James Bottomley wrote:
> > > On Mon, 2022-11-21 at 12:05 +0100, Greg Kroah-Hartman wrote:
> > > > On Sun, Nov 20, 2022 at 10:
On 11/20/22 22:14, James Bottomley wrote:
On Sun, 2022-11-20 at 17:13 +0100, Greg Kroah-Hartman wrote:
On Sat, Nov 19, 2022 at 01:20:09AM -0500, Nayna wrote:
On 11/17/22 16:27, Greg Kroah-Hartman wrote:
On Mon, Nov 14, 2022 at 06:03:43PM -0500, Nayna wrote:
On 11/10/22 04:58, Greg Kroah-Har
On Fri, 18 Nov 2022, Uwe Kleine-König wrote:
> Hello,
>
> since commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new()
> call-back type") from 2016 there is a "temporary" alternative probe
> callback for i2c drivers.
Oh yeah, this! Thanks for picking this up Uwe, I guess I've been
distract
https://bugzilla.kernel.org/show_bug.cgi?id=216715
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #303245|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=216715
--- Comment #3 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 303255
--> https://bugzilla.kernel.org/attachment.cgi?id=303255&action=edit
kernel dmesg (6.1-rc6, PowerMac G4 DP) - succesful boot
--
You may reply to this email to a
https://bugzilla.kernel.org/show_bug.cgi?id=216715
--- Comment #4 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 303256
--> https://bugzilla.kernel.org/attachment.cgi?id=303256&action=edit
kernel dmesg (6.1-rc6, PowerMac G4 DP) - BUG: KASAN: slab-out-of-bounds
Rarely but sometimes
https://bugzilla.kernel.org/show_bug.cgi?id=216715
--- Comment #5 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 303257
--> https://bugzilla.kernel.org/attachment.cgi?id=303257&action=edit
303256: kernel dmesg (6.1-rc6, PowerMac G4 DP) - BUG: KASAN:
slab-out-of-bounds, 2nd time
He
On Mon, 2022-11-21 at 23:43 +0800, Yang Yingliang wrote:
> get_function_0() calls pci_get_domain_bus_and_slot(), as comment
> says, it returns a pci device with refcount increment, so after
> using it, pci_dev_put() needs be called.
>
> Get the device reference when get_function_0() is not called,
https://bugzilla.kernel.org/show_bug.cgi?id=216723
Bug ID: 216723
Summary: BUG: spinlock wrong CPU on CPU#0, swapper/0/1 with
CONFIG_NETCONSOLE=y (on a PowerMac G4 DP)
Product: Platform Specific/Hardware
Version: 2.5
Kernel Versi
On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote:
> During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to
> offline tick_do_timer_cpu, the operation will fail because in
> function tick_nohz_cpu_down:
> ```
> if (tick_nohz_full_running && tick_do_timer_cpu == cpu)
> return
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> rtas_token() should be used only for properties that are RTAS
> function
> tokens. "rtas-event-scan-rate" does not contain a function token, but
> it
> has the same size/format as token properties so reading it with
> rtas_token() happens to
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> rtas_call() has a complex calling convention, non-standard return
> values, and many users. Add kernel-doc for it and remove the less
> structured commentary from rtas.h.
>
> Signed-off-by: Nathan Lynch
Excellent work!
I'm not overly fami
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> rtas_os_term() is called during panic. Its behavior depends on a
> couple of conditions in the /rtas node of the device tree, the
> traversal of which entails locking and local IRQ state changes. If
> the
> kernel panics while devtree_lock is
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> It's unsafe to use rtas_busy_delay() to handle a busy status from
> the ibm,os-term RTAS function in rtas_os_term():
>
> Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> BUG: sleeping function called from invalid c
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> rtas-error-log-max is not the name of an RTAS function, so
> rtas_token() is not the appropriate API for retrieving its value. We
> already have rtas_get_error_log_max() which returns a sensible value
> if the property is absent for any reaso
Hi Gedric,
Appreciate your insight. Please see the comment inline below.
On Mon, Nov 21, 2022 at 8:57 PM Cédric Le Goater wrote:
>
> On 11/21/22 12:57, Pingfan Liu wrote:
> > Sorry that forget a subject.
> >
> > On Mon, Nov 21, 2022 at 7:54 PM Pingfan Liu wrote:
> >>
> >> Hello Powerpc folks,
>
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> The code in rtas_get_error_log_max() doesn't cause problems in
> practice, but there are no measures to ensure that the lazy
> initialization of the static rtas_error_log_max variable is atomic,
> and it's not worth adding them.
>
> Initiali
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> Set pr_fmt to "rtas: " and convert the handful of printk() uses in
> rtas.c, adjusting the messages to remove now-redundant "RTAS"
> strings.
>
> Note that rtas_restart(), rtas_power_off(), and rtas_halt() all
> currently use printk() withou
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> CONFIG_PPC_RTAS_FILTER has been optional but default-enabled since
> its
> introduction. It's been enabled in enterprise distro kernels for a
> while without causing ABI breakage that wasn't easily fixed, and it
> prevents harmful abuses of t
On Fri, 2022-11-18 at 09:07 -0600, Nathan Lynch wrote:
> rtas.c used to host complex code related to pseries-specific guest
> migration and suspend, which used atomics, completions, hcalls, and
> CPU hotplug APIs. That's all been deleted or moved, so remove the
> include directives that have been r
On Mon, 2022-11-14 at 12:42 +, Christophe Leroy wrote:
> Should this be applied by Bjorn as most recent changes to that file ?
We usually take cxl patches through powerpc, though sometimes Greg
picks them up through char-misc.
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com
This series fixes two issues with the perf_hwbreak test:
- Test fails on systems with large number of cpus due to hitting the
resource limit for maximum number of open file descriptors.
- Test fails on systems running with lower SMT levels since it assumes
all cpus are online.
Fix those issu
Right now, if perf_event_open() fails for the systemwide tests, error
report is printed too late, sometimes after subsequent system calls.
Move use of perror() to the main function, just after the syscall.
Signed-off-by: Naveen N. Rao
---
.../selftests/powerpc/ptrace/perf-hwbreak.c | 21 +-
For systemwide tests, use online cpu mask to only open events on online
cpus. This enables this test to work on systems in lower SMT modes.
Signed-off-by: Naveen N. Rao
---
.../selftests/powerpc/ptrace/perf-hwbreak.c | 45 ---
1 file changed, 39 insertions(+), 6 deletions(-)
d
The systemwide perf hardware breakpoint test tries to open a perf event
on each cpu. On large systems, we run out of file descriptors and fail
the test. Instead, have the test set the file descriptor limit to an
arbitraty high value.
Reported-by: Rohan Deshpande
Signed-off-by: Naveen N. Rao
---
Started this when writing tests for a feature I'm working on, needing a way to
read/write numbers to system files. After writing some utils to safely handle
file IO and parsing, I realised I'd made the ~6th file read/write implementation
and only(?) number parser that checks all the failure modes w
No need to write inline asm for mtspr/mfspr, we have macros for this
in reg.h
---
tools/testing/selftests/powerpc/dscr/dscr.h | 17 +
.../selftests/powerpc/ptrace/ptrace-hwbreak.c | 6 ++
tools/testing/selftests/powerpc/ptrace/ptrace.h | 5 +
.../selftests/powerpc/s
- malloc() does not zero the buffer,
- fread() does not null-terminate it's output,
- `cat /proc/sys/kernel/core_pattern | hexdump -C` shows the file is
not inherently null-terminated
So using string operations on the buffer is risky. Explicitly add a null
character to the end to make it safer.
File read/write is reimplemented in about 5 different ways in the
various PowerPC selftests. This indicates it should be a common util.
Add a common read_file / write_file implementation and convert users
to it where (easily) possible.
---
tools/testing/selftests/powerpc/dscr/dscr.h | 36 ++---
Debugfs files are not always integers, so make *_file return/write a
byte buffer, and *_int deal with int values specifically. This increases
consistency with the other file read/write helpers.
---
.../testing/selftests/powerpc/include/utils.h | 6 ++--
.../selftests/powerpc/security/entry_flush.
Often a file is expected to hold an integral value. Existing functions
will use a C stdlib function like atoi or strtol to parse the file.
These operations are error prone, with complicated error conditions
(atoi returns 0 if not a number, and is undefined behaviour if not in
range. strtol returns
Add helper functions to read and write (unsigned) long values directly
from/to files. One of the kernel interfaces uses hex strings, so we need
to allow passing a base too.
write_long
write_ulong
---
tools/testing/selftests/powerpc/dscr/dscr.h | 9 +--
.../selftests/powerpc/dscr/dscr_sysfs_te
A couple of tests roll their own auto-allocating file read logic.
Add a generic implementation and convert them to use it.
---
.../testing/selftests/powerpc/include/utils.h | 1 +
.../selftests/powerpc/nx-gzip/gzfht_test.c| 37 +
.../selftests/powerpc/syscalls/Makefile | 2 +-
ps3_system_bus_type is only used inside of system-bus.c, so remove
the external declaration and the very outdated comment next to it.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/ps3.h | 4
arch/powerpc/platforms/ps3/system-bus.c | 2 +-
2 files changed, 1 insertio
Christophe Leroy wrote:
test_bpf tail call tests end up as:
test_bpf: #0 Tail call leaf jited:1 85 PASS
test_bpf: #1 Tail call 2 jited:1 111 PASS
test_bpf: #2 Tail call 3 jited:1 145 PASS
test_bpf: #3 Tail call 4 jited:1 170 PASS
test_bpf: #4 Tail call load/store leaf jited:1 190 PASS
Le 22/11/2022 à 08:33, Naveen N. Rao a écrit :
> Christophe Leroy wrote:
>> test_bpf tail call tests end up as:
>>
>> test_bpf: #0 Tail call leaf jited:1 85 PASS
>> test_bpf: #1 Tail call 2 jited:1 111 PASS
>> test_bpf: #2 Tail call 3 jited:1 145 PASS
>> test_bpf: #3 Tail call 4 jited:1 1
51 matches
Mail list logo
