From: Brendan Jackman <jackmanb@google.com>
To: David Hildenbrand <david@redhat.com>,
Oscar Salvador <osalvador@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>
Cc: 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
Subject: Re: [PATCH 2/2] mm,memory_hotplug: {READ,WRITE}_ONCE unsynchronized zone data
Date: Wed, 22 May 2024 08:42:16 +0000 [thread overview]
Message-ID: <Zk2v6LJPC0HKtBsO@google.com> (raw)
In-Reply-To: <20240521-mm-hotplug-sync-v1-2-6d53706c1ba8@google.com>
On Tue, May 21, 2024 at 12:57:19PM +0000, Brendan Jackman wrote:
> These fields are written by memory hotplug under mem_hotplug_lock but
> read without any lock. It seems like reader code is robust against the
> value being stale or "from the future", but we also need to account
> for:
>
> 1. Load/store tearing (according to Linus[1], this really happens,
> even when everything is aligned as you would hope).
>
> 2. Invented loads[2] - the compiler can spill and re-read these fields
> ([2] calls this "invented loads") and assume that they have not
> changed.
>
> Note we don't need READ_ONCE in paths that have the mem_hotplug_lock
> for write, but we still need WRITE_ONCE to prevent store-tearing.
>
> [1] https://lore.kernel.org/all/CAHk-=wj2t+GK+DGQ7Xy6U7zMf72e7Jkxn4_-kGyfH3WFEoH+YQ@mail.gmail.com/T/#u
> As discovered via the original big-bad article[2]
> [2] https://lwn.net/Articles/793253/
>
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
Oh, from a quick look it seems cma_pages would need this too.
present_early_pages seems fine.
I'll wait a few days in case anyone points out this whole thing is
garbage, then check more carefully and send a v2.
next prev parent reply other threads:[~2024-05-22 8:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-21 12:57 [PATCH 0/2] Clean up hotplug zone data synchronization Brendan Jackman
2024-05-21 12:57 ` [PATCH 1/2] mm,memory_hotplug: Remove un-taken lock Brendan Jackman
2024-05-22 14:09 ` David Hildenbrand
2024-05-22 14:27 ` Brendan Jackman
2024-05-22 15:24 ` David Hildenbrand
2024-05-24 12:02 ` Brendan Jackman
2024-05-27 7:53 ` David Hildenbrand
2024-05-21 12:57 ` [PATCH 2/2] mm,memory_hotplug: {READ,WRITE}_ONCE unsynchronized zone data Brendan Jackman
2024-05-22 4:25 ` Lance Yang
2024-05-22 8:38 ` Brendan Jackman
2024-05-22 9:20 ` Lance Yang
2024-05-22 10:10 ` Brendan Jackman
2024-05-22 11:23 ` Lance Yang
2024-05-22 8:42 ` Brendan Jackman [this message]
2024-05-22 14:05 ` David Hildenbrand
2024-05-22 14:11 ` Brendan Jackman
2024-05-31 16:41 ` Brendan Jackman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zk2v6LJPC0HKtBsO@google.com \
--to=jackmanb@google.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@kernel.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.