On Fri, Jul 19, 2024 at 10:01:25AM GMT, John Ogness wrote: > On 2024-07-18, Andrew Halaney <ahalaney@xxxxxxxxxx> wrote: > > I'll be honest, I only considered this from a printk() point of view > > so far and pretty much ignored the original splat (as someone else is > > looking at that). Here's the original splat from a centos kernel, I > > have yet to look into it other than "we took an exception prior to RCU > > coming online for this CPU" > > Thanks for posting the splat. This is indeed a printk() > issue. vprintk_emit() or nbcon_wake_threads() need to be aware of the > RCU state and act appropriately. I will look into this. > > > and me naively thinking that printk() should work everywhere. > > Your thinking is not naive. It is correct (for PREEMPT_RT). printk() > stores messages locklessly into its ringbuffer and must work in all > cases (including NMI and scheduler). And AFAIK it does. > > However, printk() is also responsible for reliably triggering or > performing console printing. This separate responsibility is tricky. For > PREEMPT_RT the problem is supposed to be solved. Obviously it still has > some issues, so thank you for the report. > > For PREEMPT_RT, if you can put a printk() anywhere after the Linux > banner and cause a problem, the printk-folks need to know about it. Just to be sure I'm following correctly, when you say PREEMPT_RT above, are you meaning "the printk/nbcon/console solution in PREEMPT (independent of the current CONFIG_PREEMPT* setting)"? Or do you mean that + CONFIG_PREEMPT_RT? Thanks, Andrew
