Message ID | 20230310204431.GW3390869@ZenIV |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1094697wrd; Fri, 10 Mar 2023 12:55:40 -0800 (PST) X-Google-Smtp-Source: AK7set/mRwtTqgl2BaBC1SzQVyTz5XKnGYtvVvtc7AjJemF6IPp/zWK1UiH+tqM8jR8tH3cfw9TU X-Received: by 2002:a17:902:e88e:b0:19c:df17:7c8e with SMTP id w14-20020a170902e88e00b0019cdf177c8emr33106461plg.68.1678481740333; Fri, 10 Mar 2023 12:55:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678481740; cv=none; d=google.com; s=arc-20160816; b=mNtw2URLyAGi3b3c8wdk8HFkOz+mSH/jjvKg8lSbAQE+a4QCpEmzWrD46pqstoh/iy vU08zTsF432HsiPiac7zw+6hxWD8VGn1BF2jvV65j8+npub78aw/3fnCz+9/Mm88lDjW iKTls8FwsJJ/jhbrEGqSpAvBKO1zbIsaS6LoWm1qSgbOxIw7Kjq81Gp1AXeNZOo8O7O5 9RCFmAEj9cE0LL1hax9FOSp77JXZytJEjoFXulDqtVMRrQiMunES3y55WgrSlLiOxovm T3n4mdsSQyTtkwz0Yly9hEAYhIVjABMuuqvs9SwKlF8WISWEiKbeyXMaFYvdCHjLvWoO 5Hiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=tz+vuGIwfHd+fip08fefzwZeUYEctg8otTI+9qKtVOo=; b=mnSz6wQUvzqh1enix3OUxwB6KcGxn2SnRhjGMefV/Ik1JVkKlWpZIVx5KXymG6Uwzc JaC2UHk79wutLv2gt0oekgOdGh0BjprYB/4/6h/wHF4VGnuZ+PApemXI/Jf30SF4RXui 2sr7VPJ5+XEzptn8E+IcZK09gAmo4y0Ffa3ekBVwDZgvjBZjOuKww05KoTwf2USVd87y qThGvOwSeqFPvLydxFtqhF4Sw6RY5ns4/QzZPGc6QP8iyaMuZOPrVclTemPIk1AzdG7g d+3HA8Sn7GtaeSmrlKdvOngf4pJXk2qa6TgAM2H6O5CGwZYfUrCL4s5bMvMZYKIePVhm aBJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=OfPox7GK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c20-20020a170902c1d400b0019c91d2a997si747968plc.211.2023.03.10.12.55.12; Fri, 10 Mar 2023 12:55:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=OfPox7GK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=zeniv.linux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231514AbjCJUog (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Fri, 10 Mar 2023 15:44:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39442 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231535AbjCJUoe (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Mar 2023 15:44:34 -0500 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A40111BB2E; Fri, 10 Mar 2023 12:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:Content-Type:MIME-Version: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:In-Reply-To:References; bh=tz+vuGIwfHd+fip08fefzwZeUYEctg8otTI+9qKtVOo=; b=OfPox7GKIkzUc4oPqsEOPEms4S ++uYfrL+7iM4H5jcH20OvQA0iEdFQMGprSb2uBWPYc75SJ6Jm/mNNTRzUlpixjbMFuqJt1DzVqUSB TMa0FbIS0DoQQxNuobZov9Xzy4Y277IfBczQkfdXStgCfME6bt02IZIlCukptIZBt+FWxOKbpObKB K27MnPu/kSR0dM5xrtAsnQWBqA6Hy2YYdbiEN85HQjaIxYPyOxRnldq+6TPr2oComzd+5pY0+ko7N rAewdSBu/57AAGKmRaCkUIXR1rODXYNf7T/lorukvJdimpYTqZludwFjzwE1DszUKBFwEjbF9I31/ kuDDpPcw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1pajbL-00FQ86-0f; Fri, 10 Mar 2023 20:44:31 +0000 Date: Fri, 10 Mar 2023 20:44:31 +0000 From: Al Viro <viro@zeniv.linux.org.uk> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [git pull] common helper for kmap_local_page() users in local filesystems Message-ID: <20230310204431.GW3390869@ZenIV> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: Al Viro <viro@ftp.linux.org.uk> X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760015669645219996?= X-GMAIL-MSGID: =?utf-8?q?1760015669645219996?= |
Series |
[git,pull] common helper for kmap_local_page() users in local filesystems
|
|
Pull-request
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-highmemMessage
Al Viro
March 10, 2023, 8:44 p.m. UTC
kmap_local_page() conversions in local filesystems keep running into
kunmap_local_page()+put_page() combinations; we can keep inventing names
for identical inline helpers, but it's getting rather inconvenient. I've added
a trivial helper to linux/highmem.h instead.
I would've held that back until the merge window, if not for the
mess it causes in tree topology - I've several branches merging from that
one, and it's only going to get worse if e.g. ext2 stuff gets picked by
Jan.
The helper is trivial and it's early in the cycle. It would simplify
the things if you could pull it - then I'd simply rebase the affected branches
to -rc2...
The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6:
Linux 6.3-rc1 (2023-03-05 14:52:03 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-highmem
for you to fetch changes up to 849ad04cf562ac63b0371a825eed473d84de9c6d:
new helper: put_and_unmap_page() (2023-03-07 01:50:53 -0500)
----------------------------------------------------------------
put_and_unmap_page() helper
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
----------------------------------------------------------------
Al Viro (1):
new helper: put_and_unmap_page()
include/linux/highmem.h | 6 ++++++
1 file changed, 6 insertions(+)
Comments
The pull request you sent on Fri, 10 Mar 2023 20:44:31 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull-highmem
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d33d4c9e0888e9ee7666813b3f9ecc244a64d127
Thank you!
On venerdì 10 marzo 2023 21:44:31 CET Al Viro wrote: > kmap_local_page() conversions in local filesystems keep running into > kunmap_local_page()+put_page() combinations; we can keep inventing names > for identical inline helpers, but it's getting rather inconvenient. I've > added a trivial helper to linux/highmem.h instead. Yeah, "put_and_unmap_page()". Nice helper :-) Today I decided to prepare a series to convert all the functions of all the filesystems where I had found the above-mentioned pattern but I stopped immediately after converting dir_put_page() in fs/sysv. Why? Just because I realized that I do not understand the reasons behind the choice of the name of the helper... Why did you name it "put_and_unmap_page()" instead of "unmap_and_put_page()", for we always unmap first _and_ put the page immediately the unmapping? It seems it want to imply that instead we put first and unmap later (which would be wrong). That name sounds misleading to me and not sound (logically speaking). Am I missing some obscure convention behind your choice of that name for the helper? If not, can you please change it from "put_and_unmap_page()" to "unmap_and_put_page()"? Thanks, Fabio > > I would've held that back until the merge window, if not for the > mess it causes in tree topology - I've several branches merging from that > one, and it's only going to get worse if e.g. ext2 stuff gets picked by > Jan. > > The helper is trivial and it's early in the cycle. It would simplify > the things if you could pull it - then I'd simply rebase the affected branches > to -rc2... > > The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6: > > Linux 6.3-rc1 (2023-03-05 14:52:03 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git tags/pull- highmem > > for you to fetch changes up to 849ad04cf562ac63b0371a825eed473d84de9c6d: > > new helper: put_and_unmap_page() (2023-03-07 01:50:53 -0500) > > ---------------------------------------------------------------- > put_and_unmap_page() helper > > Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> > > ---------------------------------------------------------------- > Al Viro (1): > new helper: put_and_unmap_page() > > include/linux/highmem.h | 6 ++++++ > 1 file changed, 6 insertions(+)
On sabato 11 marzo 2023 18:11:01 CEST Fabio M. De Francesco wrote: > On venerdì 10 marzo 2023 21:44:31 CET Al Viro wrote: > > kmap_local_page() conversions in local filesystems keep running into > > > > kunmap_local_page()+put_page() combinations; we can keep inventing names > > for identical inline helpers, but it's getting rather inconvenient. I've > > added a trivial helper to linux/highmem.h instead. > > Yeah, "put_and_unmap_page()". Nice helper :-) [snip] Hi Al, > Why did you name it "put_and_unmap_page()" instead of "unmap_and_put_page()", > for we always unmap first _and_ put the page immediately the unmapping? > > It seems it want to imply that instead we put first and unmap later (which > would be wrong). That name sounds misleading to me and not sound (logically > speaking). > > Am I missing some obscure convention behind your choice of that name for the > helper? Can you please explain what I'm missing behind your motivation? Thanks, Fabio P.S.: Adding Ira to the Cc list, since he's been doing kmap() and kmap_atomic() conversions long time before I too started with them.