On Fri 2015-06-12 14:00:37, Peter Zijlstra wrote: > On Thu, Jun 11, 2015 at 04:55:47PM +0200, Petr Mladek wrote: > > > + * 'Consume' this chunk, avoids concurrent callers printing the same > > > + * stuff. > > > + */ > > > + if (atomic_cmpxchg(&s->read, i, len) != i) > > > + goto again; > > > > I think that this is racy: > > Indeed. I'll think a bit on that. > > > I think that ordering CPUs is not worth it. I would go back to the > > first solution, add the @lock there, and double check races with > > seq_buf(). > > You mean, provide printk_nmi_flush() but completely screw concurrency? > And basically reserve it for a last ditch effort for getting crap out?
This looks much easier to me. We could call this only when the system is going down. Another possibility would be to ignore this race because it is rather theoretical and it better to print some mess than nothing. I wonder what Andrew thinks about it. I really admired the atomic operations in the 2nd patch but I was also scared by them. Note that I have already had two attempts to make printk() safe in NMI. The first one was too precise, too complicated, and thus rejected, see https://lkml.org/lkml/2014/6/10/388. The second one was rather defensive and quite simple. It has not been completely rejected but there is still some resistance to accept non-trivial code for handling printk() in NMI, see https://lkml.org/lkml/2015/5/29/699 I hope that your approach has a chance if we do not make it too complicated. The big plus is that it generalizes the already used solution for arch_trigger_all_cpu_backtrace() and the 1st variant was rather easy but quite functional. Best Regards, Petr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
