On Wed, May 25, 2022 at 03:20:06PM -0700, Andrew Morton wrote:
On Wed, 25 May 2022 23:07:35 +0100 Jessica Clarke jrtc27@jrtc27.com wrote:
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.
Ah, of course, thanks. I remember 32 bits ;)
--- a/mm/shmem.c~mm-shmemc-suppress-shift-warning +++ a/mm/shmem.c @@ -1945,7 +1945,7 @@ alloc_nohuge:
spin_lock_irq(&info->lock); info->alloced += folio_nr_pages(folio);
- inode->i_blocks += BLOCKS_PER_PAGE << folio_order(folio);
- inode->i_blocks += (blkcnt_t)BLOCKS_PER_PAGE << folio_order(folio);
Bizarre this started showing up now. The recent patch was:
- info->alloced += compound_nr(page); - inode->i_blocks += BLOCKS_PER_PAGE << compound_order(page); + info->alloced += folio_nr_pages(folio); + inode->i_blocks += BLOCKS_PER_PAGE << folio_order(folio);
so it could tell that compound_order() was small, but folio_order() might be large?
Silencing the warning is a good thing, but folio_order() can (at the moment) be at most 9 on i386, so it isn't actually going to be larger than 4096.