summaryrefslogtreecommitdiff
path: root/fs/btrfs/transaction.c
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2018-05-30 18:24:52 +0300
committerArnd Bergmann <arnd@arndb.de>2018-06-14 15:57:24 +0300
commite264abeaf9daa3cde9aed8013a6f82b0370425e5 (patch)
treee11ce1df54e768acc17b5d20e0812cde0fc4e5b7 /fs/btrfs/transaction.c
parent15eefe2a99b2b208f512047e7bc404c3efcf0a44 (diff)
downloadlinux-e264abeaf9daa3cde9aed8013a6f82b0370425e5.tar.xz
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/btrfs/transaction.c')
0 files changed, 0 insertions, 0 deletions