On Thu, 18 Jul 2024 14:34:41 -0500 Andrew Halaney <ahalaney@xxxxxxxxxx> wrote: > Heh, exactly why I made a "reproducer" for the printk/RCU side of the > splat with linux-rt-devel before reporting. > > So my takeaway is that printk is not considered safe to use in all > contexts, including during SMP bringup (because RCU's at play and not > yet ready to be used on those CPUs). So if we do printk for reasons we > can't control (say some firmware problem causing an exception) and try > to print you could get the RCU warning about printk/nbcon usage in > addition to the actual error, and that's just something to accept. Well, in most cases people don't run a debug kernel in production and if this printk was triggered in production, that warning would not show up (it's only there when lockdep is enabled). > > Ideally though we don't printk() in those situations... so if its badly > behaving code calling printk() that's a different story. Right. printk() does get called in locations it shouldn't simply due to a bug happening. But then, it's just a best effort to get information to the user. > > Let me know if you think that recap is bogus. I think you summarized it well. -- Steve
