On Tue 2020-02-25 21:11:31, John Ogness wrote: > >> --- a/kernel/printk/printk.c > >> +++ b/kernel/printk/printk.c > >> - * Every record carries the monotonic timestamp in microseconds, as well as > >> - * the standard userspace syslog level and syslog facility. The usual > >> + * Every record meta-data carries the monotonic timestamp in microseconds, as > > > > I am afraid that we could not guarantee monotonic timestamp because > > the writers are not synchronized. I hope that it will not create > > real problems and we could just remove the word "monotonic" ;-) > > I removed "monotonic". I hope userspace doesn't require the ringbuffer > to be chronologically sorted. That would explain why the safe buffers > use bogus timestamps. :-/ The timestamp was not stored into the safe buffers to keep the code simple. And people request to add the proper timestamps from time to time. IMHO, the precise timestamps are more important than ordering. So people should love the lockless ringbuffer from this POV ;-) > >> @@ -1974,9 +1966,9 @@ asmlinkage int vprintk_emit(int facility, int level, > >> > >> /* This stops the holder of console_sem just where we want him */ > >> logbuf_lock_irqsave(flags); > >> - curr_log_seq = log_next_seq; > >> + pending_output = !prb_read_valid(prb, console_seq, NULL); > >> printed_len = vprintk_store(facility, level, dict, dictlen, fmt, args); > >> - pending_output = (curr_log_seq != log_next_seq); > >> + pending_output &= prb_read_valid(prb, console_seq, NULL); > > > > The original code checked whether vprintk_store() stored the text > > into the main log buffer or only into the cont buffer. > > > > The new code checks whether console is behind which is something > > different. > > I would argue that they are the same thing in this context. Keep in mind > that we are under the logbuf_lock. If there was previously nothing > pending and now there is, this context is the only one that could have > added it. Right. > This logic will change significantly when we remove the locks (and it > will disappear once we go to kthreads). But we aren't that far at this > stage and I'd like to keep the general logic somewhat close to the > current mainline implementation for now. OK, it is not a big deal from my POV. It is just an optimization. It can be removed or improved later. It caught my eyes primary because prb_read_valid() was relatively complex function. I was not sure if it was worth the effort. But I am fine with keeping your code for now. It will help to reduce unrelated behavior changes. Best Regards, Petr _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
