On 2019-03-14, Petr Mladek wrote:
>>> I suggest the following way forward (separate patchsets):
>>>
>>> 1. Replace log buffer (least controversial thing)
>>
>> Yes. I will post a series that only implements the ringbuffer using
>> your simplified API. That will be enough to remove
On Wed 2019-03-13 18:27:59, Sergey Senozhatsky wrote:
> On (03/13/19 09:40), Sebastian Siewior wrote:
> > On 2019-03-13 09:19:32 [+0100], John Ogness wrote:
> > > recursive situation. As you are pointing out, the notification/wake
> > > component of printk_safe will still be needed. I will leave
On Tue 2019-03-12 16:15:55, John Ogness wrote:
> On 2019-03-12, Petr Mladek wrote:
> > On Tue 2019-03-12 09:17:49, John Ogness wrote:
> >> The current printk implementation is handling all console printing as
> >> best effort. Trying hard enough to dramatically affect the system, but
> >> not
On (03/13/19 18:27), Sergey Senozhatsky wrote:
> > Does this mean we keep irq_work part or we bury it and solve it by other
> > means?
>
> That's a very good question. Because if we add console_trylock()
> to printk(), then we can't invoke ->atomic() consoles when console_sem
> is already locked,
On (03/13/19 09:40), Sebastian Siewior wrote:
> On 2019-03-13 09:19:32 [+0100], John Ogness wrote:
> > recursive situation. As you are pointing out, the notification/wake
> > component of printk_safe will still be needed. I will leave that (small)
> > part in printk_safe.c.
>
> Does this mean we
On (03/13/19 09:19), John Ogness wrote:
> >> Yes. I will post a series that only implements the ringbuffer using
> >> your simplified API. That will be enough to remove printk_safe and
> >> actually does most of the work of updating devkmsg, kmsg_dump, and
> >> syslog.
> >
> > This may _not_ be
On 2019-03-13 09:19:32 [+0100], John Ogness wrote:
> recursive situation. As you are pointing out, the notification/wake
> component of printk_safe will still be needed. I will leave that (small)
> part in printk_safe.c.
Does this mean we keep irq_work part or we bury it and solve it by other
On 2019-03-13, Sergey Senozhatsky wrote:
>>> I suggest the following way forward (separate patchsets):
>>>
>>> 1. Replace log buffer (least controversial thing)
>>
>> Yes. I will post a series that only implements the ringbuffer using
>> your simplified API. That will be enough to remove
On (03/12/19 16:15), John Ogness wrote:
> > I suggest the following way forward (separate patchsets):
> >
> > 1. Replace log buffer (least controversial thing)
>
> Yes. I will post a series that only implements the ringbuffer using your
> simplified API. That will be enough to remove
On (03/12/19 13:38), Petr Mladek wrote:
> > Hmm. OK. So one of the things with printk is that it's fully sequential.
> > We call console drivers one by one. Slow consoles can affect what appears
> > on the fast consoles; fast console have no impact on slow ones.
> >
> > call_console_drivers()
On 2019-03-12, Petr Mladek wrote:
> Per-console kthread sounds interesting but there is the problem with
> reliability. I mean that kthread need not get scheduled.
>
> Some of these problems might get solved by the per-console loglevel
> patchset.
>
> Sigh, any feature might be useful in some
On Mon 2019-03-11 19:54:11, Sergey Senozhatsky wrote:
> On (03/07/19 10:53), John Ogness wrote:
> > Since all current console drivers are already irq safe, I'm
> > wondering if using irq_work to handle the emergency printing for console
> > drivers without write_atomic() would help. (If the printk
On (03/07/19 10:53), John Ogness wrote:
[..]
>
> No, I am not sure if we can convert all console drivers to atomic
> consoles. But I think if we don't have to fear disturbing the system,
> the possibilities for such an implementation are greater.
> > If there are setups which can be fully
On Thu 2019-03-07 10:53:48, John Ogness wrote:
> On 2019-03-04, Sergey Senozhatsky wrote:
> > If there are setups which can be fully !atomic (in terms of console
> > output) then we, essentially, have a fully preemptible kthread printk
> > implementation.
>
> Correct. I've mentioned in another
On 2019-03-04, Sergey Senozhatsky wrote:
- A dedicated kernel thread is created for printing to all consoles
in a fully preemptible context.
>>>
>>> How do you handle sysrq- printouts on systems which can't
>>> schedule printk-kthread?
>>
>> If those sysrq printouts are at the
Hi John,
On (02/13/19 14:43), John Ogness wrote:
> Hi Sergey,
>
> I am glad to see that you are getting involved here. Your previous
> talks, work, and discussions were a large part of my research when
> preparing for this work.
YAYY! Thanks!
That's a pretty massive research and a patch set!
On (02/13/19 15:15), John Ogness wrote:
> I don't like bust_spinlocks() because drivers end up implementing
> oops_in_progress with exactly that... ignoring their own locks. I prefer
> consoles are provided with a locking mechanism that they can use to
> support a separate NMI-safe write function.
On (02/13/19 15:43), John Ogness wrote:
> On 2019-02-13, Sergey Senozhatsky wrote:
> >> - A dedicated kernel thread is created for printing to all consoles in
> >> a fully preemptible context.
> >
> > How do you handle sysrq- printouts on systems which can't
> > schedule printk-kthread?
>
> If
On 2019-02-13, David Laight wrote:
> ...
>> - A dedicated kernel thread is created for printing to all consoles in
>> a fully preemptible context.
>>
>> - A new (optional) console operation "write_atomic" is introduced that
>> console drivers may implement. This function must be NMI-safe. An
From: John Ogness
> Sent: 12 February 2019 14:30
...
> - A dedicated kernel thread is created for printing to all consoles in
> a fully preemptible context.
>
> - A new (optional) console operation "write_atomic" is introduced that
> console drivers may implement. This function must be
On 2019-02-13, Sergey Senozhatsky wrote:
>> - A dedicated kernel thread is created for printing to all consoles in
>> a fully preemptible context.
>
> How do you handle sysrq- printouts on systems which can't
> schedule printk-kthread?
If those sysrq printouts are at the emergency loglevel
On 2019-02-13, Sergey Senozhatsky wrote:
>> - console_flush_on_panic() currently is a NOP. It is pretty clear how
>> this could be implemented if atomic_write was available. But if no
>> such console is registered, it is not clear what should be done. Is
>> this function really even needed?
Hi Sergey,
I am glad to see that you are getting involved here. Your previous
talks, work, and discussions were a large part of my research when
preparing for this work.
My response to your comments inline...
On 2019-02-13, Sergey Senozhatsky wrote:
> On (02/12/19 15:29), John Ogness wrote:
>>
On (02/12/19 15:29), John Ogness wrote:
>
> - A dedicated kernel thread is created for printing to all consoles in
> a fully preemptible context.
How do you handle sysrq- printouts on systems which can't
schedule printk-kthread?
-ss
On (02/12/19 15:29), John Ogness wrote:
> - console_flush_on_panic() currently is a NOP. It is pretty clear how
> this could be implemented if atomic_write was available. But if no
> such console is registered, it is not clear what should be done. Is
> this function really even needed?
If
On (02/12/19 15:29), John Ogness wrote:
>
> 1. The printk buffer is protected by a global raw spinlock for readers
>and writers. This restricts the contexts that are allowed to
> access the buffer.
[..]
> 2. Because of #1, NMI and recursive contexts are handled by deferring
>
Hello,
As probably many of you are aware, the current printk implementation
has some issues. This series (against 5.0-rc6) makes some fundamental
changes in an attempt to address these issues. The particular issues I
am referring to:
1. The printk buffer is protected by a global raw spinlock for
27 matches
Mail list logo
