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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 34DF9C433E6 for ; Thu, 18 Mar 2021 17:58:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B56964EE2 for ; Thu, 18 Mar 2021 17:58:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B56964EE2 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 07D7A6B006C; Thu, 18 Mar 2021 13:58:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 01ABB6B0073; Thu, 18 Mar 2021 13:58:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E24326B0074; Thu, 18 Mar 2021 13:58:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id C57076B006C for ; Thu, 18 Mar 2021 13:58:54 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 7959D18000DA9 for ; Thu, 18 Mar 2021 17:58:54 +0000 (UTC) X-FDA: 77933755788.05.BCBAA78 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 2A7E0144D for ; Thu, 18 Mar 2021 17:58:34 +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=vZm4w+si9uU9aQrNJ3zwhuKonm9Y0JsStk/oRatNIc4=; b=QJVS2QBikxM65SlYiOHVDHGTvn jr2tWC5lD4nNxv30RZK00MhCdXvYT+rEuQa7l7tjRO0zyWCJb6VTWFL78QDlmm+eLHhEnyws/SA4r iAkbV3kr/ZNOnFDEXxSxFlI+QTnuDGb9m7pPWmHvk7AG+ZiV8DGhFom5aW4kg7PnAaVRU7uCV6XfQ 7/ronkKeYKGdpsSRDemEQnvpSjyslzK/7Mb8ThUxwyCrGbwx1gNg6befAQ54piW2Za17/yuUnj4bz xh/H8F0UyfdZ5auGs9f8wXp1yhjmomXf1BHaIdgFgZPory6Iydt6tM8AF9gl5j+nqeNmphr6CxpK6 uc5Oasyw==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lMwu7-003Jkp-S5; Thu, 18 Mar 2021 17:57:58 +0000 Date: Thu, 18 Mar 2021 17:57:51 +0000 From: Matthew Wilcox To: Christoph Hellwig Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 08/25] mm: Handle per-folio private data Message-ID: <20210318175751.GS3420@casper.infradead.org> References: <20210305041901.2396498-1-willy@infradead.org> <20210305041901.2396498-9-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 2A7E0144D X-Stat-Signature: gtmym1rnqewjmy5k6ot9pm87kh6aento Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616090314-121129 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, Mar 17, 2021 at 06:20:32PM +0100, Christoph Hellwig wrote: > > +static inline void attach_page_private(struct page *page, void *data) > > +{ > > + attach_folio_private((struct folio *)page, data); > > +} > > + > > +static inline void *detach_page_private(struct page *page) > > +{ > > + return detach_folio_private((struct folio *)page); > > +} > > I hate these open code casts. Can't we have a single central > page_to_folio helper, which could also grow a debug check (maybe > under a new config option) to check that it really is called on a > head page? Some of that is already there. We have page_folio() which is the page_to_folio() helper you're asking for. And folio_flags() (which is called *all the time*) contains VM_BUG_ON_PGFLAGS(PageTail(page), page); Someone passing around a tail pointer cast to a folio is not going to get very far, assuming CONFIG_DEBUG_VM_PGFLAGS is enabled (most distros don't, but I do when I'm testing anything THPish). These helpers aren't going to live for very long ... I expect to have all filesystems which use attach/detach page private converted to folios pretty soon. Certainly before any of them _use_ multi-page folios. Anyway, the simple thing to do is just to use page_folio() here and eat the cost of calling compound_head() on something we're certain is an order-0 page. It only defers the win of removing the compound_head() call; it doesn't preclude it. And it means we're not setting a bad example here (there really shouldn't be any casts from pages to folios, except in the folio allocator, which uses the page allocator and then casts what _must be_ a non-tail page to a folio).