linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Brendan Jackman <jackmanb@google.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 16:05:12 +0200	[thread overview]
Message-ID: <9c23d824-f2c7-4f9a-ade2-e8dd3a0d30af@redhat.com> (raw)
In-Reply-To: <20240521-mm-hotplug-sync-v1-2-6d53706c1ba8@google.com>

On 21.05.24 14:57, 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>
> ---
>   include/linux/mmzone.h | 14 ++++++++++----
>   mm/compaction.c        |  2 +-
>   mm/memory_hotplug.c    | 20 ++++++++++++--------
>   mm/mm_init.c           |  2 +-
>   mm/page_alloc.c        |  2 +-
>   mm/show_mem.c          |  8 ++++----
>   mm/vmstat.c            |  4 ++--
>   7 files changed, 31 insertions(+), 21 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 194ef7fed9d6..bdb3be76d10c 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -1018,11 +1018,13 @@ static inline unsigned long zone_cma_pages(struct zone *zone)
>   #endif
>   }
>   
> +/* This is unstable unless you hold mem_hotplug_lock. */
>   static inline unsigned long zone_end_pfn(const struct zone *zone)
>   {
> -	return zone->zone_start_pfn + zone->spanned_pages;
> +	return zone->zone_start_pfn + READ_ONCE(zone->spanned_pages);

It's weird to apply that logic only to spanned_pages, whereby 
zone_start_pfn can (and will) similarly change when onlining/offlining 
memory.

-- 
Cheers,

David / dhildenb



  parent reply	other threads:[~2024-05-22 14:05 UTC|newest]

Thread overview: 16+ 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
     [not found]   ` <78e646af-e8b5-4596-8fbf-17b139cfdddd@redhat.com>
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
2024-05-22 14:05   ` David Hildenbrand [this message]
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=9c23d824-f2c7-4f9a-ade2-e8dd3a0d30af@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=jackmanb@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox