On (07/31/19 15:08), Sergey Senozhatsky wrote:
> When you have a chance, mind to take a look at the patch below?
> Doesn't look very difficult (half of it are white-spaces and
> comments, I believe).
I'm very sorry for annoyance.
Updated version:
-- passes !PRINTK build
-- moved
Sorry for the delayed response.
On (07/24/19 14:27), Petr Mladek wrote:
[..]
> > And this is where the idea of "disconnecting" those CPUs from main
> > logbuf come from.
> >
> > So what we can do:
> > - smp_send_stop()
> > - disconnect all-but-self from logbuf (via printk-safe)
>
> printk_safe
On Tue 2019-07-23 12:13:40, Sergey Senozhatsky wrote:
> On (07/19/19 14:57), Petr Mladek wrote:
> > But there is one more scenario 3:
>
> Yes!
>
> > - we have CPUB which loops or is deadlocked in IRQ context
> >
> > - we have CPUA which panic()-s the system, but can't bring CPUB down,
> >
On (07/19/19 14:57), Petr Mladek wrote:
[..]
> > Where do nested printk()-s come from? Which one of the following
> > scenarios you cover in commit message:
> >
> > scenario 1
> >
> > - we have CPUB which holds logbuf_lock
> > - we have CPUA which panic()-s the system, but can't bring CPUB down,
On Thu 2019-07-18 18:49:34, Sergey Senozhatsky wrote:
> On (07/18/19 10:36), Petr Mladek wrote:
> > On Wed 2019-07-17 18:56:15, Sergey Senozhatsky wrote:
> > > On (07/16/19 09:28), Petr Mladek wrote:
> > > > Kernel tries hard to store and show printk messages when panicking. Even
> > > >
On (07/16/19 09:28), Petr Mladek wrote:
[..]
> +int printk_bust_lock_safe(void)
> +{
> + if (!raw_spin_is_locked(_lock))
> + return 0;
> +
> + if (num_online_cpus() == 1) {
> + debug_locks_off();
> + raw_spin_lock_init(_lock);
> + return 0;
>
On (07/18/19 10:36), Petr Mladek wrote:
> On Wed 2019-07-17 18:56:15, Sergey Senozhatsky wrote:
> > On (07/16/19 09:28), Petr Mladek wrote:
> > > Kernel tries hard to store and show printk messages when panicking. Even
> > > logbuf_lock gets re-initialized when only one CPU is running after
> > >
On Wed 2019-07-17 18:56:15, Sergey Senozhatsky wrote:
> On (07/16/19 09:28), Petr Mladek wrote:
> > Kernel tries hard to store and show printk messages when panicking. Even
> > logbuf_lock gets re-initialized when only one CPU is running after
> > smp_send_stop().
> >
> > Unfortunately,
On (07/16/19 09:28), Petr Mladek wrote:
> Kernel tries hard to store and show printk messages when panicking. Even
> logbuf_lock gets re-initialized when only one CPU is running after
> smp_send_stop().
>
> Unfortunately, smp_send_stop() might fail on architectures that do not
> use NMI as a
Kernel tries hard to store and show printk messages when panicking. Even
logbuf_lock gets re-initialized when only one CPU is running after
smp_send_stop().
Unfortunately, smp_send_stop() might fail on architectures that do not
use NMI as a fallback. Then printk log buffer might stay locked and
a
10 matches
Mail list logo
