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")
>
> Not sure if it not paranoid mode, but still..
> If the 'log' call is guaranteed synced? AKA would 'grep' always catch the line?
>
> And yeah.. if the log output is pushed away (e.g by a crazy-dumping concurrent
> logger), then nothing here would work. But this is not a new problem, so just
> my two cents.
>
Good question. I added the timestamp message to ensure there would be
something in the log to grab onto... but I'm not sure what guarantees
there are about syncing back out through dmesg.
There is a loop_util() utility function in the script that could be used
to wait, like:
log "$last_dmesg_msg"
loop_until "dmesg | grep -q '$last_dmesg_msg'" ||
die "Can't find canary dmesg entry, buffer overrun?"
LAST_DMESG=$(dmesg | grep "$last_dmesg_msg")
That should catch 1) short latencies and 2) buffer rollover. Maybe that
is good enough?
--
Joe
