At 2022-07-21 10:49:40, "Baoquan He" wrote:
>On 07/21/22 at 09:56am, Slark Xiao wrote:
>> Fix typo in the comment
>
>Better tell what's fixed to save reviewers' time:
>
>Fix typo 'the the' in several places of document.
>
>Other then this nitpick, looks good to me.
>
>Reviewed-by: Baoquan He
On 07/21/22 at 09:56am, Slark Xiao wrote:
> Fix typo in the comment
Better tell what's fixed to save reviewers' time:
Fix typo 'the the' in several places of document.
Other then this nitpick, looks good to me.
Reviewed-by: Baoquan He
>
> Signed-off-by: Slark Xiao
> ---
> v2: Add all .rst
Fix typo in the comment
Signed-off-by: Slark Xiao
---
v2: Add all .rst changes in Documents into 1 single patch
---
Documentation/admin-guide/kdump/vmcoreinfo.rst| 2 +-
Documentation/bpf/map_cgroup_storage.rst | 4 ++--
Documentation/core-api/cpu_hotplug.rst| 2 +-
On 07/20/22 at 02:08pm, Eric DeVolder wrote:
> Baoquan,
> I believe I've addressed all feedback, just checking to see if you agree.
> I have the next patch set ready in the event you think it a good idea to post
> it.
> Thanks!
Thanks for the effort. Please post them for reviewing. The newly
Baoquan,
I believe I've addressed all feedback, just checking to see if you agree.
I have the next patch set ready in the event you think it a good idea to post
it.
Thanks!
eric
On 7/7/22 08:05, Eric DeVolder wrote:
On 7/5/22 20:16, Baoquan He wrote:
On 07/05/22 at 10:17am, Eric DeVolder
> From: Stefan Berger
> Sent: 07 July 2022 10:50 PM
> To: kexec@lists.infradead.org; devicet...@vger.kernel.org;
> linux-integr...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org
> Cc: na...@linux.ibm.com; Nageswara R
> From: Stefan Berger
> Sent: 07 July 2022 10:50 PM
> To: kexec@lists.infradead.org; devicet...@vger.kernel.org;
> linux-integr...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org
> Cc: na...@linux.ibm.com; Nageswara R
> From: Stefan Berger
> Sent: 07 July 2022 10:50 PM
> To: kexec@lists.infradead.org; devicet...@vger.kernel.org;
> linux-integr...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org
> Cc: na...@linux.ibm.com; Nageswara R
> From: Stefan Berger
> Sent: 07 July 2022 10:50 PM
> To: kexec@lists.infradead.org; devicet...@vger.kernel.org;
> linux-integr...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org
> Cc: na...@linux.ibm.com; Nageswara R
> From: Stefan Berger
> Sent: 07 July 2022 10:50 PM
> To: kexec@lists.infradead.org; devicet...@vger.kernel.org;
> linux-integr...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org
> Cc: na...@linux.ibm.com; Nageswara R
> From: Stefan Berger
> Sent: 07 July 2022 10:50 PM
> To: kexec@lists.infradead.org; devicet...@vger.kernel.org;
> linux-integr...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linuxppc-...@lists.ozlabs.org
> Cc: na...@linux.ibm.com; Nageswara R
Fix typo in the comment
Signed-off-by: Slark Xiao
---
Documentation/admin-guide/kdump/vmcoreinfo.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index
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' callback names;
>
>
> I'm
Currently Hyper-V guests are among the most relevant users of the panic
infrastructure, like panic notifiers, kmsg dumpers, etc. The reasons rely
both in cleaning-up procedures (closing hypervisor <-> guest connection,
disabling some paravirtualized timer) as well as to data collection
(sending
Hi Guilherme,
On Tue, 19 Jul 2022 16:53:20 -0300
"Guilherme G. Piccoli" wrote:
> The panic notifiers' callbacks execute in an atomic context, with
> interrupts/preemption disabled, and all CPUs not running the panic
> function are off, so it's very dangerous to wait on a regular
>
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 improved, since it's a
special case (userspace), hence we could run the
The panic notifier of this driver is very simple code-wise, just a
memory write to a special position with some numeric code. But this
is not clear from the semantic point-of-view, and there is no public
documentation about that either.
After discussing this in the mailing-lists [0] and having
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' callback names;
(b) Adding a dynamic debug tuning to allow showing called notifiers'
function names. Notice that this should be guarded
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 function takes a spinlock for the
ring buffer operations.
Panic path runs in
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
Cc: Sebastian Andrzej Siewior
Cc: Valentin Schneider
Cc: Xiaoming Ni
Signed-off-by:
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 all secondary CPUs (not executing
the panic path) are shutdown.
With that
The panic notifiers' callbacks execute in an atomic context, with
interrupts/preemption disabled, and all CPUs not running the panic
function are off, so it's very dangerous to wait on a regular
spinlock, there's a risk of deadlock.
Refactor the panic notifier of parisc/power driver to make use
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.
So, let's clean the code and set the notifier to run as the
latest, following the
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' callback names;
I'm not yet convinced that this is the right direction.
The
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
for these events (and that shouldnt' need to be conditional on a config option)
that's not what the patch
Hi folks, this the second iteration of the panic notifiers refactor work,
but limited to the fixes/clean-ups in the first moment. The (full) V1 is
available at:
https://lore.kernel.org/lkml/20220427224924.592546-1-gpicc...@igalia.com/
The idea of splitting the series is that, originally we had a
On 7/19/2022 1:44 PM, Guilherme G. Piccoli wrote:
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
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!
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 that the panic_print
handling happens after the secondary CPUs are already disabled,
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, since the panic path runs in atomic
context, with interrupts/preemption
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 comment and change the priority of
the notifier to make it execute earlier, avoiding
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 FIQs are high priority than IRQs, hence they
aren't masked. With that said,
32 matches
Mail list logo
