From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97684C25B74 for ; Fri, 24 May 2024 12:02:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE6DA6B0085; Fri, 24 May 2024 08:02:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E96E66B0088; Fri, 24 May 2024 08:02:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5F6A6B0089; Fri, 24 May 2024 08:02:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id B8E8E6B0085 for ; Fri, 24 May 2024 08:02:58 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3BA73140A90 for ; Fri, 24 May 2024 12:02:58 +0000 (UTC) X-FDA: 82153153236.29.865AB6D Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf25.hostedemail.com (Postfix) with ESMTP id 53F6DA001F for ; Fri, 24 May 2024 12:02:56 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mgJicXEa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jackmanb@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716552176; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CLDLdXYwwkToVr8Cvp+hiWbFyJwd77OjF46C3hbvTe4=; b=8FGwRJ72AjuCpdr+cyHYQM6jSe5tunqzReBJB/YcY6cs6Yo1tRh4j+gmbAIMT6JWoMaGbh sBC/Mf2E0BoEUk8RwIM1Q5sMVj5uEI6kKEiLzGFi8ObjM7fzGHbFe7V1350W/tFo4N51q2 nnUUvDF5QgdS9jWvMHWUt72tFsJyx5A= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mgJicXEa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of jackmanb@google.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716552176; a=rsa-sha256; cv=none; b=T4GeModoZ82zKoQleXTkECmEJWYrM1877+WtV4co6IS2HEqox2Ek++aj2zfMs5+iPPzFpI lz/ZWP+XbLx5KZrwrideQntDqqnnV933bEINEGkl2ZvldZV73yR2/Z2d4YJiedZD70V3d0 JSQu0hXo898WPV/99OaQpwnUcsqOgns= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-41ff3a5af40so53145e9.1 for ; Fri, 24 May 2024 05:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716552175; x=1717156975; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=CLDLdXYwwkToVr8Cvp+hiWbFyJwd77OjF46C3hbvTe4=; b=mgJicXEadMP4+c1sRf2Gb0F0eA6HdoRPzc1y6IPG2whheJ/T31E/yZLv0Dw2hsxH8g SkO1r4iun5xlntxOUQi6Yu7hpKGfPNMlqIxgsbKr6o8zVkbJjUfeOkvssttLRpHlO821 EyrB4DiREZh6wuwxMjhguUlwOuMbnecbxvIKlqzkp8iPYD/XNiZd2VRcqf7pERzIvfH6 gt/fOpuBzMzsQg0rPw84eEan/MmVcJviy646kpWN0RA7xrFRYu04+q63HnjN5/srwr9A dl6f0y4+OqBsNGSnZUq0HLn2xdfnPJdSOunaiOkL4wCr964Gv3r82YOzMT1Qzzim/DF1 SdMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716552175; x=1717156975; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=CLDLdXYwwkToVr8Cvp+hiWbFyJwd77OjF46C3hbvTe4=; b=mgaT8PGym+wjnbLer8ofd2HQLh1ISTDkIzEBupFosu0ogTJoqdDS7RHDHlFSP/QdkA uS7aCfsevcF9S2g3zJgaJrbFnWYN3kITmWC/GfeSitWNz2ngZuPamY4q5iXApDNfe2RU T2LbiUlZfRseTi7/HWzxqhcRSSOG1y/a478xziF8dcCH/0zyl6pudlWyQlhF2iIB5Apo 1JFrqOcABWyxbT1gWOWmlsDn5CRjcHDb3KO0zb9jywRW8kwtgZOPiS2Igfm3XFxZR6u1 rYLodktUrwr7t4YsJklv5jf9iuQyEL7iw1i8CqrgjyOb7u4o/q6vitsLD5dXEfRlF7Px uvTQ== X-Forwarded-Encrypted: i=1; AJvYcCUW02rtrKF7YX1zV9TASw2AZBnGYwHHQWT0goIPAiB21sBeZ8h6kr/JQIxoAcSosyj2lZZwSjKcED02Kmar2Regjvo= X-Gm-Message-State: AOJu0YxxgZ8wsFMnoAjdpgbMbv60fr7fk43wjWH21KjfguQUlxZkIkXo GIXY2fshVtUpszbJk7VgyRsLi3Iww/HBhnMyLxOOfl1vU+nplYmrL81qi9MUdA== X-Google-Smtp-Source: AGHT+IHBz2OtaFxzTtLCx3Q8o844GxjnoTVVIQiqS0otNnrBXZRKPB+Oi84Q3A4D/WxrbMUNsob+Bw== X-Received: by 2002:a05:600c:1e04:b0:41b:4c6a:de7a with SMTP id 5b1f17b1804b1-42108dc191amr1284895e9.3.1716552174495; Fri, 24 May 2024 05:02:54 -0700 (PDT) Received: from google.com (49.240.189.35.bc.googleusercontent.com. [35.189.240.49]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3557a08abd8sm1451216f8f.32.2024.05.24.05.02.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 May 2024 05:02:53 -0700 (PDT) Date: Fri, 24 May 2024 12:02:45 +0000 From: Brendan Jackman To: David Hildenbrand Cc: Oscar Salvador , Andrew Morton , Mike Rapoport , Michal Hocko , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm,memory_hotplug: Remove un-taken lock Message-ID: References: <20240521-mm-hotplug-sync-v1-0-6d53706c1ba8@google.com> <20240521-mm-hotplug-sync-v1-1-6d53706c1ba8@google.com> <78e646af-e8b5-4596-8fbf-17b139cfdddd@redhat.com> <0506ae4e-e17d-4c3c-aa3e-1cea04909e5a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0506ae4e-e17d-4c3c-aa3e-1cea04909e5a@redhat.com> X-Rspamd-Queue-Id: 53F6DA001F X-Stat-Signature: 6goeisy3p5ntyd18be3m997ror4joc4j X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1716552176-382754 X-HE-Meta: U2FsdGVkX1+jGgepC65K19rdJuKIsyV1ntKMvskZr87nnWExuUn7nqddDXyacKZI1LFYdv52rL4yPhBVEeLCiJuKU05MY602U+fIF/jyHV5gLcyjQwWnjmViGtJsQvbn6n8QYxYrxmbmiGUmEPaxmyl6LeVgCIbHXomb0Qe4zQ2yqVvth7r5HA2H4fwUX8ZzPdzMOOOAIRWYqnpaCJRSrajhpNAfwtnS4tZveWBB/aaDuaHfE/YJcXv/G4YR2v7DZ3ztQK6MMF9ZPku9EH1SykM2r5TCkK9CJ8Da6I+o6cOVCJ2rX2JzzMwmMR4RU2yNjd7UoXpfbPGz+uj8f6Q4r2gW7OLdvtD2NOO7EbCdYaEngCs8A+LH08suLoADOzEqcdLI1chMQrhMvjPXPOK0tCNWf4xIOkLPSM6WRnW14MVCflLfyTuanPpTcR0sIiYp3bZjJ8ztctS69JAodO71pJXlgoskFhLVZVxmM7d2YIRZuNLQhZ73DXAXTw8K4sGLbr1aX41ABJxZjDFnfmONKOlKAHoiDErfkVFqmycURHQFzNwRTyt2E1KRIamboOhyq7epdOP86hcnNE9DoHYA+yIN6AKGAzUk+dxN8kM6xe6xv8YLSAss/kAvQVJNvk6VJJtrK5IloPNn1JLQi30AXw7cPXNPvYGFoiUnHCxGGoSEgX/CfMvlK+xao7Gdh3k3LaiIw1EKQBPcI/MuJvNeRrUuJJt94KjKYIDwBrXIZ4QonRV7OL3y2CgW8pZjUZ0SXRlzf+8Ti64tgqK23wJ3kw+L/Fo0OEjUD65zCoZcsSQQ4HfCqDZVX9y2e1tT+aHcikDZCeNg8hp0SRdr3fzTvjNfV0vsYrMtcLbHTdgj5sCvbS+j17MTCVLUaGc7qkVPB+bBKcVlmzGiIkGhBslQtg4hz8m/curcH2dA/UaSCcL/xf97K8LEDk7jxIrqYN8z4yNQH6b4Bhw7FpfwJYi 3PkU54S4 LJ9eEcfu42+SxFt5RjuheXEowt23KPgnJEp1PfXhncO0GR9G39gAeGq1P2L9sWs7g+h1v1gOZRU5RpzQ0GNuJa137cXwqEn9RS9jnjWddlZeqQ8bjJcX71qeDgzgQssb8JMWf X-Bogosity: Ham, tests=bogofilter, spamicity=0.020739, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, May 22, 2024 at 05:24:17PM +0200, David Hildenbrand wrote: > On 22.05.24 16:27, Brendan Jackman wrote: > > On Wed, May 22, 2024 at 04:09:41PM +0200, David Hildenbrand wrote: > > By the way, some noob questions: am I OK with my assumption that it's > > fine for reader code to operate on zone spans that are both stale and > > "from the future"? thinking abstractly I guess that seeing a stale > > value when racing with offline_pages is roughly the same as seeing a > > value "from the future" when racing with online_pages? > > Right. PFN walkers should be using pfn_to_online_page(), where races are > possible but barely seen in practice. > > zone handlers like mm/compaction.c can likely deal with races, although it > might all be cleaner (and safer?) when using start+end. I recall it also > recalls on pfn_to_online_page(). > > Regarding page_outside_zone_boundaries(), it should be fine if we can read > start+end atomically, that way we would not accidentally report "page > outside ..." when changing the start address. I think with your current > patch that might happen (although likely extremely hard to trigger) when > growing the zone at the start, reducing zone_start_pfn. Thanks a lot, this is very helpful > > Also, is it ever possible for pages to get removed and then added back > > and end up in a different zone than before? > > Yes. Changing between MOVABLE and NORMAL is possible and can easily be > triggered by offlining+re-onlining memory blocks. So, even if we make it impossible to see a totally bogus zone span, you can observe a stale/futuristic span which currently contains pages from a different zone? That seems to imply you could look up a page page from a PFN within zone A's apparent span, lock zone A and assume you can safely modify the freelist the page is on, but actually that page is now in zone B. So for example: 1. compact_zone() sets cc->free_pfn based on zone_end_pfn 2. isolate_freepages() sets isolate_start_pfn = cc->free_pfn 3. isolate_freepages_block() looks up a page based on that PFN 3. ... then takes the cc->zone lock 4. ... then calls __isolate_free_page which removes the page from whatever freelist it's on. Is anything stopping part 4 from modifying a zone that wasn't locked in part 3?