summaryrefslogtreecommitdiffstats
path: root/fs/cramfs
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2018-05-30 17:24:52 +0200
committerArnd Bergmann <arnd@arndb.de>2018-06-14 14:57:24 +0200
commite264abeaf9daa3cde9aed8013a6f82b0370425e5 (patch)
treee11ce1df54e768acc17b5d20e0812cde0fc4e5b7 /fs/cramfs
parent15eefe2a99b2b208f512047e7bc404c3efcf0a44 (diff)
downloadlinux-e264abeaf9daa3cde9aed8013a6f82b0370425e5.tar.bz2
pstore: Remove bogus format string definition
The pstore conversion to timespec64 introduces its own method of passing seconds into sscanf() and sprintf() type functions to work around the timespec64 definition on 64-bit systems that redefine it to 'timespec'. That hack is now finally getting removed, but that means we get a (harmless) warning once both patches are merged: fs/pstore/ram.c: In function 'ramoops_read_kmsg_hdr': fs/pstore/ram.c:39:29: error: format '%ld' expects argument of type 'long int *', but argument 3 has type 'time64_t *' {aka 'long long int *'} [-Werror=format=] #define RAMOOPS_KERNMSG_HDR "====" ^~~~~~ fs/pstore/ram.c:167:21: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR' This removes the pstore specific workaround and uses the same method that we have in place for all other functions that print a timespec64. Related to this, I found that the kasprintf() output contains an incorrect nanosecond values for any number starting with zeroes, and I adapt the format string accordingly. Link: https://lkml.org/lkml/2018/5/19/115 Link: https://lkml.org/lkml/2018/5/16/1080 Fixes: 0f0d83b99ef7 ("pstore: Convert internal records to timespec64") Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'fs/cramfs')
0 files changed, 0 insertions, 0 deletions