[linux-next:master] BUILD REGRESSION 8cb8311e95e3bb58bd84d6350365f14a718faa6d
Jessica Clarke
jrtc27 at jrtc27.com
Wed May 25 15:07:35 PDT 2022
On 25 May 2022, at 22:50, Andrew Morton <akpm at linux-foundation.org> wrote:
>
> On Thu, 26 May 2022 05:35:20 +0800 kernel test robot <lkp at intel.com> wrote:
>
>> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>> branch HEAD: 8cb8311e95e3bb58bd84d6350365f14a718faa6d Add linux-next specific files for 20220525
>>
>> Error/Warning reports:
>>
>> ...
>>
>> Unverified Error/Warning (likely false positive, please contact us if interested):
>
> Could be so.
>
>> mm/shmem.c:1948 shmem_getpage_gfp() warn: should '(((1) << 12) / 512) << folio_order(folio)' be a 64 bit type?
>
> I've been seeing this one for a while. And from this report I can't
> figure out what tool emitted it. Clang?
>
>>
>> ...
>>
>> |-- i386-randconfig-m021
>> | `-- mm-shmem.c-shmem_getpage_gfp()-warn:should-((()-)-)-folio_order(folio)-be-a-bit-type
>
> If you're going to use randconfig then shouldn't you make the config
> available? Or maybe quote the KCONFIG_SEED - presumably there's a way
> for others to regenerate.
>
> Anyway, the warning seems wrong to me.
>
>
> #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
>
> #define BLOCKS_PER_PAGE (PAGE_SIZE/512)
>
> inode->i_blocks += BLOCKS_PER_PAGE << folio_order(folio);
>
> so the RHS here should have unsigned long type. Being able to generate
> the cpp output would be helpful. That requires the .config.
This is i386, so an unsigned long is 32-bit, but i_blocks is a blkcnt_t
i.e. a u64, which makes the shift without a cast of the LHS fishy.
Jess
More information about the linux-riscv
mailing list