ktrdump: ignore ts=0 when searching for earliest_ts()
authorSimon Schubert <corecode@dragonflybsd.org>
Thu, 30 Apr 2009 10:59:47 +0000 (12:59 +0200)
committerSimon Schubert <corecode@dragonflybsd.org>
Thu, 30 Apr 2009 10:59:47 +0000 (12:59 +0200)
When merge-printing multiple cpu buffers, we already treat ts=0 as
a condition to prefer a more recent entry.  However when searching for
the first entry, ts=0 (empty) will be treated regularly.  This can lead
to a situation that ktrdump would only print entries from the last CPU:

Assume you had 4 CPUs, and the buffer for CPU #2 and #3 started out with
empty entries (which would not be ignored by earliest_ts()).  When
searching for the next entry, the empty (ts=0) entry of CPU #2 would
always be selected as the first entry.  However a ts=0 entry of CPU #3
would override this.  In this case only the index of CPU #3 would
advance until full entries would be printed.  Once in this situation,
processing the ts of CPU #2 would always reset ts to 0, and this would
be treated as "not found" when processing CPU #3's entries, leading to
an output that only contains CPU #3 entries.

usr.bin/ktrdump/ktrdump.c

index d6e6dcd..31020fb 100644 (file)
@@ -623,7 +623,8 @@ earliest_ts(struct ktr_buffer *buf)
        save = &buf->ents[earliest & fifo_mask];
        for (scan = buf->end_idx - 1; scan != buf->beg_idx -1; --scan) {
                i = scan & fifo_mask;
-               if (buf->ents[i].ktr_timestamp <= save->ktr_timestamp)
+               if (buf->ents[i].ktr_timestamp <= save->ktr_timestamp &&
+                   buf->ents[i].ktr_timestamp > 0)
                        earliest = scan;
                /*
                 * We may have gotten so far behind that beg_idx wrapped