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=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 7B5F1C433B4 for ; Tue, 11 May 2021 14:19:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B8206188B for ; Tue, 11 May 2021 14:19:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B8206188B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7B5BE6B006E; Tue, 11 May 2021 10:19:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73F006B0070; Tue, 11 May 2021 10:19:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 569CC6B0072; Tue, 11 May 2021 10:19:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id 37DE26B006E for ; Tue, 11 May 2021 10:19:39 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E9AB782499B9 for ; Tue, 11 May 2021 14:19:38 +0000 (UTC) X-FDA: 78129158436.40.9E5A8FF Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id 116423FF for ; Tue, 11 May 2021 14:19:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vXY92xiVcSCoihG0TT6zFgFAzGF0aHK+j0EPAjfDpt4=; b=GMAgJT78CAXSRvHzqCyBh72c44 yKnOTdDeHdG8MpUntZdbv433uwQHd5/RqHWIbL6HmnYEwz3QL2KB8QuTc1gEegMHPB22ANVAU1B1f flJ5JdHESdxoJTK+gdCHe0f8B65Y7XohT+lruo0VVuHPIo5JYEp2Pz7mMNCu6O4573R1j9grt5KNM 0wnFsoyIDcNw+1betYYDi7JkSvSq7pqnIWz66UzWFXWnQrk3QIs0x6I3vCh0XDFvi0IvCoan7dwyt fEYmYsFekF+oqKr+5rANQZlGBFzvFBpd1tWHNl0S5rqeaAgumymOuP4ixa6eYpfV15tjeLh7R2HWo Wo6RbevA==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lgTDP-007LsX-8r; Tue, 11 May 2021 14:18:38 +0000 Date: Tue, 11 May 2021 15:18:27 +0100 From: Matthew Wilcox To: Ilias Apalodimas Cc: Matteo Croce , netdev@vger.kernel.org, linux-mm@kvack.org, Ayush Sawal , Vinay Kumar Yadav , Rohit Maheshwari , "David S. Miller" , Jakub Kicinski , Thomas Petazzoni , Marcin Wojtas , Russell King , Mirko Lindner , Stephen Hemminger , Tariq Toukan , Jesper Dangaard Brouer , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Boris Pismenny , Arnd Bergmann , Andrew Morton , "Peter Zijlstra (Intel)" , Vlastimil Babka , Yu Zhao , Will Deacon , Michel Lespinasse , Fenghua Yu , Roman Gushchin , Hugh Dickins , Peter Xu , Jason Gunthorpe , Jonathan Lemon , Alexander Lobakin , Cong Wang , wenxu , Kevin Hao , Jakub Sitnicki , Marco Elver , Willem de Bruijn , Miaohe Lin , Yunsheng Lin , Guillaume Nault , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, bpf@vger.kernel.org, Eric Dumazet , David Ahern , Lorenzo Bianconi , Saeed Mahameed , Andrew Lunn , Paolo Abeni , Sven Auhagen Subject: Re: [PATCH net-next v4 1/4] mm: add a signature in struct page Message-ID: References: <20210511133118.15012-1-mcroce@linux.microsoft.com> <20210511133118.15012-2-mcroce@linux.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=GMAgJT78; dmarc=none; spf=none (imf20.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: yj7y4qkopwqcckrbq1om74um9h8beuzy X-Rspamd-Queue-Id: 116423FF X-Rspamd-Server: rspam02 Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620742777-145005 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 Tue, May 11, 2021 at 05:11:13PM +0300, Ilias Apalodimas wrote: > Hi Matthew, > > On Tue, May 11, 2021 at 02:45:32PM +0100, Matthew Wilcox wrote: > > On Tue, May 11, 2021 at 03:31:15PM +0200, Matteo Croce wrote: > > > @@ -101,6 +101,7 @@ struct page { > > > * 32-bit architectures. > > > */ > > > unsigned long dma_addr[2]; > > > + unsigned long signature; > > > }; > > > struct { /* slab, slob and slub */ > > > union { > > > > No. Signature now aliases with page->mapping, which is going to go > > badly wrong for drivers which map this page into userspace. > > > > I had this as: > > > > + unsigned long pp_magic; > > + unsigned long xmi; > > + unsigned long _pp_mapping_pad; > > unsigned long dma_addr[2]; > > > > and pp_magic needs to be set to something with bits 0&1 clear and > > clearly isn't a pointer. I went with POISON_POINTER_DELTA + 0x40. > > Regardless to the changes required, there's another thing we'd like your > opinion on. > There was a change wrt to the previous patchset. We used to store the > struct xdp_mem_info into page->private. On the new version we store the > page_pool ptr address in page->private (there's an explanation why on the > mail thread, but the tl;dr is that we can get some more speed and keeping > xdp_mem_info is not that crucial). So since we can just store the page_pool > address directly, should we keep using page->private or it's better to > do: > > + unsigned long pp_magic; > + unsigned long pp_ptr; > + unsigned long _pp_mapping_pad; > unsigned long dma_addr[2]; > and use pp_ptr? I'd rather you didn't use page_private ... Any reason not to use: unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr[2]; ?