On 6/12/19 1:00 PM, Petr Mladek wrote:
> On Wed 2019-06-12 17:36:43, Sergey Senozhatsky wrote:
>> On (06/06/19 09:10), Petr Mladek wrote:
>>> Just to be sure. I wanted to say that I like the idea with
>>> KERN_UNSUPRESSED. So, I think that we are on the same page.
>>
>> I understand. All I wanted
On Wed 2019-06-12 17:36:43, Sergey Senozhatsky wrote:
> On (06/06/19 09:10), Petr Mladek wrote:
> > Just to be sure. I wanted to say that I like the idea with
> > KERN_UNSUPRESSED. So, I think that we are on the same page.
>
> I understand. All I wanted to say is that KERN_UNSUPRESSED is
>
On 2019/06/12 0:10, Petr Mladek wrote:
> On Sat 2019-06-08 11:45:45, Tetsuo Handa wrote:
>> On 2019/06/08 2:09, Pavel Machek wrote:
>>> On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
On 2019/05/28 17:51, Sergey Senozhatsky wrote:
>> You are trying to omit passing KERN_UNSUPPRESSED by
On (06/06/19 09:10), Petr Mladek wrote:
> > > > > > Provide KERN_UNSUPPRESSED printk() annotation for such legacy
> > > > > > places.
> > > > > > Make sysrq print the headers unsuppressed instead of changing
> > > > > > console_loglevel.
> > >
> > > I like this idea. console_loglevel is
On Sat 2019-06-08 11:45:45, Tetsuo Handa wrote:
> On 2019/06/08 2:09, Pavel Machek wrote:
> > On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
> >> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit
> printk
>
On 2019/06/08 2:09, Pavel Machek wrote:
> On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
>> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit
printk
context information. But doesn't such attempt resemble
On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
> >> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit
> >> printk
> >> context information. But doesn't such attempt resemble
> >> find_printk_buffer() ?
> >
> > Adding
On Mon 2019-06-03 15:51:53, Sergey Senozhatsky wrote:
> On (05/28/19 15:42), Petr Mladek wrote:
> > On Tue 2019-05-28 13:46:19, Sergey Senozhatsky wrote:
> > > On (05/28/19 13:15), Sergey Senozhatsky wrote:
> > > > On (05/28/19 01:24), Dmitry Safonov wrote:
> > > > [..]
> > > > > While handling
On (05/28/19 15:42), Petr Mladek wrote:
> On Tue 2019-05-28 13:46:19, Sergey Senozhatsky wrote:
> > On (05/28/19 13:15), Sergey Senozhatsky wrote:
> > > On (05/28/19 01:24), Dmitry Safonov wrote:
> > > [..]
> > > > While handling sysrq the console_loglevel is bumped to default to print
> > > >
On 2019/05/28 22:42, Petr Mladek wrote:
> On Tue 2019-05-28 13:46:19, Sergey Senozhatsky wrote:
>> On (05/28/19 13:15), Sergey Senozhatsky wrote:
>>> On (05/28/19 01:24), Dmitry Safonov wrote:
>>> [..]
While handling sysrq the console_loglevel is bumped to default to print
sysrq headers.
Hi guys,
I see that the thread is ongoing and you understand printk code much
better than me or probably anybody :)
So, feel free to reuse it. Or I can send v1 with split sysrq/printk
parts if you think it's worth being shaped further.
I think worth to mention three "features" that you might
On 2019/05/29 0:03, Petr Mladek wrote:
>> But is context dependent buffer large enough to hold SysRq-t output?
>> I think that only main logbuf can become large enough to hold SysRq-t output.
>
> SysRq messages are stored directly into the main log buffer.
>
> The limited per-CPU buffers are
On Tue 2019-05-28 23:21:17, Tetsuo Handa wrote:
> On 2019/05/28 22:42, Petr Mladek wrote:
> >> Ahh.. OK, now I sort of remember why I gave up on this idea (see [1]
> >> at the bottom, when it comes to uv_nmi_dump_state()) - printk_NMI and
> >> printk-safe redirections.
> >>
> >>NMI
> >>
On 2019/05/28 22:42, Petr Mladek wrote:
>> Ahh.. OK, now I sort of remember why I gave up on this idea (see [1]
>> at the bottom, when it comes to uv_nmi_dump_state()) - printk_NMI and
>> printk-safe redirections.
>>
>> NMI
>> loglevel = NEW
>> printk ->
On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
> >> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit
> >> printk
> >> context information. But doesn't such attempt resemble
> >> find_printk_buffer() ?
> >
> > Adding
On Tue 2019-05-28 13:46:19, Sergey Senozhatsky wrote:
> On (05/28/19 13:15), Sergey Senozhatsky wrote:
> > On (05/28/19 01:24), Dmitry Safonov wrote:
> > [..]
> > > While handling sysrq the console_loglevel is bumped to default to print
> > > sysrq headers. It's done to print sysrq messages with
On 2019/05/28 17:51, Sergey Senozhatsky wrote:
>> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit printk
>> context information. But doesn't such attempt resemble find_printk_buffer() ?
>
> Adding KERN_UNSUPPRESSED to all printks down the op_p->handler()
> line is hardly
On (05/28/19 17:02), Tetsuo Handa wrote:
> On 2019/05/28 13:22, Sergey Senozhatsky wrote:
> > On (05/28/19 12:21), Tetsuo Handa wrote:
> > [..]
> Dmitry's patch is changing only the header line (in other words, per printk()
> call).
> Since op_p->handler(key) is out of KERN_UNSUPPRESSED effect,
On 2019/05/28 13:22, Sergey Senozhatsky wrote:
> On (05/28/19 12:21), Tetsuo Handa wrote:
> [..]
>> What I suggested in my proposal ("printk: Introduce "store now but print
>> later" prefix." at
>>
On (05/28/19 13:15), Sergey Senozhatsky wrote:
> On (05/28/19 01:24), Dmitry Safonov wrote:
> [..]
> > While handling sysrq the console_loglevel is bumped to default to print
> > sysrq headers. It's done to print sysrq messages with WARNING level for
> > consumers of /proc/kmsg, though it sucks by
On (05/28/19 12:21), Tetsuo Handa wrote:
[..]
> What I suggested in my proposal ("printk: Introduce "store now but print
> later" prefix." at
> https://lore.kernel.org/lkml/1550896930-12324-1-git-send-email-penguin-ker...@i-love.sakura.ne.jp/T/#u
> )
> is "whether the caller wants to defer
On (05/28/19 01:24), Dmitry Safonov wrote:
[..]
> While handling sysrq the console_loglevel is bumped to default to print
> sysrq headers. It's done to print sysrq messages with WARNING level for
> consumers of /proc/kmsg, though it sucks by the following reasons:
> - changing console_loglevel may
On 2019/05/28 9:24, Dmitry Safonov wrote:
> Provide KERN_UNSUPPRESSED printk() annotation for such legacy places.
> Make sysrq print the headers unsuppressed instead of changing
> console_loglevel.
I think that kdb also wants to use KERN_UNSUPPRESSED for making sure
that messages are printed. But
While handling sysrq the console_loglevel is bumped to default to print
sysrq headers. It's done to print sysrq messages with WARNING level for
consumers of /proc/kmsg, though it sucks by the following reasons:
- changing console_loglevel may produce tons of messages (especially on
bloated with
24 matches
Mail list logo
