Re: [PATCHv2 1/1] mm: fix unproperly folio_put by changing API in read_pages

[Zhaoyang Huang <huangzhaoyang@gmail.com>]

On Tue, Apr 2, 2024 at 8:34 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Mon, Apr 01, 2024 at 04:17:34PM +0800, zhaoyang.huang wrote:
> > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
> >
> > An VM_BUG_ON in step 9 of [1] could happen as the refcnt is dropped
> > unproperly during the procedure of read_pages()->readahead_folio->folio_put.
> > This is introduced by commit 9fd472af84ab ("mm: improve cleanup when
> > ->readpages doesn't process all pages")'.
>
> This patch is no less bullshit than the last time you posted it.
> I explained why here:
> https://lore.kernel.org/linux-mm/ZgQRtQ60mrvOUKXo@casper.infradead.org/
Yes. I get your point in your previous feedback. Could you please
check the timing sequence in v2's commit message, where the folio_lock
failed to prevent the race from happening. I also would like to insist
that the refcnt got from alloc_pages just paired with the one which is
checked in __remove_mapping but any other folio_put. The sequence of
read_pages->readahead_folio->folio_put happens to be right when no
race and then frees the folio immediatly.