On Wed, Jun 6, 2018 at 12:41 PM, Stephen Rothwell <s...@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the y2038 tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> fs/pstore/ram.c: In function 'ramoops_read_kmsg_hdr':
> fs/pstore/ram.c:39:29: warning: format '%ld' expects argument of type 'long 
> int *', but argument 3 has type 'time64_t * {aka long long int *}' [-Wformat=]
>  #define RAMOOPS_KERNMSG_HDR "===="
>                              ^
> fs/pstore/ram.c:167:21: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR'
>   if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n%n",
>                      ^~~~~~~~~~~~~~~~~~~
> fs/pstore/ram.c:42:23: note: format string is defined here
>  # define TVSEC_FMT "%ld"
>                      ~~^
>                      %lld
> fs/pstore/ram.c:39:29: warning: format '%ld' expects argument of type 'long 
> int *', but argument 3 has type 'time64_t * {aka long long int *}' [-Wformat=]
>  #define RAMOOPS_KERNMSG_HDR "===="
>                              ^
> fs/pstore/ram.c:174:28: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR'
>   } else if (sscanf(buffer, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu\n%n",
>                             ^~~~~~~~~~~~~~~~~~~
> fs/pstore/ram.c:42:23: note: format string is defined here
>  # define TVSEC_FMT "%ld"
>                      ~~^
>                      %lld
> fs/pstore/ram.c: In function 'ramoops_write_kmsg_hdr':
> fs/pstore/ram.c:39:29: warning: format '%ld' expects argument of type 'long 
> int', but argument 3 has type 'time64_t {aka long long int}' [-Wformat=]
>  #define RAMOOPS_KERNMSG_HDR "===="
>                              ^
> fs/pstore/ram.c:370:30: note: in expansion of macro 'RAMOOPS_KERNMSG_HDR'
>   hdr = kasprintf(GFP_ATOMIC, RAMOOPS_KERNMSG_HDR TVSEC_FMT ".%lu-%c\n",
>                               ^~~~~~~~~~~~~~~~~~~
> fs/pstore/ram.c:42:23: note: format string is defined here
>  # define TVSEC_FMT "%ld"
>                      ~~^
>                      %lld
>
> Introduced by commit
>
>   0f0d83b99ef7 ("pstore: Convert internal records to timespec64")
>

Thanks for the report, I had actually provided a fix for this earlier
(it was a clash
between a patch in Deepa's tree with one of mine that Thomas had picked up
into tip) but forgot to apply it before I pushed out the merged tree.

I've updated my tree now.

      Arnd

Reply via email to