diff options
author | Arnd Bergmann <arnd@arndb.de> | 2018-05-30 17:24:52 +0200 |
---|---|---|
committer | Arnd Bergmann <arnd@arndb.de> | 2018-06-14 14:57:24 +0200 |
commit | e264abeaf9daa3cde9aed8013a6f82b0370425e5 (patch) | |
tree | e11ce1df54e768acc17b5d20e0812cde0fc4e5b7 /fs/hfs | |
parent | Merge branch 'vfs_timespec64' of https://github.com/deepa-hub/vfs into vfs-ti... (diff) | |
download | linux-e264abeaf9daa3cde9aed8013a6f82b0370425e5.tar.xz linux-e264abeaf9daa3cde9aed8013a6f82b0370425e5.zip |
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/hfs')
0 files changed, 0 insertions, 0 deletions