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