On Thu 2018-11-29 19:09:26, Tetsuo Handa wrote:
> On 2018/11/28 22:29, David Laight wrote:
> > I also spent a week trying to work out why a customer kernel was
> > locking up - only to finally find out that the distro they were
> > using set 'panic on opps' - making it almost impossible to find
> >
On 2018/11/28 22:29, David Laight wrote:
> I also spent a week trying to work out why a customer kernel was
> locking up - only to finally find out that the distro they were
> using set 'panic on opps' - making it almost impossible to find
> out what was happening.
How can line buffering negativel
From: Steven Rostedt
> > Steven told me on Plumbers conference that even few initial
> > characters saved him a day few times.
>
> Yes, and that has happened more than once. I would reboot and retest
> code that is crashing, and due to a triple fault, the machine would
> reboot because of some rac
On (11/24/18 09:24), Tetsuo Handa wrote:
> >> Steven told me on Plumbers conference that even few initial
> >> characters saved him a day few times.
> >
> > Yes, and that has happened more than once. I would reboot and retest
> > code that is crashing, and due to a triple fault, the machine would
On 2018/11/24 0:56, Steven Rostedt wrote:
> On Fri, 23 Nov 2018 13:46:47 +0100
> Petr Mladek wrote:
>
>> Steven told me on Plumbers conference that even few initial
>> characters saved him a day few times.
>
> Yes, and that has happened more than once. I would reboot and retest
> code that is cr
On Fri, 23 Nov 2018 13:46:47 +0100
Petr Mladek wrote:
> Steven told me on Plumbers conference that even few initial
> characters saved him a day few times.
Yes, and that has happened more than once. I would reboot and retest
code that is crashing, and due to a triple fault, the machine would
reb
On 2018/11/23 21:46, Petr Mladek wrote:
> I am more and more wondering if the buffered printk is worth
> the effort. The more buffers we use the more we risk that nobody
> would see some important message. Even a part of the line
> might be crucial in some situations.
>
> Steven told me on Plumber
On Sat 2018-11-10 17:52:17, Tetsuo Handa wrote:
> On 2018/11/10 0:43, Petr Mladek wrote:
> > On Fri 2018-11-09 18:55:26, Tetsuo Handa wrote:
> >> How early_printk requirement affects line buffered printk() API?
> >>
> >> I don't think it is impossible to convert from
> >>
> >> printk("Testing
On Sat 2018-11-10 11:42:03, Tetsuo Handa wrote:
> On 2018/11/10 0:43, Petr Mladek wrote:
> >> + * Line buffered printk() tries to assign a buffer when printk() from a
> >> new
> >> + * context identifier comes in. And it automatically releases that buffer
> >> when
> >> + * one of three condition
On 2018/11/10 0:43, Petr Mladek wrote:
> On Fri 2018-11-09 18:55:26, Tetsuo Handa wrote:
>> How early_printk requirement affects line buffered printk() API?
>>
>> I don't think it is impossible to convert from
>>
>> printk("Testing feature XYZ..");
>> this_may_blow_up_because_of_hw_bugs()
On 2018/11/10 0:43, Petr Mladek wrote:
>> + * Line buffered printk() tries to assign a buffer when printk() from a new
>> + * context identifier comes in. And it automatically releases that buffer
>> when
>> + * one of three conditions listed below became true.
>> + *
>> + * (1) printk() from th
On Fri 2018-11-09 18:55:26, Tetsuo Handa wrote:
> On 2018/11/09 15:12, Sergey Senozhatsky wrote:
> > On (11/08/18 20:37), Tetsuo Handa wrote:
> > > On 2018/11/08 13:45, Sergey Senozhatsky wrote:
> How early_printk requirement affects line buffered printk() API?
>
> I don't think it is impossible t
On Fri, 9 Nov 2018 08:08:13 -0600
Linus Torvalds wrote:
> You guys seem to be talking it out
> ok.
Do your new filters not only remove words, but also add text?
;-)
-- Steve
On Fri, Nov 9, 2018 at 12:12 AM Sergey Senozhatsky
wrote:
>
> Dunno. I guess we still haven't heard from Linus because he did quite a good
> job setting up his 'email filters' ;)
Not filters, just long threads that I lurk on.
I don't actually care too much about this - the part I care about is
t
On 2018/11/09 15:12, Sergey Senozhatsky wrote:
> On (11/08/18 20:37), Tetsuo Handa wrote:
> > On 2018/11/08 13:45, Sergey Senozhatsky wrote:
> > > So, can we just do the following? /* a sketch */
> > >
> > > lockdep.c
> > > printk_safe_enter_irqsave(flags);
> > > lockdep_report();
> > > prin
On 2018/11/08 0:19, Petr Mladek wrote:
> I really hope that the maze of pr_cont() calls in lockdep.c is the most
> complicated one that we would meet.
>
> Anyway, the following comes to my mind:
>
> 1. The mixing of normal and buffered printk calls is a bit confusing
>and error prone. It woul
On (11/08/18 20:37), Tetsuo Handa wrote:
> On 2018/11/08 13:45, Sergey Senozhatsky wrote:
> > So, can we just do the following? /* a sketch */
> >
> > lockdep.c
> > printk_safe_enter_irqsave(flags);
> > lockdep_report();
> > printk_safe_exit_irqrestore(flags);
>
> If buffer size were
On (11/08/18 21:44), Sergey Senozhatsky wrote:
>
> If lockdep and OOM people will ACK buffered printk transition in
> its current form, then we can go ahead.
That printk_safe approach in lockdep, BTW, does not change (convert)
any printk-s within lockdep, thus Peter's earlycon should not be
affec
On (11/08/18 12:53), Petr Mladek wrote:
> > lockdep.c
> > printk_safe_enter_irqsave(flags);
> > lockdep_report();
> > printk_safe_exit_irqrestore(flags);
>
> All this looks nice. Let's look it also from the other side.
> The following comes to my mind:
>
> a) lockdep is not the only p
On Thu 2018-11-08 13:45:10, Sergey Senozhatsky wrote:
> On (11/07/18 16:19), Petr Mladek wrote:
> > I really hope that the maze of pr_cont() calls in lockdep.c is the most
> > complicated one that we would meet.
>
> Hmm... Yes, buffered/seq_buf printk looks like a hard-to-use API,
> when it comes
On 2018/11/08 13:45, Sergey Senozhatsky wrote:
> So, can we just do the following? /* a sketch */
>
> lockdep.c
> printk_safe_enter_irqsave(flags);
> lockdep_report();
> printk_safe_exit_irqrestore(flags);
If buffer size were large enough to hold messages from out_of_memory(),
I
On (11/07/18 16:19), Petr Mladek wrote:
> > syzbot is sometimes getting mixed output like below due to concurrent
> > printk(). Mitigate such output by using line-buffered printk() API.
> >
> > @@ -2421,18 +2458,20 @@ static void check_chain_key(struct task_struct
> > *curr)
> > print_usage_bug_
On Fri 2018-11-02 22:31:57, Tetsuo Handa wrote:
> syzbot is sometimes getting mixed output like below due to concurrent
> printk(). Mitigate such output by using line-buffered printk() API.
>
> @@ -2421,18 +2458,20 @@ static void check_chain_key(struct task_struct *curr)
> print_usage_bug_scenari
On Tue 2018-11-06 18:05:44, Sergey Senozhatsky wrote:
> On (11/06/18 09:38), Petr Mladek wrote:
> >
> > If you would want to avoid buffering, you could set the number
> > of buffers to zero. Then it would always fallback to
> > the direct printk().
This comment was a hint for Peter and his workar
On 2018/11/06 17:38, Petr Mladek wrote:
> If you would want to avoid buffering, you could set the number
> of buffers to zero. Then it would always fallback to
> the direct printk().
1 lock held by swapper/1/0:
#0:
(
rcu_read_lock
){}
, at: trace_call_bpf+0xf8/0x640 kernel/trace
On (11/06/18 09:38), Petr Mladek wrote:
>
> If you would want to avoid buffering, you could set the number
> of buffers to zero. Then it would always fallback to
> the direct printk().
This printk-fallback makes me wonder if 'cont' really can ever go away.
We would totally break cont printk-s tha
On Fri 2018-11-02 14:36:29, Peter Zijlstra wrote:
> On Fri, Nov 02, 2018 at 10:31:57PM +0900, Tetsuo Handa wrote:
> > syzbot is sometimes getting mixed output like below due to concurrent
> > printk(). Mitigate such output by using line-buffered printk() API.
> >
> > RCU used illegally from idle
On 2018/11/02 22:36, Peter Zijlstra wrote:
> On Fri, Nov 02, 2018 at 10:31:57PM +0900, Tetsuo Handa wrote:
>> syzbot is sometimes getting mixed output like below due to concurrent
>> printk(). Mitigate such output by using line-buffered printk() API.
>>
>> RCU used illegally from idle CPU!
>> r
On Fri, Nov 02, 2018 at 10:31:57PM +0900, Tetsuo Handa wrote:
> syzbot is sometimes getting mixed output like below due to concurrent
> printk(). Mitigate such output by using line-buffered printk() API.
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 2, debug_locks = 1
> RSP:
syzbot is sometimes getting mixed output like below due to concurrent
printk(). Mitigate such output by using line-buffered printk() API.
RCU used illegally from idle CPU!
rcu_scheduler_active = 2, debug_locks = 1
RSP: 0018:88007bb8 EFLAGS: 0286
RCU used illegally from extended
30 matches
Mail list logo
