* Re: [PATCH v2 4/6] PCI: Provide wrapper to access a pci_dev's bound driver
From: Andy Shevchenko @ 2021-08-03 14:37 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Mark Rutland, Giovanni Cabiddu, Rafał Miłecki,
Peter Zijlstra, linux-pci, Alexander Duyck, Sathya Prakash,
oss-drivers, Paul Mackerras, H. Peter Anvin, Jiri Olsa,
Boris Ostrovsky, linux-perf-users, Stefano Stabellini, Herbert Xu,
linux-scsi, Ido Schimmel, x86, qat-linux, Alexander Shishkin,
Ingo Molnar, linux-wireless, Jakub Kicinski, Mathias Nyman,
Yisen Zhuang, Fiona Trahe, Andrew Donnellan, Arnd Bergmann,
Konrad Rzeszutek Wilk, Suganath Prabu Subramani, Simon Horman,
Arnaldo Carvalho de Melo, Borislav Petkov, Michael Buesch,
Jiri Pirko, Bjorn Helgaas, Namhyung Kim, Thomas Gleixner,
Juergen Gross, Salil Mehta, Sreekanth Reddy, xen-devel,
Vadym Kochan, MPT-FusionLinux.pdl, Greg Kroah-Hartman, linux-usb,
Wojciech Ziemba, linux-kernel, Taras Chornyi, Zhou Wang,
linux-crypto, kernel, netdev, Frederic Barrat,
Oliver O'Halloran, linuxppc-dev, David S. Miller
In-Reply-To: <20210803100150.1543597-5-u.kleine-koenig@pengutronix.de>
On Tue, Aug 03, 2021 at 12:01:48PM +0200, Uwe Kleine-König wrote:
> Which driver a device is bound to is available twice: In struct
> pci_dev::dev->driver and in struct pci_dev::driver. To get rid of the
> duplication introduce a wrapper to access struct pci_dev's driver
> member. Once all users are converted the wrapper can be changed to
> calculate the driver using pci_dev::dev->driver.
...
> #define to_pci_driver(drv) container_of(drv, struct pci_driver, driver)
> +#define pci_driver_of_dev(pdev) ((pdev)->driver)
Seems like above is (mis)using TAB instead of space after #define. Not sure if
it's good to have them different.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 00/38] Replace deprecated CPU-hotplug
From: Sebastian Andrzej Siewior @ 2021-08-03 14:15 UTC (permalink / raw)
To: linux-kernel
Cc: Juri Lelli, Ben Segall, Paul Mackerras, Pavel Machek,
Srinivas Pandruvada, Vincent Guittot, linux-acpi, Mel Gorman,
Viresh Kumar, Guenter Roeck, Petr Mladek, Jean Delvare, linux-pm,
Arnaldo Carvalho de Melo, Pekka Paalanen, Andy Lutomirski, tglx,
Dietmar Eggemann, Greg Kroah-Hartman, Rafael J. Wysocki,
Karol Herbst, linux-crypto, Tejun Heo, Andrew Morton,
Mark Rutland, Zefan Li, linux-doc, nouveau, Dave Hansen,
virtualization, Song Liu, Ingo Molnar, linux-s390,
Davidlohr Bueso, Daniel Lezcano, Julian Wiedmann, Daniel Jordan,
Gonglei, Len Brown, Vasily Gorbik, Suzuki K Poulose, Mike Travis,
coresight, kvm-ppc, John Stultz, cgroups, linux-arm-kernel,
Tony Luck, Mathieu Poirier, Stephen Boyd, Robin Holt,
Daniel Bristot de Oliveira, Alexander Shishkin, Jason Wang,
Amit Kucheria, Lai Jiangshan, platform-driver-x86, Steve Wahl,
Joel Fernandes, Mark Gross, Jonathan Corbet, Michael S. Tsirkin,
Christian Borntraeger, Arnd Bergmann, Jiri Kosina, Josh Triplett,
Steven Rostedt, rcu, Mathieu Desnoyers, linux-hwmon,
Thomas Bogendoerfer, Stuart Hayes, David S. Miller, Len Brown,
Peter Zijlstra, linux-mm, H. Peter Anvin, live-patching,
Miroslav Benes, Jiri Olsa, Steffen Klassert, Herbert Xu, x86,
Ingo Molnar, Jakub Kicinski, Zhang Rui, Mike Leach,
Paul E. McKenney, Heiko Carstens, Johannes Weiner, linux-raid,
Hans de Goede, Joe Lawrence, Josh Poimboeuf, Namhyung Kim,
linux-edac, netdev, linux-mips, Leo Yan, Borislav Petkov,
linuxppc-dev, Karsten Graul
This is a tree wide replacement of the deprecated CPU hotplug functions
which are only wrappers around the actual functions.
Each patch is independent and can be picked up by the relevant maintainer.
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Amit Kucheria <amitk@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ben Segall <bsegall@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: cgroups@vger.kernel.org
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: coresight@lists.linaro.org
Cc: Daniel Bristot de Oliveira <bristot@redhat.com>
Cc: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Gonglei <arei.gonglei@huawei.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Joel Fernandes <joel@joelfernandes.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Julian Wiedmann <jwi@linux.ibm.com>
Cc: Juri Lelli <juri.lelli@redhat.com>
Cc: Karol Herbst <karolherbst@gmail.com>
Cc: Karsten Graul <kgraul@linux.ibm.com>
Cc: kvm-ppc@vger.kernel.org
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: linux-acpi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-edac@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-pm@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-raid@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: live-patching@vger.kernel.org
Cc: Mark Gross <mgross@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Mike Travis <mike.travis@hpe.com>
Cc: Miroslav Benes <mbenes@suse.cz>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: netdev@vger.kernel.org
Cc: nouveau@lists.freedesktop.org
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Pekka Paalanen <ppaalanen@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: platform-driver-x86@vger.kernel.org
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: rcu@vger.kernel.org
Cc: Robin Holt <robinmholt@gmail.com>
Cc: Song Liu <song@kernel.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Steve Wahl <steve.wahl@hpe.com>
Cc: Stuart Hayes <stuart.w.hayes@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: virtualization@lists.linux-foundation.org
Cc: x86@kernel.org
Cc: Zefan Li <lizefan.x@bytedance.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Sebastian
^ permalink raw reply
* Re: [PATCH v2 5/6] PCI: Adapt all code locations to not use struct pci_dev::driver directly
From: Boris Ostrovsky @ 2021-08-03 13:53 UTC (permalink / raw)
To: Uwe Kleine-König, Bjorn Helgaas
Cc: Mark Rutland, Giovanni Cabiddu, Rafał Miłecki,
Peter Zijlstra, linux-pci, Alexander Duyck, Sathya Prakash,
oss-drivers, Paul Mackerras, H. Peter Anvin, Jiri Olsa,
linux-perf-users, Stefano Stabellini, Herbert Xu, linux-scsi,
Ido Schimmel, x86, qat-linux, Alexander Shishkin, Ingo Molnar,
linux-wireless, Jakub Kicinski, Mathias Nyman, Yisen Zhuang,
Fiona Trahe, Andrew Donnellan, Arnd Bergmann,
Konrad Rzeszutek Wilk, Suganath Prabu Subramani, Simon Horman,
Arnaldo Carvalho de Melo, Borislav Petkov, Michael Buesch,
Jiri Pirko, Namhyung Kim, Thomas Gleixner, Andy Shevchenko,
Juergen Gross, Salil Mehta, Sreekanth Reddy, xen-devel,
Vadym Kochan, MPT-FusionLinux.pdl, Greg Kroah-Hartman, linux-usb,
Wojciech Ziemba, linux-kernel, Taras Chornyi, Zhou Wang,
linux-crypto, kernel, netdev, Frederic Barrat,
Oliver O'Halloran, linuxppc-dev, David S. Miller
In-Reply-To: <20210803100150.1543597-6-u.kleine-koenig@pengutronix.de>
On 8/3/21 6:01 AM, Uwe Kleine-König wrote:
> This prepares removing the driver member of struct pci_dev which holds the
> same information than struct pci_dev::dev->driver.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> arch/powerpc/include/asm/ppc-pci.h | 3 +-
> arch/powerpc/kernel/eeh_driver.c | 12 ++++---
> arch/x86/events/intel/uncore.c | 2 +-
> arch/x86/kernel/probe_roms.c | 2 +-
> drivers/bcma/host_pci.c | 6 ++--
> drivers/crypto/hisilicon/qm.c | 2 +-
> drivers/crypto/qat/qat_common/adf_aer.c | 2 +-
> drivers/message/fusion/mptbase.c | 4 +--
> drivers/misc/cxl/guest.c | 21 +++++------
> drivers/misc/cxl/pci.c | 25 +++++++------
> .../ethernet/hisilicon/hns3/hns3_ethtool.c | 2 +-
> .../ethernet/marvell/prestera/prestera_pci.c | 2 +-
> drivers/net/ethernet/mellanox/mlxsw/pci.c | 2 +-
> .../ethernet/netronome/nfp/nfp_net_ethtool.c | 2 +-
> drivers/pci/iov.c | 23 +++++++-----
> drivers/pci/pci-driver.c | 28 ++++++++-------
> drivers/pci/pci.c | 10 +++---
> drivers/pci/pcie/err.c | 35 ++++++++++---------
> drivers/pci/xen-pcifront.c | 3 +-
> drivers/ssb/pcihost_wrapper.c | 7 ++--
> drivers/usb/host/xhci-pci.c | 3 +-
> 21 files changed, 112 insertions(+), 84 deletions(-)
For Xen bits:
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
^ permalink raw reply
* Re: [PATCH printk v1 00/10] printk: introduce atomic consoles and sync mode
From: Andy Shevchenko @ 2021-08-03 13:52 UTC (permalink / raw)
To: John Ogness
Cc: Gautham R. Shenoy, Gustavo A. R. Silva, Srikar Dronamraju,
Jiri Slaby, Tony Lindgren, Tetsuo Handa, Al Cooper,
Douglas Anderson, Paul Cercueil, Matthias Brugger, Paul Mackerras,
H. Peter Anvin, Cengiz Can, Chengyang Fan, Daniel Thompson,
Sergey Senozhatsky, Bhaskar Chowdhury, Changbin Du,
Masahiro Yamada, x86, linux-mediatek, Peter Zijlstra, Ingo Molnar,
linux-serial, kgdb-bugreport, linux-mips, Wang Qing, Petr Mladek,
Paul E. McKenney, Johan Hovold, Steven Rostedt, Borislav Petkov,
Nicholas Piggin, Hsin-Yi Wang, Sedat Dilek, Claire Chang,
Thomas Gleixner, Eddie Huang, Andrij Abyzov, linux-arm-kernel,
Sumit Garg, kuldip dwivedi, Andrew Jeffery, Greg Kroah-Hartman,
Zhang Qilong, Nick Desaulniers, linux-kernel, Serge Semin,
Sergey Senozhatsky, Guenter Roeck, Jason Wessel,
Christophe JAILLET, Andrew Morton, Maciej W. Rozycki,
linuxppc-dev, Vitor Massaru Iha, Cédric Le Goater
In-Reply-To: <20210803131301.5588-1-john.ogness@linutronix.de>
On Tue, Aug 03, 2021 at 03:18:51PM +0206, John Ogness wrote:
> Hi,
>
> This is the next part of our printk-rework effort (points 3 and
> 4 of the LPC 2019 summary [0]).
>
> Here the concept of "atomic consoles" is introduced through a
> new (optional) write_atomic() callback for console drivers. This
> callback must be implemented as an NMI-safe variant of the
> write() callback, meaning that it can function from any context
> without relying on questionable tactics such as ignoring locking
> and also without relying on the synchronization of console
> semaphore.
>
> As an example of how such an atomic console can look like, this
> series implements write_atomic() for the 8250 UART driver.
>
> This series also introduces a new console printing mode called
> "sync mode" that is only activated when the kernel is about to
> end (such as panic, oops, shutdown, reboot). Sync mode can only
> be activated if atomic consoles are available. A system without
> registered atomic consoles will be unaffected by this series.
>
> When in sync mode, the console printing behavior becomes:
>
> - only consoles implementing write_atomic() will be called
>
> - printing occurs within vprintk_store() instead of
> console_unlock(), since the console semaphore is irrelevant
> for atomic consoles
>
> For systems that have registered atomic consoles, this series
> improves the reliability of seeing crash messages by using new
> locking techniques rather than "ignoring locks and hoping for
> the best". In particular, atomic consoles rely on the
> CPU-reentrant spinlock (i.e. the printk cpulock) for
> synchronizing console output.
If console is runtime suspended, who will bring it up?
Does it mean that this callback can't be implemented on the consoles that
do runtime suspend (some of 8250 currently, for example)?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH printk v1 00/10] printk: introduce atomic consoles and sync mode
From: John Ogness @ 2021-08-03 13:12 UTC (permalink / raw)
To: Petr Mladek
Cc: Gautham R. Shenoy, Gustavo A. R. Silva, Srikar Dronamraju,
Jiri Slaby, Peter Zijlstra, Al Cooper, Douglas Anderson,
Paul Cercueil, Matthias Brugger, Paul Mackerras, H. Peter Anvin,
Cengiz Can, Chengyang Fan, Daniel Thompson, Eddie Huang,
Bhaskar Chowdhury, Changbin Du, Masahiro Yamada, x86,
linux-mediatek, Tetsuo Handa, Ingo Molnar, linux-serial,
kgdb-bugreport, linux-mips, Wang Qing, Sergey Senozhatsky,
Paul E. McKenney, Johan Hovold, Steven Rostedt, Borislav Petkov,
Nicholas Piggin, Hsin-Yi Wang, Sedat Dilek, Claire Chang,
Thomas Gleixner, Andy Shevchenko, Andrij Abyzov, linux-arm-kernel,
Sumit Garg, kuldip dwivedi, Andrew Jeffery, Greg Kroah-Hartman,
Zhang Qilong, Nick Desaulniers, linux-kernel, Serge Semin,
Sergey Senozhatsky, Guenter Roeck, Jason Wessel,
Christophe JAILLET, Andrew Morton, Maciej W. Rozycki,
linuxppc-dev, Vitor Massaru Iha, Cédric Le Goater
Hi,
This is the next part of our printk-rework effort (points 3 and
4 of the LPC 2019 summary [0]).
Here the concept of "atomic consoles" is introduced through a
new (optional) write_atomic() callback for console drivers. This
callback must be implemented as an NMI-safe variant of the
write() callback, meaning that it can function from any context
without relying on questionable tactics such as ignoring locking
and also without relying on the synchronization of console
semaphore.
As an example of how such an atomic console can look like, this
series implements write_atomic() for the 8250 UART driver.
This series also introduces a new console printing mode called
"sync mode" that is only activated when the kernel is about to
end (such as panic, oops, shutdown, reboot). Sync mode can only
be activated if atomic consoles are available. A system without
registered atomic consoles will be unaffected by this series.
When in sync mode, the console printing behavior becomes:
- only consoles implementing write_atomic() will be called
- printing occurs within vprintk_store() instead of
console_unlock(), since the console semaphore is irrelevant
for atomic consoles
For systems that have registered atomic consoles, this series
improves the reliability of seeing crash messages by using new
locking techniques rather than "ignoring locks and hoping for
the best". In particular, atomic consoles rely on the
CPU-reentrant spinlock (i.e. the printk cpulock) for
synchronizing console output.
John Ogness
[0] https://lore.kernel.org/lkml/87k1acz5rx.fsf@linutronix.de/
John Ogness (10):
printk: relocate printk cpulock functions
printk: rename printk cpulock API and always disable interrupts
kgdb: delay roundup if holding printk cpulock
printk: relocate printk_delay()
printk: call boot_delay_msec() in printk_delay()
printk: use seqcount_latch for console_seq
console: add write_atomic interface
printk: introduce kernel sync mode
kdb: if available, only use atomic consoles for output mirroring
serial: 8250: implement write_atomic
arch/powerpc/include/asm/smp.h | 1 +
arch/powerpc/kernel/kgdb.c | 10 +-
arch/powerpc/kernel/smp.c | 5 +
arch/x86/kernel/kgdb.c | 9 +-
drivers/tty/serial/8250/8250.h | 47 ++-
drivers/tty/serial/8250/8250_core.c | 17 +-
drivers/tty/serial/8250/8250_fsl.c | 9 +
drivers/tty/serial/8250/8250_ingenic.c | 7 +
drivers/tty/serial/8250/8250_mtk.c | 29 +-
drivers/tty/serial/8250/8250_port.c | 92 ++--
drivers/tty/serial/8250/Kconfig | 1 +
include/linux/console.h | 32 ++
include/linux/kgdb.h | 3 +
include/linux/printk.h | 57 +--
include/linux/serial_8250.h | 5 +
kernel/debug/debug_core.c | 45 +-
kernel/debug/kdb/kdb_io.c | 16 +
kernel/printk/printk.c | 554 +++++++++++++++++--------
lib/Kconfig.debug | 3 +
lib/dump_stack.c | 4 +-
lib/nmi_backtrace.c | 4 +-
21 files changed, 684 insertions(+), 266 deletions(-)
base-commit: 23d8adcf8022b9483605531d8985f5b77533cb3a
--
2.20.1
^ permalink raw reply
* Re: [PATCH v3 31/41] powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE
From: Finn Thain @ 2021-08-04 4:57 UTC (permalink / raw)
To: Stan Johnson, Christophe Leroy
Cc: Stan Johnson, linux-kernel, Nick Piggin, Paul Mackerras,
linuxppc-dev
In-Reply-To: <683c8156-97b0-5ba7-ce31-2e8613089836@yahoo.com>
On Tue, 3 Aug 2021, Stan Johnson wrote:
> Attached you will find the following six files:
>
> 1) config-5.13-patched_VMAP.txt
> 2) config-5.13-patched_NO_VMAP.txt
> 3) pb3400c-console-5.13-patched_VMAP.txt (using config 1)
> 4) pb3400c-console-5.13-patched_NO_VMAP.txt (using config 2)
> 5) ws-console-5.13-patched_VMAP.txt (using config 1)
> 6) ws-console-5.13-patched_NO_VMAP.txt (using config 2)
>
Thanks!
> The command lines in BootX were as follows:
>
> PB 3400c:
> root=/dev/sda13 console=ttyS0 video=chips65550:vmode:14,cmode:16
>
> Wallstreet:
> root=/dev/sda12 console=ttyS0 video=ofonly
>
> Notes:
>
> For 3), the patch seems to have fixed the "hang-at-boot" at the Mac
> OS screen for the PB 3400c.
I doubt that. I suspect that this is an unrelated failure that only
affects the Powerbook 3400 and only intermittently. I say that because
you've also observed this failure in v5.11.
So we should probably ignore this early-boot failure for the moment. Stan,
if it happens again, please reboot and retry. That may allow us to make
progress on the other bugs.
> After a successful boot, I didn't see any errors until I accessed the
> system via ssh. In an ssh window, I entered "dmesg" (no errors) followed
> by "ls -Rail /usr/bin", and while that was running, the errors appeared.
Since Stan has a yahoo email address that isn't allowed past the spam
filter, I'll paste that portion of the console log he sent --
Kernel attempted to write user page (78a930) - exploit attempt? (uid: 1000)
------------[ cut here ]------------
Bug: Write fault blocked by KUAP!
WARNING: CPU: 0 PID: 1619 at arch/powerpc/mm/fault.c:230 do_page_fault+0x484/0x720
Modules linked in:
CPU: 0 PID: 1619 Comm: sshd Not tainted 5.13.0-pmac-VMAP #10
NIP: c001b780 LR: c001b780 CTR: 00000000
REGS: cb981bc0 TRAP: 0700 Not tainted (5.13.0-pmac-VMAP)
MSR: 00021032 <ME,IR,DR,RI> CR: 24942424 XER: 00000000
GPR00: c001b780 cb981c80 c151c1e0 00000021 3ffffbff 085b0000 00000027 c8eb644c
GPR08: 00000023 00000000 00000000 00000000 24942424 0076f8c8 00000000 000186a0
GPR16: afab5544 afab5540 afab553c afab5538 afab5534 afab5530 00000004 0078a934
GPR24: 00000000 00000000 0078a970 02000000 c1497b60 0078a930 00000300 cb981cc0
NIP [c001b780] do_page_fault+0x484/0x720
LR [c001b780] do_page_fault+0x484/0x720
Call Trace:
[cb981c80] [c001b780] do_page_fault+0x484/0x720 (unreliable)
[cb981cb0] [c000424c] DataAccess_virt+0xd4/0xe4
--- interrupt: 300 at __copy_tofrom_user+0x110/0x20c
NIP: c001f9bc LR: c0172b04 CTR: 00000001
REGS: cb981cc0 TRAP: 0300 Not tainted (5.13.0-pmac-VMAP)
MSR: 00009032 <EE,ME,IR,DR,RI> CR: 442444e8 XER: 20000000
DAR: 0078a930 DSISR: 0a000000
GPR00: 00000000 cb981d80 c151c1e0 0078a930 cb981db8 00000004 0078a92c 00000100
GPR08: 00000122 10c279a1 10000000 c1800034 242444e2 0076f8c8 00000000 000186a0
GPR16: afab5544 afab5540 afab553c afab5538 afab5534 afab5530 00000004 0078a934
GPR24: 00000000 00000000 0078a970 0078a930 cb981dac cb981dac 00000001 00000004
NIP [c001f9bc] __copy_tofrom_user+0x110/0x20c
LR [c0172b04] core_sys_select+0x3e8/0x594
--- interrupt: 300
[cb981d80] [c0172960] core_sys_select+0x244/0x594 (unreliable)
[cb981ee0] [c0172d98] kern_select+0xe8/0x158
[cb981f30] [c001604c] ret_from_syscall+0x0/0x28
--- interrupt: c00 at 0xa7a4f388
NIP: a7a4f388 LR: a7a4f35c CTR: 00000000
REGS: cb981f40 TRAP: 0c00 Not tainted (5.13.0-pmac-VMAP)
MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 240044e2 XER: 20000000
GPR00: 0000008e afab54e0 a73cc7d0 0000000c 0078a930 0078a970 00000000 00000000
GPR08: 00000004 00000000 00000000 a79e45b0 28004462 0076f8c8 00000000 000186a0
GPR16: afab5544 afab5540 afab553c afab5538 afab5534 afab5530 00000004 00770490
GPR24: afab552f 00000004 00000000 0078a930 00000000 00771734 a7b2fff4 00798cb0
NIP [a7a4f388] 0xa7a4f388
LR [a7a4f35c] 0xa7a4f35c
--- interrupt: c00
Instruction dump:
3884aa30 3863012c 4807685d 807f0080 48042e41 2f830000 419e0148 3c80c079
3c60c076 38841b6c 38630174 4801f701 <0fe00000> 3860000b 4bfffe30 3c80c06b
---[ end trace c6ec12d4725e6f89 ]---
> I'll enter the same commands for the other three boots. It may be
> important that I didn't see errors until there was significant network
> access.
>
> For 4), the PB 3400c also booted normally. Errors started after
> logging in via ssh when I entered "dmesg". To be consistent with the
> first test, I followed that with "ls -Rail /usr/bin" and saw more
> errors. A normal reboot ("shutdown -r now") caused even more errors.
>
Here's the relevant portion of that log:
Kernel attempted to write user page (ba3bc0) - exploit attempt? (uid: 1000)
------------[ cut here ]------------
Bug: Write fault blocked by KUAP!
WARNING: CPU: 0 PID: 1609 at arch/powerpc/mm/fault.c:230 do_page_fault+0x484/0x720
Modules linked in:
CPU: 0 PID: 1609 Comm: bash Not tainted 5.13.0-pmac-NO_VMAP #11
NIP: c001b780 LR: c001b780 CTR: 00000000
REGS: c3c5bba0 TRAP: 0700 Not tainted (5.13.0-pmac-NO_VMAP)
MSR: 00021032 <ME,IR,DR,RI> CR: 24442424 XER: 00000000
GPR00: c001b780 c3c5bc60 c3842ca0 00000021 3ffffbff 085ac000 00000027 c8eb2444
GPR08: 00000023 00000000 00000000 00000000 24442424 00b6fff4 00180008 00000000
GPR16: c18ac148 c3c5beb0 c8fc3e00 00000000 c7a70000 00ba4260 00000000 00000000
GPR24: c3c5be90 00001000 c7a70000 02000000 c1f43900 00ba3bc0 00000300 c3c5bca0
NIP [c001b780] do_page_fault+0x484/0x720
LR [c001b780] do_page_fault+0x484/0x720
Call Trace:
[c3c5bc60] [c001b780] do_page_fault+0x484/0x720 (unreliable)
[c3c5bc90] [c000424c] DataAccess_virt+0xd4/0xe4
--- interrupt: 300 at __copy_tofrom_user+0xbc/0x20c
NIP: c001f968 LR: c03258c4 CTR: 00000031
REGS: c3c5bca0 TRAP: 0300 Not tainted (5.13.0-pmac-NO_VMAP)
MSR: 00009032 <EE,ME,IR,DR,RI> CR: 42424288 XER: 20000000
DAR: 00ba3bc0 DSISR: 0a000000
GPR00: 00000004 c3c5bd60 c3842ca0 00000084 c7a7096c 00000000 00ba3bbc 20776974
GPR08: 68207469 6c646520 287e290a 00000004 22422282 00b6fff4 00180008 00000000
GPR16: c18ac148 c3c5beb0 c8fc3e00 00000000 c7a70000 00ba4260 00000000 00000000
GPR24: c3c5be90 00001000 c7a70000 c8fc3e00 00001000 c3c5be98 00008000 00ba3260
NIP [c001f968] __copy_tofrom_user+0xbc/0x20c
LR [c03258c4] copy_page_to_iter+0x2c0/0xab8
--- interrupt: 300
[c3c5bd60] [00000000] 0x0 (unreliable)
[c3c5bdb0] [c00f5bb4] filemap_read+0x424/0xa2c
[c3c5be80] [c0156910] vfs_read+0x274/0x340
[c3c5bf00] [c0156ec4] ksys_read+0x70/0x118
[c3c5bf30] [c001604c] ret_from_syscall+0x0/0x28
--- interrupt: c00 at 0x86bc88
NIP: 0086bc88 LR: 0086bc5c CTR: 00000000
REGS: c3c5bf40 TRAP: 0c00 Not tainted (5.13.0-pmac-NO_VMAP)
MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 20422224 XER: 20000000
GPR00: 00000003 afa710a0 a799a8c0 00000003 00b9b260 00012b22 00badd88 00000000
GPR08: 0000e279 00012b31 00b9b258 00b9b178 00002564 00b6fff4 00b8b4c0 00000000
GPR16: 00000002 00012b22 00aa2ad0 00000000 00b85730 00b85680 00b87900 00b85620
GPR24: 00b856d0 00b9aa80 00000003 00b85520 00b855d0 00b878a0 00959ff4 0000000e
NIP [0086bc88] 0x86bc88
LR [0086bc5c] 0x86bc5c
--- interrupt: c00
Instruction dump:
3884a9e0 386300f0 48076575 807f0080 48042b59 2f830000 419e0148 3c80c079
3c60c076 38841b24 38630138 4801f419 <0fe00000> 3860000b 4bfffe30 3c80c06b
---[ end trace c6966f6cf6736566 ]---
So the PowerBook 3400 and the PowerBook G3 Series "Wallstreet" may have one
failure mode in common (?) The "Wallstreet" (stock v5.13), in the log
sent a few days ago, showed:
Kernel attempted to write user page (c6207c) - exploit attempt? (uid: 0)
BUG: Unable to handle kernel data access on write at 0x00c6207c
Faulting instruction address: 0xa77ad1dc
Oops: Kernel access of bad area, sig: 11 [#1]
...
> For 5), login at the Wallstreet X console failed, with errors. After
> logging in via ssh, entering "dmesg" and "ls -Rail /usr/bin" generated
> more errors.
>
Here's the relevant portion of the log:
------------[ cut here ]------------
kernel BUG at arch/powerpc/kernel/interrupt.c:49!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
Modules linked in:
CPU: 0 PID: 1859 Comm: xfce4-session Not tainted 5.13.0-pmac-VMAP #10
NIP: c0011474 LR: c0011464 CTR: 00000000
REGS: e2f75e40 TRAP: 0700 Not tainted (5.13.0-pmac-VMAP)
MSR: 00021032 <ME,IR,DR,RI> CR: 2400446c XER: 20000000
GPR00: c001604c e2f75f00 ca284a60 00000000 00000000 a5205eb0 00000008 00000020
GPR08: ffffffc0 00000001 501200d9 ce030005 ca285010 00c1f778 00000000 00000000
GPR16: 00945b20 009402f8 00000001 a6b87550 a51fd000 afb73220 a6b22c78 a6a6aecc
GPR24: 00000000 ffffffc0 00000020 00000008 a5205eb0 00000000 e2f75f40 000000ae
NIP [c0011474] system_call_exception+0x60/0x164
LR [c0011464] system_call_exception+0x50/0x164
Call Trace:
[e2f75f00] [00009000] 0x9000 (unreliable)
[e2f75f30] [c001604c] ret_from_syscall+0x0/0x28
--- interrupt: c00 at 0xa69d6cb0
NIP: a69d6cb0 LR: a69d6c3c CTR: 00000000
REGS: e2f75f40 TRAP: 0c00 Not tainted (5.13.0-pmac-VMAP)
MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 2400446c XER: 20000000
GPR00: 000000ae a5205de0 a5687ca0 00000000 00000000 a5205eb0 00000008 00000020
GPR08: ffffffc0 401201ea 401200d9 ffffffff c158f230 00c1f778 00000000 00000000
GPR16: 00945b20 009402f8 00000001 a6b87550 a51fd000 afb73220 a6b22c78 a6a6aecc
GPR24: afb72fc8 00000000 00000001 a5205f30 afb733dc 00000000 a6b85ff4 a5205eb0
NIP [a69d6cb0] 0xa69d6cb0
LR [a69d6c3c] 0xa69d6c3c
--- interrupt: c00
Instruction dump:
7cdb3378 93810020 7cbc2b78 93a10024 7c9d2378 93e1002c 7d3f4b78 4800d629
817e0084 931e0088 69690002 5529fffe <0f090000> 69694000 552997fe 0f090000
---[ end trace c66c6c3c44806276 ]---
> For 6), login at the Wallstreet X console worked, with no errors.
> There were also no errors from entering "dmesg" or "ls -Rail /usr/bin"
> in an ssh window. Everything seems stable.
>
I think that's consistent with results from a previous test with this
machine with v5.13 with CONFIG_VMAP_STACK disabled.
^ permalink raw reply
* Re: [PATCH] powerpc/32s: Fix napping restore in data storage interrupt (DSI)
From: Finn Thain @ 2021-08-04 4:04 UTC (permalink / raw)
To: Christophe Leroy; +Cc: userm57, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <731694e0885271f6ee9ffc179eb4bcee78313682.1628003562.git.christophe.leroy@csgroup.eu>
On Tue, 3 Aug 2021, Christophe Leroy wrote:
> When a DSI (Data Storage Interrupt) is taken while in NAP mode, r11
> doesn't survive the call to power_save_ppc32_restore().
>
> So use r1 instead of r11 as they both contain the virtual stack pointer
> at that point.
>
> Reported-by: Finn Thain <fthain@linux-m68k.org>
> Fixes: 4c0104a83fc3 ("powerpc/32: Dismantle EXC_XFER_STD/LITE/TEMPLATE")
Regarding that 'Fixes' tag, this patch has not fixed the failure below,
unfortunately. But there appears to be several bugs in play here. Can you
tell us which failure mode is associated with the bug addressed by this
patch?
------------[ cut here ]------------
kernel BUG at arch/powerpc/kernel/interrupt.c:49!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
Modules linked in:
CPU: 0 PID: 1859 Comm: xfce4-session Not tainted 5.13.0-pmac-VMAP #10
NIP: c0011474 LR: c0011464 CTR: 00000000
REGS: e2f75e40 TRAP: 0700 Not tainted (5.13.0-pmac-VMAP)
MSR: 00021032 <ME,IR,DR,RI> CR: 2400446c XER: 20000000
GPR00: c001604c e2f75f00 ca284a60 00000000 00000000 a5205eb0 00000008 00000020
GPR08: ffffffc0 00000001 501200d9 ce030005 ca285010 00c1f778 00000000 00000000
GPR16: 00945b20 009402f8 00000001 a6b87550 a51fd000 afb73220 a6b22c78 a6a6aecc
GPR24: 00000000 ffffffc0 00000020 00000008 a5205eb0 00000000 e2f75f40 000000ae
NIP [c0011474] system_call_exception+0x60/0x164
LR [c0011464] system_call_exception+0x50/0x164
Call Trace:
[e2f75f00] [00009000] 0x9000 (unreliable)
[e2f75f30] [c001604c] ret_from_syscall+0x0/0x28
--- interrupt: c00 at 0xa69d6cb0
NIP: a69d6cb0 LR: a69d6c3c CTR: 00000000
REGS: e2f75f40 TRAP: 0c00 Not tainted (5.13.0-pmac-VMAP)
MSR: 0000d032 <EE,PR,ME,IR,DR,RI> CR: 2400446c XER: 20000000
GPR00: 000000ae a5205de0 a5687ca0 00000000 00000000 a5205eb0 00000008 00000020
GPR08: ffffffc0 401201ea 401200d9 ffffffff c158f230 00c1f778 00000000 00000000
GPR16: 00945b20 009402f8 00000001 a6b87550 a51fd000 afb73220 a6b22c78 a6a6aecc
GPR24: afb72fc8 00000000 00000001 a5205f30 afb733dc 00000000 a6b85ff4 a5205eb0
NIP [a69d6cb0] 0xa69d6cb0
LR [a69d6c3c] 0xa69d6c3c
--- interrupt: c00
Instruction dump:
7cdb3378 93810020 7cbc2b78 93a10024 7c9d2378 93e1002c 7d3f4b78 4800d629
817e0084 931e0088 69690002 5529fffe <0f090000> 69694000 552997fe 0f090000
---[ end trace c66c6c3c44806276 ]---
^ permalink raw reply
* [PATCH v3 2/2] virtio-console: remove unnecessary kmemdup()
From: Xianting Tian @ 2021-08-04 2:55 UTC (permalink / raw)
To: gregkh, jirislaby, amit, arnd, osandov
Cc: Xianting Tian, linuxppc-dev, linux-kernel, virtualization
hvc framework will never pass stack memory to the put_chars() function,
So the calling of kmemdup() is unnecessary, remove it.
This revert commit c4baad5029 ("virtio-console: avoid DMA from stack")
Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
---
drivers/char/virtio_console.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 7eaf303a7..4ed3ffb1d 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1117,8 +1117,6 @@ static int put_chars(u32 vtermno, const char *buf, int count)
{
struct port *port;
struct scatterlist sg[1];
- void *data;
- int ret;
if (unlikely(early_put_chars))
return early_put_chars(vtermno, buf, count);
@@ -1127,14 +1125,8 @@ static int put_chars(u32 vtermno, const char *buf, int count)
if (!port)
return -EPIPE;
- data = kmemdup(buf, count, GFP_ATOMIC);
- if (!data)
- return -ENOMEM;
-
- sg_init_one(sg, data, count);
- ret = __send_to_port(port, sg, 1, count, data, false);
- kfree(data);
- return ret;
+ sg_init_one(sg, buf, count);
+ return __send_to_port(port, sg, 1, count, (void *)buf, false);
}
/*
--
2.17.1
^ permalink raw reply related
* [PATCH v3 1/2] tty: hvc: pass DMA capable memory to put_chars()
From: Xianting Tian @ 2021-08-04 2:54 UTC (permalink / raw)
To: gregkh, jirislaby, amit, arnd, osandov
Cc: Xianting Tian, linuxppc-dev, linux-kernel, virtualization
As well known, hvc backend can register its opertions to hvc backend.
the opertions contain put_chars(), get_chars() and so on.
Some hvc backend may do dma in its opertions. eg, put_chars() of
virtio-console. But in the code of hvc framework, it may pass DMA
incapable memory to put_chars() under a specific configuration, which
is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
1, c[] is on stack,
hvc_console_print():
char c[N_OUTBUF] __ALIGNED__;
cons_ops[index]->put_chars(vtermnos[index], c, i);
2, ch is on stack,
static void hvc_poll_put_char(,,char ch)
{
struct tty_struct *tty = driver->ttys[0];
struct hvc_struct *hp = tty->driver_data;
int n;
do {
n = hp->ops->put_chars(hp->vtermno, &ch, 1);
} while (n <= 0);
}
Commit c4baad5029 is just the fix to avoid DMA from stack memory, which
is passed to virtio-console by hvc framework in above code. But I think
the fix is aggressive, it directly uses kmemdup() to alloc new buffer
from kmalloc area and do memcpy no matter the memory is in kmalloc area
or not. But most importantly, it should better be fixed in the hvc
framework, by changing it to never pass stack memory to the put_chars()
function in the first place. Otherwise, we still face the same issue if
a new hvc backend using dma added in the furture.
Considering lock competition of hp->outbuf, we created a new buffer
hp->hvc_con_outbuf, which is aligned at least to N_OUTBUF, and use it
in above two cases.
With the patch, we can remove the fix c4baad5029.
Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
Tested-by: Xianting Tian <xianting.tian@linux.alibaba.com>
---
drivers/tty/hvc/hvc_console.c | 30 ++++++++++++++++++++++++++++--
drivers/tty/hvc/hvc_console.h | 2 ++
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 5bb8c4e44..e5862989c 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -151,9 +151,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;
unsigned i = 0, n = 0;
int r, donecr = 0, index = co->index;
+ unsigned long flags;
+ struct hvc_struct *hp;
/* Console access attempt outside of acceptable console range. */
if (index >= MAX_NR_HVC_CONSOLES)
@@ -163,6 +165,13 @@ static void hvc_console_print(struct console *co, const char *b,
if (vtermnos[index] == -1)
return;
+ list_for_each_entry(hp, &hvc_structs, next)
+ if (hp->vtermno == vtermnos[index])
+ break;
+
+ c = hp->hvc_con_outbuf;
+
+ spin_lock_irqsave(&hp->hvc_con_lock, flags);
while (count > 0 || i > 0) {
if (count > 0 && i < sizeof(c)) {
if (b[n] == '\n' && !donecr) {
@@ -191,6 +200,7 @@ static void hvc_console_print(struct console *co, const char *b,
}
}
}
+ spin_unlock_irqrestore(&hp->hvc_con_lock, flags);
hvc_console_flush(cons_ops[index], vtermnos[index]);
}
@@ -878,9 +888,15 @@ static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch)
struct tty_struct *tty = driver->ttys[0];
struct hvc_struct *hp = tty->driver_data;
int n;
+ unsigned long flags;
+ char *c;
+ c = hp->hvc_con_outbuf;
do {
- n = hp->ops->put_chars(hp->vtermno, &ch, 1);
+ spin_lock_irqsave(&hp->hvc_con_lock, flags);
+ c[0] = ch;
+ n = hp->ops->put_chars(hp->vtermno, c, 1);
+ spin_unlock_irqrestore(&hp->hvc_con_lock, flags);
} while (n <= 0);
}
#endif
@@ -933,6 +949,16 @@ struct hvc_struct *hvc_alloc(uint32_t vtermno, int data,
hp->outbuf_size = outbuf_size;
hp->outbuf = &((char *)hp)[ALIGN(sizeof(*hp), sizeof(long))];
+ /*
+ * hvc_con_outbuf is guaranteed to be aligned at least to the
+ * size(N_OUTBUF) by kmalloc().
+ */
+ hp->hvc_con_outbuf = kzalloc(N_OUTBUF, GFP_KERNEL);
+ if (!hp->hvc_con_outbuf)
+ return ERR_PTR(-ENOMEM);
+
+ spin_lock_init(&hp->hvc_con_lock);
+
tty_port_init(&hp->port);
hp->port.ops = &hvc_port_ops;
diff --git a/drivers/tty/hvc/hvc_console.h b/drivers/tty/hvc/hvc_console.h
index 18d005814..8972c52de 100644
--- a/drivers/tty/hvc/hvc_console.h
+++ b/drivers/tty/hvc/hvc_console.h
@@ -48,6 +48,8 @@ struct hvc_struct {
struct work_struct tty_resize;
struct list_head next;
unsigned long flags;
+ char *hvc_con_outbuf;
+ spinlock_t hvc_con_lock;
};
/* implemented by a low level driver */
--
2.17.1
^ permalink raw reply related
* [powerpc:next] BUILD SUCCESS a6cae77f1bc89368a4e2822afcddc45c3062d499
From: kernel test robot @ 2021-08-04 1:36 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
branch HEAD: a6cae77f1bc89368a4e2822afcddc45c3062d499 powerpc/stacktrace: Include linux/delay.h
elapsed time: 725m
configs tested: 154
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20210803
mips ip28_defconfig
arm cerfcube_defconfig
arm neponset_defconfig
arc nsimosci_defconfig
arm hackkit_defconfig
powerpc obs600_defconfig
m68k atari_defconfig
mips rs90_defconfig
mips jmr3927_defconfig
mips ip32_defconfig
powerpc xes_mpc85xx_defconfig
arm s3c6400_defconfig
arm xcep_defconfig
arm vf610m4_defconfig
ia64 alldefconfig
powerpc tqm8541_defconfig
nios2 3c120_defconfig
arm pleb_defconfig
powerpc pseries_defconfig
arm trizeps4_defconfig
arm imote2_defconfig
arm dove_defconfig
h8300 alldefconfig
sh se7619_defconfig
powerpc bluestone_defconfig
mips rm200_defconfig
powerpc ppc64e_defconfig
powerpc ppc6xx_defconfig
sh sh7710voipgw_defconfig
powerpc allnoconfig
x86_64 alldefconfig
powerpc mpc512x_defconfig
openrisc simple_smp_defconfig
powerpc ppa8548_defconfig
s390 alldefconfig
sh se7343_defconfig
h8300 h8300h-sim_defconfig
ia64 gensparse_defconfig
sh apsh4ad0a_defconfig
mips rb532_defconfig
arc axs103_defconfig
sh se7722_defconfig
arm socfpga_defconfig
mips db1xxx_defconfig
powerpc lite5200b_defconfig
arm omap1_defconfig
sparc sparc32_defconfig
powerpc mpc8540_ads_defconfig
powerpc ebony_defconfig
powerpc bamboo_defconfig
powerpc kilauea_defconfig
mips bcm63xx_defconfig
powerpc mpc8315_rdb_defconfig
xtensa generic_kc705_defconfig
mips ip27_defconfig
powerpc64 defconfig
arm sama5_defconfig
sh sdk7786_defconfig
arc vdk_hs38_smp_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
x86_64 allnoconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a002-20210803
x86_64 randconfig-a004-20210803
x86_64 randconfig-a006-20210803
x86_64 randconfig-a003-20210803
x86_64 randconfig-a001-20210803
x86_64 randconfig-a005-20210803
i386 randconfig-a004-20210803
i386 randconfig-a005-20210803
i386 randconfig-a002-20210803
i386 randconfig-a006-20210803
i386 randconfig-a001-20210803
i386 randconfig-a003-20210803
i386 randconfig-a004-20210802
i386 randconfig-a005-20210802
i386 randconfig-a002-20210802
i386 randconfig-a006-20210802
i386 randconfig-a001-20210802
i386 randconfig-a003-20210802
i386 randconfig-a005-20210804
i386 randconfig-a004-20210804
i386 randconfig-a002-20210804
i386 randconfig-a006-20210804
i386 randconfig-a003-20210804
i386 randconfig-a001-20210804
i386 randconfig-a012-20210803
i386 randconfig-a011-20210803
i386 randconfig-a015-20210803
i386 randconfig-a013-20210803
i386 randconfig-a014-20210803
i386 randconfig-a016-20210803
i386 randconfig-a012-20210802
i386 randconfig-a011-20210802
i386 randconfig-a015-20210802
i386 randconfig-a013-20210802
i386 randconfig-a014-20210802
i386 randconfig-a016-20210802
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel-8.3-kselftests
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-c001-20210803
x86_64 randconfig-a012-20210803
x86_64 randconfig-a016-20210803
x86_64 randconfig-a013-20210803
x86_64 randconfig-a011-20210803
x86_64 randconfig-a014-20210803
x86_64 randconfig-a015-20210803
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH] powerpc: Always inline radix_enabled() to fix build failure
From: Jordan Niethe @ 2021-08-04 1:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jordan Niethe, erhard_f
This is the same as commit acdad8fb4a15 ("powerpc: Force inlining of
mmu_has_feature to fix build failure") but for radix_enabled(). The
config in the linked bugzilla causes the following build failure:
LD .tmp_vmlinux.kallsyms1
powerpc64-linux-ld: arch/powerpc/mm/pgtable.o: in function `.__ptep_set_access_flags':
pgtable.c:(.text+0x17c): undefined reference to `.radix__ptep_set_access_flags'
powerpc64-linux-ld: arch/powerpc/mm/pageattr.o: in function `.change_page_attr':
pageattr.c:(.text+0xc0): undefined reference to `.radix__flush_tlb_kernel_range'
powerpc64-linux-ld: arch/powerpc/mm/pageattr.o: in function `.set_page_attr':
pageattr.c:(.text+0x228): undefined reference to `.radix__flush_tlb_kernel_range'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/mmu_context.o:(.toc+0x0): undefined reference to `mmu_pid_bits'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/mmu_context.o:(.toc+0x8): undefined reference to `mmu_base_pid'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/pgtable.o: in function `.pmd_hugepage_update':
pgtable.c:(.text+0x98): undefined reference to `.radix__pmd_hugepage_update'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/pgtable.o: in function `.do_serialize':
pgtable.c:(.text+0xdc): undefined reference to `.exit_lazy_flush_tlb'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/pgtable.o: in function `.pmdp_set_access_flags':
pgtable.c:(.text+0x258): undefined reference to `.radix__ptep_set_access_flags'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/pgtable.o: in function `.pmdp_invalidate':
pgtable.c:(.text+0x4a8): undefined reference to `.radix__flush_pmd_tlb_range'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/pgtable.o: in function `.pmdp_huge_get_and_clear_full':
pgtable.c:(.text+0x510): undefined reference to `.radix__pmdp_huge_get_and_clear'
powerpc64-linux-ld: pgtable.c:(.text+0x550): undefined reference to `.radix__flush_pmd_tlb_range'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/pgtable.o: in function `.mmu_cleanup_all':
pgtable.c:(.text+0x674): undefined reference to `.radix__mmu_cleanup_all'
powerpc64-linux-ld: arch/powerpc/mm/book3s64/pgtable.o: in function `.ptep_modify_prot_commit':
pgtable.c:(.text+0xdf8): undefined reference to `.radix__ptep_modify_prot_commit'
powerpc64-linux-ld: arch/powerpc/lib/code-patching.o: in function `.patch_instruction':
code-patching.c:(.text+0x318): undefined reference to `.radix__map_kernel_page'
powerpc64-linux-ld: code-patching.c:(.text+0x498): undefined reference to `.radix__flush_tlb_kernel_range'
powerpc64-linux-ld: kernel/fork.o: in function `.dup_mm':
fork.c:(.text+0x2138): undefined reference to `.radix__flush_tlb_mm'
powerpc64-linux-ld: mm/memory.o: in function `.unmap_page_range':
memory.c:(.text+0x305c): undefined reference to `.radix__tlb_flush'
powerpc64-linux-ld: mm/memory.o: in function `.do_wp_page':
memory.c:(.text+0x36cc): undefined reference to `.radix__flush_tlb_page'
powerpc64-linux-ld: mm/memory.o: in function `.do_set_pmd':
memory.c:(.text+0x42f8): undefined reference to `.radix__pgtable_trans_huge_deposit'
powerpc64-linux-ld: mm/memory.o: in function `.__handle_mm_fault':
memory.c:(.text+0x6af8): undefined reference to `.radix__flush_tlb_page'
powerpc64-linux-ld: mm/mprotect.o: in function `.change_protection':
mprotect.c:(.text+0x274): undefined reference to `.radix__flush_tlb_range'
powerpc64-linux-ld: mm/mremap.o: in function `.flush_tlb_range':
mremap.c:(.text+0x500): undefined reference to `.radix__flush_tlb_range'
powerpc64-linux-ld: mm/pgtable-generic.o: in function `.ptep_clear_flush':
pgtable-generic.c:(.text+0xb0): undefined reference to `.radix__flush_tlb_page'
powerpc64-linux-ld: mm/pgtable-generic.o: in function `.pmdp_huge_clear_flush':
pgtable-generic.c:(.text+0x160): undefined reference to `.radix__pmdp_huge_get_and_clear'
powerpc64-linux-ld: pgtable-generic.c:(.text+0x198): undefined reference to `.radix__flush_pmd_tlb_range'
powerpc64-linux-ld: mm/rmap.o: in function `.try_to_unmap_one':
rmap.c:(.text+0x1d60): undefined reference to `.radix__flush_tlb_range'
powerpc64-linux-ld: mm/rmap.o: in function `.try_to_migrate_one':
rmap.c:(.text+0x222c): undefined reference to `.radix__flush_tlb_range'
powerpc64-linux-ld: mm/vmalloc.o: in function `.flush_tlb_kernel_range':
vmalloc.c:(.text+0x5a8): undefined reference to `.radix__flush_tlb_kernel_range'
powerpc64-linux-ld: mm/hugetlb.o: in function `.hugetlb_cow':
hugetlb.c:(.text+0x53b0): undefined reference to `.radix__flush_hugetlb_page'
powerpc64-linux-ld: mm/hugetlb.o: in function `.hugetlb_change_protection':
hugetlb.c:(.text+0x6558): undefined reference to `.radix__flush_hugetlb_tlb_range'
powerpc64-linux-ld: mm/hugetlb.o: in function `.hugetlb_unshare_all_pmds':
hugetlb.c:(.text+0x70f0): undefined reference to `.radix__flush_hugetlb_tlb_range'
powerpc64-linux-ld: mm/huge_memory.o: in function `.pgtable_trans_huge_deposit':
huge_memory.c:(.text+0x6b0): undefined reference to `.radix__pgtable_trans_huge_deposit'
powerpc64-linux-ld: mm/huge_memory.o: in function `.pgtable_trans_huge_withdraw':
huge_memory.c:(.text+0x6f8): undefined reference to `.radix__pgtable_trans_huge_withdraw'
powerpc64-linux-ld: mm/huge_memory.o: in function `.pmd_hugepage_update.isra.0':
huge_memory.c:(.text+0xa28): undefined reference to `.radix__pmd_hugepage_update'
powerpc64-linux-ld: mm/huge_memory.o: in function `.do_huge_pmd_numa_page':
huge_memory.c:(.text+0x2184): undefined reference to `.radix__flush_tlb_range'
powerpc64-linux-ld: mm/huge_memory.o: in function `.move_huge_pmd':
huge_memory.c:(.text+0x270c): undefined reference to `.radix__pmdp_huge_get_and_clear'
powerpc64-linux-ld: huge_memory.c:(.text+0x27a8): undefined reference to `.radix__flush_tlb_range'
powerpc64-linux-ld: mm/khugepaged.o: in function `.pmdp_collapse_flush':
khugepaged.c:(.text+0x19c8): undefined reference to `.radix__pmdp_collapse_flush'
powerpc64-linux-ld: mm/khugepaged.o: in function `.khugepaged':
khugepaged.c:(.text+0x4eec): undefined reference to `.radix__pgtable_trans_huge_deposit'
powerpc64-linux-ld: fs/proc/task_mmu.o: in function `.clear_refs_write':
task_mmu.c:(.text+0x2340): undefined reference to `.radix__flush_tlb_mm'
This is due to radix_enabled() not being inlined. See extract from building with -Winline:
In file included from arch/powerpc/include/asm/lppaca.h:46,
from arch/powerpc/include/asm/paca.h:17,
from arch/powerpc/include/asm/current.h:13,
from include/linux/thread_info.h:23,
from include/asm-generic/preempt.h:5,
from ./arch/powerpc/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:6,
from arch/powerpc/mm/pgtable.c:21:
arch/powerpc/include/asm/book3s/64/pgtable.h: In function '__ptep_set_access_flags':
arch/powerpc/include/asm/mmu.h:327:20: error: inlining failed in call to 'radix_enabled': call is unlikely and code size would grow [-Werror=inline]
The code relies on constant folding of MMU_FTRS_POSSIBLE at buildtime
and elimination of non possible parts of code at compile time. For this
to work radix_enabled() must be inlined so make it __always_inline.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=213803
Reported-by: Erhard F. <erhard_f@mailbox.org>
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Jordan Niethe <jniethe5@gmail.com>
---
arch/powerpc/include/asm/mmu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 27016b98ecb2..8abe8e42e045 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -324,7 +324,7 @@ static inline void assert_pte_locked(struct mm_struct *mm, unsigned long addr)
}
#endif /* !CONFIG_DEBUG_VM */
-static inline bool radix_enabled(void)
+static __always_inline bool radix_enabled(void)
{
return mmu_has_feature(MMU_FTR_TYPE_RADIX);
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] cpuidle: pseries: Mark pseries_idle_proble() as __init
From: Michael Ellerman @ 2021-08-04 0:54 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Gautham R. Shenoy, linux-pm, Nick Desaulniers, linux-kernel,
Nathan Chancellor, clang-built-linux, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20210803211547.1093820-1-nathan@kernel.org>
Nathan Chancellor <nathan@kernel.org> writes:
> After commit 7cbd631d4dec ("cpuidle: pseries: Fixup CEDE0 latency only
> for POWER10 onwards"), pseries_idle_probe() is no longer inlined when
> compiling with clang, which causes a modpost warning:
>
> WARNING: modpost: vmlinux.o(.text+0xc86a54): Section mismatch in
> reference from the function pseries_idle_probe() to the function
> .init.text:fixup_cede0_latency()
> The function pseries_idle_probe() references
> the function __init fixup_cede0_latency().
> This is often because pseries_idle_probe lacks a __init
> annotation or the annotation of fixup_cede0_latency is wrong.
>
> pseries_idle_probe() is a non-init function, which calls
> fixup_cede0_latency(), which is an init function, explaining the
> mismatch. pseries_idle_probe() is only called from
> pseries_processor_idle_init(), which is an init function, so mark
> pseries_idle_probe() as __init so there is no more warning.
>
> Fixes: 054e44ba99ae ("cpuidle: pseries: Add function to parse extended CEDE records")
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> drivers/cpuidle/cpuidle-pseries.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I don't see this in my builds for some reason, but I guess toolchain or
config differences probably explain it.
Regardless, the patch is correct so I'll pick it up, thanks.
cheers
> diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
> index bba449b77641..7e7ab5597d7a 100644
> --- a/drivers/cpuidle/cpuidle-pseries.c
> +++ b/drivers/cpuidle/cpuidle-pseries.c
> @@ -403,7 +403,7 @@ static void __init fixup_cede0_latency(void)
> * pseries_idle_probe()
> * Choose state table for shared versus dedicated partition
> */
> -static int pseries_idle_probe(void)
> +static int __init pseries_idle_probe(void)
> {
>
> if (cpuidle_disable != IDLE_NO_OVERRIDE)
>
> base-commit: a6cae77f1bc89368a4e2822afcddc45c3062d499
> --
> 2.33.0.rc0
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Finn Thain @ 2021-08-04 0:34 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Debian PowerPC, linuxppc-dev, Stan Johnson
In-Reply-To: <fac98e72-14a1-802e-8343-9bed9a6eaedc@csgroup.eu>
On Tue, 3 Aug 2021, Christophe Leroy wrote:
>
> Looks like the memory errors are linked to KUAP (Kernel Userspace Access
> Protection). Based on the places the problems happen, I don't think
> there are any invalid access, so there must be something wrong in the
> KUAP logic, probably linked to some interrupts happenning in kernel mode
> while the KUAP window is opened. And because is not selected by default
> on book3s/32 until 5.14, probably nobody ever tested it in a real
> environment before you.
>
> I think the issue may be linked to commit
> https://github.com/linuxppc/linux/commit/c16728835 which happened
> between 5.12 and 5.13.
The messages, "Kernel attempted to write user page (c6207c) - exploit
attempt? (uid: 0)", appear in the console logs generated by v5.13. Those
logs come from the Powerbook G3 discussion in the other thread. Could that
be the same bug?
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Finn Thain @ 2021-08-04 0:02 UTC (permalink / raw)
To: Stan Johnson; +Cc: Debian PowerPC, linuxppc-dev
In-Reply-To: <757cf732-d572-26c5-9a3f-6b63e3d2d0bd@yahoo.com>
On Tue, 3 Aug 2021, Stan Johnson wrote:
>
> I'm not sure of the issue you are referencing. If it's the Wallstreet
> issue, I believe we were waiting to hear back from you regarding the
> memory errors that crop up with CONFIG_VMAP_STACK=y and mem >464M.
> Finn, if that is not correct, please let me know.
>
No, it's not correct. I sent a message dated 3 Aug 2021 with a patch from
Christophe. I also sent (privately) a message with instructions for
testing that patch. I will resend these now.
^ permalink raw reply
* Re: Debian SID kernel doesn't boot on PowerBook 3400c
From: Stan Johnson @ 2021-08-03 22:20 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Debian PowerPC, linuxppc-dev, Finn Thain
In-Reply-To: <fac98e72-14a1-802e-8343-9bed9a6eaedc@csgroup.eu>
[-- Attachment #1: Type: text/plain, Size: 6284 bytes --]
On 8/3/21 4:08 AM, Christophe Leroy wrote:
>
>
> Le 02/08/2021 à 19:32, Stan Johnson a écrit :
>> On 8/2/21 8:41 AM, Christophe Leroy wrote:
>>>
>>> ...
>>>>>
>>>>> Can you try again without CONFIG_VMAP_STACK ?
>>>>>
>>>>> Thanks
>>>>> Christophe
>>>>> ...
>>>>
>>>>
>>>> With CONFIG_VMAP_STACK=y, 5.11.0-rc5-pmac-00034-g684da7628d9 hangs at
>>>> boot on the PB 3400c.
>>>>
>>>> Without CONFIG_VMAP_STACK, 5.11.0-rc5-pmac-00034-g684da7628d9 boots as
>>>> expected.
>>>>
>>>> I didn't re-build the Debian SID kernel, though I confirmed that the
>>>> Debian config file for 5.10.0-8-powerpc includes CONFIG_VMAP_STACK=y.
>>>> It's not clear whether removing CONFIG_VMAP_STACK would be appropriate
>>>> for other powerpc systems.
>>>>
>>>> Please let me know why removing CONFIG_VMAP_STACK fixed the problem on
>>>> the PB 3400c. Should CONFIG_HAVE_ARCH_VMAP_STACK also be removed?
>>>>
>>>
>>> When CONFIG_HAVE_ARCH_VMAP_STACK is selected by the architecture,
>>> CONFIG_VMAP_STACK is selected by default.
>>>
>>> The point is that your config has CONFIG_ADB_PMU.
>>>
>>> A bug with VMAP stack was detected during 5.9 release cycle for
>>> platforms selecting CONFIG_ADB_PMU. Because fixing the bug was an heavy
>>> change, we prefered at that time to disable VMAP stack, so VMAP stack
>>> was deselected for CONFIG_ADB_PMU by commit
>>> 4a133eb351ccc275683ad49305d0b04dde903733.
>>>
>>> Then as a second step, the proper fix was implemented and then VMAP
>>> stack was enabled again by the commit you bisected.
>>>
>>> Taking into account that the problem disappears for you when you
>>> manually deselect VMAP stacks, it means the problem is not the fix
>>> itself, but the fact that VMAP stacks are now enable by default.
>>>
>>> We need to understand why VMAP stack doesn't work on your platform, more
>>> than that why it doesn't boot at all with VMAP stack.
>>>
>>> Could you send me the dmesg output of your system when it properly
>>> boots ?
>>>
>>> Did you check with kernel 5.13 ?
>>>
>>> Thanks
>>> Christophe
>>>
>>
>> Christophe,
>>
>> Thanks for your response. It looks like I never tested v5.13 (I was
>> originally just reporting that the default Debian SID kernel,
>> 5.10.0-8-powerpc, hangs at boot on the PB 3400c).
>>
>> So I rebuilt the stock v5.13 from kernel.org using Finn's
>> dot-config-powermac-5.13, which got changed slightly at compilation (see
>> dot-config-v5.13-pmac, attached). It has CONFIG_VMAP_STACK and
>> CONFIG_ADB_PMU set, and it booted, but there were multiple memory
>> errors. So it looks like the hang-at-boot problem was fixed sometime
>> after v5.11, but there are now memory errors (similar to Wallstreet).
>>
>> With CONFIG_VMAP_STACK not set (CONFIG_ADB_PMU is still set), the
>> .config file turns into the attached dot-config-v5.13-pmac_NO_VMAP. And
>> there were still memory errors (dmesg output attached).
>>
>> The memory errors may be a completely unrelated issue, since they occur
>> regardless of the CONFIG_VMAP_STACK setting.
>>
>> To help rule out a hardware issue, I confirmed that memory errors don't
>> occur with v5.8.2 (dmesg output attached).
>>
>> A useful git bisect might be possible if CONFIG_VMAP_STACK is disabled
>> for each build. I would need to determine where the memory errors
>> started (v5.9, v5.10, v5.11, or v5.12). There is the complication that
>> (at least) several v5.10 kernels won't compile if SMP is set, so I might
>> need to disable that everywhere as well, assuming the SMP fix didn't
>> cause the memory errors.
>>
>
> Thanks a lot for the information.
>
> Looks like the memory errors are linked to KUAP (Kernel Userspace Access
> Protection). Based on the places the problems happen, I don't think
> there are any invalid access, so there must be something wrong in the
> KUAP logic, probably linked to some interrupts happenning in kernel mode
> while the KUAP window is opened. And because is not selected by default
> on book3s/32 until 5.14, probably nobody ever tested it in a real
> environment before you.
>
> I think the issue may be linked to commit
> https://github.com/linuxppc/linux/commit/c16728835 which happened
> between 5.12 and 5.13. Would be nice if you could confirm that 5.12
> doesn't have the problem (At the same time maybe you can see if 5.12
> also boots OK with CONFIG_VMAP_STACK)
On the PB 3400c:
1) v5.12 with CONFIG_VMAP_STACK -- hangs at boot; see attached config.
2) v5.12 without CONFIG_VMAP_STACK -- did not hang at boot, but hung at
"Run /sbin/init as init process" (I tested it twice; there were no
errors logged); see attached config and serial console log.
3) v5.11 with CONFIG_VMAP_STACK -- hangs at boot, no output at serial
console (see attached config).
4) v5.11 without CONFIG_VMAP_STACK -- no errors (confirms earlier
result); see attached config and dmesg output.
The PB 3400C has a 240 MHz 603e and 144M memory. It's a text-only system
running Debian SID with sysvinit (X Windows and systemd would run too
slowly here).
Please note that the issue on the PB 3400c appears to be different than
the memory problem on the Wallstreet (I think Finn sent you some
Wallstreet dmesg outputs for the Wallstreet problem).
On the Wallstreet, with CONFIG_VMAP_STACK, X logins start to fail and
memory errors start happening somewhere around mem=464M (I've never seen
problems at <= 464M, but it's possible the memory errors are just more
likely to start happening somewhere >384M). With CONFIG_VMAP_STACK off,
X logins work on the Wallstreet and there are no memory errors with any
memory size <= 512M.
On the PB 3400c, there was the hang-at-boot problem that went away in
v5.11 with CONFIG_VMAP_STACK off. However, it appears a new issue may
have happened between v5.11 and v5.12 that causes v5.12 to hang at "Run
/sbin/init as init process" when CONFIG_VMAP_STACK is off (further
complicating any possible bisect).
>
> Note that the error detected in the other thread which is being
> discussed with Finn might also be an issue to be checked while we are here.
>
I'm not sure of the issue you are referencing. If it's the Wallstreet
issue, I believe we were waiting to hear back from you regarding the
memory errors that crop up with CONFIG_VMAP_STACK=y and mem >464M. Finn,
if that is not correct, please let me know.
thanks
-Stan
[-- Attachment #2: config-v5.12-pmac_VMAP.xz --]
[-- Type: application/octet-stream, Size: 17824 bytes --]
[-- Attachment #3: config-v5.12-pmac_NO_VMAP.xz --]
[-- Type: application/octet-stream, Size: 17832 bytes --]
[-- Attachment #4: serial_log_v5.12-NO_VMAP.txt.xz --]
[-- Type: application/octet-stream, Size: 4328 bytes --]
[-- Attachment #5: config-v5.11-pmac_VMAP.xz --]
[-- Type: application/octet-stream, Size: 17804 bytes --]
[-- Attachment #6: config-v5.11-pmac_NO_VMAP.xz --]
[-- Type: application/octet-stream, Size: 17828 bytes --]
[-- Attachment #7: dmesg-5.11.0-pmac-NO_VMAP.txt.xz --]
[-- Type: application/octet-stream, Size: 5736 bytes --]
^ permalink raw reply
* [PATCH] cpuidle: pseries: Mark pseries_idle_proble() as __init
From: Nathan Chancellor @ 2021-08-03 21:15 UTC (permalink / raw)
To: Michael Ellerman
Cc: Gautham R. Shenoy, linux-pm, Nick Desaulniers, linux-kernel,
Nathan Chancellor, clang-built-linux, Paul Mackerras,
linuxppc-dev
After commit 7cbd631d4dec ("cpuidle: pseries: Fixup CEDE0 latency only
for POWER10 onwards"), pseries_idle_probe() is no longer inlined when
compiling with clang, which causes a modpost warning:
WARNING: modpost: vmlinux.o(.text+0xc86a54): Section mismatch in
reference from the function pseries_idle_probe() to the function
.init.text:fixup_cede0_latency()
The function pseries_idle_probe() references
the function __init fixup_cede0_latency().
This is often because pseries_idle_probe lacks a __init
annotation or the annotation of fixup_cede0_latency is wrong.
pseries_idle_probe() is a non-init function, which calls
fixup_cede0_latency(), which is an init function, explaining the
mismatch. pseries_idle_probe() is only called from
pseries_processor_idle_init(), which is an init function, so mark
pseries_idle_probe() as __init so there is no more warning.
Fixes: 054e44ba99ae ("cpuidle: pseries: Add function to parse extended CEDE records")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
drivers/cpuidle/cpuidle-pseries.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
index bba449b77641..7e7ab5597d7a 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -403,7 +403,7 @@ static void __init fixup_cede0_latency(void)
* pseries_idle_probe()
* Choose state table for shared versus dedicated partition
*/
-static int pseries_idle_probe(void)
+static int __init pseries_idle_probe(void)
{
if (cpuidle_disable != IDLE_NO_OVERRIDE)
base-commit: a6cae77f1bc89368a4e2822afcddc45c3062d499
--
2.33.0.rc0
^ permalink raw reply related
* Re: [PATCH v4] soc: fsl: qe: convert QE interrupt controller to platform_device
From: Saravana Kannan @ 2021-08-03 17:51 UTC (permalink / raw)
To: Maxim Kochetkov
Cc: kernel test robot, gregkh, linux-kernel, leoyang.li,
Dan Carpenter, linuxppc-dev, linux-arm-kernel, qiang.zhao
In-Reply-To: <20210803113538.560277-1-fido_max@inbox.ru>
On Tue, Aug 3, 2021 at 4:33 AM Maxim Kochetkov <fido_max@inbox.ru> wrote:
>
> Since 5.13 QE's ucc nodes can't get interrupts from devicetree:
>
> ucc@2000 {
> cell-index = <1>;
> reg = <0x2000 0x200>;
> interrupts = <32>;
> interrupt-parent = <&qeic>;
> };
>
> Now fw_devlink expects driver to create and probe a struct device
> for interrupt controller.
>
> So lets convert this driver to simple platform_device with probe().
> Also use platform_get_ and devm_ family function to get/allocate
> resources and drop unused .compatible = "qeic".
Yes, please!
Acked-by: Saravana Kannan <saravanak@google.com>
-Saravana
>
> [1] - https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com
> Fixes: e590474768f1 ("driver core: Set fw_devlink=on by default")
> Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""")
> Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> drivers/soc/fsl/qe/qe_ic.c | 75 ++++++++++++++++++++++----------------
> 1 file changed, 44 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe_ic.c b/drivers/soc/fsl/qe/qe_ic.c
> index 3f711c1a0996..e710d554425d 100644
> --- a/drivers/soc/fsl/qe/qe_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ic.c
> @@ -23,6 +23,7 @@
> #include <linux/signal.h>
> #include <linux/device.h>
> #include <linux/spinlock.h>
> +#include <linux/platform_device.h>
> #include <asm/irq.h>
> #include <asm/io.h>
> #include <soc/fsl/qe/qe.h>
> @@ -404,41 +405,40 @@ static void qe_ic_cascade_muxed_mpic(struct irq_desc *desc)
> chip->irq_eoi(&desc->irq_data);
> }
>
> -static void __init qe_ic_init(struct device_node *node)
> +static int qe_ic_init(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> void (*low_handler)(struct irq_desc *desc);
> void (*high_handler)(struct irq_desc *desc);
> struct qe_ic *qe_ic;
> - struct resource res;
> - u32 ret;
> + struct resource *res;
> + struct device_node *node = pdev->dev.of_node;
>
> - ret = of_address_to_resource(node, 0, &res);
> - if (ret)
> - return;
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res == NULL) {
> + dev_err(dev, "no memory resource defined\n");
> + return -ENODEV;
> + }
>
> - qe_ic = kzalloc(sizeof(*qe_ic), GFP_KERNEL);
> + qe_ic = devm_kzalloc(dev, sizeof(*qe_ic), GFP_KERNEL);
> if (qe_ic == NULL)
> - return;
> + return -ENOMEM;
>
> - qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
> - &qe_ic_host_ops, qe_ic);
> - if (qe_ic->irqhost == NULL) {
> - kfree(qe_ic);
> - return;
> + qe_ic->regs = devm_ioremap(dev, res->start, resource_size(res));
> + if (qe_ic->regs == NULL) {
> + dev_err(dev, "failed to ioremap() registers\n");
> + return -ENODEV;
> }
>
> - qe_ic->regs = ioremap(res.start, resource_size(&res));
> -
> qe_ic->hc_irq = qe_ic_irq_chip;
>
> - qe_ic->virq_high = irq_of_parse_and_map(node, 0);
> - qe_ic->virq_low = irq_of_parse_and_map(node, 1);
> + qe_ic->virq_high = platform_get_irq(pdev, 0);
> + qe_ic->virq_low = platform_get_irq(pdev, 1);
>
> - if (!qe_ic->virq_low) {
> - printk(KERN_ERR "Failed to map QE_IC low IRQ\n");
> - kfree(qe_ic);
> - return;
> + if (qe_ic->virq_low < 0) {
> + return -ENODEV;
> }
> +
> if (qe_ic->virq_high != qe_ic->virq_low) {
> low_handler = qe_ic_cascade_low;
> high_handler = qe_ic_cascade_high;
> @@ -447,6 +447,13 @@ static void __init qe_ic_init(struct device_node *node)
> high_handler = NULL;
> }
>
> + qe_ic->irqhost = irq_domain_add_linear(node, NR_QE_IC_INTS,
> + &qe_ic_host_ops, qe_ic);
> + if (qe_ic->irqhost == NULL) {
> + dev_err(dev, "failed to add irq domain\n");
> + return -ENODEV;
> + }
> +
> qe_ic_write(qe_ic->regs, QEIC_CICR, 0);
>
> irq_set_handler_data(qe_ic->virq_low, qe_ic);
> @@ -456,20 +463,26 @@ static void __init qe_ic_init(struct device_node *node)
> irq_set_handler_data(qe_ic->virq_high, qe_ic);
> irq_set_chained_handler(qe_ic->virq_high, high_handler);
> }
> + return 0;
> }
> +static const struct of_device_id qe_ic_ids[] = {
> + { .compatible = "fsl,qe-ic"},
> + { .type = "qeic"},
> + {},
> +};
>
> -static int __init qe_ic_of_init(void)
> +static struct platform_driver qe_ic_driver =
> {
> - struct device_node *np;
> + .driver = {
> + .name = "qe-ic",
> + .of_match_table = qe_ic_ids,
> + },
> + .probe = qe_ic_init,
> +};
>
> - np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> - if (!np) {
> - np = of_find_node_by_type(NULL, "qeic");
> - if (!np)
> - return -ENODEV;
> - }
> - qe_ic_init(np);
> - of_node_put(np);
> +static int __init qe_ic_of_init(void)
> +{
> + platform_driver_register(&qe_ic_driver);
> return 0;
> }
> subsys_initcall(qe_ic_of_init);
> --
> 2.31.1
>
^ permalink raw reply
* Re: [PATCH v5] pseries: prevent free CPU ids to be reused on another node
From: Laurent Dufour @ 2021-08-03 17:37 UTC (permalink / raw)
To: Nathan Lynch, mpe, benh, paulus; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87v94mii3z.fsf@linux.ibm.com>
Le 03/08/2021 à 18:54, Nathan Lynch a écrit :
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>> V5:
>> - Rework code structure
>> - Reintroduce the capability to reuse other node's ids.
>
> OK. While I preferred v4, where we would fail an add rather than allow
> CPU IDs to appear to "travel" between nodes, this change is a net
> improvement.
>
> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com>
>
Thanks Nathan,
Regarding the reuse of other nodes free CPU ids, with this patch the kernel does
it best to prevent that. Instead of failing adding new CPUs, I think it's better
to reuse free CPU ids of other nodes, otherwise, only a reboot would allow the
CPU adding operation to succeed.
Laurent.
^ permalink raw reply
* Re: [PATCH v5] pseries/drmem: update LMBs after LPM
From: Laurent Dufour @ 2021-08-03 17:34 UTC (permalink / raw)
To: Nathan Lynch, mpe, benh, paulus
Cc: Aneesh Kumar K . V, linuxppc-dev, linux-kernel, Tyrel Datwyler
In-Reply-To: <87sfzqigd9.fsf@linux.ibm.com>
Le 03/08/2021 à 19:32, Nathan Lynch a écrit :
> Laurent Dufour <ldufour@linux.ibm.com> writes:
>> V5:
>> - Reword the commit's description to address Nathan's comments.
>
> Thanks. Still don't like the global variable usage but:
>
> Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com>
>
Thanks Nathan,
I don't like either the global variable usage but I can't see any smarter way to
achieve that.
Laurent.
^ permalink raw reply
* Re: [PATCH v5] pseries/drmem: update LMBs after LPM
From: Nathan Lynch @ 2021-08-03 17:32 UTC (permalink / raw)
To: Laurent Dufour, mpe, benh, paulus
Cc: Aneesh Kumar K . V, linuxppc-dev, linux-kernel, Tyrel Datwyler
In-Reply-To: <20210517090606.56930-1-ldufour@linux.ibm.com>
Laurent Dufour <ldufour@linux.ibm.com> writes:
> V5:
> - Reword the commit's description to address Nathan's comments.
Thanks. Still don't like the global variable usage but:
Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com>
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 98b7252a619bc485763d8e7b9f446f7cc3b992e8
From: kernel test robot @ 2021-08-03 17:15 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 98b7252a619bc485763d8e7b9f446f7cc3b992e8 Automatic merge of 'master' into merge (2021-08-02 11:50)
elapsed time: 873m
configs tested: 108
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arc axs101_defconfig
sh se7750_defconfig
arc haps_hs_smp_defconfig
xtensa iss_defconfig
mips gpr_defconfig
riscv allmodconfig
arm pxa3xx_defconfig
sh se7751_defconfig
arm assabet_defconfig
arm pxa910_defconfig
powerpc mpc8315_rdb_defconfig
s390 zfcpdump_defconfig
mips rt305x_defconfig
powerpc g5_defconfig
arc hsdk_defconfig
sparc64 alldefconfig
mips e55_defconfig
powerpc xes_mpc85xx_defconfig
powerpc powernv_defconfig
m68k mvme16x_defconfig
mips rbtx49xx_defconfig
powerpc ksi8560_defconfig
sh defconfig
arm moxart_defconfig
sh kfr2r09_defconfig
arm palmz72_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
x86_64 allnoconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
arc defconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
s390 allmodconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a002-20210803
x86_64 randconfig-a004-20210803
x86_64 randconfig-a006-20210803
x86_64 randconfig-a003-20210803
x86_64 randconfig-a001-20210803
x86_64 randconfig-a005-20210803
i386 randconfig-a004-20210803
i386 randconfig-a005-20210803
i386 randconfig-a002-20210803
i386 randconfig-a006-20210803
i386 randconfig-a001-20210803
i386 randconfig-a003-20210803
i386 randconfig-a012-20210803
i386 randconfig-a011-20210803
i386 randconfig-a015-20210803
i386 randconfig-a013-20210803
i386 randconfig-a014-20210803
i386 randconfig-a016-20210803
i386 randconfig-a012-20210802
i386 randconfig-a011-20210802
i386 randconfig-a015-20210802
i386 randconfig-a013-20210802
i386 randconfig-a014-20210802
i386 randconfig-a016-20210802
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
um x86_64_defconfig
um i386_defconfig
x86_64 allyesconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-c001-20210803
x86_64 randconfig-a012-20210803
x86_64 randconfig-a016-20210803
x86_64 randconfig-a013-20210803
x86_64 randconfig-a011-20210803
x86_64 randconfig-a014-20210803
x86_64 randconfig-a015-20210803
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v5] pseries: prevent free CPU ids to be reused on another node
From: Nathan Lynch @ 2021-08-03 16:54 UTC (permalink / raw)
To: Laurent Dufour, mpe, benh, paulus; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20210429174908.16613-1-ldufour@linux.ibm.com>
Laurent Dufour <ldufour@linux.ibm.com> writes:
> V5:
> - Rework code structure
> - Reintroduce the capability to reuse other node's ids.
OK. While I preferred v4, where we would fail an add rather than allow
CPU IDs to appear to "travel" between nodes, this change is a net
improvement.
Reviewed-by: Nathan Lynch <nathanl@linux.ibm.com>
^ permalink raw reply
* [Bug 213961] New: Oops while loading radeon driver
From: bugzilla-daemon @ 2021-08-03 16:45 UTC (permalink / raw)
To: linuxppc-dev
https://bugzilla.kernel.org/show_bug.cgi?id=213961
Bug ID: 213961
Summary: Oops while loading radeon driver
Product: Platform Specific/Hardware
Version: 2.5
Kernel Version: 5.14-rc4
Hardware: PPC-32
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: PPC-32
Assignee: platform_ppc-32@kernel-bugs.osdl.org
Reporter: riesebie@lxtec.de
Regression: No
Created attachment 298183
--> https://bugzilla.kernel.org/attachment.cgi?id=298183&action=edit
Boot proto
Please find attached boot proto. The virtual console freezes. X doesn' start.
ssh login from remote gives access to the system.
Thanks in advance
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH v2] arch: vdso: remove if-conditionals of $(c-gettimeofday-y)
From: Catalin Marinas @ 2021-08-03 16:19 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Thomas Bogendoerfer, Russell King, linuxppc-dev, linux-kernel,
linux-csky, linux-mips, Paul Walmsley, Albert Ou, Palmer Dabbelt,
linux-arm-kernel, Andy Lutomirski, Guo Ren, Thomas Gleixner,
Vincenzo Frascino, Will Deacon, linux-riscv, Paul Mackerras
In-Reply-To: <20210731060020.12913-1-masahiroy@kernel.org>
On Sat, Jul 31, 2021 at 03:00:20PM +0900, Masahiro Yamada wrote:
> arm, arm64, csky, mips, powerpc always select GENERIC_GETTIMEOFDAY,
> hence $(gettimeofday-y) never becomes empty.
>
> riscv conditionally selects GENERIC_GETTIMEOFDAY when MMU=y && 64BIT=y,
> but arch/riscv/kernel/vdso/vgettimeofday.o is built only under that
> condition. So, you can always define CFLAGS_vgettimeofday.o
>
> Remove all the meaningless conditionals.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH printk v1 03/10] kgdb: delay roundup if holding printk cpulock
From: John Ogness @ 2021-08-03 15:30 UTC (permalink / raw)
To: Daniel Thompson
Cc: Gautham R. Shenoy, Douglas Anderson, Srikar Dronamraju,
Peter Zijlstra, linux-kernel, Paul Mackerras, H. Peter Anvin,
Chengyang Fan, Bhaskar Chowdhury, x86, Ingo Molnar,
kgdb-bugreport, Petr Mladek, Nicholas Piggin, Borislav Petkov,
Steven Rostedt, Thomas Gleixner, Gustavo A. R. Silva,
Sergey Senozhatsky, Jason Wessel, linuxppc-dev,
Cédric Le Goater
In-Reply-To: <20210803142558.cz7apumpgijs5y4y@maple.lan>
On 2021-08-03, Daniel Thompson <daniel.thompson@linaro.org> wrote:
> On Tue, Aug 03, 2021 at 03:18:54PM +0206, John Ogness wrote:
>> kgdb makes use of its own cpulock (@dbg_master_lock, @kgdb_active)
>> during cpu roundup. This will conflict with the printk cpulock.
>
> When the full vision is realized what will be the purpose of the printk
> cpulock?
>
> I'm asking largely because it's current role is actively unhelpful
> w.r.t. kdb. It is possible that cautious use of in_dbg_master() might
> be a better (and safer) solution. However it sounds like there is a
> larger role planned for the printk cpulock...
The printk cpulock is used as a synchronization mechanism for
implementing atomic consoles, which need to be able to safely interrupt
the console write() activity at any time and immediately continue with
their own printing. The ultimate goal is to move all console printing
into per-console dedicated kthreads, so the primary function of the
printk cpulock is really to immediately _stop_ the CPU/kthread
performing write() in order to allow write_atomic() (from any context on
any CPU) to safely and reliably take over.
Atomic consoles are actually quite similar to the kgdb_io ops. For
example, comparing:
serial8250_console_write_atomic() + serial8250_console_putchar_locked()
with
serial8250_put_poll_char()
The difference is that serial8250_console_write_atomic() is line-based
and synchronizing with serial8250_console_write() so that if the kernel
crashes while outputing to the console, write() can be interrupted by
write_atomic() and cleanly formatted crash data can be output.
Also serial8250_put_poll_char() is calling into __pm_runtime_resume(),
which includes a spinlock and possibly sleeping. This would not be
acceptable for atomic consoles. Although, as Andy pointed out [0], I
will need to figure out how to deal with suspended consoles. Or just
implement a policy that registered atomic consoles may never be
suspended.
I had not considered merging kgdb_io ops with atomic console ops. But
now that I look at it more closely, there may be some useful overlap. I
will consider this. Thank you for this idea.
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index 3d0c933937b4..1b546e117f10 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -214,6 +215,7 @@ int devkmsg_sysctl_set_loglvl(struct ctl_table *table, int write,
>> #ifdef CONFIG_SMP
>> static atomic_t printk_cpulock_owner = ATOMIC_INIT(-1);
>> static atomic_t printk_cpulock_nested = ATOMIC_INIT(0);
>> +static unsigned int kgdb_cpu = -1;
>
> Is this the flag to provoke retriggering? It appears to be a write-only
> variable (at least in this patch). How is it consumed?
Critical catch! Thank you. I am quite unhappy to see these hunks were
accidentally dropped when generating this series.
@@ -3673,6 +3675,9 @@ EXPORT_SYMBOL(__printk_cpu_trylock);
*/
void __printk_cpu_unlock(void)
{
+ bool trigger_kgdb = false;
+ unsigned int cpu;
+
if (atomic_read(&printk_cpulock_nested)) {
atomic_dec(&printk_cpulock_nested);
return;
@@ -3683,6 +3688,12 @@ void __printk_cpu_unlock(void)
* LMM(__printk_cpu_unlock:A)
*/
+ cpu = smp_processor_id();
+ if (kgdb_cpu == cpu) {
+ trigger_kgdb = true;
+ kgdb_cpu = -1;
+ }
+
/*
* Guarantee loads and stores from this CPU when it was the
* lock owner are visible to the next lock owner. This pairs
@@ -3703,6 +3714,21 @@ void __printk_cpu_unlock(void)
*/
atomic_set_release(&printk_cpulock_owner,
-1); /* LMM(__printk_cpu_unlock:B) */
+
+ if (trigger_kgdb) {
+ pr_warn("re-triggering kgdb roundup for CPU#%d\n", cpu);
+ kgdb_roundup_cpu(cpu);
+ }
}
EXPORT_SYMBOL(__printk_cpu_unlock);
John Ogness
[0] https://lore.kernel.org/lkml/YQlKAeXS9MPmE284@smile.fi.intel.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox