On 11/05/2012 02:00 PM, Kees Cook wrote:
We must not call timekeeping functions unless they are available. If we dump
before they have resumed, avoid a WARN_ON by setting the timestamp to 0.

Since the "ram" pstore driver can be a module, we must have
timekeeping_suspended exported.

Reported-by: Doug Anderson <diand...@chromium.org>
Cc: Anton Vorontsov <cbouatmai...@gmail.com>
Cc: John Stultz <johns...@us.ibm.com>
Signed-off-by: Kees Cook <keesc...@chromium.org>
---
v2:
  - export needed for timekeeping_suspended (thanks to Fengguang Wu).
---
  fs/pstore/ram.c           |    8 +++++++-
  kernel/time/timekeeping.c |    1 +
  2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 1a4f6da..6d014e0 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -171,7 +171,13 @@ static size_t ramoops_write_kmsg_hdr(struct 
persistent_ram_zone *prz)
        struct timeval timestamp;
        size_t len;

-       do_gettimeofday(&timestamp);
+       /* Handle dumping before timekeeping has resumed. */
+       if (unlikely(timekeeping_suspended)) {
+               timestamp.tv_sec = 0;
+               timestamp.tv_usec = 0;
+       } else
+               do_gettimeofday(&timestamp);
+
Would nulling out the timestamp be better done in do_gettimeofday()? That way we don't have to export timekeeping internals and users would get something more sane for this corner case.

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to