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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61FD9C47096 for ; Thu, 3 Jun 2021 08:38:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 050A5613E3 for ; Thu, 3 Jun 2021 08:38:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 050A5613E3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8AE6B6B006C; Thu, 3 Jun 2021 04:38:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85E106B006E; Thu, 3 Jun 2021 04:38:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C3D76B0070; Thu, 3 Jun 2021 04:38:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 3398A6B006C for ; Thu, 3 Jun 2021 04:38:29 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id C6538180AD802 for ; Thu, 3 Jun 2021 08:38:28 +0000 (UTC) X-FDA: 78211761096.36.C9A5AB6 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf02.hostedemail.com (Postfix) with ESMTP id B4D3F4202A29 for ; Thu, 3 Jun 2021 08:38:20 +0000 (UTC) Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id DC0091FD4D; Thu, 3 Jun 2021 08:38:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1622709506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zt2fjzTinBjC64Cl7tJnOBqSXBywln5vqKhFtXBD5pc=; b=Sn1/9hQHmHfPpCwhNXwfIj5VyyYze0wc5ZHI8qH9rhEe0vlhSqPaLcNNhfcSDtu6myAow+ Qc2o6x1ShjuGukUAzGoPrSUerMeqEy0tN5znm3UCPwNnkGgWZS3vQTedwfRf4jBEpzyxW8 CE2TkYX9SxoJtnUcNHuTYhOB7uLaxgo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1622709506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zt2fjzTinBjC64Cl7tJnOBqSXBywln5vqKhFtXBD5pc=; b=vWMRHpufxPiPK2KZIdZBeBikX5sTr8Wu9dGaLDno5+njY429b3f9TzrkuxUjcapw1/D1TS rbgWfnnu5gxcf3BQ== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id 3587C118DD; Thu, 3 Jun 2021 08:38:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1622709506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zt2fjzTinBjC64Cl7tJnOBqSXBywln5vqKhFtXBD5pc=; b=Sn1/9hQHmHfPpCwhNXwfIj5VyyYze0wc5ZHI8qH9rhEe0vlhSqPaLcNNhfcSDtu6myAow+ Qc2o6x1ShjuGukUAzGoPrSUerMeqEy0tN5znm3UCPwNnkGgWZS3vQTedwfRf4jBEpzyxW8 CE2TkYX9SxoJtnUcNHuTYhOB7uLaxgo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1622709506; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zt2fjzTinBjC64Cl7tJnOBqSXBywln5vqKhFtXBD5pc=; b=vWMRHpufxPiPK2KZIdZBeBikX5sTr8Wu9dGaLDno5+njY429b3f9TzrkuxUjcapw1/D1TS rbgWfnnu5gxcf3BQ== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id BgSbCQKVuGAQMwAALh3uQQ (envelope-from ); Thu, 03 Jun 2021 08:38:26 +0000 Date: Thu, 3 Jun 2021 10:38:24 +0200 From: Oscar Salvador To: David Hildenbrand Cc: Andrew Morton , Dave Hansen , Michal Hocko , Anshuman Khandual , Vlastimil Babka , Pavel Tatashin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/3] mm,page_alloc: Use {get,put}_online_mems() to get stable zone's values Message-ID: References: <20210602091457.17772-1-osalvador@suse.de> <20210602091457.17772-2-osalvador@suse.de> <39473305-6e91-262d-bcc2-76b745a5b14a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: B4D3F4202A29 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="Sn1/9hQH"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=vWMRHpuf; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="Sn1/9hQH"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=vWMRHpuf; dmarc=none; spf=pass (imf02.hostedemail.com: domain of osalvador@suse.de designates 195.135.220.29 as permitted sender) smtp.mailfrom=osalvador@suse.de X-Rspamd-Server: rspam03 X-Stat-Signature: pz8t7yxh6ykr17hnqx19wyrm6zzfbo8r X-HE-Tag: 1622709500-138206 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jun 02, 2021 at 09:45:58PM +0200, Oscar Salvador wrote: > It was too nice and easy to be true I guess. > Yeah, I missed the point that blocking might be an issue here, and hotplug > operations can take really long, so not an option. > I must have switched my brain off back there, because now it is just too > obvious. > > Then I guwmess that seqlock must stay and the only thing than can go is the > pgdat resize lock from the hotplug code. So, I have been looking into this again. Of course, the approach taken here is outrageously wrong, but there are some other things that are a bit confusing. As pointed out, bad_range() (the function that ends up calling page_outside_zone_boundaries) is called from different functions via VM_BUG_ON_*. page_outside_zone_boundaries() takes care of taking the seqlock to avoid reading stale values that might happen if we race with memhotplug operations. page_outside_zone_boundaries() calls zone_spans_pfn() to check that. Now on the funny thing. We do have several places happily calling zone_spans_pfn() without holding zone's seqlock, e.g: set_pageblock_migratetype set_pfnblock_flags_mask zone_spans_pfn move_freepages_block zone_spans_pfn alloc_contig_pages zone_spans_last_pfn zone_spans_pfn Those places hold zone->lock, while move_pfn_range_to_zone() and remove_pfn_range_from_zone() hold zone->seqlock, so AFAICS, those places could read a stale value and proceed thinking the range is within the zone while it is not. So I guess my question is, should we force those places to take the seqlock reader as we do in page_outside_zone_boundaries(), (or maybe just move the seqlock handling to zone_spans_pfn())? Because I does not make much sense to take it in a VM_DEBUG context and not in "real life". Thoughts? -- Oscar Salvador SUSE L3