linux-kernel - Re: [PATCH 2/2] mm,memory_hotplug: {READ,WRITE}

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zk2vDeQ3feZ3hsf0@google.com>
Date: Wed, 22 May 2024 08:38:37 +0000
From: Brendan Jackman <jackmanb@...gle.com>
To: Lance Yang <ioworker0@...il.com>
Cc: David Hildenbrand <david@...hat.com>,
	Oscar Salvador <osalvador@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mike Rapoport <rppt@...nel.org>, Michal Hocko <mhocko@...e.com>,
	Anshuman Khandual <anshuman.khandual@....com>,
	Vlastimil Babka <vbabka@...e.cz>,
	Pavel Tatashin <pasha.tatashin@...een.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] mm,memory_hotplug: {READ,WRITE}_ONCE unsynchronized
 zone data

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 PM Brendan Jackman <jackmanb@...gle.com> wrote:
> > @@ -1077,7 +1081,7 @@ void adjust_present_page_count(struct page *page, struct memory_group *group,
> >          */
> >         if (early_section(__pfn_to_section(page_to_pfn(page))))
> >                 zone->present_early_pages += nr_pages;
> > -       zone->present_pages += nr_pages;
> > +       WRITE_ONCE(zone->present_pages, zone->present_pages + nr_pages);
> 
> I'm not sure that using the WRITE_ONCE() wrapper would prevent load tearing
> 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?

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