Message ID | 20221114212155.221829-1-feldsherov@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2373461wru; Mon, 14 Nov 2022 13:29:16 -0800 (PST) X-Google-Smtp-Source: AA0mqf6MOHjRIJHD6evjucA2fp2QTPdHWHnvlPqJxo0x6SqT3IKePGBD0xHL0BCI4fV9zOdKkywX X-Received: by 2002:a17:906:af5a:b0:7ae:4a7d:813b with SMTP id ly26-20020a170906af5a00b007ae4a7d813bmr10964316ejb.573.1668461356657; Mon, 14 Nov 2022 13:29:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668461356; cv=none; d=google.com; s=arc-20160816; b=uPx2TVO7Wc4NIG6p2OaPpP46XQOPiqhiFKZlj11e/xB3yNIb5auc80TnQHmgtadl49 iLa6KXLrwlSWqHdj9IWXCO/pstwMTzPkh9AfNfobue2nfzCbaPeYoeTpII5OhVVseQQN p3I9t528YCzp5l6AOervGZf6PltzvKR+ctuhsLKNo4NdGY0JYeo9igoCOBT7WzYCh7re 7vUfGUfKebXv+gnWzugrCopeBi7yrDkF4QRnL/swmopeRmT3r0N5Gdrk11WNOovlzA9b 7/C9BDWE6O7dR709IInJOIjnQq1/Ww82K6WC9dOApvUkPu6bfmrsqa3pdlpv7v424CH2 o73w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:dkim-signature; bh=2s5p7qUTZoX+xCiO6iUkhANRSk/2v5qgG9igFsxp65M=; b=nmVkVgC2hcF/hhJyOExXTChMo7QDVkz6r0ulVpk5fF6KV7uHQJkGKmb69xgw5XDb4B hw1TNTPLrq2LzYAREvZSplUrBKzsjswn1Q4ZcDdTAgDr+7hqrNTSythIA0KPCKShr0a5 yi7fndpQrIMSFpLFOTDGlrcws+JgK/xJvtmC01xyiHldESWB2m6nOY59o0q7thPg0Esa RudzmY6Mbl/i8iuCjdIXtJ2kucxGfoirTvAkY5vOs01XmT7BUm2ArVAGf0I6BkrhNdV1 038Sguco8y+4oDe3tYXv2NgoE66GVvp7OIgnpdMfMKGXe/tZbei4FQEviuQ+5PjEgNkY VJBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=S2Kj3NDM; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f24-20020a50d558000000b00457f9c97f13si8731986edj.581.2022.11.14.13.28.52; Mon, 14 Nov 2022 13:29:16 -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=@google.com header.s=20210112 header.b=S2Kj3NDM; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236724AbiKNVXm (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Mon, 14 Nov 2022 16:23:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237635AbiKNVXk (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 14 Nov 2022 16:23:40 -0500 Received: from mail-wr1-x44a.google.com (mail-wr1-x44a.google.com [IPv6:2a00:1450:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB39B3898 for <linux-kernel@vger.kernel.org>; Mon, 14 Nov 2022 13:23:39 -0800 (PST) Received: by mail-wr1-x44a.google.com with SMTP id r22-20020adfa156000000b0023660e969ddso2277305wrr.19 for <linux-kernel@vger.kernel.org>; Mon, 14 Nov 2022 13:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=2s5p7qUTZoX+xCiO6iUkhANRSk/2v5qgG9igFsxp65M=; b=S2Kj3NDMntV93G0ZGOxCLd15RWQhiWng/uuFCMn+z5aAJGDLzXGR6qRQ47yO+p98ro F72bMYkbKOngtGU2MEr3YF9SERzf8wjuRoXDxhAAiO84bP8i5xdMDr8MvkxipXuhi2Ns YALre42dFlZ/SoncAScMZXjCC5WuhU//Zjb6Sqss5iRz47cj3LVzKEjEMPR8xiTy8A6O zw0ONphrScEMXVCo1d5q59zibgd2n/UfGY8jlqxanJgf265SdsZzvJWVVdbn0hF/vds8 LqmifXWvjIqfLLnvNwZJ8cw+qMzGjg/JfksX2547mWdENWGrvPMl3tz3bwligeBBi3G3 9rTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2s5p7qUTZoX+xCiO6iUkhANRSk/2v5qgG9igFsxp65M=; b=mJTpMGe9baxmXPM/9uuCuzEIHAb9nsF+cnQ5Y8n4ciip/oc/QfVz22lGZMpSrIDqLp 7f7fuPJ7ANQaAJexTBGGHNRtqD3vPq5EkUXvX5Jfi0sjEKsXDnEysXG++eNlNLwzfYvV QUNTpEIDIK1zcugCuPRzSZFCmbByVmWJU7MzvT0HhuJHso1WRNHMFM/KHMD2HYRTTQ6A mM5s0N5A/L94RbYQEbQj82QDtvzYQLJShiirGb2ff2F9ntjioeALiD7rHTV1JRh52uru zbv1K+4v2V3RKgOAQt4BFppbMzYibHLtrhxiUhozdEv/89XnJ+cF9VzYaNUlr4JKBXSS LDew== X-Gm-Message-State: ANoB5pnXl1AUlXi/ebnXJ4JZlrM62UQUgcgFHP/dSOJbc6DSdvnUDwdI oDnu/V97VqWsvGwdbGhIIPE6vvazr1Naj4oR X-Received: from fkdev.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:3506]) (user=feldsherov job=sendgmr) by 2002:a05:600c:35c6:b0:3c2:7211:732e with SMTP id r6-20020a05600c35c600b003c27211732emr9326994wmq.191.1668461018405; Mon, 14 Nov 2022 13:23:38 -0800 (PST) Date: Mon, 14 Nov 2022 21:21:55 +0000 In-Reply-To: <20221114192129.zkmubc6pmruuzkc7@quack3> Mime-Version: 1.0 References: <20221114192129.zkmubc6pmruuzkc7@quack3> X-Mailer: git-send-email 2.38.1.431.g37b22c650d-goog Message-ID: <20221114212155.221829-1-feldsherov@google.com> Subject: [PATCH v2] fs: do not update freeing inode io_list From: Svyatoslav Feldsherov <feldsherov@google.com> To: Alexander Viro <viro@zeniv.linux.org.uk>, Lukas Czerner <lczerner@redhat.com>, "Theodore Ts'o" <tytso@mit.edu>, Jan Kara <jack@suse.cz> Cc: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com, oferz@google.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Svyatoslav Feldsherov <feldsherov@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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?1749508535798311996?= X-GMAIL-MSGID: =?utf-8?q?1749508535798311996?= |
Series |
[v2] fs: do not update freeing inode io_list
|
|
Commit Message
Svyatoslav Feldsherov
Nov. 14, 2022, 9:21 p.m. UTC
After commit cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode
already has I_DIRTY_INODE") writeiback_single_inode can push inode with
I_DIRTY_TIME set to b_dirty_time list. In case of freeing inode with
I_DIRTY_TIME set this can happened after deletion of inode io_list at
evict. Stack trace is following.
evict
fat_evict_inode
fat_truncate_blocks
fat_flush_inodes
writeback_inode
sync_inode_metadata(inode, sync=0)
writeback_single_inode(inode, wbc) <- wbc->sync_mode == WB_SYNC_NONE
This will lead to use after free in flusher thread.
Similar issue can be triggered if writeback_single_inode in the
stack trace update inode->io_list. Add explicit check to avoid it.
Fixes: cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE")
Reported-by: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com
Signed-off-by: Svyatoslav Feldsherov <feldsherov@google.com>
---
V1 -> V2:
- address review comments
- skip inode_cgwb_move_to_attached for freeing inode
fs/fs-writeback.c | 30 +++++++++++++++++++-----------
1 file changed, 19 insertions(+), 11 deletions(-)
Comments
Hi-- Please see a small nit below. On 11/14/22 13:21, Svyatoslav Feldsherov wrote: > After commit cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode > already has I_DIRTY_INODE") writeiback_single_inode can push inode with > I_DIRTY_TIME set to b_dirty_time list. In case of freeing inode with > I_DIRTY_TIME set this can happened after deletion of inode io_list at > evict. Stack trace is following. > > evict > fat_evict_inode > fat_truncate_blocks > fat_flush_inodes > writeback_inode > sync_inode_metadata(inode, sync=0) > writeback_single_inode(inode, wbc) <- wbc->sync_mode == WB_SYNC_NONE > > This will lead to use after free in flusher thread. > > Similar issue can be triggered if writeback_single_inode in the > stack trace update inode->io_list. Add explicit check to avoid it. > > Fixes: cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE") > Reported-by: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com > Signed-off-by: Svyatoslav Feldsherov <feldsherov@google.com> > --- > V1 -> V2: > - address review comments > - skip inode_cgwb_move_to_attached for freeing inode > > fs/fs-writeback.c | 30 +++++++++++++++++++----------- > 1 file changed, 19 insertions(+), 11 deletions(-) > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index 443f83382b9b..c4aea096689c 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -1712,18 +1712,26 @@ static int writeback_single_inode(struct inode *inode, > wb = inode_to_wb_and_lock_list(inode); > spin_lock(&inode->i_lock); > /* > - * If the inode is now fully clean, then it can be safely removed from > - * its writeback list (if any). Otherwise the flusher threads are > - * responsible for the writeback lists. > + * If the inode is freeing, it's io_list shoudn't be updated its > + * as it can be finally deleted at this moment. > */ > - if (!(inode->i_state & I_DIRTY_ALL)) > - inode_cgwb_move_to_attached(inode, wb); > - else if (!(inode->i_state & I_SYNC_QUEUED)) { > - if ((inode->i_state & I_DIRTY)) > - redirty_tail_locked(inode, wb); > - else if (inode->i_state & I_DIRTY_TIME) { > - inode->dirtied_when = jiffies; > - inode_io_list_move_locked(inode, wb, &wb->b_dirty_time); > + if (!(inode->i_state & I_FREEING)) { > + /* > + * If the inode is now fully clean, then it can be safely > + * removed from its writeback list (if any). Otherwise the > + * flusher threads are responsible for the writeback lists. > + */ > + if (!(inode->i_state & I_DIRTY_ALL)) > + inode_cgwb_move_to_attached(inode, wb); > + else if (!(inode->i_state & I_SYNC_QUEUED)) { > + if ((inode->i_state & I_DIRTY)) > + redirty_tail_locked(inode, wb); > + else if (inode->i_state & I_DIRTY_TIME) { > + inode->dirtied_when = jiffies; > + inode_io_list_move_locked(inode, > + wb, > + &wb->b_dirty_time); > + } > } > } >
Thank you for noticing that! I will send a fixed patch in 8-10 hours if no other comment will arrive. On Mon, Nov 14, 2022 at 11:25 PM Randy Dunlap <rdunlap@infradead.org> wrote: > > Hi-- > > Please see a small nit below. > > On 11/14/22 13:21, Svyatoslav Feldsherov wrote: > > After commit cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode > > already has I_DIRTY_INODE") writeiback_single_inode can push inode with > > I_DIRTY_TIME set to b_dirty_time list. In case of freeing inode with > > I_DIRTY_TIME set this can happened after deletion of inode io_list at > > evict. Stack trace is following. > > > > evict > > fat_evict_inode > > fat_truncate_blocks > > fat_flush_inodes > > writeback_inode > > sync_inode_metadata(inode, sync=0) > > writeback_single_inode(inode, wbc) <- wbc->sync_mode == WB_SYNC_NONE > > > > This will lead to use after free in flusher thread. > > > > Similar issue can be triggered if writeback_single_inode in the > > stack trace update inode->io_list. Add explicit check to avoid it. > > > > Fixes: cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE") > > Reported-by: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com > > Signed-off-by: Svyatoslav Feldsherov <feldsherov@google.com> > > --- > > V1 -> V2: > > - address review comments > > - skip inode_cgwb_move_to_attached for freeing inode > > > > fs/fs-writeback.c | 30 +++++++++++++++++++----------- > > 1 file changed, 19 insertions(+), 11 deletions(-) > > > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > > index 443f83382b9b..c4aea096689c 100644 > > --- a/fs/fs-writeback.c > > +++ b/fs/fs-writeback.c > > @@ -1712,18 +1712,26 @@ static int writeback_single_inode(struct inode *inode, > > wb = inode_to_wb_and_lock_list(inode); > > spin_lock(&inode->i_lock); > > /* > > - * If the inode is now fully clean, then it can be safely removed from > > - * its writeback list (if any). Otherwise the flusher threads are > > - * responsible for the writeback lists. > > + * If the inode is freeing, it's io_list shoudn't be updated > > its > > > + * as it can be finally deleted at this moment. > > */ > > - if (!(inode->i_state & I_DIRTY_ALL)) > > - inode_cgwb_move_to_attached(inode, wb); > > - else if (!(inode->i_state & I_SYNC_QUEUED)) { > > - if ((inode->i_state & I_DIRTY)) > > - redirty_tail_locked(inode, wb); > > - else if (inode->i_state & I_DIRTY_TIME) { > > - inode->dirtied_when = jiffies; > > - inode_io_list_move_locked(inode, wb, &wb->b_dirty_time); > > + if (!(inode->i_state & I_FREEING)) { > > + /* > > + * If the inode is now fully clean, then it can be safely > > + * removed from its writeback list (if any). Otherwise the > > + * flusher threads are responsible for the writeback lists. > > + */ > > + if (!(inode->i_state & I_DIRTY_ALL)) > > + inode_cgwb_move_to_attached(inode, wb); > > + else if (!(inode->i_state & I_SYNC_QUEUED)) { > > + if ((inode->i_state & I_DIRTY)) > > + redirty_tail_locked(inode, wb); > > + else if (inode->i_state & I_DIRTY_TIME) { > > + inode->dirtied_when = jiffies; > > + inode_io_list_move_locked(inode, > > + wb, > > + &wb->b_dirty_time); > > + } > > } > > } > > > > -- > ~Randy -- Slava
On Mon 14-11-22 21:21:55, Svyatoslav Feldsherov wrote: > After commit cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode > already has I_DIRTY_INODE") writeiback_single_inode can push inode with ^^^ writeback > I_DIRTY_TIME set to b_dirty_time list. In case of freeing inode with > I_DIRTY_TIME set this can happened after deletion of inode io_list at ^^ happen ^^^ deletion of inode *from i_io_list* > evict. Stack trace is following. > > evict > fat_evict_inode > fat_truncate_blocks > fat_flush_inodes > writeback_inode > sync_inode_metadata(inode, sync=0) > writeback_single_inode(inode, wbc) <- wbc->sync_mode == WB_SYNC_NONE > > This will lead to use after free in flusher thread. > > Similar issue can be triggered if writeback_single_inode in the > stack trace update inode->io_list. Add explicit check to avoid it. ^^ inode->i_io_list > Fixes: cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE") > Reported-by: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com > Signed-off-by: Svyatoslav Feldsherov <feldsherov@google.com> Besides these gramatical nits the patch looks good to me. Feel free to add: Reviewed-by: Jan Kara <jack@suse.cz> Thanks! Honza > --- > V1 -> V2: > - address review comments > - skip inode_cgwb_move_to_attached for freeing inode > > fs/fs-writeback.c | 30 +++++++++++++++++++----------- > 1 file changed, 19 insertions(+), 11 deletions(-) > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index 443f83382b9b..c4aea096689c 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -1712,18 +1712,26 @@ static int writeback_single_inode(struct inode *inode, > wb = inode_to_wb_and_lock_list(inode); > spin_lock(&inode->i_lock); > /* > - * If the inode is now fully clean, then it can be safely removed from > - * its writeback list (if any). Otherwise the flusher threads are > - * responsible for the writeback lists. > + * If the inode is freeing, it's io_list shoudn't be updated > + * as it can be finally deleted at this moment. > */ > - if (!(inode->i_state & I_DIRTY_ALL)) > - inode_cgwb_move_to_attached(inode, wb); > - else if (!(inode->i_state & I_SYNC_QUEUED)) { > - if ((inode->i_state & I_DIRTY)) > - redirty_tail_locked(inode, wb); > - else if (inode->i_state & I_DIRTY_TIME) { > - inode->dirtied_when = jiffies; > - inode_io_list_move_locked(inode, wb, &wb->b_dirty_time); > + if (!(inode->i_state & I_FREEING)) { > + /* > + * If the inode is now fully clean, then it can be safely > + * removed from its writeback list (if any). Otherwise the > + * flusher threads are responsible for the writeback lists. > + */ > + if (!(inode->i_state & I_DIRTY_ALL)) > + inode_cgwb_move_to_attached(inode, wb); > + else if (!(inode->i_state & I_SYNC_QUEUED)) { > + if ((inode->i_state & I_DIRTY)) > + redirty_tail_locked(inode, wb); > + else if (inode->i_state & I_DIRTY_TIME) { > + inode->dirtied_when = jiffies; > + inode_io_list_move_locked(inode, > + wb, > + &wb->b_dirty_time); > + } > } > } > > -- > 2.38.1.431.g37b22c650d-goog >
Thank you for the review. I've sent v3 with proposed fixes. Also tried to be more consistent and use i_io_list in comments and commit message instead of io_list//io list. On Tue, Nov 15, 2022 at 12:55 PM Jan Kara <jack@suse.cz> wrote: > > On Mon 14-11-22 21:21:55, Svyatoslav Feldsherov wrote: > > After commit cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode > > already has I_DIRTY_INODE") writeiback_single_inode can push inode with > ^^^ writeback > > > I_DIRTY_TIME set to b_dirty_time list. In case of freeing inode with > > I_DIRTY_TIME set this can happened after deletion of inode io_list at > ^^ happen ^^^ deletion of > inode *from i_io_list* > > > evict. Stack trace is following. > > > > evict > > fat_evict_inode > > fat_truncate_blocks > > fat_flush_inodes > > writeback_inode > > sync_inode_metadata(inode, sync=0) > > writeback_single_inode(inode, wbc) <- wbc->sync_mode == WB_SYNC_NONE > > > > This will lead to use after free in flusher thread. > > > > Similar issue can be triggered if writeback_single_inode in the > > stack trace update inode->io_list. Add explicit check to avoid it. > ^^ inode->i_io_list > > > Fixes: cbfecb927f42 ("fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE") > > Reported-by: syzbot+6ba92bd00d5093f7e371@syzkaller.appspotmail.com > > Signed-off-by: Svyatoslav Feldsherov <feldsherov@google.com> > > Besides these gramatical nits the patch looks good to me. Feel free to add: > > Reviewed-by: Jan Kara <jack@suse.cz> > > Thanks! > > Honza > > > --- > > V1 -> V2: > > - address review comments > > - skip inode_cgwb_move_to_attached for freeing inode > > > > fs/fs-writeback.c | 30 +++++++++++++++++++----------- > > 1 file changed, 19 insertions(+), 11 deletions(-) > > > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > > index 443f83382b9b..c4aea096689c 100644 > > --- a/fs/fs-writeback.c > > +++ b/fs/fs-writeback.c > > @@ -1712,18 +1712,26 @@ static int writeback_single_inode(struct inode *inode, > > wb = inode_to_wb_and_lock_list(inode); > > spin_lock(&inode->i_lock); > > /* > > - * If the inode is now fully clean, then it can be safely removed from > > - * its writeback list (if any). Otherwise the flusher threads are > > - * responsible for the writeback lists. > > + * If the inode is freeing, it's io_list shoudn't be updated > > + * as it can be finally deleted at this moment. > > */ > > - if (!(inode->i_state & I_DIRTY_ALL)) > > - inode_cgwb_move_to_attached(inode, wb); > > - else if (!(inode->i_state & I_SYNC_QUEUED)) { > > - if ((inode->i_state & I_DIRTY)) > > - redirty_tail_locked(inode, wb); > > - else if (inode->i_state & I_DIRTY_TIME) { > > - inode->dirtied_when = jiffies; > > - inode_io_list_move_locked(inode, wb, &wb->b_dirty_time); > > + if (!(inode->i_state & I_FREEING)) { > > + /* > > + * If the inode is now fully clean, then it can be safely > > + * removed from its writeback list (if any). Otherwise the > > + * flusher threads are responsible for the writeback lists. > > + */ > > + if (!(inode->i_state & I_DIRTY_ALL)) > > + inode_cgwb_move_to_attached(inode, wb); > > + else if (!(inode->i_state & I_SYNC_QUEUED)) { > > + if ((inode->i_state & I_DIRTY)) > > + redirty_tail_locked(inode, wb); > > + else if (inode->i_state & I_DIRTY_TIME) { > > + inode->dirtied_when = jiffies; > > + inode_io_list_move_locked(inode, > > + wb, > > + &wb->b_dirty_time); > > + } > > } > > } > > > > -- > > 2.38.1.431.g37b22c650d-goog > > > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR -- Slava
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 443f83382b9b..c4aea096689c 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -1712,18 +1712,26 @@ static int writeback_single_inode(struct inode *inode, wb = inode_to_wb_and_lock_list(inode); spin_lock(&inode->i_lock); /* - * If the inode is now fully clean, then it can be safely removed from - * its writeback list (if any). Otherwise the flusher threads are - * responsible for the writeback lists. + * If the inode is freeing, it's io_list shoudn't be updated + * as it can be finally deleted at this moment. */ - if (!(inode->i_state & I_DIRTY_ALL)) - inode_cgwb_move_to_attached(inode, wb); - else if (!(inode->i_state & I_SYNC_QUEUED)) { - if ((inode->i_state & I_DIRTY)) - redirty_tail_locked(inode, wb); - else if (inode->i_state & I_DIRTY_TIME) { - inode->dirtied_when = jiffies; - inode_io_list_move_locked(inode, wb, &wb->b_dirty_time); + if (!(inode->i_state & I_FREEING)) { + /* + * If the inode is now fully clean, then it can be safely + * removed from its writeback list (if any). Otherwise the + * flusher threads are responsible for the writeback lists. + */ + if (!(inode->i_state & I_DIRTY_ALL)) + inode_cgwb_move_to_attached(inode, wb); + else if (!(inode->i_state & I_SYNC_QUEUED)) { + if ((inode->i_state & I_DIRTY)) + redirty_tail_locked(inode, wb); + else if (inode->i_state & I_DIRTY_TIME) { + inode->dirtied_when = jiffies; + inode_io_list_move_locked(inode, + wb, + &wb->b_dirty_time); + } } }