On Tue 2023-12-19 09:50:18, Joe Lawrence wrote:
> On 12/19/23 04:45, Alexander Gordeev wrote:
> > On Mon, Dec 18, 2023 at 05:44:54PM -0500, Joe Lawrence wrote:
> >
> >> @@ -280,7 +268,13 @@ function set_pre_patch_ret {
> >> function start_test {
> >> local test="$1"
> >>
> >> - save_dmesg
> >> + # Dump something unique into the dmesg log, then stash the entry
> >> + # in LAST_DMESG. The check_result() function will use it to
> >> + # find new kernel messages since the test started.
> >> + local timestamp="$(date --rfc-3339=ns)"
> >> + log "livepatch kselftest timestamp: $timestamp"
> >> + LAST_DMESG=$(dmesg | grep "livepatch kselftest timestamp: $timestamp")
I like this approach.
> > Not sure if it not paranoid mode, but still..
> > If the 'log' call is guaranteed synced? AKA would 'grep' always catch the
> > line?
I believe that the write is synchronized. The "log" command does:
function log() {
echo "$1" > /dev/kmsg
}
The message is stored into the log buffer during the write to
/dev/kmsg(). See devkmsg_emit() in devkmsg_write(), where
devkmsg_write() is .write_iter callback in struct file_operations.
const struct file_operations kmsg_fops = {
.open = devkmsg_open,
.read = devkmsg_read,
.write_iter = devkmsg_write,
.llseek = devkmsg_llseek,
.poll = devkmsg_poll,
.release = devkmsg_release,
};
I would explect that the write() callback is called directly when
shell is writing "echo" stdout to /dev/kmsg.
I hope that all this is sychronous. Everything is in memory.
I think that write operations are asynchronous only when
the data are written to a disk or another "slow" medium.
And dmesg reads the data from the ring buffer as well. It is
actually using /dev/kmsg as well by default.
Best Regards,
Petr
