On 2018/11/12 16:59, Sergey Senozhatsky wrote:
> On (11/09/18 15:10), Petr Mladek wrote:
>>>
>>> If I'm not mistaken, this is for the futute "printk injection" work.
>>
>> The above code only tries to push complete lines to the main log buffer
>> and consoles ASAP. It sounds like a Good Idea(tm).
>
On 2018/11/12 16:59, Sergey Senozhatsky wrote:
> Tetsuo, lockdep report with buffered printks looks a bit different:
>
> kernel: Possible unsafe locking scenario:
> kernel:CPU0CPU1
> kernel:
> kernel: lock(bar_lock);
> kernel:
On (11/09/18 15:10), Petr Mladek wrote:
> >
> > If I'm not mistaken, this is for the futute "printk injection" work.
>
> The above code only tries to push complete lines to the main log buffer
> and consoles ASAP. It sounds like a Good Idea(tm).
Probably it is. So *quite likely* I'm wrong here.
On Thu 2018-11-08 21:30:49, Sergey Senozhatsky wrote:
> On (11/08/18 12:24), Petr Mladek wrote:
> > > - It seems that buffered printk attempts to solve too many problems.
> > > I'd prefer it to address just one.
> >
> > This API tries to handle continuous lines more reliably.
> > Do I miss anyth
On (11/08/18 12:24), Petr Mladek wrote:
> I believe that I mentioned this more times. 16 buffers is the first
> attempt. We could improve it later in several ways
Sure. Like I said - maybe it is a normal development pattern; I really
don't know.
> > Let's have one more look at what we will fix an
On 2018/11/08 20:24, Petr Mladek wrote:
>> Let's have one more look at what we will fix and what we will break.
>>
>> 'cont' has premature flushes.
>>
>> Why is it good.
>> It preserves the correct order of events.
>>
>> pr_cont("calling foo->init()");
>> foo->init()
>>printk("Can't
On Thu 2018-11-08 11:21:38, Sergey Senozhatsky wrote:
> On (11/07/18 11:21), Petr Mladek wrote:
> What is the problem:
> - we have tons of CPUs, with tons of tasks running on them, with preemption,
> and interrupts, and potentially printk-s coming from various
> contexts/CPUs/tasks etc. so one
On (11/07/18 19:52), Tetsuo Handa wrote:
> > A question.
> >
> > How bad would it actually be to:
> >
> > - Allocate seq_buf 512-bytes buffer (GFP_ATOMIC) just-in-time, when we
> > need it.
> > // How often systems cannot allocate a 512-byte buffer? //
>
> It is a very bad thing to do GFP_
On (11/07/18 11:21), Petr Mladek wrote:
> > [..]
> > - The printk-fallback sounds like a hint that the existing 'cont' handling
> > better stay in the kernel. I don't see how the existing 'cont' is
> > significantly worse than
> > bpr_warn(NULL, ...)->printk() // no 'cont' support
>
On Fri 2018-11-02 22:31:55, Tetsuo Handa wrote:
> How to use this API:
>
> (1) Call get_printk_buffer() and acquire "struct printk_buffer *".
>
> (2) Rewrite printk() calls in the following way. The "ptr" is
> "struct printk_buffer *" obtained in step (1).
>
> printk(fmt, ...)
On Fri 2018-11-02 22:31:55, Tetsuo Handa wrote:
> Sometimes we want to print a whole line without being disturbed by
> concurrent printk() from interrupts and/or other threads, for printk()
> which does not end with '\n' can be disturbed.
>
> Since mixed printk() output makes it hard to interpret,
On 2018/11/07 19:21, Petr Mladek wrote:
> On Tue 2018-11-06 23:35:02, Sergey Senozhatsky wrote:
>>> Since we want to remove "struct cont" eventually, we will try to remove
>>> both "implicit printk() users who are expecting KERN_CONT behavior" and
>>> "explicit pr_cont()/printk(KERN_CONT) users". T
On Wed 2018-11-07 11:01:05, David Laight wrote:
> From: Tetsuo Handa
> > Sent: 07 November 2018 10:53
> A though:
>
> Why not make the printf lock slightly 'sticky'?
> - If the output line is incomplete save the cpuid.
> - If there is a saved cpuid that doesn't match the current cpu then spin for
On Wed 2018-11-07 19:52:53, Tetsuo Handa wrote:
> On 2018/11/06 23:35, Sergey Senozhatsky wrote:
> > - Do not allocate seq_buf if we are in printk-safe or in printk-nmi mode.
> > To avoid "buffering for the sake of buffering". IOW, when in printk-safe
> > use printk-safe.
>
> Why? Since printk
From: Tetsuo Handa
> Sent: 07 November 2018 10:53
>
> On 2018/11/06 23:35, Sergey Senozhatsky wrote:
> >> Since we want to remove "struct cont" eventually, we will try to remove
> >> both "implicit printk() users who are expecting KERN_CONT behavior" and
> >> "explicit pr_cont()/printk(KERN_CONT)
On 2018/11/06 23:35, Sergey Senozhatsky wrote:
>> Since we want to remove "struct cont" eventually, we will try to remove
>> both "implicit printk() users who are expecting KERN_CONT behavior" and
>> "explicit pr_cont()/printk(KERN_CONT) users". Therefore, converting to
>> this API is recommended.
On Tue 2018-11-06 23:35:02, Sergey Senozhatsky wrote:
> On (11/02/18 22:31), Tetsuo Handa wrote:
> > (1) Call get_printk_buffer() and acquire "struct printk_buffer *".
> >
> > (2) Rewrite printk() calls in the following way. The "ptr" is
> > "struct printk_buffer *" obtained in step (1).
On (11/02/18 22:31), Tetsuo Handa wrote:
> (1) Call get_printk_buffer() and acquire "struct printk_buffer *".
>
> (2) Rewrite printk() calls in the following way. The "ptr" is
> "struct printk_buffer *" obtained in step (1).
>
> printk(fmt, ...) => printk_buffered(ptr, fmt, ..
On 2018/11/02 23:40, Matthew Wilcox wrote:
> On Fri, Nov 02, 2018 at 10:31:55PM +0900, Tetsuo Handa wrote:
>> get_printk_buffer() tries to assign a "struct printk_buffer" from
>> statically preallocated array. get_printk_buffer() returns NULL if
>> all "struct printk_buffer" are in use, but t
Hi Tetsuo,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.19 next-20181102]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Tet
On Fri, Nov 02, 2018 at 10:31:55PM +0900, Tetsuo Handa wrote:
> get_printk_buffer() tries to assign a "struct printk_buffer" from
> statically preallocated array. get_printk_buffer() returns NULL if
> all "struct printk_buffer" are in use, but the caller does not need to
> check for NULL.
Sometimes we want to print a whole line without being disturbed by
concurrent printk() from interrupts and/or other threads, for printk()
which does not end with '\n' can be disturbed.
Since mixed printk() output makes it hard to interpret, this patch
introduces API for line-buffered printk() outp
22 matches
Mail list logo
