On 14/03/2023 18:18, Andrew Morton wrote:
> On Tue, 14 Mar 2023 18:08:37 -0300 "Guilherme G. Piccoli"
> wrote:
> [...]
>> Hi Andrew, thanks!
>>
>> Do you want me to re-submit? I see some emails of the patch getting
>> added to "mm-nonmm-unstable&q
On 14/03/2023 17:50, Andrew Morton wrote:
> On Tue, 14 Mar 2023 17:00:58 -0300 "Guilherme G. Piccoli"
> wrote:
>
>> include/trace/events/notifiers.h | 69
>> kernel/notifier.c| 6 +++
>
> Perhaps th
Cc: Xiaoming Ni
Signed-off-by: Guilherme G. Piccoli
---
V4:
- Rebased and tested on top of v6.3-rc2.
- Sending as standalone patch, not part of any series.
V3:
- Yet another major change - thanks to Arjan's great suggestion,
refactored the code to make use of tracepoints instead of guarding
On 26/02/2023 02:44, Andrew Morton wrote:
> On Fri, 10 Feb 2023 17:35:10 -0300 "Guilherme G. Piccoli"
> wrote:
> [...]
>> Notice that while at it, I got rid of the "crash_kexec_post_notifiers"
>> local copy in panic(). This was introduced by commi
dump all CPUs backtraces in
panic_print")
Cc: sta...@vger.kernel.org
Signed-off-by: Guilherme G. Piccoli
---
V5:
- Kept the local version of "crash_kexec_post_notifiers", since
this is standalone fix that should be backported to stable. Hence,
it's not a good idea to mess with it in
On 14/02/2023 11:46, Petr Mladek wrote:
> [...]
>> My understanding is that it's a mechanism to prevent some concurrency,
>> in case some other CPU modify this variable while panic() is running.
>> I find it very unlikely, hence I removed it - but if people consider
>> this copy needed, I can
dump all CPUs backtraces in
panic_print")
Cc: sta...@vger.kernel.org
Signed-off-by: Guilherme G. Piccoli
---
V4:
- Sent as standalone patch, rebased against v6.2-rc7.
V2 / V3:
- New patch, there was no V1 of this one.
Link for V3:
https://lore.kernel.org/lkml/20220819221731.480795-12-gpicc...@
Hi Boris and Petr, first of all thanks for your great analysis and
really sorry for the huge delay in my response.
Below I'm pasting the 2 relevant responses from both Petr and Boris.
On 22/11/2022 12:06, Borislav Petkov wrote:
> On Tue, Nov 22, 2022 at 10:33:12AM -0300, Guilherme G. Picc
On 20/12/2022 02:51, Baoquan He wrote:
> On 12/20/22 at 01:41pm, Baoquan He wrote:
>> On one intel bare metal system, I can randomly reproduce the kdump hang
>> as below with tick_periodic call trace. Attach the kernel config for
>> reference.
>
> Forgot mentioning this random hang is also caused
On 08/12/2022 13:38, Ricardo Ribalda wrote:
> Add two parameter to specify how many times a kexec kernel can be loaded.
>
> The sysadmin can set different limits for kexec panic and kexec reboot
> kernels.
>
> The value can be modified at runtime via sysfs, but only with a value
> smaller than
On 13/12/2022 21:06, Steven Rostedt wrote:
> [...]
> Heh, yeah, I forgot about this one too.
>
>>
>> So, do you think it's possible to pick it for 6.2? No dependency here,
>> it's a standalone patch.
>
> I can pull it in.
Awesome, thanks a bunch!
>
>>
>> Thanks again and sorry for the
On 20/10/2022 18:29, Steven Rostedt wrote:
> On Fri, 19 Aug 2022 19:17:26 -0300
> "Guilherme G. Piccoli" wrote:
>
>> Currently the tracing dump_on_oops feature is implemented through
>> separate notifiers, one for die/oops and the other for panic;
>> given th
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Commit 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in
> panic_print")
> introduced a setting for the "panic_print" kernel parameter to allow
> users to request a NMI backtrace on panic. Problem is
On 18/09/2022 11:10, Guilherme G. Piccoli wrote:
> On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
>> The altera_edac panic notifier performs some data collection with
>> regards errors detected; such code relies in the regmap layer to
>> perform reads/writes, so t
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Currently there is no way to show the callback names for registered,
> unregistered or executed notifiers. This is very useful for debug
> purposes, hence add this functionality here in the form of notifiers'
> tracepoints, one p
On 20/10/2022 19:22, Steven Rostedt wrote:
> On Thu, 20 Oct 2022 18:53:43 -0300
> "Guilherme G. Piccoli" wrote:
>
>> Could you pick it in your tree? Or do you prefer that I re-send as a
>> solo patch, with your ACK?
>
> I wasn't sure there were any dep
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> The alpha panic notifier has some code issues, not following
> the conventions of other notifiers. Also, it might halt the
> machine but still it is set to run as early as possible, which
> doesn't seem to be a good idea.
>
&g
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Although many notifiers are mentioned in the comments, the panic
> notifiers infrastructure is not. Also, the file contains some
> trailing whitespaces. Fix both issues here.
>
> Cc: Arjan van de Ven
> Cc: Cong Wang
>
On 11/11/2022 20:16, Wei Liu wrote:
> On Fri, Nov 11, 2022 at 10:47:17PM +, Wei Liu wrote:
>> On Thu, Nov 10, 2022 at 06:32:54PM -0300, Guilherme G. Piccoli wrote:
>>> [Trimming long CC list]
>>>
>>> Hi Wei / Michael, just out of curiosity, did this (an
[Trimming long CC list]
Hi Wei / Michael, just out of curiosity, did this (and patch 9) ended-up
being queued in hyperv-next?
Thanks in advance,
Guilherme
On 17/10/2022 12:26, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Tuesday, October 4,
> 2022 10:20 AM
>>
On 20/10/2022 18:29, Steven Rostedt wrote:
> [...]
> Sorry for the late reply.
>
> Acked-by: Steven Rostedt (Google)
>
> -- Steve
No need for apologies! Appreciate your review/ack =)
Could you pick it in your tree? Or do you prefer that I re-send as a
solo patch, with your ACK?
Cheers,
On 20/10/2022 19:22, Steven Rostedt wrote:
> On Thu, 20 Oct 2022 18:53:43 -0300
> "Guilherme G. Piccoli" wrote:
>
>> Could you pick it in your tree? Or do you prefer that I re-send as a
>> solo patch, with your ACK?
>
> I wasn't sure there were any dep
On 17/10/2022 14:47, Russell King (Oracle) wrote:
> On Mon, Oct 17, 2022 at 11:50:05AM -0300, Guilherme G. Piccoli wrote:
>> On 17/10/2022 11:17, Russell King (Oracle) wrote:
>>> [...]
>>>> Monthly ping - let me know if there's something I should improve in
>
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Currently there is no way to show the callback names for registered,
> unregistered or executed notifiers. This is very useful for debug
> purposes, hence add this functionality here in the form of notifiers'
> tracepoints, one p
On 17/10/2022 11:17, Russell King (Oracle) wrote:
> [...]
>> Monthly ping - let me know if there's something I should improve in
>> order this fix is considered!
>
> Patches don't get applied unless they end up in the patch system.
> Thanks.
>
Thanks Russell! Can you show me some documentation
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Currently the tracing dump_on_oops feature is implemented through
> separate notifiers, one for die/oops and the other for panic;
> given they have the same functionality, let's unify them.
>
> Also improve the function com
On 18/09/2022 18:19, Richard Weinberger wrote:
> - Ursprüngliche Mail -
>> Von: "Guilherme G. Piccoli"
>> On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
>>> Currently the panic notifiers from user mode linux don't follow
>>> the convent
On 18/09/2022 10:58, Guilherme G. Piccoli wrote:
> On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
>> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
>> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
>> is responsible for that. IRQ
On 18/09/2022 11:10, Guilherme G. Piccoli wrote:
> On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
>> The altera_edac panic notifier performs some data collection with
>> regards errors detected; such code relies in the regmap layer to
>> perform reads/writes, so t
On 17/10/2022 11:10, Richard Weinberger wrote:
> - Ursprüngliche Mail -
>> Von: "Guilherme G. Piccoli"
>> Hi Richard / Johannes, is there any news on this one?
>> Thanks in advance,
>
> It's upstream:
> git.kernel.org/linus/758dfdb9185c
On 04/10/2022 13:24, Michael Kelley (LINUX) wrote:
> [...]
>
> Tested this patch in combination with Patch 9 in this series. Verified
> that both the panic and die paths work correctly with notification to
> Hyper-V via hyperv_report_panic() or via hv_kmsg_dump(). Hyper-V
> framebuffer is
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Currently there is no way to show the callback names for registered,
> unregistered or executed notifiers. This is very useful for debug
> purposes, hence add this functionality here in the form of notifiers'
> tracepoints, one p
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> The altera_edac panic notifier performs some data collection with
> regards errors detected; such code relies in the regmap layer to
> perform reads/writes, so the code is abstracted and there is some
> risk level to execute that, sin
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Commit 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in
> panic_print")
> introduced a setting for the "panic_print" kernel parameter to allow
> users to request a NMI backtrace on panic. Problem is
On 18/09/2022 18:19, Richard Weinberger wrote:
> - Ursprüngliche Mail -
>> Von: "Guilherme G. Piccoli"
>> On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
>>> Currently the panic notifiers from user mode linux don't follow
>>> the convent
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> The Hyper-V framebuffer code registers a panic notifier in order
> to try updating its fbdev if the kernel crashed. The notifier
> callback is straightforward, but it calls the vmbus_sendpacket()
> routine eventually, and such fu
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Currently the tracing dump_on_oops feature is implemented through
> separate notifiers, one for die/oops and the other for panic;
> given they have the same functionality, let's unify them.
>
> Also improve the function com
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Currently the panic notifiers from user mode linux don't follow
> the convention for most of the other notifiers present in the
> kernel (indentation, priority setting, numeric return).
> More important, the priorities could be imp
On 19/08/2022 19:17, Guilherme G. Piccoli wrote:
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. IRQs are architecturally masked when we
> take an interrupt, but F
;
if so, bail-out avoiding the potential lockup scenario.
Cc: Andrea Parri (Microsoft)
Cc: Dexuan Cui
Cc: Haiyang Zhang
Cc: "K. Y. Srinivasan"
Cc: Michael Kelley
Cc: Stephen Hemminger
Cc: Tianyu Lan
Cc: Wei Liu
Tested-by: Fabio A M Martins
Signed-off-by: Guilherme G. Piccoli
-by: Baoquan He
Signed-off-by: Guilherme G. Piccoli
---
V3:
- Added Baoquan review tag - thanks!
V2:
- No changes.
include/linux/notifier.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index aef88c2d1173..d5b01f2e3fcc
ally!) off.
So, let's disable FIQs in both paths and *not* disable IRQs a second
time, since they are already masked in both paths by the architecture.
This way, we keep both CPU quiesce paths consistent and safe.
Cc: Marc Zyngier
Cc: Michael Kelley
Cc: Russell King
Signed-off-by: Guilherme
showing useless trace
data (like the callback names for the other notifiers); finally,
we also removed an unnecessary header inclusion.
Cc: Petr Mladek
Cc: Sergei Shtylyov
Cc: Steven Rostedt
Signed-off-by: Guilherme G. Piccoli
---
V3:
- Removed goto usage, as per Steven suggestion (thanks
dump all CPUs backtraces in
panic_print")
Cc: Feng Tang
Cc: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
V3:
- No changes.
V2:
- new patch, there was no V1 of this one.
Hi folks, thanks upfront for reviews. This is a new patch, fixing an issue
I found in my tests, so I shoved it i
Siewior
Cc: Steven Rostedt
Cc: Valentin Schneider
Cc: Xiaoming Ni
Signed-off-by: Guilherme G. Piccoli
---
V3:
- Yet another major change - thanks to Arjan's great suggestion,
refactored the code to make use of tracepoints instead of guarding
the output with a Kconfig debug setting.
V2
e for them!
Cheers,
Guilherme
Guilherme G. Piccoli (11):
ARM: Disable FIQs (but not IRQs) on CPUs shutdown paths
notifier: Add panic notifiers info and purge trailing whitespaces
alpha: Clean-up the panic notifier code
um: Improve panic notifiers consistency and ordering
parisc: Repla
the same approach other architectures are
doing - also, remove the unnecessary include of a header already
included indirectly.
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Richard Henderson
Reviewed-by: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
V3:
- No changes.
V2:
- Fixed rth email
tins
Signed-off-by: Guilherme G. Piccoli
---
V3:
- Added Michael's review tag - thanks!
V2:
- Unfortunately we cannot rely in the crash shutdown (custom) handler
to perform the vmbus unload - arm64 architecture doesn't have this
"feature" [0]. So, in V2 we kept the notifier behavior and always
u
by the architecture one (that coredumps).
Cc: Anton Ivanov
Cc: Johannes Berg
Cc: Richard Weinberger
Signed-off-by: Guilherme G. Piccoli
V3:
- No changes.
V2:
- Kept the notifier header to avoid implicit usage - thanks
Johannes for the suggestion!
---
arch/um/drivers/mconsole_kern.c | 7 +++
arch/um
Signed-off-by: Guilherme G. Piccoli
---
V3:
- s/in/on as per Jeroen's suggestion - thanks!
V2:
- Added Helge's ACK - thanks!
arch/parisc/include/asm/pdc.h | 1 +
arch/parisc/kernel/firmware.c | 27 +++
drivers/parisc/power.c| 17 ++---
3 files c
: Borislav Petkov
Cc: Petr Mladek
Cc: Tony Luck
Acked-by: Dinh Nguyen
Signed-off-by: Guilherme G. Piccoli
---
V3:
- added the ack tag from Dinh - thanks!
- had a good discussion with Boris about that in V2 [0],
hopefully we can continue and reach a consensus in this V3.
[0]
https
On 17/08/2022 19:19, Borislav Petkov wrote:
> On Wed, Aug 17, 2022 at 07:09:26PM -0300, Guilherme G. Piccoli wrote:
>> Again - a matter of a trade-off, a good compromise must be agreed by all
>> parties (kdump maintainers are usually extremely afraid of taking risks
>&g
On 17/08/2022 14:31, Borislav Petkov wrote:
> [...]
>
> How does the fact that kdump is loaded, obviate the need to print
> information about the errors?
>
> Are you suggesting that people who have the whole vmcore would be able
> to piece together the error information?
>
Hi Boris, thanks for
On 17/08/2022 19:00, Borislav Petkov wrote:
> On Wed, Aug 17, 2022 at 06:56:11PM -0300, Guilherme G. Piccoli wrote:
>> But do you agree that currently, in case of a kdump, that information
>> *is not collected*, with our without my patch?
>
> If for some reason that panic
On 17/08/2022 18:46, Borislav Petkov wrote:
> On Wed, Aug 17, 2022 at 06:39:07PM -0300, Guilherme G. Piccoli wrote:
>> Sorry for the confusion, let me try to be a bit more clear:
>
> I think you're missing the point. Lemme try again:
>
> You *absolutely* must log those e
On 17/08/2022 18:02, Borislav Petkov wrote:
> On Wed, Aug 17, 2022 at 05:28:34PM -0300, Guilherme G. Piccoli wrote:
>> My understanding is the same as yours, i.e., this is not possible to
>> collect from vmcore, it requires register reading. But again: if you
>> kdump your mac
On 17/08/2022 16:34, Borislav Petkov wrote:
> [...]
>
> What is "the failure risk for kdump"?
>
> Some of the notifiers which run before kdump might fail and thus prevent
> the machine from kdumping?
>
Exactly; some notifiers could break the machine and prevent a successful
kdump. The EDAC one
On 16/08/2022 12:52, Steven Rostedt wrote:
> On Tue, 16 Aug 2022 10:57:20 -0400
> Alan Stern wrote:
>
>>> static int trace_die_panic_handler(struct notifier_block *self,
>>> unsigned long ev, void *unused)
>>> {
>>> if (!ftrace_dump_on_oops)
>>> return
On 16/08/2022 15:44, Dinh Nguyen wrote:
> [...]
>> V2:
>> - new patch, based on the discussion in [0].
>> [0]
>> https://lore.kernel.org/lkml/62a63fc2-346f-f375-043a-fa2138527...@igalia.com/
>>
>
> Acked-by: Dinh Nguyen
Thanks a lot Dinh!
There is something I'm asking for maintainers on
On 09/08/2022 16:08, Johannes Berg wrote:
> [...]
>> Perfect, thank you! Let me take the opportunity to ask you something I'm
>> asking all the maintainers involved here - do you prefer taking the
>> patch through your tree, or to get it landed with the whole series, at
>> once, from some
On 09/08/2022 15:09, Johannes Berg wrote:
> [...]
>>> V2:
>>> - Kept the notifier header to avoid implicit usage - thanks
>>> Johannes for the suggestion!
>>>
>>> arch/um/drivers/mconsole_kern.c | 7 +++
>>> arch/um/kernel/um_arch.c| 8
>>> 2 files changed, 7 insertions(+), 8
On 08/08/2022 12:26, Greg Kroah-Hartman wrote:
> [...]
>>
>> Ard / Greg, do you think you could get this patch through your -next (or
>> -fixes) trees? Not sure which tree is the most common for picking GSMI
>> stuff.
>
> Picking out an individual patch from a series with as many responses and
>
On 08/08/2022 02:07, Evan Green wrote:
> On Tue, Jul 19, 2022 at 12:55 PM Guilherme G. Piccoli
> wrote:
>>
>> Currently the gsmi driver registers a panic notifier as well as
>> reboot and die notifiers. The callbacks registered are called in
>> atomic and very
On 19/07/2022 16:53, Guilherme G. Piccoli wrote:
> The altera_edac panic notifier performs some data collection with
> regards errors detected; such code relies in the regmap layer to
> perform reads/writes, so the code is abstracted and there is some
> risk level to execute that, sin
On 19/07/2022 16:53, Guilherme G. Piccoli wrote:
> Currently the tracing dump_on_oops feature is implemented
> through separate notifiers, one for die/oops and the other
> for panic - given they have the same functionality, let's
> unify them.
>
> Also improve the function
On 19/07/2022 16:53, Guilherme G. Piccoli wrote:
> Currently the panic notifiers from user mode linux don't follow
> the convention for most of the other notifiers present in the
> kernel (indentation, priority setting, numeric return).
> More important, the priorities could be imp
On 19/07/2022 16:53, Guilherme G. Piccoli wrote:
> Currently the gsmi driver registers a panic notifier as well as
> reboot and die notifiers. The callbacks registered are called in
> atomic and very limited context - for instance, panic disables
> preemption and local IRQs, also a
On 19/07/2022 16:53, Guilherme G. Piccoli wrote:
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. IRQs are architecturally masked when we
> take an interrupt, but F
On 03/08/2022 06:52, Baoquan He wrote:
> [...]
>>
>> Although the switch-case code of original trace_die_handler() is werid,
>> this unification is not much more comfortable. Just personal feeling
>> from code style, not strong opinion. Leave it to trace reviewers.
>
> Please ignore this
On 25/07/2022 15:09, Michael Kelley (LINUX) wrote:
> [...]
>> +bool hv_ringbuffer_spinlock_busy(struct vmbus_channel *channel)
>> +{
>> +struct hv_ring_buffer_info *rinfo = >outbound;
>> +
>> +if (spin_is_locked(>ring_lock))
>> +return true;
>> +
>> +return false;
>
>
On 21/07/2022 10:45, Helge Deller wrote:
> [...]
> Guilherme, I'd really prefer that you push the whole series at once through
> some generic tree.
>
> Helge
Hmm..OK.
Some maintainers will take patches from here and merge, but given your
preference I can talk to Andrew to see if the can pick
On 19/07/2022 22:43, Jeroen Roovers wrote:
> Hi Guilherme,
> [...]
>> + *
>> + * The _panic version relies in spin_trylock to prevent deadlock
>> + * on panic path.
>
> in => on
>
Hi Jer, thanks for the suggestion!
Helge, do you think you could fix it when applying, if there's no other
On 19/07/2022 19:04, Arjan van de Ven wrote:
> On 7/19/2022 2:00 PM, Guilherme G. Piccoli wrote:
>> On 19/07/2022 17:48, Arjan van de Ven wrote:
>>> [...]
>>> I would totally support an approach where instead of pr_info, there's a
>>> tracepoint
>>&
On 20/07/2022 20:00, Florian Fainelli wrote:
> [...]
>
> Applied to https://github.com/Broadcom/stblinux/commits/drivers/next, thanks!
> --
> Florian
Thanks Florian =)
___
kexec mailing list
kexec@lists.infradead.org
On 19/07/2022 17:33, Arjan van de Ven wrote:
> On 7/19/2022 12:53 PM, Guilherme G. Piccoli wrote:
>> Currently we have a debug infrastructure in the notifiers file, but
>> it's very simple/limited. Extend it by:
>>
>> (a) Showing all registered/unregistered notifiers'
panic reliability on Hyper-V. This was tested on Hyper-V with success.
Cc: Andrea Parri (Microsoft)
Cc: Dexuan Cui
Cc: Haiyang Zhang
Cc: "K. Y. Srinivasan"
Cc: Michael Kelley
Cc: Petr Mladek
Cc: Stephen Hemminger
Cc: Tianyu Lan
Cc: Wei Liu
Tested-by: Fabio A M Martins
Signed-off
by the architecture one (that coredumps).
Cc: Anton Ivanov
Cc: Johannes Berg
Cc: Richard Weinberger
Signed-off-by: Guilherme G. Piccoli
---
V2:
- Kept the notifier header to avoid implicit usage - thanks
Johannes for the suggestion!
arch/um/drivers/mconsole_kern.c | 7 +++
arch/um/kernel/um_arch.c
Jones
Cc: Markus Mayer
Acked-by: Florian Fainelli
Signed-off-by: Guilherme G. Piccoli
---
V2:
- Removed the Fixes tag;
- Added Florian's ACK - thanks!
drivers/soc/bcm/brcmstb/pm/pm-arm.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/bcm/brcmstb
as a tunable since
it can flood the kernel log buffer.
Cc: Arjan van de Ven
Cc: Cong Wang
Cc: Sebastian Andrzej Siewior
Cc: Steven Rostedt
Cc: Valentin Schneider
Cc: Xiaoming Ni
Signed-off-by: Guilherme G. Piccoli
---
V2:
- Major improvement thanks to the great idea from Xiaoming - changed
;
if so, bail-out avoiding the potential lockup scenario.
Cc: Andrea Parri (Microsoft)
Cc: Dexuan Cui
Cc: Haiyang Zhang
Cc: "K. Y. Srinivasan"
Cc: Michael Kelley
Cc: Stephen Hemminger
Cc: Tianyu Lan
Cc: Wei Liu
Tested-by: Fabio A M Martins
Signed-off-by: Guilherme G. Piccoli
---
-by: Guilherme G. Piccoli
---
V2:
- no change.
include/linux/notifier.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/linux/notifier.h b/include/linux/notifier.h
index aef88c2d1173..d5b01f2e3fcc 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
heuvel
Cc: David Gow
Cc: Evan Green
Cc: Julius Werner
Signed-off-by: Guilherme G. Piccoli
---
V2:
- do not use spin_trylock anymore, to avoid messing with
non-panic paths; now we just check the spinlock state in
the panic notifier before taking it. Thanks Evan for the
review/idea!
driver
of spin_trylock - for that, we've added a second version of the
soft-power function. Also, some comments were reorganized and
trailing white spaces, useless header inclusion and blank lines
were removed.
Cc: "James E.J. Bottomley"
Acked-by: Helge Deller # parisc
Signed-off-by: Guilherme
the same approach other architectures are
doing - also, remove the unnecessary include of a header already
included indirectly.
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Richard Henderson
Reviewed-by: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
V2:
- Fixed rth email address;
- Added
t
anybody interested in the topic (my apologies if so).
As usual, reviews / comments are always welcome, thanks in advance for them!
Cheers,
Guilherme
Guilherme G. Piccoli (13):
ARM: Disable FIQs (but not IRQs) on CPUs shutdown paths
notifier: Add panic notifiers info and purge trailing whitespace
On 19/07/2022 17:48, Arjan van de Ven wrote:
> [...]
> I would totally support an approach where instead of pr_info, there's a
> tracepoint
> for these events (and that shouldnt' need to be conditional on a config
> option)
>
> that's not what the patch does though.
This is a good idea Arjan!
dump all CPUs backtraces in
panic_print")
Cc: Feng Tang
Cc: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
V2:
- new patch, there was no V1 of this one.
Hi folks, thanks upfront for reviews. This is a new patch, fixing an issue
I found in my tests, so I shoved it into this fixes series.
: Dinh Nguyen
Cc: Petr Mladek
Cc: Tony Luck
Signed-off-by: Guilherme G. Piccoli
---
V2:
- new patch, based on the discussion in [0].
[0]
https://lore.kernel.org/lkml/62a63fc2-346f-f375-043a-fa2138527...@igalia.com/
drivers/edac/altera_edac.c | 16
1 file changed, 12 insertions
showing useless
trace data (like the callback names for the other notifiers);
finally, we also removed an unnecessary header inclusion.
Cc: Petr Mladek
Cc: Sergei Shtylyov
Cc: Steven Rostedt
Signed-off-by: Guilherme G. Piccoli
---
V2:
- Different approach; instead of using IDs to distinguish
ally!) off.
So, let's disable FIQs in both paths and *not* disable IRQs a second
time, since they are already masked in both paths by the architecture.
This way, we keep both CPU quiesce paths consistent and safe.
Cc: Marc Zyngier
Cc: Michael Kelley
Cc: Russell King
Signed-off-by: Guilherme
On 29/06/2022 07:25, Baoquan He wrote:
> Hi,
>
> On a HP machine, after crash triggered via sysrq-c, kdump kernel will
> boot and get soft lockup as below. And this can be always reproduced.
>
> From log, it seems that unreliable tsc was marked as unstable in
> clocksource_watchdog, then worker
Perfect Petr, thanks for your feedback!
I'll be out for some weeks, but after that what I'm doing is to split
the series in 2 parts:
(a) The general fixes, which should be reviewed by subsystem maintainers
and even merged individually by them.
(b) The proper panic refactor, which includes the
ing that is not mission critical to
> motherboards.
>
> Notifiers in any sense on these paths are just bollocks. Any kind of
> notifier list is fundamentally fragile in the face of memory corruption
> and very very difficult to review.
>
> So I am going to refresh my ancie
On 19/05/2022 16:20, Scott Branden wrote:
> [...]
>> Hi Scott / Desmond, thanks for the detailed answer! Is this adapter
>> designed to run in x86 only or you have other architectures' use cases?
> The adapter may be used in any PCIe design that supports DMA.
> So it may be possible to run in
On 28/04/2022 13:55, Helge Deller wrote:
> [...]
> You may add:
> Acked-by: Helge Deller # parisc
>
> Helge
Hi Helge, do you think would be possible to still pick this one for
v5.19 or do you prefer to hold for the next release?
I'm working on V2, so if it's merged for 5.19 I won't send it
On 18/05/2022 19:17, Scott Branden wrote:
> Hi Guilherme,
>
> +Desmond
> [...]
I'm afraid it breaks kdump if this device is not reset beforehand - it's
a doorbell write, so not high risk I think...
But in case the not-reset device can be probed normally in kdump kernel,
On 19/05/2022 04:03, Petr Mladek wrote:
> [...]
> I would ignore it for now. If anyone would want to safe the log
> then they would need to read it. They will most likely use
> the existing kmsg_dump() infastructure. In fact, they should
> use it to avoid a code duplication.
>
> Best Regards,
>
On 19/05/2022 20:45, Baoquan He wrote:
> [...]
>> I really appreciate the summary skill you have, to convert complex
>> problems in very clear and concise ideas. Thanks for that, very useful!
>> I agree with what was summarized above.
>
> I want to say the similar words to Petr's reviewing
On 18/05/2022 04:33, Petr Mladek wrote:
> [...]
> Anyway, I would distinguish it the following way.
>
> + If the notifier is preserving kernel log then it should be ideally
> treated as kmsg_dump().
>
> + It the notifier is saving another debugging data then it better
> fits into the
On 18/05/2022 04:58, Petr Mladek wrote:
> [...]
>> I does similar things like kmsg_dump() so it should be called in
>> the same location (after info notifier list and before kdump).
>>
>> A solution might be to put it at these notifiers at the very
>> end of the "info" list or make extra "dump"
1 - 100 of 276 matches
Mail list logo
