Received-SPF: pass (google.com: domain of linux-kernel+bounces-120171-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Precedence: bulk
MIME-Version: 1.0
References: <Zfg0WLrcOmCtdn_M@casper.infradead.org> <CAGWkznGhiuzkqfeewNq-ykKehvFTBjH2v_==xAS2_7iFqsFk5A@mail.gmail.com>
 <Zfj_-LbiIsAVWcPX@casper.infradead.org> <CAGWkznHOWVPpKHOuvvDF2zppkTT0_x4WyJ5S75j+EghhZmEDdg@mail.gmail.com>
 <ZfwpuRjAZV07_lc3@casper.infradead.org> <CAGWkznFtez1fj2L2CtFnA5k-Tn4WtxmDOw=fjOWPg-ZGJX=VWw@mail.gmail.com>
 <Zfz4_GJAHRInB8ul@casper.infradead.org> <CAGWkznEzpcWi4oXVn_WFahnQj3dHcwc_4VW6m1Ss-KJ8mD3F3Q@mail.gmail.com>
 <ZgDt9mwN-Py5Y-xr@casper.infradead.org> <CAGWkznHO27EpVVpFyKnv-SX-JTYCXQxb0MG+EW07gaupocR4RQ@mail.gmail.com>
 <ZgK91II_eSYY6D2F@casper.infradead.org>
In-Reply-To: <ZgK91II_eSYY6D2F@casper.infradead.org>
From: Zhaoyang Huang <huangzhaoyang@gmail.com>
Date: Wed, 27 Mar 2024 09:25:59 +0800
Message-ID: <CAGWkznGLySzLE17+rCe=UoA26vx=iM375o2zkruKM9ssG05QzA@mail.gmail.com>
Subject: Re: summarize all information again at bottom//reply: reply: [PATCH]
 mm: fix a race scenario in folio_isolate_lru
To: Matthew Wilcox <willy@infradead.org>
Cc: =?UTF-8?B?6buE5pyd6ZizIChaaGFveWFuZyBIdWFuZyk=?= <zhaoyang.huang@unisoc.com>, 
	Andrew Morton <akpm@linux-foundation.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	=?UTF-8?B?5bq357qq5ruoIChTdGV2ZSBLYW5nKQ==?= <Steve.Kang@unisoc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 26, 2024 at 8:21=E2=80=AFPM Matthew Wilcox <willy@infradead.org=
> wrote:
>
> On Tue, Mar 26, 2024 at 05:06:55PM +0800, Zhaoyang Huang wrote:
> > 1. Thread_readahead remove the folio from page cache and drop 2 refcnt
> > by readahead_folio & filemap_remove_folio(get rid of the folios which
> > failed to launch IO during readahead)
> >     refcnt =3D=3D 0, PG_lru =3D=3D true, PG_lock =3D=3D true
> >     read_pages
> > ...
> >         folio =3D readahead_folio
> >         <one refcnt dropped here>
> > ********For the folio which can not launch IO, we should NOT drop
> > refcnt here??? replaced by __readahead_folio???**********
> >         folio_get
> >         filemap_remove_folio(folio)
> >         folio_unlock
> >         <one refcnt dropped here>
> >         folio_put
>
> Ignoring any other thread, you're basically saying that there's a
> refcount imbalance here.  Which means we'd hit an assert (that folio
> refcount went below zero) in the normal case where another thread wasn't
> simultaneously trying to do anything.
Theoretically Yes but it is rare in practice as aops->readahead will
launch all pages to IO under most scenarios.

read_pages
    aops->readahead[1]
..
    while (folio =3D readahead_folio)[2]
        filemap_remove_folio

IMO, according to the comments of readahead_page, the refcnt
represents page cache dropped in [1] makes sense for two reasons, '1.
The folio is going to do IO and is locked until IO done;2. The refcnt
will be added back when found again from the page cache and then serve
for PTE or vfs' while it doesn't make sense in [2] as the refcnt of
page cache will be dropped in filemap_remove_folio

 * Context: The page is locked and has an elevated refcount.  The caller
 * should decreases the refcount once the page has been submitted for I/O
 * and unlock the page once all I/O to that page has completed.
 * Return: A pointer to the next page, or %NULL if we are done.