On Wed 19-04-23 14:03:29, Petr Mladek wrote: > On Wed 2023-04-19 11:11:52, John Ogness wrote: > > On 2023-04-19, Petr Mladek <pmladek@xxxxxxxx> wrote: > > > it is safe to interrupt one writer now. The preemption still > > > has to be disabled because the deferred context is CPU specific. > > > > Really it is enough to disable migration. > > True. But it gets too far to my taste. As you describe below. > It affects all printk's on the CPU. > > Sigh, even the enabled intrrupts might be questionable. For example, > when the iterrupt is from a watchdog and want's to report a stall. > > > We need to keep an eye on the usage of this function. By allowing > > interrupts and preemption, it means that other printk's on that CPU will > > also be deferred if the context interrupted within the deferred block. > > A solution would be to make this more clear in the comment. > Something like: > > /* > * The printk_deferred_enter/exit macros are available only as a hack. > * They define a per-CPU context where all printk console printing is > * deferred because it might cause a deadlock otherwise. > * > * The API user is responsible for calling the corresponding enter/exit > * pair on the same CPU. It is highly recommended to use them only in > * a context with interrupts disabled. Otherwise, other unrelated > * printk() calls might be deferred when they interrupt/preempt > * the deferred code section. > */ This looks better but I would argue that as a potential user of those I would appreciate less internal implementation details and more instructions on how/when to use it. What about something like this? /* * The printk_deferred_enter/exit macros are available only as a hack * for code paths which are prone to printk related deadlocks. That * might be caused by locking context around printk which can be reused * directly or indirectly by lower level printk infrastructure. * * Any new use of these MUST be consulted with printk maintainers as the * use might have some unexpected side effects on the printk * infrastructure. * * enter/exit pair must be called from the same CPU without any * preemption in between. */ -- Michal Hocko SUSE Labs
