All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Ogness <john.ogness@linutronix.de>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Mike Galbraith <efault@gmx.de>
Cc: RT <linux-rt-users@vger.kernel.org>, Petr Mladek <pmladek@suse.com>
Subject: Re: v5.19-rc2-rt3: nouveau might sleep splat
Date: Mon, 25 Jul 2022 12:04:50 +0206	[thread overview]
Message-ID: <87h735ikdh.fsf@jogness.linutronix.de> (raw)
In-Reply-To: <Yt5RDajSVTPqahV4@linutronix.de>

On 2022-07-25, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> I remember asking why it is needed to disable interrupts across
> vsnprintf(). John, can I take this as-it or are you sending a new
> batch?

Mike's patch only addresses the vsnprintf() to print the prefix and get
the message length. There is also a vscnprintf() for the message itself,
which is still happening with interrupts disabled (see
printk_sprint()). I suppose this patch side-steps the splat because the
first vsnprintf() already triggered the random bytes for the pointer
hash.

I am preparing a new series that addresses this by completely removing
interrupt disabling from the printk() path. This required changes to the
printk_enter() macro, recursion handling, and the printk-ringbuffer
itself.

The focus of my new series are the various non-RT issues reported during
the early 5.19-rc cycles. I still need more time to get the series into
shape for LKML.

If Mike's patch is reliably side-stepping the issue, feel free to take
it.

>> Bandaid:
>> 
>> printk: fix RT vprintk_store() might sleep splat
>> 
>> RT can't call vsnprintf() with IRQs disabled, so disable migration
>> and move the printk_enter_irqsave() call down to where it's needed.

It might be worth mentioning that vscnprintf() is called later in
vprintk_store() when interrupts are disabled, but since it is s-printing
the same string (and probably the same values), new random bytes are not
required. (But someone should verify the reasoning here. I am not really
familiar with the crng code.)

John Ogness

  reply	other threads:[~2022-07-25  9:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-18  9:25 v5.19-rc2-rt3: nouveau might sleep splat Mike Galbraith
2022-06-24  8:42 ` Sebastian Andrzej Siewior
2022-06-24  9:52   ` Mike Galbraith
2022-06-24 10:18     ` Sebastian Andrzej Siewior
2022-06-24 10:19       ` Sebastian Andrzej Siewior
2022-06-24 14:30       ` John Ogness
2022-06-24 14:31         ` John Ogness
2022-06-24 14:39           ` Sebastian Andrzej Siewior
2022-06-25  3:26             ` Mike Galbraith
2022-07-21 13:06           ` Mike Galbraith
2022-07-25  8:15             ` Sebastian Andrzej Siewior
2022-07-25  9:58               ` John Ogness [this message]
2022-07-25 13:26                 ` Mike Galbraith
2022-08-03 16:10                 ` Petr Mladek
2022-08-05 14:23                   ` John Ogness

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h735ikdh.fsf@jogness.linutronix.de \
    --to=john.ogness@linutronix.de \
    --cc=bigeasy@linutronix.de \
    --cc=efault@gmx.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=pmladek@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.