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 9344DC54FB3 for ; Fri, 30 May 2025 01:16:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 10DF86B0082; Thu, 29 May 2025 21:16:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E5D46B0085; Thu, 29 May 2025 21:16:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3FB86B0088; Thu, 29 May 2025 21:16:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D4F826B0082 for ; Thu, 29 May 2025 21:16:33 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 48AD6121C6A for ; Fri, 30 May 2025 01:16:33 +0000 (UTC) X-FDA: 83497809066.27.C31D99A Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf20.hostedemail.com (Postfix) with ESMTP id 829BE1C000E for ; Fri, 30 May 2025 01:16:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748567791; a=rsa-sha256; cv=none; b=x/mSsF8kTm9rug89NcZsy+R39MPgylkCc4nti09TVE/Yfm4qsuclU38504YPM/akJgN7gE sKZ45A3Q9QJpr5GnMiqmQh6JbRjjFzIcidlYXlnKtyjJFFTvFlyqlZ1ySGM+Lg+vQNmXQa 3g18C36IxYcKCoxgWaqxdMlLj5A9IRg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748567791; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zX70O6fNIR3kMvXOMBb2hMjvpIakvc8+p8XQDKjXljE=; b=iVGLsryS1skKTP//Fn+HLfActTfOT4KO2SLHLvL5HWr4jXKzDNerpe7zCtQsTHpZln2Roj 1AcMC/NL1iWcCc8Zp64VAGVemh8KhPot+cXm3xbbUR6R21HaSg0Gf8WzXVk6t5j3lv4WcP F1XHPz6VGyPhVkfE60v6cdRIO5xVtKo= X-AuditID: a67dfc5b-669ff7000002311f-62-683906ea504f Date: Fri, 30 May 2025 10:16:21 +0900 From: Byungchul Park To: Mina Almasry Cc: willy@infradead.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com, kuba@kernel.org, ilias.apalodimas@linaro.org, harry.yoo@oracle.com, hawk@kernel.org, akpm@linux-foundation.org, davem@davemloft.net, john.fastabend@gmail.com, andrew+netdev@lunn.ch, asml.silence@gmail.com, toke@redhat.com, tariqt@nvidia.com, edumazet@google.com, pabeni@redhat.com, saeedm@nvidia.com, leon@kernel.org, ast@kernel.org, daniel@iogearbox.net, david@redhat.com, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, horms@kernel.org, linux-rdma@vger.kernel.org, bpf@vger.kernel.org, vishal.moola@gmail.com Subject: Re: [RFC v3 18/18] page_pool: access ->pp_magic through struct netmem_desc in page_pool_page_is_pp() Message-ID: <20250530011621.GB3093@system.software.com> References: <20250529031047.7587-1-byungchul@sk.com> <20250529031047.7587-19-byungchul@sk.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA02Sf0yMcRzH+97zfZ57Ot32OIdv2ZizFm0Siz62Fv+wx+a3fwzDcc/c5era XVLGnApzUyiG68olqqt028lVtEpFUtQutUu4dpTNohGtRHSl6b/33p/3+/P6/PFhKdltOojV xCUI+jilVsFIsORzQN7yT8xadbi3Nhws9lIGSkaSoLC3kgZLsRPB99EeMQw1NjGQnzdMgaUt DcMP+08K+p56xeAp6MdQfb6CAu+lZwykp41RkFJZJIJ2ZwYNV3/epaDC2CuGjocWBt6V/qGh vz4dQ7PZhsGTsR6eWufBcMsAgkZ7hQiGL+YwkOWyMvA+zYPA1eDFkH0mA4G9xk3D2IiFWb+Y L7d1i/gq81sxb3Uc4+8XhfImt4viHcUXGN7xLVPMv+mqZvhnN8YwX1U5JOLTU78w/Ne+15gf rOlkeHt5J+ZbrY1ifsixcDu3RxKlErSaREG/IvqgRN1tM1LxvfOSPme/oYzonMyE/FnCRRBj /3N6Wnv6r01qzAUTb1Ot2KcZLoS43aOUT8u5ZeROzZXJDMV5aPLSEmNCLDuH05HmqnifLeUi iaPq+kRcwsq4QkQ6Bz7SU4PZpPnmBzzVDSG/cl2Ur0txC0jhODtlLyKpD7InUf7cDlI0Pj4Z n8stIXXOJpFvJ+HKWdJlefTv5kDyuMiNL6PZ5hkI8wyE+T/CPANhRbgYyTRxibFKjTYiTJ0c p0kKO6yLdaCJzyk49WtvJfrWvqsecSxSBEjDo0Eto5WJhuTYekRYSiGXpqxbo5ZJVcrkE4Je d0B/TCsY6tECFivmS1cNH1fJuCPKBOGoIMQL+umpiPUPMiLtp/s7W6NUr8y6TQyJ1h0SBd8K LvHbsqEnaGmbsqTheIwhZZ9T5RownYpsf6ePPHL15EqXOD/rxe4ttjJyxq8u5+y9lrx1+0MO 5wYmlp5vl5fMSm0SnZY34w7Htq2b5Z0ZvxWXXS8HV7v6ejLxCfVGQ1jZhSdzQu8wJuetwblj 1QpsUCtXhlJ6g/Ivt6oqCjUDAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA02SW0iTYRjHe/cd9jlbfC6zFw2C2bCig6HZ07mb6KWgEqLEi3TkR1vNKZua RsFKU7LUrFZrLl1ZnjIGy9SFWZjkpLCaGVrqbHnofNLEmlhNibz78z/8npuHo2QnmGBOrU0R dFqlRs5KaMn2tZlL37OrVeFXs+eDxVbNwo2xdCjvq2fAUlWLYOTnKzEMN7ewUHpllALLkywa fth+UTDw0CMGd9kgDQ05dRR4Cpws5GV5KTheXyGCB5dbGXham8/A+V/XKagz9Imh/Y6Fhd7q 3wwMNuXR0GqupMGdvwkeWoNg9NFHBM22OhGMnr7MwjmXlYU3WW4ErgceGoqO5SOwNXYy4B2z sJvkpKayS0Qc5h4xsdpTya2KxSS300URe9VJlti/nxWT7hcNLHGavDRx1A+LSF7mZ5Z8G3hJ ky+NHSwpfftVRGw1HTR5bG0W7wyIlaxLEDTqNEG3fEO8RNVVaaCS+4LSPxV1UwaULctFfhzm I7F70Mj4NM0rsKflntinWT4Md3b+pHw6kF+ErzUWTnYo3s3gNsuBXMRxs/kk3OpI9tlSfhW2 Oy7+rUs4GV+OcMfHIWYqCMCtl/rpqW0YHi92Ub4txYfg8gluyp6PM28XTZ7y46NxxcTEZH0O H4rv17aIzqBZ5mkk8zSS+T/JPI1kRXQVClRr0xKVas3KZfqDqgytOn3ZvqREO/r7HGVHxwvr 0Uj7libEc0g+UwqbQSVjlGn6jMQmhDlKHig9vjFKJZMmKDMOC7qkOF2qRtA3oRCOls+Vbt0j xMv4/coU4aAgJAu6f6mI8ws2oN4CTVzEctGOuuLXNv/EhUdOXzN/sA4tiHbtjYg03LowGnXo N1Xl/9zGGElMz6zIU86Y9TeZhiXnn4W4VIr349vahkJr5oXHlHiNgTNmGgaOGXcPV5SYAt7F m3oj7eG75q3ZSu9WKGy4MCfhTGj/YAGzwDQWGxTLFcuUZMldp7+c1quUKxZTOr3yD4i/9+QY AwAA X-CFilter-Loop: Reflected X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 829BE1C000E X-Stat-Signature: iz1roimqqwutp8aix67hkdyjpokcej7c X-Rspam-User: X-HE-Tag: 1748567790-423883 X-HE-Meta: U2FsdGVkX18lfKaV/NByAK6KEdGh9Bz1tZWt6rtf9DLhYNlfesLxMW5lqdUSX+7Ccl5XtcpD8VxVbMK+Awf5jUaOcykbmpDlD5W0+fhyuR44IUFhNzp9TbFtPnVQ7ZWHPQkm1uAn+Ztqno/trm+l53roe5DFNJb+YElmNZUFhP6MLcgX7ThSVSuZN2h0vdamIlsAx/lI7+5ft0MZ33GaouCla+/1/QZx50QNGK/mZXrskzvNIFmBrcWQSHH/ePuwshy7PxfNf1h2E87pVAAn3RRYhGOuYnA11Mowv2Q8ZnFTJ03lDP4CvhVqWSdNhThxsrOYdcCPWhJoy3uwFXbBwC/Cnt0Xi8PqZkjNPWQ7PdGL+rIaeblpJisra91WR7DkDtjbqE3VToOiy4U20wUWZER8Rnzt0XgusJhFAJZLNjMRJoa3vCodXAhltQawP+3xyRWfcmufk2/qRbsSbsPI3t82c8saNvtrEVdYVNT9vlfiCbSUZ+a/+Ofre5Y8ieOjBsAbkWwq6dhrboRLzgbPZxtLq0itNVJXsiZk+uuz5rhm4XyB9KdsplsQAHLyFpZudvXe7e1TpZIDz+r+YpUx8moqiFscTyy/ybaUfWq4nb5tNNs5T72r2QvYduqfvLh73zsL3OaUwM0B7k4KQqMkM2v2bXFQ+X0E8oZtfR5spypK02HmnLS1SuhgUMIegrz2C9BOK5fqjZtPz+r8TloWV3LidVC1rGnaAONuumq9XLhxXDPpRYFvCI/IsvvYzz9Umy1k0a35l/EgxFOIfA0Ot3gTHwxAuK+vvNzSRzIWj1MN2pf/Ospg+IY55DAXbQSam0kkTtk8AA/K5YLPOpcjhnH+caMQiao1EWx1BhL/itG6vMfchis6uVf0EJKl2uxAztB1qzU21HMNtal1bBFOu+nSGT9ZL6CNbTl0idPFLgNqlmq3tS+PUGOXbnMOX/+xTbo9b9GlXmrqkMLO2Y3 UIDZYib/ lqYQ6i/cVqunFW2UvEorI295FSpNTCxEq98LnqgHhbidxRqJhhw1TK3sY/VtLYkcAhS8cCztH1pJZ6nGcqTa9LCuEHrIoBiGzdVbQHFcxJlXF1SAwITlmGQqry+5s/2nVBPqaKeuiRXgVzmlCA3zmLJwDRQ== 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, May 29, 2025 at 12:54:31PM -0700, Mina Almasry wrote: > On Wed, May 28, 2025 at 8:11 PM Byungchul Park wrote: > > > > To simplify struct page, the effort to separate its own descriptor from > > struct page is required and the work for page pool is on going. > > > > To achieve that, all the code should avoid directly accessing page pool > > members of struct page. > > > > Access ->pp_magic through struct netmem_desc instead of directly > > accessing it through struct page in page_pool_page_is_pp(). Plus, move > > page_pool_page_is_pp() from mm.h to netmem.h to use struct netmem_desc > > without header dependency issue. > > > > Signed-off-by: Byungchul Park > > --- > > include/linux/mm.h | 12 ------------ > > include/net/netmem.h | 14 ++++++++++++++ > > mm/page_alloc.c | 1 + > > 3 files changed, 15 insertions(+), 12 deletions(-) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 8dc012e84033..de10ad386592 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -4311,16 +4311,4 @@ int arch_lock_shadow_stack_status(struct task_struct *t, unsigned long status); > > */ > > #define PP_MAGIC_MASK ~(PP_DMA_INDEX_MASK | 0x3UL) > > > > -#ifdef CONFIG_PAGE_POOL > > -static inline bool page_pool_page_is_pp(struct page *page) > > -{ > > - return (page->pp_magic & PP_MAGIC_MASK) == PP_SIGNATURE; > > -} > > -#else > > -static inline bool page_pool_page_is_pp(struct page *page) > > -{ > > - return false; > > -} > > -#endif > > - > > #endif /* _LINUX_MM_H */ > > diff --git a/include/net/netmem.h b/include/net/netmem.h > > index f05a8b008d00..9e4ed3530788 100644 > > --- a/include/net/netmem.h > > +++ b/include/net/netmem.h > > @@ -53,6 +53,20 @@ NETMEM_DESC_ASSERT_OFFSET(pp_ref_count, pp_ref_count); > > */ > > static_assert(sizeof(struct netmem_desc) <= offsetof(struct page, _refcount)); > > > > +#ifdef CONFIG_PAGE_POOL > > +static inline bool page_pool_page_is_pp(struct page *page) > > +{ > > + struct netmem_desc *desc = (__force struct netmem_desc *)page; > > + > > Is it expected that page can be cast to netmem_desc freely? I know it > works now since netmem_desc and page have the same layout, but how is > it going to continue to work when page is shrunk and no longer has This should be updated once struct netmem_desc has its own instance from slab. As Pavel mentioned, that should be done another way. > 'pp_magic' inside of it? Is that series going to fixup all the places > where casts are done? > > Is it also allowed that we can static cast netmem_desc to page? > > Consider creating netmem_desc_page helper like ptdesc_page. Do we need casting netmem_desc to page? > > I'm not sure the __force is needed too. Ah, I will remove it. Byungchul > > -- > Thanks, > Mina