Received-SPF: pass (google.com: domain of linux-kernel+bounces-72303-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240219082040.7495-1-ryncsn@gmail.com> <20240219173147.3f4b50b7c9ae554008f50b66@linux-foundation.org>
 <CAMgjq7DgBOJhDJStwGuD+C6-FNYZBp-cu6M_HAgRry3gBSf7GA@mail.gmail.com>
In-Reply-To: <CAMgjq7DgBOJhDJStwGuD+C6-FNYZBp-cu6M_HAgRry3gBSf7GA@mail.gmail.com>
From: Barry Song <21cnbao@gmail.com>
Date: Tue, 20 Feb 2024 17:01:10 +1300
Message-ID: <CAGsJ_4zyf5OOq_WA7VjsDKp1ciaDwzM23Ef95_O-24oLtr_5AQ@mail.gmail.com>
Subject: Re: [PATCH v4] mm/swap: fix race when skipping swapcache
To: Kairui Song <ryncsn@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org, 
	"Huang, Ying" <ying.huang@intel.com>, Chris Li <chrisl@kernel.org>, 
	Minchan Kim <minchan@kernel.org>, Barry Song <v-songbaohua@oppo.com>, Yu Zhao <yuzhao@google.com>, 
	SeongJae Park <sj@kernel.org>, David Hildenbrand <david@redhat.com>, Hugh Dickins <hughd@google.com>, 
	Johannes Weiner <hannes@cmpxchg.org>, Matthew Wilcox <willy@infradead.org>, Michal Hocko <mhocko@suse.com>, 
	Yosry Ahmed <yosryahmed@google.com>, Aaron Lu <aaron.lu@intel.com>, stable@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 20, 2024 at 4:42=E2=80=AFPM Kairui Song <ryncsn@gmail.com> wrot=
e:
>
> On Tue, Feb 20, 2024 at 9:31=E2=80=AFAM Andrew Morton <akpm@linux-foundat=
ion.org> wrote:
> >
> > On Mon, 19 Feb 2024 16:20:40 +0800 Kairui Song <ryncsn@gmail.com> wrote=
:
> >
> > > From: Kairui Song <kasong@tencent.com>
> > >
> > > When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more thread=
s
> > > swapin the same entry at the same time, they get different pages (A, =
B).
> > > Before one thread (T0) finishes the swapin and installs page (A)
> > > to the PTE, another thread (T1) could finish swapin of page (B),
> > > swap_free the entry, then swap out the possibly modified page
> > > reusing the same entry. It breaks the pte_same check in (T0) because
> > > PTE value is unchanged, causing ABA problem. Thread (T0) will
> > > install a stalled page (A) into the PTE and cause data corruption.
> > >
> > > @@ -3867,6 +3868,20 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> > >       if (!folio) {
> > >               if (data_race(si->flags & SWP_SYNCHRONOUS_IO) &&
> > >                   __swap_count(entry) =3D=3D 1) {
> > > +                     /*
> > > +                      * Prevent parallel swapin from proceeding with
> > > +                      * the cache flag. Otherwise, another thread ma=
y
> > > +                      * finish swapin first, free the entry, and swa=
pout
> > > +                      * reusing the same entry. It's undetectable as
> > > +                      * pte_same() returns true due to entry reuse.
> > > +                      */
> > > +                     if (swapcache_prepare(entry)) {
> > > +                             /* Relax a bit to prevent rapid repeate=
d page faults */
> > > +                             schedule_timeout_uninterruptible(1);
> >
> > Well this is unpleasant.  How often can we expect this to occur?
> >
>
> The chance is very low, using the current mainline kernel and ZRAM,
> even with threads set to race on purpose using the reproducer I
> provides, for 647132 page faults it occured 1528 times (~0.2%).
>
> If I run MySQL and sysbench with 128 threads and 16G buffer pool, with
> 6G cgroup limit and 32G ZRAM, it occured 1372 times for 40 min,
> 109930201 page faults in total (~0.001%).

it might not be a problem for throughput. but for real-time and tail latenc=
y,
this hurts. For example, this might increase dropping frames of UI which
is an important parameter to evaluate performance :-)

BTW, I wonder if ying's previous proposal - moving swapcache_prepare()
after swap_read_folio() will further help decrease the number?

Thanks
Barry