Received-SPF: pass (google.com: domain of linux-kernel+bounces-185980-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: <20240521-mm-hotplug-sync-v1-0-6d53706c1ba8@google.com>
 <20240521-mm-hotplug-sync-v1-2-6d53706c1ba8@google.com> <CABzRoyZXq3u4DYxO39Fcezo56HAbkNh6xLuK9jnuiNK5gVmV1w@mail.gmail.com>
 <Zk2vDeQ3feZ3hsf0@google.com>
In-Reply-To: <Zk2vDeQ3feZ3hsf0@google.com>
From: Lance Yang <ioworker0@gmail.com>
Date: Wed, 22 May 2024 17:20:08 +0800
Message-ID: <CAK1f24=fNFPyGCh+sxsq-Gg6BkD5qH=z+Ur2UD8+4CRZYoZc6g@mail.gmail.com>
Subject: Re: [PATCH 2/2] mm,memory_hotplug: {READ,WRITE}_ONCE unsynchronized
 zone data
To: Brendan Jackman <jackmanb@google.com>
Cc: David Hildenbrand <david@redhat.com>, Oscar Salvador <osalvador@suse.de>, 
	Andrew Morton <akpm@linux-foundation.org>, Mike Rapoport <rppt@kernel.org>, 
	Michal Hocko <mhocko@suse.com>, Anshuman Khandual <anshuman.khandual@arm.com>, 
	Vlastimil Babka <vbabka@suse.cz>, Pavel Tatashin <pasha.tatashin@soleen.com>, linux-mm@kvack.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 22, 2024 at 4:38=E2=80=AFPM Brendan Jackman <jackmanb@google.co=
m> wrote:
>
> Hi Lance, thanks for taking a look.
>
> On Wed, May 22, 2024 at 12:25:30PM +0800, Lance Yang wrote:
> > Hi Brendan,
> >
> > On Tue, May 21, 2024 at 8:57=E2=80=AFPM Brendan Jackman <jackmanb@googl=
e.com> wrote:
> > > @@ -1077,7 +1081,7 @@ void adjust_present_page_count(struct page *pag=
e, struct memory_group *group,
> > >          */
> > >         if (early_section(__pfn_to_section(page_to_pfn(page))))
> > >                 zone->present_early_pages +=3D nr_pages;
> > > -       zone->present_pages +=3D nr_pages;
> > > +       WRITE_ONCE(zone->present_pages, zone->present_pages + nr_page=
s);
> >
> > I'm not sure that using the WRITE_ONCE() wrapper would prevent load tea=
ring
> > on 'zone->present_pages', but it's probably just me overthinking it :)
>
> Hmm.. this isn't for load-tearing, it's for store-tearing. I have a
> feeling I might be missing your pont here though, can you elaborate?

Sorry, my explanation wasn't clear :(

I'm a bit confused about whether 'WRITE_ONCE(zone->present_pages,
zone->present_pages + nr_pages);'
is equivalent to the following:

1 a =3D zone->present_pages + nr_pages;
2 WRITE_ONCE(zone->present_pages, a);

If so, is there any possibility of load tearing on
'zone->present_pages' in line 1?

>
> I have just noticed that the original "big bad optimizing compiler"
> article[1] only says store-tearing has been observed in the wild when
> the value being stored can be split into immediates (i.e. is
> constant). But it doesn't really seem wise to rely on that. From what
> I can tell from tools/memory-model/Documentation you are really out in
> the wild with unmarked accesses.
>
> [1] https://lwn.net/Articles/793253

Thanks for clarifying!
Lance