Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2513326pxa; Fri, 7 Aug 2020 13:03:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJmVH4vk2pNWqiHZDZrdFRqQOyVm7xYC2BgEZbQEOvn3ixuIcFEsIfAmXxI9zTA5ygrgWa X-Received: by 2002:a50:ef0a:: with SMTP id m10mr10597456eds.226.1596830625998; Fri, 07 Aug 2020 13:03:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596830625; cv=none; d=google.com; s=arc-20160816; b=M7uSufNy5QeGqKAXNOauY4gDkTifJg4bhFp6z6H7SPQSumuHkZzhrDDkixUm/InzfJ 6y0GjUoqzrwoFtFYUezSMM++ROIj+Yb4BgnKGLVxkouvrCbP9hQXwW9HhcwKLwhCp5M/ rOtbXHVRk0xu03e2hKy5qdFa3G8RgVBg4m5Vdfp+3JyHXcumwKUc9e7hbWZWBoTVoWdf N2bJnG4hOBjlKdFyNrAhpm2AlLK40VhXc2WDT2TqQaxtYztF3RfGaRwyozIU2T2wBcWQ 8rZ3UloFyIOHjc1cEqLRGaXv1aAod236L1nEbZReFF3+y1yannNcDLp+z3N2YoNvObPm namQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=/TUsbWMirQ0jUpRqp7AOJDOwLWB9t57VJUoFpuc/QpI=; b=DUerIs/qXkZUv9hl9me3xRdRsrQ09lP4dwMsKJxP/jQ+68nGQXdE9mDQLH602oNSBU QicQcgGd+ueAQQGChQIhIGckceZe/H47ghrgeFCQB3Kb4YvLEfGG5hxyPqbG3Fkk5j/W OQqggBd6bqL5VcwyxchQLBJOj0aSYyNCpFu9e5keLc77Odsv7oL+sFEja79JlT6LN6eb CDyesnsxtNhjdoHyesL77F+7WAFD1Uyd9IMdIcaEh2rE4j7aotX9eUdIoXC30SBsROsy SF8OJdn2AFUPp3012f9k4fA/tINkfIAYd7zzBjCkUSCVcyODbFIToQOI9WVfTmawpq/k 6NbA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v10si5735837eds.470.2020.08.07.13.03.12; Fri, 07 Aug 2020 13:03:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725970AbgHGUDF (ORCPT + 99 others); Fri, 7 Aug 2020 16:03:05 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:58521 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725893AbgHGUDE (ORCPT ); Fri, 7 Aug 2020 16:03:04 -0400 Received: from callcc.thunk.org (pool-96-230-252-158.bstnma.fios.verizon.net [96.230.252.158]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 077K2sxo017388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Aug 2020 16:02:55 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 2FA1A420263; Fri, 7 Aug 2020 16:02:54 -0400 (EDT) Date: Fri, 7 Aug 2020 16:02:54 -0400 From: tytso@mit.edu To: Xianting Tian Cc: viro@zeniv.linux.org.uk, adilger.kernel@dilger.ca, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH] ext4: move buffer_mapped() to proper position Message-ID: <20200807200254.GY7657@mit.edu> References: <1596211825-8750-1-git-send-email-xianting_tian@126.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1596211825-8750-1-git-send-email-xianting_tian@126.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Thanks, applied, although I rewrote the commit description to make it be a bit more clearer: fs: prevent BUG_ON in submit_bh_wbc() If a device is hot-removed --- for example, when a physical device is unplugged from pcie slot or a nbd device's network is shutdown --- this can result in a BUG_ON() crash in submit_bh_wbc(). This is because the when the block device dies, the buffer heads will have their Buffer_Mapped flag get cleared, leading to the crash in submit_bh_wbc. We had attempted to work around this problem in commit a17712c8 ("ext4: check superblock mapped prior to committing"). Unfortunately, it's still possible to hit the BUG_ON(!buffer_mapped(bh)) if the device dies between when the work-around check in ext4_commit_super() and when submit_bh_wbh() is finally called: Code path: ext4_commit_super judge if 'buffer_mapped(sbh)' is false, return <== commit a17712c8 lock_buffer(sbh) ... unlock_buffer(sbh) __sync_dirty_buffer(sbh,... lock_buffer(sbh) judge if 'buffer_mapped(sbh))' is false, return <== added by this patch submit_bh(...,sbh) submit_bh_wbc(...,sbh,...) [100722.966497] kernel BUG at fs/buffer.c:3095! <== BUG_ON(!buffer_mapped(bh))' in submit_bh_wbc() [100722.966503] invalid opcode: 0000 [#1] SMP [100722.966566] task: ffff8817e15a9e40 task.stack: ffffc90024744000 [100722.966574] RIP: 0010:submit_bh_wbc+0x180/0x190 [100722.966575] RSP: 0018:ffffc90024747a90 EFLAGS: 00010246 [100722.966576] RAX: 0000000000620005 RBX: ffff8818a80603a8 RCX: 0000000000000000 [100722.966576] RDX: ffff8818a80603a8 RSI: 0000000000020800 RDI: 0000000000000001 [100722.966577] RBP: ffffc90024747ac0 R08: 0000000000000000 R09: ffff88207f94170d [100722.966578] R10: 00000000000437c8 R11: 0000000000000001 R12: 0000000000020800 [100722.966578] R13: 0000000000000001 R14: 000000000bf9a438 R15: ffff88195f333000 [100722.966580] FS: 00007fa2eee27700(0000) GS:ffff88203d840000(0000) knlGS:0000000000000000 [100722.966580] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [100722.966581] CR2: 0000000000f0b008 CR3: 000000201a622003 CR4: 00000000007606e0 [100722.966582] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [100722.966583] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [100722.966583] PKRU: 55555554 [100722.966583] Call Trace: [100722.966588] __sync_dirty_buffer+0x6e/0xd0 [100722.966614] ext4_commit_super+0x1d8/0x290 [ext4] [100722.966626] __ext4_std_error+0x78/0x100 [ext4] [100722.966635] ? __ext4_journal_get_write_access+0xca/0x120 [ext4] [100722.966646] ext4_reserve_inode_write+0x58/0xb0 [ext4] [100722.966655] ? ext4_dirty_inode+0x48/0x70 [ext4] [100722.966663] ext4_mark_inode_dirty+0x53/0x1e0 [ext4] [100722.966671] ? __ext4_journal_start_sb+0x6d/0xf0 [ext4] [100722.966679] ext4_dirty_inode+0x48/0x70 [ext4] [100722.966682] __mark_inode_dirty+0x17f/0x350 [100722.966686] generic_update_time+0x87/0xd0 [100722.966687] touch_atime+0xa9/0xd0 [100722.966690] generic_file_read_iter+0xa09/0xcd0 [100722.966694] ? page_cache_tree_insert+0xb0/0xb0 [100722.966704] ext4_file_read_iter+0x4a/0x100 [ext4] [100722.966707] ? __inode_security_revalidate+0x4f/0x60 [100722.966709] __vfs_read+0xec/0x160 [100722.966711] vfs_read+0x8c/0x130 [100722.966712] SyS_pread64+0x87/0xb0 [100722.966716] do_syscall_64+0x67/0x1b0 [100722.966719] entry_SYSCALL64_slow_path+0x25/0x25 To address this, add the check of 'buffer_mapped(bh)' to __sync_dirty_buffer(). This also has the benefit of fixing this for other file systems. With this addition, we can drop the workaround in ext4_commit_supper(). [ Commit description rewritten by tytso. ] Signed-off-by: Xianting Tian Link: https://lore.kernel.org/r/1596211825-8750-1-git-send-email-xianting_tian@126.com Signed-off-by: Theodore Ts'o - Ted