On 18/05/2022 04:38, Petr Mladek wrote:
> [...]
> I have answered this in more detail in the other reply, see
> https://lore.kernel.org/r/YoShZVYNAdvvjb7z@alley
>
> I agree that both notifiers in
>
> drivers/soc/bcm/brcmstb/pm/pm-arm.c
> drivers/firmware/google/gsmi.c
>
> better fit
On 17/05/2022 10:57, Petr Mladek wrote:
> [...]
--- a/drivers/misc/bcm-vk/bcm_vk_dev.c
+++ b/drivers/misc/bcm-vk/bcm_vk_dev.c
@@ -1446,7 +1446,7 @@ static int bcm_vk_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
>>> [... snip ...]
>>> It seems to reset some
On 17/05/2022 14:02, Luck, Tony wrote:
>> Tony / Dinh - can I just *skip* this notifier *if kdump* is set or else
>> we run the code as-is? Does that make sense to you?
>
> The "skip" option sounds like it needs some special flag associated with
> an entry on the notifier chain. But there are
On 17/05/2022 07:58, Petr Mladek wrote:
> [...]
>> Thanks for the review Petr. Patch was already merged - my goal was to be
>> concise, i.e., a patch per driver / module, so the patch kinda fixes
>> whatever I think is wrong with the driver with regards panic handling.
>>
>> Do you think it worth
On 17/05/2022 11:11, Petr Mladek wrote:
> [...]
>>> Then notifiers could make an informed choice on whether to deep dive to
>>> get all the possible details (when there is no kdump) or just skim the high
>>> level stuff (to maximize chance of getting a successful kdump).
>>>
>>> -Tony
>>
>> Good
On 17/05/2022 10:11, Petr Mladek wrote:
> [...]
>> You mentioned 2 cases:
>>
>> (a) Same notifier_list used in different situations;
>>
>> (b) Same *notifier callback* used in different lists;
>>
>> Mine is case (b), right? Can you show me an example of case (a)?
>
> There are many examples of
On 10/05/2022 12:28, Petr Mladek wrote:
> [...]
> IMHO, the check of the @self parameter was the proper solution.
>
> "gisb_die_notifier" list uses @val from enum die_val.
> "gisb_panic_notifier" list uses @val from enum panic_notifier_val.
>
> These are unrelated types. It might easily break
On 11/05/2022 08:45, Petr Mladek wrote:
> [...]
> DIE_OOPS and PANIC_NOTIFIER are from different enum.
> It feels like comparing apples with oranges here.
>
> IMHO, the proper way to unify the two notifiers is
> a check of the @self parameter. Something like:
>
> static int
On 17/05/2022 10:28, Petr Mladek wrote:
> [...]
>>> Disagree here. I'm looping Google maintainers, so they can comment.
>>> (CCed Evan, David, Julius)
>>>
>>> This notifier is clearly a hypervisor notification mechanism. I've fixed
>>> a locking stuff there (in previous patch), I feel it's
On 16/05/2022 13:18, Luck, Tony wrote:
>> [...]
> Would it be possible to have some global "kdump is configured + enabled" flag?
>
> Then notifiers could make an informed choice on whether to deep dive to
> get all the possible details (when there is no kdump) or just skim the high
> level stuff
On 16/05/2022 07:21, Petr Mladek wrote:
> [...]
> Ah, it should have been:
>
> + notifiers vs. kmsg_dump
> + notifiers vs. crash_dump
> + crash_dump vs. kmsg_dump
>
> I am sorry for the confusion. Even "crash_dump" is slightly
> misleading because there is no function with this
On 16/05/2022 11:56, Petr Mladek wrote:
> [...]
> I really like both changes. Just please split it them into two
> patchset. I mean one patch for the new "panic_console_replay"
> parameter and 2nd that moves "printk_info" into the notifier.
>
OK sure, will do that in V2.
Thanks,
Guilherme
On 10/05/2022 14:29, Steven Rostedt wrote:
> [...]
> Also, don't sprinkle #ifdef in C code. Instead:
>
> if (IS_ENABLED(CONFIG_DEBUG_NOTIFIERS))
> pr_info("notifers: regsiter %ps()\n",
> n->notifer_call);
>
>
> Or define a print macro at the start of
On 16/05/2022 11:50, Petr Mladek wrote:
> [...]
> Shame on me that I do not care that much about the style of the commit
> message :-)
>
> Anyway, the code looks good to me. With the better commit message:
>
> Reviewed-by: Petr Mladek
>
Heheh, cool - I'll add your tag and improve the message
Thanks for the review!
I agree with the blinking stuff, I can rework and add all LED/blinking
stuff into the loop list, it does make sense. I'll comment a bit in the
others below...
On 16/05/2022 11:01, Petr Mladek wrote:
> [...]
>> --- a/arch/mips/sgi-ip22/ip22-reset.c
>> +++
On 16/05/2022 11:45, Petr Mladek wrote:
> [...]
>
> The patch looks good to me. I would just suggest two changes.
>
> 1. I would rename the list to "panic_loop_list" instead of
>"panic_post_reboot_list".
>
>It will be more clear that it includes things that are
>needed before
Thanks again for the review! Comments inline below:
On 16/05/2022 11:33, Petr Mladek wrote:
> [...]
>> --- a/drivers/edac/altera_edac.c
>> +++ b/drivers/edac/altera_edac.c
>> @@ -2163,7 +2162,7 @@ static int altr_edac_a10_probe(struct platform_device
>> *pdev)
>> int dberror,
On 16/05/2022 11:11, Petr Mladek wrote:
> [...]
>
> All notifiers moved in this patch seems to fit well the "info"
> notifier list. The patch looks good from this POV.
>
> I still have to review the rest of the patches to see if it
> is complete.
>
> Best Regards,
> Petr
Thanks a bunch for the
On 12/05/2022 11:03, Petr Mladek wrote:
> Hello,
>
> first, I am sorry for stepping into the discussion so late.
> I was busy with some other stuff and this patchset is far
> from trivial.
>
> Second, thanks a lot for putting so much effort into it.
> Most of the changes look pretty good,
On 13/05/2022 11:44, Johannes Berg wrote:
> [...]
>> Maybe Anton / Johannes / Richard could give their opinions - appreciate
>> that, I'm not attached to the priority here, it's more about users'
>> common usage of UML I can think of...
>
> It's hard to say ... In a sense I'm not sure it matters?
On 10/05/2022 11:28, Petr Mladek wrote:
> [...]
> It is not clear to me why user mode linux should not care about
> the other notifiers. It might be because I do not know much
> about the user mode linux.
>
> Is the because they always create core dump or are never running
> in a hypervisor or
On 10/05/2022 14:40, Steven Rostedt wrote:
> On Wed, 27 Apr 2022 19:49:17 -0300
> "Guilherme G. Piccoli" wrote:
>
>> Currently we don't have a way to check if there are dumpers set,
>> except counting the list members maybe. This patch introduces a v
On 10/05/2022 11:16, Petr Mladek wrote:
> [...]
> Yeah, it is pretty strange behavior.
>
> I looked into the history. This notifier was added into the alpha code
> in 2.4.0-test2pre2. In this historic code, the default panic() code
> either rebooted after a timeout or ended in a infinite loop.
On 11/05/2022 13:45, Heiko Carstens wrote:
> [...]
>>
>> Hey S390/SPARC folks, sorry for the ping!
>>
>> Any reviews on this V1 would be greatly appreciated, I'm working on V2
>> and seeking feedback in the non-reviewed patches.
>
> Sorry, missed that this is quite s390 specific. So, yes, this
On 10/05/2022 22:50, HAGIO KAZUHITO(萩尾 一仁) wrote:
> [...]
>
> Fair enough, and as far as I've checked:
>
> - The makedumpfile.conf.sample file does not need to be in /etc, because
> makedumpfile does not have any default path for it and reads a config
> file only when specified with --config
you said, it requires a *lot* of code analysis to
understand these multiple shutdown patches, the problem is complicated
by nature heh
I've tested your patch 0001 and it works well for all cases [0], so go
ahead and submit the miniseries, feel free to add:
Reported-and-tested-by: Guilherme G. Picc
On 10/05/2022 10:53, Michael Ellerman wrote:
> "Guilherme G. Piccoli" writes:
>> On 05/05/2022 15:55, Hari Bathini wrote:
>>> [...]
>>> The change looks good. I have tested it on an LPAR (ppc64).
>>>
>>> Reviewed-by: Hari Bathini
>>&
On 10/05/2022 08:38, Petr Mladek wrote:
> [...]
> I see two more alternative solutions:
>
> 1st variant is a trick already used in console write() callbacks.
> They do trylock() when oops_in_progress is set. They remember
> the result to prevent double unlock when printing Oops messages and
> the
On 10/05/2022 09:14, Petr Mladek wrote:
> [...]
>> With that said, it's dangerous to use regular spinlocks in such path,
>> as introduced by commit b3c0f8774668 ("misc/pvpanic: probe multiple
>> instances").
>> This patch fixes that by replacing regular spinlocks with the trylock
>> safer
On 10/05/2022 12:16, Petr Mladek wrote:
> [...]
> Hmm, this looks like a hack. PANIC_UNUSED will never be used.
> All notifiers will be always called with PANIC_NOTIFIER.
>
> The @val parameter is normally used when the same notifier_list
> is used in different situations.
>
> But you are going
On 09/05/2022 13:14, Suzuki K Poulose wrote:
> [...]>
> I have queued this to coresight/next.
>
> Thanks
> Suzuki
Thanks a lot Suzuki!
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Hey Hatayma, thanks for your great analysis and no need for apologies!
I'll comment/respond properly inline below, just noticing here that I've
CCed Mark and Marc (from the ARM64 perspective), Michael (Hyper-V
perspective) and Hari (PowerPC perspective), besides the usual suspects
as Petr,
On 29/04/2022 13:04, Guilherme G. Piccoli wrote:
> On 27/04/2022 21:28, Randy Dunlap wrote:
>>
>>
>> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>>> + crash_kexec_post_notifiers
>>> + This was
On 05/05/2022 15:55, Hari Bathini wrote:
> [...]
> The change looks good. I have tested it on an LPAR (ppc64).
>
> Reviewed-by: Hari Bathini
>
Hi Michael. do you think it's possible to add this one to powerpc/next
(or something like that), or do you prefer a V2 with his tag?
Thanks,
On 27/04/2022 19:49, Guilherme G. Piccoli wrote:
> Currently we have 3 notifier lists in the panic path, which will
> be wired in a way to allow the notifier callbacks to run in
> different moments at panic time, in a subsequent patch.
>
> But there is also an odd set of arc
On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
>
> On 27/04/2022 23:49, Guilherme G. Piccoli wrote:
>> The panic notifier infrastructure executes registered callbacks when
>> a panic event happens - such callbacks are executed in atomic context,
>> wit
On 27/04/2022 19:48, Guilherme G. Piccoli wrote:
> In the panic path we have a list of functions to be called, the panic
> notifiers - such callbacks perform various actions in the machine's
> last breath, and sometimes users want them to run before kdump. We
> have t
On 04/05/2022 17:32, Thomas Bogendoerfer wrote:
> [...]
>
> applied to mips-next.
>
> Thomas.
>
Thanks a bunch Thomas =)
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 03/05/2022 14:44, Michael Kelley (LINUX) wrote:
> [...]
>>
>> Hi Michael, thanks for your feedback! I agree that your idea could work,
>> but...there is one downside: imagine the kmsg_dump() approach is not set
>> in some Hyper-V guest, then we would rely in the regular notification
>>
On 05/05/2022 15:55, Hari Bathini wrote:
> [...]
>
> The change looks good. I have tested it on an LPAR (ppc64).
>
> Reviewed-by: Hari Bathini
Thanks a bunch Hari, much appreciated!
___
kexec mailing list
kexec@lists.infradead.org
On 03/05/2022 14:31, Michael Kelley (LINUX) wrote:
> [...]
>
> To me, it's a weak correlation between having a kmsg dumper, and
> wanting or not wanting the info level output to come before kdump.
> Hyper-V is one of only a few places that register a kmsg dumper, so most
> Linux instances outside
On 03/05/2022 18:56, Evan Green wrote:
> Hi Guilherme,
> [...]
>> Do you agree with that, or prefer really a parameter in
>> gsmi_shutdown_reason() ? I'll follow your choice =)
>
> I'm fine with either, thanks for the link. Mostly I want to make sure
> other paths to gsmi_shutdown_reason()
On 03/05/2022 15:03, Evan Green wrote:
> [...]
> gsmi_shutdown_reason() is a common function called in other scenarios
> as well, like reboot and thermal trip, where it may still make sense
> to wait to acquire a spinlock. Maybe we should add a parameter to
> gsmi_shutdown_reason() so that you can
On 27/04/2022 19:49, 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.
>
>
On 03/05/2022 15:13, Michael Kelley (LINUX) wrote:
> [...]
>> (a) We could forget about this change, and always do the clean-up here,
>> not relying in machine_crash_shutdown().
>> Pro: really simple, behaves the same as it is doing currently.
>> Con: less elegant/concise, doesn't allow arm64
the change for the .spec file, which aims specific distros, by creating
RPM packages.
Cc: Coiby Xu
Cc: Kazuhito Hagio
Cc: Leonidas Spyropoulos
Signed-off-by: Guilherme G. Piccoli
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index cc6b0120aa7d
On 02/05/2022 12:38, Florian Fainelli wrote:
> [...]
>
> Acked-by: Florian Fainelli
>
> Not sure if the Fixes tag is warranted however as this is a clean up,
> and not really fixing a bug.
Perfect, thanks Florian. I'll add your ACK and remove the fixes tag in V2.
Cheers,
Guilherme
On 02/05/2022 12:38, Florian Fainelli wrote:
> [...]
> Acked-by: Florian Fainelli
>
> Likewise, I am not sure if the Fixes tag is necessary here.
Perfect Florian, thanks! I'll add your Acked-by tag and remove the
fixes for V2 =)
Cheers,
Guilherme
Hi Michael, first of all thanks for the great review, much appreciated.
Some comments inline below:
On 29/04/2022 14:16, Michael Kelley (LINUX) wrote:
> [...]
>> hypervisor I/O completion), so we postpone that to run late. But more
>> relevant: this *same* vmbus unloading happens in the
On 29/04/2022 18:45, Russell King (Oracle) wrote:
> [...]
>> Marc, I did some investigation in the code (and tried/failed in the ARM
>> documentation as well heh), but this is still not 100% clear for me.
>>
>> You're saying IPI calls disable IRQs/FIQs by default in the the target
>> CPUs? Where
Thanks Marc and Michael for the review/discussion.
On 29/04/2022 15:20, Marc Zyngier wrote:
> [...]
> My expectations would be that, since we're getting here using an IPI,
> interrupts are already masked. So what reenabled them the first place?
>
> Thanks,
>
> M.
>
Marc, I did some
On 27/04/2022 22:01, Xiaoming Ni wrote:
> [...]
> Duplicate Code.
>
> Is it better to use __func__ and %pS?
>
> pr_info("%s: %pS\n", __func__, n->notifier_call);
>
>
This is a great suggestion Xiaoming, much appreciated!
I feel like reinventing the wheel here - with your idea, code was super
On 29/04/2022 13:04, Max Filippov wrote:
> [...]
>> arch/xtensa/platforms/iss/setup.c | 4 ++--For xtensa:
>
> For xtensa:
> Acked-by: Max Filippov
>
Perfect, thanks Max!
Cheers,
Guilherme
___
kexec mailing list
kexec@lists.infradead.org
On 29/04/2022 15:46, Heiko Carstens wrote:
> [...]
>
> Code looks good, and everything still seems to work. I applied this
> internally for the time being, and if it passes testing, I'll schedule
> it for the next merge window.
>
> Thanks!
Perfect Heiko, thanks a bunch for your review and
On 28/04/2022 13:26, Corey Minyard wrote:
> [...]
>
> For the IPMI portion:
>
> Acked-by: Corey Minyard
Thanks Alex and Corey for the ACKs!
>
> Note that the IPMI panic_event() should always return, but it may take
> some time, especially if the IPMI controller is no longer functional.
> So
On 27/04/2022 21:28, Randy Dunlap wrote:
>
>
> On 4/27/22 15:49, Guilherme G. Piccoli wrote:
>> +crash_kexec_post_notifiers
>> +This was DEPRECATED - users should always prefer the
>
> This is DEPRECATED -
On 28/04/2022 13:55, Helge Deller wrote:
> [...]
> You may add:
> Acked-by: Helge Deller # parisc
>
> Helge
Thanks Helge, added!
Cheers,
Guilherme
>
>
>> ---
>> arch/parisc/include/asm/pdc.h | 1 +
>> arch/parisc/kernel/firmware.c | 27 +++
>>
On 28/04/2022 05:11, Suzuki K Poulose wrote:
> Hi Guilherme,
> [...]
> How would you like to proceed with queuing this ? I am happy
> either way. In case you plan to push this as part of this
> series (I don't see any potential conflicts) :
>
> Reviewed-by: Suzuki K Poulose
Thanks for your
Thanks Paul and Suzuki for the ACKs.
Cheers,
Guilherme
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 29/04/2022 10:23, Steven Rostedt wrote:
> On Fri, 29 Apr 2022 12:22:44 +0300
> Sergei Shtylyov wrote:
>
>>> + switch (ev) {
>>> + case DIE_OOPS:
>>> + do_dump = 1;
>>> + break;
>>> + case PANIC_NOTIFIER:
>>> + do_dump = 1;
>>> + break;
>>
>>
On 29/04/2022 14:53, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> 2022 3:49 PM
>> [...]
>> +panic_notifiers_level=
>> +[KNL] Set the panic notifiers execution order.
>> +Forma
On 29/04/2022 14:30, Michael Kelley (LINUX) wrote:
> From: Guilherme G. Piccoli Sent: Wednesday, April 27,
> 2022 3:49 PM
>> [...]
>>
>> @@ -2843,7 +2843,7 @@ static void __exit vmbus_exit(void)
>> if (ms_hyperv.misc_features & HV
On 29/04/2022 10:56, Steven Rostedt wrote:
> [...]
> No. The fallthrough keyword is only needed when there's code between case
> labels. As it is very common to list multiple cases for the same code path.
> That is:
>
> case DIE_OOPS:
> case PANIC_NOTIFIER:
> do_dump =
abling crash_kexec_post_notifiers"
Cc: Andrea Parri (Microsoft)
Cc: Dexuan Cui
Cc: Haiyang Zhang
Cc: "K. Y. Srinivasan"
Cc: Michael Kelley
Cc: Stephen Brennan
Cc: Stephen Hemminger
Cc: Tianyu Lan
Cc: Wei Liu
Tested-by: Fabio A M Martins
Signed-off-by: Guilherme G. Piccoli
--
: Richard Weinberger
Signed-off-by: Guilherme G. Piccoli
---
arch/um/kernel/um_arch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/kernel/um_arch.c b/arch/um/kernel/um_arch.c
index fc6e443299da..651310e3e86f 100644
--- a/arch/um/kernel/um_arch.c
+++ b/arch/um/kernel/um_arch.c
@@ -241,7
ystem")
Cc: Benjamin Herrenschmidt
Cc: Hari Bathini
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Paul Mackerras
Signed-off-by: Guilherme G. Piccoli
---
We'd like to thanks specially the MiniCloud infrastructure [0] maintainers,
that allow us to test PowerPC code in a very complete,
ring (which was also improved in the
refactor) from within arch code.
Fixes: 06e629c25daa ("powerpc/fadump: Fix inaccurate CPU state info in vmcore
generated with panic")
Cc: Benjamin Herrenschmidt
Cc: Hari Bathini
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Paul Mackerras
Signe
n.
We also moved its code to kernel/printk.c, it seems to make more
sense given it's related to printing stuff.
Suggested-by: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
.../admin-guide/kernel-parameters.txt | 12 +++-
Documentation/admin-guide/sysctl/kernel.rst | 5 +-
inc
lerman
Cc: Paul Mackerras
Cc: Pavel Machek
Cc: Richard Henderson
Cc: Richard Weinberger
Cc: Robert Richter
Cc: Stefano Stabellini
Cc: Stephen Hemminger
Cc: Sven Schnelle
Cc: Tony Luck
Cc: Vasily Gorbik
Cc: Wei Liu
Signed-off-by: Guilherme G. Piccoli
---
Notice that, with this
ut also very customizable.
[0] https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/
Suggested-by: Petr Mladek
Signed-off-by: Guilherme G. Piccoli
---
Special thanks to Petr and Baoquan for the suggestion and feedback in a previous
email thread. There's some important design decisions that worth men
patch.
Notice that the spinlock guarding kmsg_dumpers list also guards
increment/decrement of the dumper's counter, but there's no need
for that when reading the counter in the panic path, since that is
an atomic path and there's no other (planned) user.
Signed-off-by: Guilherme G. Piccoli
Leach
Cc: Mikko Perttunen
Cc: Neeraj Upadhyay
Cc: Nicholas Piggin
Cc: Paul Mackerras
Cc: Suzuki K Poulose
Cc: Thierry Reding
Cc: Thomas Bogendoerfer
Signed-off-by: Guilherme G. Piccoli
---
arch/arm64/kernel/setup.c | 2 +-
arch/mips/kernel/relocate.c
Cc: Tianyu Lan
Cc: Vasily Gorbik
Cc: Wang ShaoBo
Cc: Wei Liu
Cc: zhenwei pi
Signed-off-by: Guilherme G. Piccoli
---
arch/mips/sgi-ip22/ip22-reset.c | 2 +-
arch/mips/sgi-ip32/ip32-reset.c | 3 +--
arch/powerpc/kernel/setup-common.c | 2 +-
arch/sparc/kernel/sstate
be guarded as a tunable since
it can flood the kernel log buffer.
Cc: Arjan van de Ven
Cc: Cong Wang
Cc: Sebastian Andrzej Siewior
Cc: Valentin Schneider
Cc: Xiaoming Ni
Signed-off-by: Guilherme G. Piccoli
---
We have some design decisions that worth discussing here:
(a) First of call
changes the priority of the
notifier blocks, in order they run early compared to other
notifiers, to prevent useless trace data (like the callback
names for the other notifiers). Finally, we also removed an
unnecessary header inclusion.
Signed-off-by: Guilherme G. Piccoli
---
kerne
There is no users anymore of this variable that requires
it to be "exported" in the headers; also, it was deprecated
by the kernel parameter "panic_notifiers_level".
Signed-off-by: Guilherme G. Piccoli
---
include/linux/panic.h | 2 --
include/linux/panic_notif
the future will be moved to a new list, that encompass the
information notifiers only.
Fixes: 9eb60880d9a9 ("bus: brcmstb_gisb: add notifier handling")
Cc: Brian Norris
Cc: Florian Fainelli
Signed-off-by: Guilherme G. Piccoli
---
drivers/bus/brcmstb_gisb.c | 26 +++---
/ hardcoded approaches.
Cc: Alexander Gordeev
Cc: Christian Borntraeger
Cc: "David S. Miller"
Cc: Heiko Carstens
Cc: Sven Schnelle
Cc: Vasily Gorbik
Signed-off-by: Guilherme G. Piccoli
---
arch/s390/kernel/setup.c | 19 ++-
arch/sparc/kernel/setup_3
ingful
"id" over there.
Signed-off-by: Guilherme G. Piccoli
---
include/linux/panic_notifier.h | 5 +
kernel/panic.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/panic_notifier.h b/include/linux/panic_notifier.h
index 41e324
ordeev
Cc: Christian Borntraeger
Cc: Heiko Carstens
Cc: Sven Schnelle
Cc: Vasily Gorbik
Signed-off-by: Guilherme G. Piccoli
---
As a design choice, the option used here to verify a given spinlock is taken
was the function "spin_is_locked()" - but we noticed that it is not often used.
to make use 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: Helge Deller
Cc: "James E.J. Bottomley"
Signed-off-by: Guilherme
by the architecture one (that coredumps).
Also, we remove a useless header inclusion.
Cc: Anton Ivanov
Cc: Johannes Berg
Cc: Richard Weinberger
Signed-off-by: Guilherme G. Piccoli
---
arch/um/drivers/mconsole_kern.c | 8 +++-
arch/um/kernel/um_arch.c| 8
2 files changed, 7
with the regular mutex).
Fixes: 2227b7c74634 ("coresight: add support for CPU debug module")
Cc: Leo Yan
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Suzuki K Poulose
Signed-off-by: Guilherme G. Piccoli
---
drivers/hwtracing/coresight/coresight-cpu-debug.c | 7 ---
1 file changed, 4 insert
should expect more panic reliability
with this patch.
Cc: Benjamin Herrenschmidt
Cc: Hari Bathini
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Paul Mackerras
Signed-off-by: Guilherme G. Piccoli
---
We'd like to thanks specially the MiniCloud infrastructure [0] maintainers,
that allow us to test
nclude you but it was something
considered interesting by you.
Thanks in advance for reviews / comments / suggestions!
Cheers,
Guilherme
[0] https://lore.kernel.org/lkml/YfPxvzSzDLjO5ldp@alley/
Guilherme G. Piccoli (30):
x86/crash,reboot: Avoid re-disabling VMX in all CPUs on crash/restart
Many other place in the kernel prefer the latter, so let's keep
it consistent in MIPS code as well. Also, removes a useless header.
Cc: Thomas Bogendoerfer
Signed-off-by: Guilherme G. Piccoli
---
arch/mips/sgi-ip22/ip22-reset.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions
pport for S2/S3/S5 suspend
states (ARM)")
Cc: Brian Norris
Cc: Doug Berger
Cc: Florian Fainelli
Cc: Justin Chen
Cc: Lee Jones
Cc: Markus Mayer
Signed-off-by: Guilherme G. Piccoli
---
drivers/soc/bcm/brcmstb/pm/pm-arm.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletion
Green
Cc: Julius Werner
Signed-off-by: Guilherme G. Piccoli
---
drivers/firmware/google/gsmi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index adaa492c3d2d..b01ed02e4a87 100644
--- a/drivers/firmware/goo
enwei pi
Signed-off-by: Guilherme G. Piccoli
---
drivers/misc/pvpanic/pvpanic.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/pvpanic/pvpanic.c b/drivers/misc/pvpanic/pvpanic.c
index 4b8f1c7d726d..049a12006348 100644
--- a/drivers/misc/pvpanic/pvpanic.
i
Cc: Paolo Bonzini
Cc: Sean Christopherson
Signed-off-by: Guilherme G. Piccoli
---
arch/x86/include/asm/cpu.h | 1 +
arch/x86/kernel/crash.c| 8
arch/x86/kernel/reboot.c | 14 --
3 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include
secondary CPUs in the kexec/panic path as well.
Cc: Marc Zyngier
Cc: Russell King
Signed-off-by: Guilherme G. Piccoli
---
arch/arm/kernel/machine_kexec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index f567032a09c0
e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
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: Guilh
the same approach other architectures are doing.
Also, we remove the unnecessary include of a header already
included indirectly.
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: Richard Henderson
Signed-off-by: Guilherme G. Piccoli
---
arch/alpha/kernel/setup.c | 36
-by: Guilherme G. Piccoli
---
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 87069b8459af..0589896fc7bd 100644
--- a/include/linux/notifier.h
+++ b/include/linux/notifier.h
@@ -201,12
On 21/03/2022 13:32, Florian Fainelli wrote:
> [...]
> The AON (standing for always-on) is a small domain in the SoC that can
> retain its state across various system wide sleep states and specific
> reset conditions. The AON DATA RAM is a small ram of a few words (< 1KB)
> which can store
Hi Brian and Florian, I'm studying the panic notifiers and found one
added by you in the commit 0b741b8234c ("soc: bcm: brcmstb: Add support
for S2/S3/S5 suspend states (ARM)". Basically, the handler is very
simple and the only thing it does is:
/* from drivers/soc/bcm/brcmstb/pm/aon_defs.h */
On 20/03/2022 22:41, Coiby Xu wrote:
> [...]
>
> I believe some users have security concern for where to save vmcore.
> This use case exactly fits your description and your proposed solution
> shall be good for this type of users. But I think many more users may
> just choose to encrypt the hard
On 18/03/2022 07:34, Coiby Xu wrote:
> [...]
> Based on Milan's feedback [1] on Kairui's ideas to support kdump with
> LUKS encryption, this patch set addresses the above issues by
> 1) first saving the LUKS master key to kexec when opening the encrypted
> device
> 2) then saving the master
This patch fixes that by unconditionally unregistering the panic notifier
in the module's exit routine as well.
Fixes: 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")
Signed-off-by: Guilherme G. Piccoli
---
Hi folks, thanks in advance for any reviews! T
On 08/03/2022 09:54, Petr Mladek wrote:
> [...]
> Honestly, I am not that keen about enforcing the priorities.
>
> It would make sense only when the ordering is really important.
> Then there should be some rules. It should be obvious why
> something has to be done earlier than something else.
>
101 - 200 of 276 matches
Mail list logo