On Tue, Jul 30, 2019 at 12:36 AM Arnd Bergmann arnd@arndb.de wrote:
On Tue, Jul 30, 2019 at 6:31 AM Kees Cook keescook@chromium.org wrote:
On Mon, Jul 29, 2019 at 06:49:23PM -0700, Deepa Dinamani wrote:
Also update the gran since pstore has microsecond granularity.
So, I'm fine with this, but technically the granularity depends on the backend storage... many have no actual time keeping, though. My point is, pstore's timestamps are really mostly a lie, but the most common backend (ramoops) is seconds-granularity.
So, I'm fine with this, but it's a lie but it's a lie that doesn't matter, so ...
Acked-by: Kees Cook keescook@chromium.org
I'm open to suggestions to improve it...
If we don't care about using sub-second granularity, then setting it to one second unconditionally here will make it always use that and report it correctly.
Should this printf in ramoops_write_kmsg_hdr() also be fixed then?
RAMOOPS_KERNMSG_HDR "%lld.%06lu-%c\n", (time64_t)record->time.tv_sec, record->time.tv_nsec / 1000, record->compressed ? 'C' : 'D'); persistent_ram_write(prz, hdr, len);
ramoops_read_kmsg_hdr() doesn't read this as microseconds. Seems like a mismatch from above.
If we want to agree that we just want seconds granularity for pstore, we could replace the tv_nsec part to be all 0's if anybody else is depending on this format. I could drop this patch from the series and post that patch seperately.
Thanks, -Deepa