Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3724080imu; Tue, 18 Dec 2018 03:10:45 -0800 (PST) X-Google-Smtp-Source: AFSGD/Xu7zcnVhcmpxQnLvfWhAR2yzd+aMYolH46TgYW/DfD74w2k2RK/YzLehhpGH0fku5AJfPS X-Received: by 2002:a17:902:724a:: with SMTP id c10mr16369333pll.51.1545131445748; Tue, 18 Dec 2018 03:10:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545131445; cv=none; d=google.com; s=arc-20160816; b=iAbSLpM8pA3ySjMTTQx2cKHbtESA6zBFE9oOrVQYYeM1zRQIHqcGFMdrB9HhTliS32 IRsbXDfzv6B/zvbaVoeziYz2g5z0apfUcOjbe00gFmHvELYvfKQ4VCZvZSOJlnPOUx8u 8z6OAOu+QIuZVR1AE3oOcZXttcy/162ucHyDyzq0w2Q7pQhi7ZqVT/vaE5OFOy7dqSRc pC7OiQbsufy8jIELbcGE8UzyQV9ELM1CKL2WMJYaFOW9zrS2s7xwA4PWlhDWKwznoRkD 5uUwsVwSLHZehUHs/OgBItLNo9rrLVot+Ne2QSDBSh/WJE67LidwmwJfv3kqqqG2XdNN eEOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dmarc-filter:dkim-signature:dkim-signature; bh=yN4edpFBiu743WZqg8kg8YLj6X3mSS+1Wea5zrOdhuU=; b=hHDpYcwie3FHGpnnMX9jU+E8qNKbHsTyLZSRrSaHncddBCS7B80XOPyVghHw0A0Th4 5BSjPoB6VaqQnBFxoDAEeIqGCqVkdQCLzDmrtYynIAyRTkiBn1LHJ+q3VdXPG2w3zLwr WQltAVwgmtfJVp67nNT2am6PLUORAHeaDeN2O1kUO1cheQoJMMHAngdgfV720VsHnMI8 HSyjZvJ0DHbo+cF4syyCc4XBp+MjVEt3VwhtBEv0MELhQ3RXnHJ4+6pCzfmoW2GSw60X UjkWNLnvPDzaySiRjqHbLxTb30sRZalUQd+HcyfNO1ECi5/hnKn3qCAFHz0pF8rCLEMA ybmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=QRkMm9g4; dkim=pass header.i=@codeaurora.org header.s=default header.b="J/HNdC5O"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x66si13785431pfk.73.2018.12.18.03.10.29; Tue, 18 Dec 2018 03:10:45 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=QRkMm9g4; dkim=pass header.i=@codeaurora.org header.s=default header.b="J/HNdC5O"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726450AbeLRLJj (ORCPT + 99 others); Tue, 18 Dec 2018 06:09:39 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:57530 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726364AbeLRLJj (ORCPT ); Tue, 18 Dec 2018 06:09:39 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 03C7D6076A; Tue, 18 Dec 2018 11:09:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1545131378; bh=Nl8/XOFjBS6ud7JB+kU0EZB5hq5yrXXEbRdiwub+mN0=; h=From:To:Cc:Subject:Date:From; b=QRkMm9g4Iro2g78PKz2cfgm+fS4fV4ZMPQE5g9On2hKNb1gNrsHl0TgMm4QeYftlF JZdRJlwGN8THkQha1TDvLeOcLFSZM9o6gotDbFNo1JmZfNdvYGOeCaQVppSatDoRjD a9qbmfdZSozqmjJheviyyVE9c0xDhQEoyTu09lxo= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from codeaurora.org (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: stummala@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id E05436014B; Tue, 18 Dec 2018 11:09:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1545131376; bh=Nl8/XOFjBS6ud7JB+kU0EZB5hq5yrXXEbRdiwub+mN0=; h=From:To:Cc:Subject:Date:From; b=J/HNdC5OlkqNH7grdGfP05nF3LWMGDR4J2X/2G8xObPT/jkWlCKAUB+DdNMyJGdYA rFYh2hEAyl42MtQhf+qTTNQr5Iu2QThlSGrEkdxybt5LNxlYRMtVq0zsnrPG28IrOn vivfSw4eCTCohq1syeQcN84A4Xp32Nb7IdAamjDQ= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org E05436014B Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=stummala@codeaurora.org From: Sahitya Tummala To: Jaegeuk Kim , Chao Yu , linux-f2fs-devel@lists.sourceforge.net Cc: linux-kernel@vger.kernel.org, Sahitya Tummala Subject: [PATCH v3] f2fs: fix sbi->extent_list corruption issue Date: Tue, 18 Dec 2018 16:39:24 +0530 Message-Id: <1545131364-21196-1-git-send-email-stummala@codeaurora.org> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When there is a failure in f2fs_fill_super() after/during the recovery of fsync'd nodes, it frees the current sbi and retries again. This time the mount is successful, but the files that got recovered before retry, still holds the extent tree, whose extent nodes list is corrupted since sbi and sbi->extent_list is freed up. The list_del corruption issue is observed when the file system is getting unmounted and when those recoverd files extent node is being freed up in the below context. list_del corruption. prev->next should be fffffff1e1ef5480, but was (null) <...> kernel BUG at kernel/msm-4.14/lib/list_debug.c:53! lr : __list_del_entry_valid+0x94/0xb4 pc : __list_del_entry_valid+0x94/0xb4 <...> Call trace: __list_del_entry_valid+0x94/0xb4 __release_extent_node+0xb0/0x114 __free_extent_tree+0x58/0x7c f2fs_shrink_extent_tree+0xdc/0x3b0 f2fs_leave_shrinker+0x28/0x7c f2fs_put_super+0xfc/0x1e0 generic_shutdown_super+0x70/0xf4 kill_block_super+0x2c/0x5c kill_f2fs_super+0x44/0x50 deactivate_locked_super+0x60/0x8c deactivate_super+0x68/0x74 cleanup_mnt+0x40/0x78 __cleanup_mnt+0x1c/0x28 task_work_run+0x48/0xd0 do_notify_resume+0x678/0xe98 work_pending+0x8/0x14 Fix this by not creating extents for those recovered files if shrinker is not registered yet. Once mount is successful and shrinker is registered, those files can have extents again. Signed-off-by: Sahitya Tummala --- v3: -do not create extents itself in the first place for those recovered files, instead of cleaning it up later via sync/evict_inodes. fs/f2fs/f2fs.h | 11 ++++++++++- fs/f2fs/shrinker.c | 2 +- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 7cec897..1380f07 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -2695,10 +2695,19 @@ static inline bool is_dot_dotdot(const struct qstr *str) static inline bool f2fs_may_extent_tree(struct inode *inode) { - if (!test_opt(F2FS_I_SB(inode), EXTENT_CACHE) || + struct f2fs_sb_info *sbi = F2FS_I_SB(inode); + + if (!test_opt(sbi, EXTENT_CACHE) || is_inode_flag_set(inode, FI_NO_EXTENT)) return false; + /* + * for recovered files during mount do not create extents + * if shrinker is not registered. + */ + if (list_empty(&sbi->s_list)) + return false; + return S_ISREG(inode->i_mode); } diff --git a/fs/f2fs/shrinker.c b/fs/f2fs/shrinker.c index 9e13db9..a467aca 100644 --- a/fs/f2fs/shrinker.c +++ b/fs/f2fs/shrinker.c @@ -135,6 +135,6 @@ void f2fs_leave_shrinker(struct f2fs_sb_info *sbi) f2fs_shrink_extent_tree(sbi, __count_extent_cache(sbi)); spin_lock(&f2fs_list_lock); - list_del(&sbi->s_list); + list_del_init(&sbi->s_list); spin_unlock(&f2fs_list_lock); } -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.