lkml.org 
[lkml]   [2022]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage
    Sending again. The previous attempt was rejected by several
    recipients. It was caused by a mail server changes on my side.

    I am sorry for spamming those who got the 1st mail already.

    On Wed 2022-06-08 16:27:47, Peter Zijlstra wrote:
    > The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console
    > tracepoint"), was printk usage from the cpuidle path where RCU was
    > already disabled.
    >
    > Per the patches earlier in this series, this is no longer the case.

    My understanding is that this series reduces a lot the amount
    of code called with RCU disabled. As a result the particular printk()
    call mentioned by commit fc98c3c8c9dc ("printk: use rcuidle console
    tracepoint") is called with RCU enabled now. Hence this particular
    problem is fixed better way now.

    But is this true in general?
    Does this "prevent" calling printk() a safe way in code with
    RCU disabled?

    I am not sure if anyone cares. printk() is the best effort
    functionality because of the consoles code anyway. Also I wonder
    if anyone uses this trace_console().

    Therefore if this patch allows to remove some tricky tracing
    code then it might be worth it. But if trace_console_rcuidle()
    variant is still going to be available then I would keep using it.

    Best Regards,
    Petr

    > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    > ---
    > kernel/printk/printk.c | 2 +-
    > 1 file changed, 1 insertion(+), 1 deletion(-)
    >
    > --- a/kernel/printk/printk.c
    > +++ b/kernel/printk/printk.c
    > @@ -2238,7 +2238,7 @@ static u16 printk_sprint(char *text, u16
    > }
    > }
    >
    > - trace_console_rcuidle(text, text_len);
    > + trace_console(text, text_len);
    >
    > return text_len;
    > }
    >

    \
     
     \ /
      Last update: 2022-06-09 12:15    [W:2.416 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site