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 0961BC433EF for ; Wed, 13 Apr 2022 20:07:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D7B46B0072; Wed, 13 Apr 2022 16:07:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 088766B0073; Wed, 13 Apr 2022 16:07:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6C516B0074; Wed, 13 Apr 2022 16:07:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0128.hostedemail.com [216.40.44.128]) by kanga.kvack.org (Postfix) with ESMTP id D8EBB6B0072 for ; Wed, 13 Apr 2022 16:07:03 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 91CD9A7981 for ; Wed, 13 Apr 2022 20:07:03 +0000 (UTC) X-FDA: 79352939526.27.65A51C5 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf30.hostedemail.com (Postfix) with ESMTP id E3A7380003 for ; Wed, 13 Apr 2022 20:07:02 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 63D19B8276E; Wed, 13 Apr 2022 20:07:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1BE4C385A3; Wed, 13 Apr 2022 20:06:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649880420; bh=1lv0TYn1rI0bZiX2xcJLC6rgxIwufGUuDS8PwYZgZZE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oxeoUVNxqagKDTCoBhEg0ZjenI8HlagF6DUcw+G/PXtILlsb/+4C9pEpvNlD3uf3p E1v+kxYnRb8b20Y1YbQOvYk79efC+87JQDK3EzvaIg4gX5CtXbi6K6Z8Gfj7QI0Dop TYMDAmgwT9qN1CC287v6xLZf9RDalh20LNPvfCIJPDQlgqB5MU43zs16zcyjJp3bps aJhxG6La5MxAlJFcJ8YkEprju0ttd6mReGFuXZKsED7A7qu3OrktN/MXqtX+Y6z9Vh jaJNTthb2d6e3Adq6vTyH+gxu4FVqcgI5SXduICpNWFjEqDM466H4gwBr7tIY6rfE8 zQR8zc24UsmKQ== Date: Wed, 13 Apr 2022 23:06:46 +0300 From: Mike Rapoport To: "Kirill A. Shutemov" Cc: Dave Hansen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Brijesh Singh , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport Subject: Re: [PATCHv4 1/8] mm: Add support for unaccepted memory Message-ID: References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-2-kirill.shutemov@linux.intel.com> <767c2100-c171-1fd3-6a92-0af2e4bf3067@intel.com> <20220409155423.iv2arckmvavvpegt@box.shutemov.name> <6c976344-fdd6-95cd-2cb0-b0e817bf0392@intel.com> <20220413114001.wdsi2xrm4btrghms@box.shutemov.name> <20220413151517.tzd76kzja3424lqu@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220413151517.tzd76kzja3424lqu@box.shutemov.name> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E3A7380003 X-Stat-Signature: ossmoz8gfxodd63dcboyqwp6m3fj1uf3 Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oxeoUVNx; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf30.hostedemail.com: domain of rppt@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspam-User: X-HE-Tag: 1649880422-904180 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: On Wed, Apr 13, 2022 at 06:15:17PM +0300, Kirill A. Shutemov wrote: > On Wed, Apr 13, 2022 at 05:48:09PM +0300, Mike Rapoport wrote: > > On Wed, Apr 13, 2022 at 02:40:01PM +0300, Kirill A. Shutemov wrote: > > > On Mon, Apr 11, 2022 at 01:07:29PM +0300, Mike Rapoport wrote: > > > > On Sun, Apr 10, 2022 at 11:38:08PM -0700, Dave Hansen wrote: > > > > > On 4/9/22 08:54, Kirill A. Shutemov wrote: > > > > > > On Fri, Apr 08, 2022 at 11:55:43AM -0700, Dave Hansen wrote: > > > > > > > > > > >>> if (fpi_flags & FPI_TO_TAIL) > > > > > >>> to_tail = true; > > > > > >>> else if (is_shuffle_order(order)) > > > > > >>> @@ -1149,7 +1192,8 @@ static inline void __free_one_page(struct page *page, > > > > > >>> static inline bool page_expected_state(struct page *page, > > > > > >>> unsigned long check_flags) > > > > > >>> { > > > > > >>> - if (unlikely(atomic_read(&page->_mapcount) != -1)) > > > > > >>> + if (unlikely(atomic_read(&page->_mapcount) != -1) && > > > > > >>> + !PageUnaccepted(page)) > > > > > >>> return false; > > > > > >> > > > > > >> That probably deserves a comment, and maybe its own if() statement. > > > > > > > > > > > > Own if does not work. PageUnaccepted() is encoded in _mapcount. > > > > > > > > > > > > What about this: > > > > > > > > > > > > /* > > > > > > * page->_mapcount is expected to be -1. > > > > > > * > > > > > > * There is an exception for PageUnaccepted(). The page type can be set > > > > > > * for pages on free list. Page types are encoded in _mapcount. > > > > > > * > > > > > > * PageUnaccepted() will get cleared in post_alloc_hook(). > > > > > > */ > > > > > > if (unlikely((atomic_read(&page->_mapcount) | PG_unaccepted) != -1)) > > > > > > > > Maybe I'm missing something, but isn't this true for any PageType? > > > > > > PG_buddy gets clear on remove from the free list, before the chec. > > > > > > PG_offline and PG_table pages are never on free lists. > > > > Right, this will work 'cause PageType is inverted. I still think this > > condition is hard to parse and I liked the old variant with > > !PageUnaccepted() better. > > Well the old way to deal with PageUnaccepted() had a flaw: if the page is > PageUnaccepted() it will allow any other page types to pass here. Like > PG_unaccepted + PG_buddy will slide here. It seems to me that there was an implicit assumption that page types are exclusive and PG_unaccepted would break it. > > Maybe if we wrap the whole construct in a helper it will be less eye > > hurting. > > Hm. Any suggestion how such helper could look like? Cannot think of > anything sane. Me neither :( How about updating the comment to be /* * The page must not be mapped to userspace and must not have a * PageType other than PageUnaccepted. * This means that page->_mapcount must be -1 or have only * PG_unaccepted bit cleared. */ if (unlikely((atomic_read(&page->_mapcount) | PG_unaccepted) != -1)) > -- > Kirill A. Shutemov -- Sincerely yours, Mike.