Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2082050yba; Mon, 15 Apr 2019 04:41:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqxPDWhrmDRc1oWUimFoC4oQw+jK9DBd44eYVuxjf9PBpSAQt0r/Y8UVOROXYFblgtKKC9F1 X-Received: by 2002:a63:7154:: with SMTP id b20mr70122090pgn.359.1555328463460; Mon, 15 Apr 2019 04:41:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555328463; cv=none; d=google.com; s=arc-20160816; b=eqGOUjKH3e9b+2U+wfRd050lx54TtTYEfgPJJTpdDH6bOHHHGwwgmpFOyPbFsC4eMt UlDn/9EHITRQvZR+PGFm/HbvwEo9bbKA2ctZ28em8Xb5N7Jb9C2dKneqvPN+yPQd9tS0 lZJECF4/Mfxpf816p2ApCywv+u0FYQ8C99SWK22TGnRkTOQnHIyxVLK8/ctJW4FW42pc zEItLELOk+6kkcZd8zeUnrVSoTRrV4i0OH7bjKSCdAOrM+KN7R3akX609bS2wA3dglZf DZP/t6YzoXqhSCy8cjSJb42WNSwsFnATD3jT8O6LPrIGBnUdVRErcXoPtm+U1GvPwVpj 91Fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from; bh=/7GFVoqySMmpUel6OfNxvNoKvdSOKIXd6ex04vNJPh4=; b=PnLqKEWAae/sCUfsRmwcp2mOpEP0PbJgKup4lNau33iNXGG+Elifl2Yl7DZvRV5MSo H352ZzQix0r3x/04SubcvWahcu9ZTVX224F70GMQChk09AjNUAvk/yICIh2A7qqkmh3l h0H5OXRNFLFlrC2qP9I3/Mf/767QZYM2P+Ki/WF20ClHHZ/p9KTidMSswwbfdcgk8BhA R7R0Al80fbIfgk1bzeZliAnH6OdZKbVSgxWUS2+yQ1ptm2pJdJcXI3qNGTZ7GCeaCVGs j6oX5oP0Wskoaj5mqo7wqQXmd+p7xmboVCwN3DK4wfNgoc4ddstPdzvH+kuYtuoILHoj B8dA== ARC-Authentication-Results: i=1; mx.google.com; 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 m23si45743050pgc.550.2019.04.15.04.40.46; Mon, 15 Apr 2019 04:41:03 -0700 (PDT) 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; 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 S1727257AbfDOLjs (ORCPT + 99 others); Mon, 15 Apr 2019 07:39:48 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:48828 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726298AbfDOLjs (ORCPT ); Mon, 15 Apr 2019 07:39:48 -0400 Received: from DGGEMM402-HUB.china.huawei.com (unknown [172.30.72.53]) by Forcepoint Email with ESMTP id 3EB7EF6C5183527CC0E0; Mon, 15 Apr 2019 19:39:44 +0800 (CST) Received: from dggeme763-chm.china.huawei.com (10.3.19.109) by DGGEMM402-HUB.china.huawei.com (10.3.20.210) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Apr 2019 19:39:43 +0800 Received: from szvp000201624.huawei.com (10.120.216.130) by dggeme763-chm.china.huawei.com (10.3.19.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 15 Apr 2019 19:39:43 +0800 From: Chao Yu To: CC: , , , Chao Yu Subject: [PATCH v2 13/13] f2fs: don't recovery orphan inode on readonly device Date: Mon, 15 Apr 2019 19:39:33 +0800 Message-ID: <20190415113933.21621-1-yuchao0@huawei.com> X-Mailer: git-send-email 2.18.0.rc1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.120.216.130] X-ClientProxiedBy: dggeme708-chm.china.huawei.com (10.1.199.104) To dggeme763-chm.china.huawei.com (10.3.19.109) X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As Park Ju Hyung reported in mailing list: https://sourceforge.net/p/linux-f2fs/mailman/message/36639787/ generic_make_request: Trying to write to read-only block-device loop0 (partno 0) WARNING: CPU: 0 PID: 23437 at block/blk-core.c:2174 generic_make_request_checks+0x594/0x630 generic_make_request+0x46/0x3d0 submit_bio+0x30/0x110 __submit_merged_bio+0x68/0x390 f2fs_submit_page_write+0x1bb/0x7f0 f2fs_do_write_meta_page+0x7f/0x160 __f2fs_write_meta_page+0x70/0x140 f2fs_sync_meta_pages+0x140/0x250 f2fs_write_checkpoint+0x5c5/0x17b0 f2fs_sync_fs+0x9c/0x110 sync_filesystem+0x66/0x80 f2fs_recover_fsync_data+0x790/0xa30 f2fs_fill_super+0xe4e/0x1980 mount_bdev+0x518/0x610 mount_fs+0x34/0x13f vfs_kern_mount.part.11+0x4f/0x120 do_mount+0x2d1/0xe40 __x64_sys_mount+0xbf/0xe0 do_syscall_64+0x4a/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 print_req_error: I/O error, dev loop0, sector 4096 If block device is readonly, we should never trigger write IO from filesystem layer, but previously, orphan recovery didn't consider such condition, result in triggering above warning, fix it. Reported-by: Park Ju Hyung Tested-by: Park Ju Hyung Signed-off-by: Chao Yu --- v2: - adjust Park's first/last name order. fs/f2fs/checkpoint.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index a7ad1b1e5750..90e1bab86269 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -674,6 +674,12 @@ int f2fs_recover_orphan_inodes(struct f2fs_sb_info *sbi) if (!is_set_ckpt_flags(sbi, CP_ORPHAN_PRESENT_FLAG)) return 0; + if (bdev_read_only(sbi->sb->s_bdev)) { + f2fs_msg(sbi->sb, KERN_INFO, "write access " + "unavailable, skipping orphan cleanup"); + return 0; + } + if (s_flags & SB_RDONLY) { f2fs_msg(sbi->sb, KERN_INFO, "orphan cleanup on readonly fs"); sbi->sb->s_flags &= ~SB_RDONLY; -- 2.18.0.rc1