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 9083DC3600C for ; Thu, 3 Apr 2025 14:10:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DBC1C280003; Thu, 3 Apr 2025 10:10:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6ABF280001; Thu, 3 Apr 2025 10:10:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C5C25280003; Thu, 3 Apr 2025 10:10:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AB198280001 for ; Thu, 3 Apr 2025 10:10:14 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4931FAA503 for ; Thu, 3 Apr 2025 14:10:15 +0000 (UTC) X-FDA: 83292917190.06.80829B6 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf19.hostedemail.com (Postfix) with ESMTP id 8F1C91A000B for ; Thu, 3 Apr 2025 14:10:13 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p4tCPFYY; spf=pass (imf19.hostedemail.com: domain of rppt@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743689413; 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=BdyFL4GeBSGa/19dqYa/jBUg//G09CApfxjPS3UQzQo=; b=X0tf282ZxmWwPcYFMdVn/Mxe3XeEitqkK0WzJJYq1gaNR4jgcRCXHB+dO1FPBeCkM63/jE 9aSkpO4E9Kc6JEqub8RKI+4tOm6pRAmxZ9g+/vISndLFvsXVmQFo9UnkxkYWwxc+/P/iiW TzMXIyjvLe3YlW9XjjOmiGOckwTOjwk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p4tCPFYY; spf=pass (imf19.hostedemail.com: domain of rppt@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743689413; a=rsa-sha256; cv=none; b=H1UIIW80JMCd9ACeI6WM7EZI4nDY0pEamnkA1QiV5LsAnk00Yo7OJ6q2JTMvOLat8W8hJO 7oowcP67J2ClTV8MYF1mMqxbekjmsiZ5kKudGzM+adFSGoLNCqkwG6+PzeHftuueq5fbW2 ot91ibi/dG7K7fQ0ABwVf8OqtQe4t7g= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id C408168429; Thu, 3 Apr 2025 14:10:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96A22C4CEE3; Thu, 3 Apr 2025 14:10:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743689412; bh=HehmzWN07oImSDzOXjOMFAC9bLomTxZFRkiMNjxI5FQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p4tCPFYYYPGoaZWejEYhyx1y7zD3cp3NTUeFqKkYekF1dCNx8KDC4P0g66yoeO4fj IwQeRmrNwV+NXJciR0mgdgA6w6dLUogofUeFKcS6brgieJ4VEzsExBZsOaZYHtc5fR sLRe6uQRvYTJw2G5EZMRtQ8sydPfG4I8GEmaP/Gm2jeQtdppNQCAGEDSHnU9vhK7Hq SFXipEe7jLpRvLbkwRKX3pJWCXfRBYqfkk9EXc8forpXVlHdDUfdZ3Vo4TcIpD8vk9 ui6dBY5E6bgi5+Ffe916I7e/DwfPLsM9iBqNRXH9PJO1hX3BTGEisqGFtMeFiPRumM 2X0cBdR7DNuXg== Date: Thu, 3 Apr 2025 17:10:03 +0300 From: Mike Rapoport To: David Woodhouse Cc: Andrew Morton , "Sauerwein, David" , Anshuman Khandual , Ard Biesheuvel , Catalin Marinas , David Hildenbrand , Marc Zyngier , Mark Rutland , Mike Rapoport , Will Deacon , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 3/3] mm: Implement for_each_valid_pfn() for CONFIG_SPARSEMEM Message-ID: References: <20250402201841.3245371-1-dwmw2@infradead.org> <20250402201841.3245371-3-dwmw2@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8F1C91A000B X-Stat-Signature: 8t85533qmiwf95qxquhn9hwfoib4t6so X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1743689413-489843 X-HE-Meta: U2FsdGVkX18PAwU9cUNIuhxiIM65yAV2MZyBQmSzGAADdNr0k0cQiImVg96Rf+z6WGaPabhvKdnEncnH11QBoCUa4mALf6N38JXPRsfqBQh5vnaFS956xHlV5r3ucHhUPFVrPFu5aDnuMs5vIHJUrAhu7A5ipbB+LFUzQBw89FzeD1Kbn90enHjgSxkKYUWD916/NlA29b3O+U4dyoVj7KWwF0MTdwaFosDybjLHbUWKlZef5eHjA55U6hMXSZ60VojtjltXVAiVxiXH2mBGTi48Ucd+mn/ghWcA4fXvCPAOlsR/a6isCaGxT+W59pdv+q1+ZxrWSNeJEFs237aA8wfCzZCRl88KgMLfmVPOd7Vv3KkTR1D4enVBfddLYDrK/vi9oTesbvrHHvyXIuNeaFH5w06F98+/WlZFLjCw5dOvp3L4oBNF93s0roO3frqKowbu/z39MjFLozcX4xRVL2rHU4i493jQtvGTkJdwjplxI+VH03QZik2r5lTrdZZ/wEkzNfeINyW5g5ARnhMaA3R4f0xgy0mFhJN5lwVsBtDsa+rILXZmcwKTugVjArpjQ7IfxgV1CKp1IMqmCncfX1Wr7mqCNC5DV69GGUbe0B+m2whBS4DhrJA7DmFXCAAE2uszSWTjko/szDDC5ntLEAtd4BRmF0Fn+iD3V/xBGzyUrNh3FK6sVkVrJhIM8Yyb7gOPNVKVzGh+z7mrpLJll/L9ORmgrt31COl/PDuFmkByyGbv4wwXTf4qsdVxSK6Wlax5UvX2+AWgLUh7O+TRc+ovhBLqfeU03nTfX0Vbn78iI1wxG9vEGIVjWW3va8I6ORpc3ytJXS6zk8+6gbh0pDbnTHI/jvilARO2uRNt249/tcbknUH84pYbORMqJrTi++73dPR29Blw5a4hoqU2MbvcVv8+ENzYW7lVTEV5ZGCcsaea7C+WKmQEGWxiTUlfBobzOF9hA0JvtVfATnq pteQECmq YT8qNSLYUMje706rXmHqdI9qLjf5+i61XJZPH5XTaGIQgInH4NDcRCchMago1d7WG3U+CpViH/0mW0q5ZQTxd/psNeO9RseTQ6TpRj0hx8G1sU2pnLHVDsh+CSvPqBbtlaI9LqEfTpVHcSs1U2LhRrrFqHXgEUrJuJsTqp3MaFAwnMtzNtzcZ3N1yYQtTjA4I2ZxTSPtDqXv4CbeWyi1E7KK8VGLi9yjxO/H2XJGeSpEdsSBQG0pkC/n0otMjNn6/RM5cvgBqD7i1KDoe7wBzez5X0z0XYWpiPHlV02b3KHbEcIs= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Thu, Apr 03, 2025 at 08:07:22AM +0100, David Woodhouse wrote: > On Thu, 2025-04-03 at 09:24 +0300, Mike Rapoport wrote: > > with a small nit below > > > > > +static inline bool first_valid_pfn(unsigned long *p_pfn) > > > +{ > > > + unsigned long pfn = *p_pfn; > > > + unsigned long nr = pfn_to_section_nr(pfn); > > > + struct mem_section *ms; > > > + bool ret = false; > > > + > > > + ms = __pfn_to_section(pfn); > > > + > > > + rcu_read_lock_sched(); > > > + > > > + while (!ret && nr <= __highest_present_section_nr) { > > > > This could be just for(;;), we anyway break when ret becomes true or we get > > past last present section. > > True for the 'ret' part but not *nicely* for the last present section. > If the original pfn is higher than the last present section it could > trigger that check before entering the loop. > > Yes, in that case 'ms' will be NULL, valid_section(NULL) is false and > you're right that it'll make it through to the check in the loop > without crashing. So it would currently be harmless, but I didn't like > it. It's relying on the loop not to do the wrong thing with an input > which is arguably invalid. > > I'll see if I can make it neater. I may drop the 'ret' variable > completely and just turn the match clause into unlock-and-return-true. > I *like* having a single unlock site. But I think I like simpler loop > code more than that. > > FWIW I think the check for (PHYS_PFN(PFN_PHYS(pfn)) != pfn) at the > start of pfn_valid() a few lines above is similarly redundant. Because > if the high bits are set in the PFN then pfn_to_section_nr(pfn) is > surely going to be higher than NR_MEM_SECTIONS and it'll get thrown out > at the very next check, won't it? I believe the check for (PHYS_PFN(PFN_PHYS(pfn)) != pfn) got to the generic version from arm64::pfn_valid() that historically supported both FLATMEM and SPARSEMEM. I can't think of a configuration in which (PHYS_PFN(PFN_PHYS(pfn)) != pfn) and pfn_to_section_nr(pfn) won't be higher than NR_MEM_SECTIONS, but with all variants that arm64 has for PAGE_SHIFT and ARM64_PA_BITS I could miss something. > I care because I didn't bother to duplicate that 'redundant' check in > my first_valid_pfn(), so if there's a reason for it that I'm missing, I > should take a closer look. > > I'm also missing the reason why the FLATMEM code in memory_model.h does > 'unsigned long pfn_offset = ARCH_PFN_OFFSET' and then uses its local > pfn_offset variable, instead of just using ARCH_PFN_OFFSET directly as > I do in the FLATMEM for_each_valid_pfn() macro. Don't remember now, but I surely had some $REASON for that :) -- Sincerely yours, Mike.