Dear Sergey, > sorry for long reply. do you see this in practice?
No, I've only thought of the bug will trying to adapt this code to build a separate cyclic buffer in a dedicated kernel module. > the first printk()->console_unlock() to notice `seen_seq != log_next_seq` > will wakeup a task from log_wait, sleeping on > wait_event_interruptible(seq != log_next_seq) Yes, but a task could be not waiting to read reading while still having open /dev/kmsg (e.g. after having read it in O_NONBLOCK) > so I believe your assumption here is that we wrap around and then fill up > the log_buf again without waking up the klogd even once, correct? > > CPU0 CPU1 > > console_lock(); > printk(); > ... devkmsg_read(); > printk(); > console_unlock(); > > like the above? Mmm, I did not think of such a case, which might be possible. I was more thinking of a userland daemon reading the buffer (via /dev/kmsg) in non-blocking mode and only pulling from time to time. I agree that this is probably not seen often, which could explain why nobody can see it in practice. Thanks for your time, Vincent Brillault
signature.asc
Description: OpenPGP digital signature
