Message ID | 20230410022418.1843178-1-chao@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1642113vqo; Sun, 9 Apr 2023 19:51:10 -0700 (PDT) X-Google-Smtp-Source: AKy350a2lKNrXxZqVWul3rsZb3FiJAl4AdmLK3jnBn0nLR2g85ysN7YreAf2C5OH4UFNhDQuPTDf X-Received: by 2002:a17:902:dccc:b0:1a2:626b:ba1d with SMTP id t12-20020a170902dccc00b001a2626bba1dmr6356000pll.39.1681095070584; Sun, 09 Apr 2023 19:51:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681095070; cv=none; d=google.com; s=arc-20160816; b=lKHD4AekK55ulOkqF1r3Wz15QL9HhF1RQndMv6nPkZXUztSS74fCHZhomEj66hH3L8 7Rpkk/lTqt/6Nb1X6nGqs7ZGvGpyP0i/7IJqfakKqfTuoSCDiHhtp+tOdFVox3Gwqgmz u0ODZrfymhVBRd0pFzfLZZe3uHXbu9fl61ojqUKgLUeKACHv8eCoZh8CR0kFlTGTteYN 8J+COcI6ayQ/4C7bKpXHmk8eD7XUNBz4+yo/28L8hrFAjchlNmbbqvczkAksuBaArbFk UHP/sRkBYh/3rv5+ToggRbUPPEHlZzJPK7ODdV2/s54ZIVDpBZTz61CmDO9/ak+WP8Ln 6RIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=4pKndLMlyp/um+NedT0Gj49sdbEbQ5kd4upD0wpTwa8=; b=Uiku3EKUYmhelHoW3vPxb+WC6DvHpzwRkc4/HVfPA210EJQcRGGlqqmoSPw8xTd8Fx LQu346/vzeGFvFCkLWWzbdrnmFOCc80Y2OOm1Mh3n6Ic1HjDd0xHcDke0oKrM4bEgxux LofxubnuHPtKcnq0OUMtyzGp9zrTbXrMCmxuTiUkpyYKQVo0PSiLiQlyN30sBbeA88bv zUfZjkc85vikHV7+IffebqLNdkkTrtVP72VZKOagtRWqJGNmX/z1nG3wGO6YCUOsBYvx muAoR5/iW8bE3UC+YIF6ulS/cXdMygWY0aGWmp3Qiv1BgSGKRVEiFyGb/LDCvKtPQpWK +X4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ehXGleML; 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=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i19-20020a17090320d300b0019953ab9cf2si9686499plb.138.2023.04.09.19.50.57; Sun, 09 Apr 2023 19:51:10 -0700 (PDT) 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=@kernel.org header.s=k20201202 header.b=ehXGleML; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229720AbjDJCZL (ORCPT <rfc822;yuanzuo1009@gmail.com> + 99 others); Sun, 9 Apr 2023 22:25:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229702AbjDJCZK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 9 Apr 2023 22:25:10 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA7CC4491 for <linux-kernel@vger.kernel.org>; Sun, 9 Apr 2023 19:24:41 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7208A6175F for <linux-kernel@vger.kernel.org>; Mon, 10 Apr 2023 02:24:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A42D5C433D2; Mon, 10 Apr 2023 02:24:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1681093476; bh=lfKqRPUiqgrvfO9fwMhr+hAhaRhNAJLuNXb1o5Hmn2w=; h=From:To:Cc:Subject:Date:From; b=ehXGleMLkdtUae3AMLDJ+sJKwc91yJFxns08gvEzd3ftR1CZ8UGOtAtpkpI88veiK gwBY/GMWbsk0tNs+74lu2kz9CzkjzJI0CkSe+Jyx2v8Ibevvld+V9VmfNEYSkwlXA2 DyOCVMlWyhvifc2O3OjLr4H2+gQM04KrYm/yNiISbMAD+nzvYAw5o1DsXPsjLpa+x8 iqtkl2mDbginz5ssOSK6UHVbj3B2L8ldDge0sC0FM1S8+CzwK6kgr9Kf5UkVeFJwrb mWQfeQJYax3RgbTqs8XRLYlhczFAd+m0VacWq2b96M1dYUXMy/tnXRfWiaYXw+IpVb KtJrl3Zv/M22Q== From: Chao Yu <chao@kernel.org> To: jaegeuk@kernel.org Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Chao Yu <chao@kernel.org> Subject: [PATCH 1/2] f2fs: remove folio_detach_private() in .invalidate_folio and .release_folio Date: Mon, 10 Apr 2023 10:24:17 +0800 Message-Id: <20230410022418.1843178-1-chao@kernel.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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?1762755944623421700?= X-GMAIL-MSGID: =?utf-8?q?1762755944623421700?= |
Series |
[1/2] f2fs: remove folio_detach_private() in .invalidate_folio and .release_folio
|
|
Commit Message
Chao Yu
April 10, 2023, 2:24 a.m. UTC
We have maintain PagePrivate and page_private and page reference
w/ {set,clear}_page_private_*, it doesn't need to call
folio_detach_private() in the end of .invalidate_folio and
.release_folio, remove it and use f2fs_bug_on instead.
Signed-off-by: Chao Yu <chao@kernel.org>
---
fs/f2fs/data.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
Comments
On 04/10, Chao Yu wrote: > We have maintain PagePrivate and page_private and page reference > w/ {set,clear}_page_private_*, it doesn't need to call > folio_detach_private() in the end of .invalidate_folio and > .release_folio, remove it and use f2fs_bug_on instead. > > Signed-off-by: Chao Yu <chao@kernel.org> > --- > fs/f2fs/data.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > index 4946df6dd253..8b179b4bdc03 100644 > --- a/fs/f2fs/data.c > +++ b/fs/f2fs/data.c > @@ -3737,7 +3737,8 @@ void f2fs_invalidate_folio(struct folio *folio, size_t offset, size_t length) > inode->i_ino == F2FS_COMPRESS_INO(sbi)) > clear_page_private_data(&folio->page); > > - folio_detach_private(folio); > + f2fs_bug_on(sbi, PagePrivate(&folio->page)); > + f2fs_bug_on(sbi, page_private(&folio->page)); I think we can just check page_private() only. > } > > bool f2fs_release_folio(struct folio *folio, gfp_t wait) > @@ -3759,7 +3760,9 @@ bool f2fs_release_folio(struct folio *folio, gfp_t wait) > clear_page_private_reference(&folio->page); > clear_page_private_gcing(&folio->page); > > - folio_detach_private(folio); > + f2fs_bug_on(sbi, PagePrivate(&folio->page)); > + f2fs_bug_on(sbi, page_private(&folio->page)); > + > return true; > } > > -- > 2.25.1
On 2023/4/11 2:33, Jaegeuk Kim wrote: > On 04/10, Chao Yu wrote: >> We have maintain PagePrivate and page_private and page reference >> w/ {set,clear}_page_private_*, it doesn't need to call >> folio_detach_private() in the end of .invalidate_folio and >> .release_folio, remove it and use f2fs_bug_on instead. >> >> Signed-off-by: Chao Yu <chao@kernel.org> >> --- >> fs/f2fs/data.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c >> index 4946df6dd253..8b179b4bdc03 100644 >> --- a/fs/f2fs/data.c >> +++ b/fs/f2fs/data.c >> @@ -3737,7 +3737,8 @@ void f2fs_invalidate_folio(struct folio *folio, size_t offset, size_t length) >> inode->i_ino == F2FS_COMPRESS_INO(sbi)) >> clear_page_private_data(&folio->page); >> >> - folio_detach_private(folio); >> + f2fs_bug_on(sbi, PagePrivate(&folio->page)); >> + f2fs_bug_on(sbi, page_private(&folio->page)); > > I think we can just check page_private() only. Why? how about the case PagePrivate was set, but page_private was't? It must be a bug as well? Thanks, > >> } >> >> bool f2fs_release_folio(struct folio *folio, gfp_t wait) >> @@ -3759,7 +3760,9 @@ bool f2fs_release_folio(struct folio *folio, gfp_t wait) >> clear_page_private_reference(&folio->page); >> clear_page_private_gcing(&folio->page); >> >> - folio_detach_private(folio); >> + f2fs_bug_on(sbi, PagePrivate(&folio->page)); >> + f2fs_bug_on(sbi, page_private(&folio->page)); >> + >> return true; >> } >> >> -- >> 2.25.1
On 04/11, Chao Yu wrote: > On 2023/4/11 2:33, Jaegeuk Kim wrote: > > On 04/10, Chao Yu wrote: > > > We have maintain PagePrivate and page_private and page reference > > > w/ {set,clear}_page_private_*, it doesn't need to call > > > folio_detach_private() in the end of .invalidate_folio and > > > .release_folio, remove it and use f2fs_bug_on instead. > > > > > > Signed-off-by: Chao Yu <chao@kernel.org> > > > --- > > > fs/f2fs/data.c | 7 +++++-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > > > index 4946df6dd253..8b179b4bdc03 100644 > > > --- a/fs/f2fs/data.c > > > +++ b/fs/f2fs/data.c > > > @@ -3737,7 +3737,8 @@ void f2fs_invalidate_folio(struct folio *folio, size_t offset, size_t length) > > > inode->i_ino == F2FS_COMPRESS_INO(sbi)) > > > clear_page_private_data(&folio->page); > > > - folio_detach_private(folio); > > > + f2fs_bug_on(sbi, PagePrivate(&folio->page)); > > > + f2fs_bug_on(sbi, page_private(&folio->page)); > > > > I think we can just check page_private() only. > > Why? how about the case PagePrivate was set, but page_private was't? It must > be a bug as well? Given the code, I think both are set all the time. My concern is someone is not doing set/get properly. Actually, I got a panic on page_private() when running fsstress overnight. I'm trying to reproduce it to find which bit was set. > > Thanks, > > > > > > } > > > bool f2fs_release_folio(struct folio *folio, gfp_t wait) > > > @@ -3759,7 +3760,9 @@ bool f2fs_release_folio(struct folio *folio, gfp_t wait) > > > clear_page_private_reference(&folio->page); > > > clear_page_private_gcing(&folio->page); > > > - folio_detach_private(folio); > > > + f2fs_bug_on(sbi, PagePrivate(&folio->page)); > > > + f2fs_bug_on(sbi, page_private(&folio->page)); > > > + > > > return true; > > > } > > > -- > > > 2.25.1
On 04/11, Jaegeuk Kim wrote: > On 04/11, Chao Yu wrote: > > On 2023/4/11 2:33, Jaegeuk Kim wrote: > > > On 04/10, Chao Yu wrote: > > > > We have maintain PagePrivate and page_private and page reference > > > > w/ {set,clear}_page_private_*, it doesn't need to call > > > > folio_detach_private() in the end of .invalidate_folio and > > > > .release_folio, remove it and use f2fs_bug_on instead. > > > > > > > > Signed-off-by: Chao Yu <chao@kernel.org> > > > > --- > > > > fs/f2fs/data.c | 7 +++++-- > > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c > > > > index 4946df6dd253..8b179b4bdc03 100644 > > > > --- a/fs/f2fs/data.c > > > > +++ b/fs/f2fs/data.c > > > > @@ -3737,7 +3737,8 @@ void f2fs_invalidate_folio(struct folio *folio, size_t offset, size_t length) > > > > inode->i_ino == F2FS_COMPRESS_INO(sbi)) > > > > clear_page_private_data(&folio->page); > > > > - folio_detach_private(folio); > > > > + f2fs_bug_on(sbi, PagePrivate(&folio->page)); > > > > + f2fs_bug_on(sbi, page_private(&folio->page)); > > > > > > I think we can just check page_private() only. > > > > Why? how about the case PagePrivate was set, but page_private was't? It must > > be a bug as well? > > Given the code, I think both are set all the time. My concern is someone is > not doing set/get properly. Actually, I got a panic on page_private() when > running fsstress overnight. I'm trying to reproduce it to find which bit was > set. It turned out that inline bit is somehow set, guessing the bit was not cleared when the first dirty page was truncated or somewhere else. Anyway, tooking a look at the usecase of flushing inline_data to inode page aggressively, I feel it's kinda hack and may increase the checkpoint latency. Hence, I'd like to remove it simply. https://lore.kernel.org/linux-f2fs-devel/20230412160810.1534632-1-jaegeuk@kernel.org/T/#t > > > > > Thanks, > > > > > > > > > } > > > > bool f2fs_release_folio(struct folio *folio, gfp_t wait) > > > > @@ -3759,7 +3760,9 @@ bool f2fs_release_folio(struct folio *folio, gfp_t wait) > > > > clear_page_private_reference(&folio->page); > > > > clear_page_private_gcing(&folio->page); > > > > - folio_detach_private(folio); > > > > + f2fs_bug_on(sbi, PagePrivate(&folio->page)); > > > > + f2fs_bug_on(sbi, page_private(&folio->page)); > > > > + > > > > return true; > > > > } > > > > -- > > > > 2.25.1 > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 4946df6dd253..8b179b4bdc03 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -3737,7 +3737,8 @@ void f2fs_invalidate_folio(struct folio *folio, size_t offset, size_t length) inode->i_ino == F2FS_COMPRESS_INO(sbi)) clear_page_private_data(&folio->page); - folio_detach_private(folio); + f2fs_bug_on(sbi, PagePrivate(&folio->page)); + f2fs_bug_on(sbi, page_private(&folio->page)); } bool f2fs_release_folio(struct folio *folio, gfp_t wait) @@ -3759,7 +3760,9 @@ bool f2fs_release_folio(struct folio *folio, gfp_t wait) clear_page_private_reference(&folio->page); clear_page_private_gcing(&folio->page); - folio_detach_private(folio); + f2fs_bug_on(sbi, PagePrivate(&folio->page)); + f2fs_bug_on(sbi, page_private(&folio->page)); + return true; }