Message ID | 20240115083337.1355191-1-hsiangkao@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-25736-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:693c:2614:b0:101:6a76:bbe3 with SMTP id mm20csp1573467dyc; Mon, 15 Jan 2024 00:34:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IFPMqMyqHZW67s3yP9hBeckYyEAVFrCqom0MCDjom4wYHh1KGJLA2gQCCoTPTFowCDJw4XC X-Received: by 2002:a05:6a20:7f87:b0:19a:419f:64c6 with SMTP id d7-20020a056a207f8700b0019a419f64c6mr5697094pzj.12.1705307652749; Mon, 15 Jan 2024 00:34:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1705307652; cv=none; d=google.com; s=arc-20160816; b=QHV+og5VaYiYymYwIZ4hxVeYOXymrbexFOSxZ/T3F8+BZlQouUN+7o5dLge74Nq5M/ D6NeZsk3EdUBXjVYiDP1b8YlLkb8cnoxZYCAcdrSg5Rlg7rnGNA8fKGp0aDhqPteF0G2 awXSuXoiwwevjHvPiqEltqQ0NUSB0/orzvxBnl6bPxBE2DLGOgxNsIIq8AycNonCgqy8 6/lZua+K/BwjoPvNCjg52vUgZEp+NEFWggJ9z4kTwKvPCx8eDWbvifZxVK2eZOnQXEZ9 UHqqzW/j89N6vv2APGh0v52pjC0yBTgAD02kNXTEaW3jPsOPIaf60IOo0cSNIlEOkTuo 3sbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=/y/yzL8tML/pf3ry6uK+QziwiYPOWOXTZCXt4B4L3BQ=; fh=o2uHjugiPjB58XdARDWJKl3FTaqNvXZ1kJ/rwPVuIMM=; b=ABAoeTguR5cvcu8ggOywyS2cvUQmWBCxSd53D8oQ4JormXM6cQbdhY6Z0r/xCYO7lJ OtuANWwnn7d2SAj+DDavavDFN/7gFsPA4RsXNhRYYJdvzmOxFohxy9ph//Dgw53ECJic k1IY86HxYFxwhHH+k10pQw66ZKZYZ3E+sCSz18/Bfx+a8xjQiHgucd2LojPrvVJCfh0s bon5WuYH+5mOkCAqcEstEn1QD3aMyL7FMLmO5K4M8UQtbdGxT5LOfKfeNaS3PlWSh5s/ U9+JR0rwQgwp3/4UvoHQCQk0HZGda7KkiNUISnK1eUjgxn8EXNDjtqCnfsMhR16pBeeJ Z/Zw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-25736-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25736-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id kq11-20020a170903284b00b001d48a73f1fdsi8004642plb.163.2024.01.15.00.34.12 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 00:34:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-25736-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-25736-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-25736-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 65656281AE9 for <ouuuleilei@gmail.com>; Mon, 15 Jan 2024 08:34:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BD4BB748F; Mon, 15 Jan 2024 08:33:57 +0000 (UTC) Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52C466FA4; Mon, 15 Jan 2024 08:33:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R181e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045176;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=12;SR=0;TI=SMTPD_---0W-eUMPj_1705307618; Received: from e69b19392.et15sqa.tbsite.net(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0W-eUMPj_1705307618) by smtp.aliyun-inc.com; Mon, 15 Jan 2024 16:33:44 +0800 From: Gao Xiang <hsiangkao@linux.alibaba.com> To: linux-cachefs@redhat.com, linux-fsdevel@vger.kernel.org, linux-erofs@lists.ozlabs.org, David Howells <dhowells@redhat.com>, Christian Brauner <christian@brauner.io>, Jeff Layton <jlayton@kernel.org> Cc: LKML <linux-kernel@vger.kernel.org>, Matthew Wilcox <willy@infradead.org>, Chao Yu <chao@kernel.org>, Yue Hu <huyue2@coolpad.com>, Jeffle Xu <jefflexu@linux.alibaba.com>, Gao Xiang <hsiangkao@linux.alibaba.com> Subject: [PATCH v2 3/4] erofs: Don't use certain internal folio_*() functions Date: Mon, 15 Jan 2024 16:33:37 +0800 Message-Id: <20240115083337.1355191-1-hsiangkao@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1788144677455761174 X-GMAIL-MSGID: 1788144677455761174 |
Series |
None
|
|
Commit Message
Gao Xiang
Jan. 15, 2024, 8:33 a.m. UTC
From: David Howells <dhowells@redhat.com> Filesystems should use folio->index and folio->mapping, instead of folio_index(folio), folio_mapping() and folio_file_mapping() since they know that it's in the pagecache. Change this automagically with: perl -p -i -e 's/folio_mapping[(]([^)]*)[)]/\1->mapping/g' fs/erofs/*.c perl -p -i -e 's/folio_file_mapping[(]([^)]*)[)]/\1->mapping/g' fs/erofs/*.c perl -p -i -e 's/folio_index[(]([^)]*)[)]/\1->index/g' fs/erofs/*.c Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Cc: Chao Yu <chao@kernel.org> Cc: Yue Hu <huyue2@coolpad.com> Cc: Jeffle Xu <jefflexu@linux.alibaba.com> Cc: linux-erofs@lists.ozlabs.org Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> --- Hi folks, I tend to apply this patch upstream since compressed data fscache adaption touches this part too. If there is no objection, I'm going to take this patch separately for -next shortly.. Thanks, Gao Xiang Change since v1: - a better commit message pointed out by Jeff Layton. fs/erofs/fscache.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Comments
On Mon, Jan 15, 2024 at 04:33:37PM +0800, Gao Xiang wrote: > From: David Howells <dhowells@redhat.com> > > Filesystems should use folio->index and folio->mapping, instead of > folio_index(folio), folio_mapping() and folio_file_mapping() since > they know that it's in the pagecache. > > Change this automagically with: > > perl -p -i -e 's/folio_mapping[(]([^)]*)[)]/\1->mapping/g' fs/erofs/*.c > perl -p -i -e 's/folio_file_mapping[(]([^)]*)[)]/\1->mapping/g' fs/erofs/*.c > perl -p -i -e 's/folio_index[(]([^)]*)[)]/\1->index/g' fs/erofs/*.c > > Reported-by: Matthew Wilcox <willy@infradead.org> > Signed-off-by: David Howells <dhowells@redhat.com> > Reviewed-by: Jeff Layton <jlayton@kernel.org> > Cc: Chao Yu <chao@kernel.org> > Cc: Yue Hu <huyue2@coolpad.com> > Cc: Jeffle Xu <jefflexu@linux.alibaba.com> > Cc: linux-erofs@lists.ozlabs.org > Cc: linux-fsdevel@vger.kernel.org > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> > --- > Hi folks, > > I tend to apply this patch upstream since compressed data fscache > adaption touches this part too. If there is no objection, I'm > going to take this patch separately for -next shortly.. Could you change the subject? It's not that the functions are "internal", it's that filesystems don't need to use them because they're guaranteed to not see swap pages. Maybe just s/internal/unnecessary/ > Thanks, > Gao Xiang > > Change since v1: > - a better commit message pointed out by Jeff Layton. > > fs/erofs/fscache.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/fs/erofs/fscache.c b/fs/erofs/fscache.c > index 87ff35bff8d5..bc12030393b2 100644 > --- a/fs/erofs/fscache.c > +++ b/fs/erofs/fscache.c > @@ -165,10 +165,10 @@ static int erofs_fscache_read_folios_async(struct fscache_cookie *cookie, > static int erofs_fscache_meta_read_folio(struct file *data, struct folio *folio) > { > int ret; > - struct erofs_fscache *ctx = folio_mapping(folio)->host->i_private; > + struct erofs_fscache *ctx = folio->mapping->host->i_private; > struct erofs_fscache_request *req; > > - req = erofs_fscache_req_alloc(folio_mapping(folio), > + req = erofs_fscache_req_alloc(folio->mapping, > folio_pos(folio), folio_size(folio)); > if (IS_ERR(req)) { > folio_unlock(folio); > @@ -276,7 +276,7 @@ static int erofs_fscache_read_folio(struct file *file, struct folio *folio) > struct erofs_fscache_request *req; > int ret; > > - req = erofs_fscache_req_alloc(folio_mapping(folio), > + req = erofs_fscache_req_alloc(folio->mapping, > folio_pos(folio), folio_size(folio)); > if (IS_ERR(req)) { > folio_unlock(folio); > -- > 2.39.3 >
Hi Matthew, On 2024/1/15 22:06, Matthew Wilcox wrote: > On Mon, Jan 15, 2024 at 04:33:37PM +0800, Gao Xiang wrote: >> From: David Howells <dhowells@redhat.com> >> >> Filesystems should use folio->index and folio->mapping, instead of >> folio_index(folio), folio_mapping() and folio_file_mapping() since >> they know that it's in the pagecache. >> >> Change this automagically with: >> >> perl -p -i -e 's/folio_mapping[(]([^)]*)[)]/\1->mapping/g' fs/erofs/*.c >> perl -p -i -e 's/folio_file_mapping[(]([^)]*)[)]/\1->mapping/g' fs/erofs/*.c >> perl -p -i -e 's/folio_index[(]([^)]*)[)]/\1->index/g' fs/erofs/*.c >> >> Reported-by: Matthew Wilcox <willy@infradead.org> >> Signed-off-by: David Howells <dhowells@redhat.com> >> Reviewed-by: Jeff Layton <jlayton@kernel.org> >> Cc: Chao Yu <chao@kernel.org> >> Cc: Yue Hu <huyue2@coolpad.com> >> Cc: Jeffle Xu <jefflexu@linux.alibaba.com> >> Cc: linux-erofs@lists.ozlabs.org >> Cc: linux-fsdevel@vger.kernel.org >> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> >> --- >> Hi folks, >> >> I tend to apply this patch upstream since compressed data fscache >> adaption touches this part too. If there is no objection, I'm >> going to take this patch separately for -next shortly.. > > Could you change the subject? It's not that the functions are > "internal", it's that filesystems don't need to use them because they're > guaranteed to not see swap pages. Maybe just s/internal/unnecessary/ Yes, the subject line was inherited from the original one. Such helpers are useful if the type of a folio is unknown, let me revise it. Thanks, Gao Xiang
diff --git a/fs/erofs/fscache.c b/fs/erofs/fscache.c index 87ff35bff8d5..bc12030393b2 100644 --- a/fs/erofs/fscache.c +++ b/fs/erofs/fscache.c @@ -165,10 +165,10 @@ static int erofs_fscache_read_folios_async(struct fscache_cookie *cookie, static int erofs_fscache_meta_read_folio(struct file *data, struct folio *folio) { int ret; - struct erofs_fscache *ctx = folio_mapping(folio)->host->i_private; + struct erofs_fscache *ctx = folio->mapping->host->i_private; struct erofs_fscache_request *req; - req = erofs_fscache_req_alloc(folio_mapping(folio), + req = erofs_fscache_req_alloc(folio->mapping, folio_pos(folio), folio_size(folio)); if (IS_ERR(req)) { folio_unlock(folio); @@ -276,7 +276,7 @@ static int erofs_fscache_read_folio(struct file *file, struct folio *folio) struct erofs_fscache_request *req; int ret; - req = erofs_fscache_req_alloc(folio_mapping(folio), + req = erofs_fscache_req_alloc(folio->mapping, folio_pos(folio), folio_size(folio)); if (IS_ERR(req)) { folio_unlock(folio);