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(×tamp);
+ /* Handle dumping before timekeeping has resumed. */
+ if (unlikely(timekeeping_suspended)) {
+ timestamp.tv_sec = 0;
+ timestamp.tv_usec = 0;
+ } else
+ do_gettimeofday(×tamp);
+
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/