From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56741C77B61 for ; Fri, 28 Apr 2023 05:24:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD2F3900002; Fri, 28 Apr 2023 01:24:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C83B76B0072; Fri, 28 Apr 2023 01:24:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4BB0900002; Fri, 28 Apr 2023 01:24:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A51C06B0071 for ; Fri, 28 Apr 2023 01:24:30 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 66F5B1A0196 for ; Fri, 28 Apr 2023 05:24:30 +0000 (UTC) X-FDA: 80729659500.30.343F794 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf09.hostedemail.com (Postfix) with ESMTP id 83540140012 for ; Fri, 28 Apr 2023 05:24:27 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=tyZtkQYq; spf=pass (imf09.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682659467; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5tT+FnXXVAfiL2lANfau8hR1k0QdF35mbhRvcLTl8f8=; b=753TAfmfKiz5aTX1UulO8FmOgMlquy5eKoI7iTsiB9Z9UkzmdF5Z0BAlSzyt882wNJzf6T ZgU8mNYCRTDb7E4DS1oeSgjLq6jvvXoFZMm/RufvRp5HFj4t0f8iraP30gDf6ViSR7Hgoc L/9HXmb8+ADt+DV+GWbJqC3eXqmFWIg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=tyZtkQYq; spf=pass (imf09.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682659467; a=rsa-sha256; cv=none; b=gabKMkh1jHAqxxs8MB5pA3aLKmUzm+pdTkEZMiK7DTFSJvBo0E7n3n6eli01j7WzxcUVBk fQC0z80Bjl0zPjbrTdO8eWo0wxfoAJQoNVZaGXyRwvmpP8I/6BO3uXciFb/o/q0v5AgQ9z xZtOK5fnZDjTU642xjFOzPBT0PKMP3I= Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1a6bc48aec8so70512685ad.2 for ; Thu, 27 Apr 2023 22:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1682659466; x=1685251466; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5tT+FnXXVAfiL2lANfau8hR1k0QdF35mbhRvcLTl8f8=; b=tyZtkQYqVjHIc1EEnxVQCQG4Tldpi8hGhievTL1QX2Rkc71hGXqhO9HENHkeUSKGnc B61ELQorVwh5O7/rO7z5fQk8mrRW0cvfCtxYqgxvqsi5u0BxK6zAKnGpq5NAkGP/VD/V YcgarWZGxc2icbaGM3rZ5saUPcmMyaRB04AUDhEy+jo1UICcdQ8mgRmIalPW0J3ZEMDF mxLLYpUJsDW/xrgPFLUGzMg3fv13ONzzBYPG4W+dEZXJlh6fYHvFQEaM+tknxaB24AmI xmvwdHeqM776thiHX7JFp2Dxwaf7lEGabm8M7boBdeZJsFFkdhlrl0FkGUSvbHnrZO9G 5nkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682659466; x=1685251466; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5tT+FnXXVAfiL2lANfau8hR1k0QdF35mbhRvcLTl8f8=; b=GnIwURsDj7RPJtAVhGq+2lz5f2O45TRMKUKgEMQR97V+y0TV6dfG4YxMWKuuhZ5Ev5 czbjmVPm1vSy6gP1JSPhoPWnCDxrwpZeL43GFtGYMgYElXP+AIuix8iSPBpN/oOs5fl5 CkNCbZ5B2vu5JRGQa6W4zVds42VX+gxvY//jj8raIbIrHiRePW3pKawzwgS4fFPfSh2w tvwIuPKQghV9wdu9a9PquT2ViKEzvGDefXO9aqpCVxDbjEaAVxB4Ul6GMnVgpIrKdB9z BKv7c26nAlnDRVW13D7mtxUvFmES8aYQt24vsEUnRMXzSAuvEbgRkQkUzkMV5hHn234Z Gfpg== X-Gm-Message-State: AC+VfDzCrDrYgnAJK3m63QtU1TdXk5FqpdUEZlFdnkuU984PQE/MrP52 YDhhvhePLqCVcr4CJ9uDoArKMQ== X-Google-Smtp-Source: ACHHUZ510rI5TRspLV3WEivPBLF6owNABSCj5GOJiTfryVmfvTBWvFbt5DnvD96jcRuz8RSV72EplQ== X-Received: by 2002:a17:902:fb8f:b0:1a1:defc:30d8 with SMTP id lg15-20020a170902fb8f00b001a1defc30d8mr3489595plb.32.1682659465786; Thu, 27 Apr 2023 22:24:25 -0700 (PDT) Received: from dread.disaster.area (pa49-181-88-204.pa.nsw.optusnet.com.au. [49.181.88.204]) by smtp.gmail.com with ESMTPSA id s13-20020a170902a50d00b001a64ce7b18dsm12476240plq.165.2023.04.27.22.24.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Apr 2023 22:24:25 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1psGak-008l7h-7i; Fri, 28 Apr 2023 15:24:22 +1000 Date: Fri, 28 Apr 2023 15:24:22 +1000 From: Dave Chinner To: Matthew Wilcox Cc: Dave Chinner , Ming Lei , Theodore Ts'o , linux-ext4@vger.kernel.org, Andreas Dilger , linux-block@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Eric Sandeen , Christoph Hellwig , Zhang Yi Subject: Re: [ext4 io hang] buffered write io hang in balance_dirty_pages Message-ID: <20230428052422.GB1969623@dread.disaster.area> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 83540140012 X-Stat-Signature: zbkat9tkbbipssc693xheukzna7uaag9 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1682659467-864717 X-HE-Meta: U2FsdGVkX18GgTeqtR8EmpwxXrrGYUGzVpjam825gTmXBnHizBAf6xW7QPqFc3xD3hRKoAQZoEYxgjGG0Ac0CcyhtYXNo3hZiCi40ScDB2iMd85B8OjsL88D95Nqv2zasru1DHqQo65/WPoTkrDqci0KgZP4eTmSZzPHhdSD6u08S1il7+2w0e3QqEyVbJDjlU1wmvpbNDpoZshy9+3/cnV4JaZ4LaPLRUom28naj1VQc0aYv9RXnOpzGo9nCc/NijeqHDN5aTFmEQ8wpR99Vtux/FzWYuhuSkSPWc2B/uH+Dg+lWOVph+P/TAyLHJ+Mi2Ly52+GHaxFvKDReFVxaLA6RnTeNCNXhzWZP7UTMlnQDUaE+LJlhExzvTVlLqht7r2kSKk7JnYEKl9B0gd8WxcSOOVQdCl2SoycW3u9vwhyVhswPF8UYxwQVcBFaP1ULK5aRqVEBnUFp6zykMkNodWbgiPRMi38RFkh7bAbI2baHWkduLl/Y/DZRP3QSP2uuBnsONOn7PKfbf7y/oILioQ1nimzW1SyrUH4hFv9sF2LAo3zRzlLxzPAtC5FHVgisJSnRmXngyAwScm0cnw5fV7wtOU29FGdufkX5Q9RsswNFfOC5Eyi5BMGQQ3nt2xMtC2skYPLaJq7xtEE7H8EHmeJFDfbkyocWz32OqjYW1o2kvyg8FJZHB0E2yYYgAcD6vlvSVCsPxmHY8aPF2Zu/hKPxzckGX3MI98V79uLYjO2OMQG5jq3sPxwmXnFdll3o/DQ7Nb3HkvIuwhntp0JaZDxn1tROJtxaRGvvArCIjFWxQCownPsRn4Xlxz3HY9/zwYqQOxpbLhBJIFGoZHuBps5pzzBHEpwhIDPjSCYBNmjmBtGd5t/dQj1pqSS8Gtk4rs994V149dtPLVGv9wsaNPv92wvDtjYmF67Pk5/98GPFFPc/RjlaWQSds50xcMlE1tgpSzAjHjoNG5ZcPM fzxzFYTn 3cj4GufS6j1GEqYt/DFMj8KkIZqnjlzCOolLpdoJKjwu9Co1zAoi4t0KS2vV7P6ODEwmCf3MmG1iOHKo6L8yssyLSMn55FOoqzjTMpuG0oMUg5iGy2XvcPfDfO5MX3XS2RboyxzpgPZ6fMn7V6GX7YxH2fb5gpbSCJQu3Cdg+Ly2QbTbAG0GnNyfUS/stNtrhFsB+RXUSPPlSFWmZB95uC0nFL/KdBAGbtwUJ8VfE7ruVQR9KKc9lrNkeYHQVE9XJb9uRgqr7HL6TtQqYYWsS9+jfgmW3WBiVSFZXoZLTj/sQkSSXzyvtH6gP1eeN4iiwdOXscw6HXwg8VvxTzKnbH69B2EnU079Z+oAbuKgqHIHLW7lPNBRcgSRgcKdeyv3LzzuWe3P76ld/Cn1h++UL8dXWSPtW9pZb+2Je/JvDwr2i/vRc+HNtBtHd3Zg7C0c7IYMHfhhWc4pAm3mkGBf8Ge8Wp6xlUlVc6WWNCWpcjc/TvuoR9Cmpa16uK0ijWXRaFmJmUvjzfCTNKAmi3a7NBqHn+fKQteoz/lC2wz6mQXUe1R0o3KNdB9oPxwAclAWqrT4bevP+7ZJJkNuu1nyLvkcR6yK/hvCxq4Ba X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Apr 28, 2023 at 03:56:13AM +0100, Matthew Wilcox wrote: > On Fri, Apr 28, 2023 at 09:33:20AM +1000, Dave Chinner wrote: > > The block device needs to be shutting down the filesystem when it > > has some sort of fatal, unrecoverable error like this (e.g. hot > > unplug). We have the XFS_IOC_GOINGDOWN ioctl for telling the > > filesystem it can't function anymore. This ioctl > > (_IOR('X',125,__u32)) has also been replicated into ext4, f2fs and > > CIFS and it gets exercised heavily by fstests. Hence this isn't XFS > > specific functionality, nor is it untested functionality. > > > > The ioctl should be lifted to the VFS as FS_IOC_SHUTDOWN and a > > super_operations method added to trigger a filesystem shutdown. > > That way the block device removal code could simply call > > sb->s_ops->shutdown(sb, REASON) if it exists rather than > > sync_filesystem(sb) if there's a superblock associated with the > > block device. Then all these > > I think this is the wrong approach. Not that I've had any time to > work on my alternative approach: > > https://www.infradead.org/~willy/banbury.html While that looks interesting, I'm going to say straight out that re-attaching a storage device that was hot-unplugged from under a running filesystem and then resuming service as if nothing happened is going to be both a filesystem corruption vector and a major security hole. The moment a mounted device is unexpectedly unplugged, it becomes an untrusted device. We cannot trust that it's contents when plugged back in are identical to when it was unplugged. I can't wait for syzbot to learn that it can mount a filesystem, hot-unplug the device, fuzz the image on the device and then plug it back in and expect the filesystem to handle the in-memory vs on-disk inconsistencies that result from the fuzzing. it's basically no different to allowing someone to write to the block device while the filesystem is mounted. You do that, you get to keep all the broken bits to yourself. Even without image tampering considerations, there's no guarantee that the device caches are flushed properly when someone just pulls the plug on a storage device. Hence even without tampering, we cannot trust the image on the device to match what the in-memory state of the filesystem expects it to be. So, yeah, I just don't see this ever being something we'd support with filesystems like XFS - there's just too much risk associated with untrusted devices... -Dave. -- Dave Chinner david@fromorbit.com