On Thu, Aug 24, 2023 at 05:17:21PM -0700, Atul Raut wrote:
> ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790
No. This is your clue. ntfs corrupts memory. You can't take bug
reports involving ntfs seriously. Ignore everything tagged with ntfs.
> In folio_batch_add, which contains folios rather
> than fixed-size pages, there is a chance that the
> array index will fall outside of bounds.
> Before adding folios, examine the available space to fix.
This is definitely the wrong fix.
> static inline unsigned folio_batch_add(struct folio_batch *fbatch,
> struct folio *folio)
> {
> - fbatch->folios[fbatch->nr++] = folio;
> + if (folio_batch_space(fbatch))
> + fbatch->folios[fbatch->nr++] = folio;
Did you look at what folio_batch_space() actually does?
static inline unsigned int folio_batch_space(struct folio_batch *fbatch)
{
return PAGEVEC_SIZE - fbatch->nr;
}
So if fbatch->nr is 255, what will it return? How will
folio_batch_add() behave?
The right way to fix this problem is to find the data corrupter in NTFS.
You can't "fix" it anywhere else.
