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 75A54C7618E for ; Sat, 29 Apr 2023 05:11:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BA8406B0071; Sat, 29 Apr 2023 01:11:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B580C6B0074; Sat, 29 Apr 2023 01:11:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A20FA6B007B; Sat, 29 Apr 2023 01:11:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 931D16B0071 for ; Sat, 29 Apr 2023 01:11:13 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 593EA1203BF for ; Sat, 29 Apr 2023 05:11:13 +0000 (UTC) X-FDA: 80733254826.27.5D27B04 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id 39F3E4000A for ; Sat, 29 Apr 2023 05:11:11 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AcAQUPRk; spf=pass (imf04.hostedemail.com: domain of ming.lei@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=ming.lei@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682745071; 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=2hAEIix55mQqheQ/XmVIMx3hso9fuBFFY9y7DgUUBM8=; b=c9p0AeBWb83BvHaSWFNWs5/cq7HkUYDlKq2kN062J0W3JR3EUgCbN19goOsnvWPN2a5SCe bIg3jT/3Xd3/Sup6IzKGJfQ8X65HBDG2QPt7s6aPguC4E3Fa+kq5nZiSSm3KTLzjI0J6QG TVhYb6KnbhxBhIXaDLCRP3IQTVS6l38= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682745071; a=rsa-sha256; cv=none; b=VZzosegDauTHEMjionKPbXUryS3u1TBJ+WSFk6gVuCypOq2mVA22zuzsxfQl64QanbMUAZ 8wQY/nOA+XLq8OYLzRaZh0gGFNtLC03vU9x4gFb7RUlSQiGbTEyxEqhCt1llz17L+5FljI 4SLben6T8+Lb5+sgHMnKbxRI/U75Tao= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AcAQUPRk; spf=pass (imf04.hostedemail.com: domain of ming.lei@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=ming.lei@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1682745070; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2hAEIix55mQqheQ/XmVIMx3hso9fuBFFY9y7DgUUBM8=; b=AcAQUPRkHv9S41fHPmwipk94F7Ggh8gGakVVG5lIcP3BDVb7YAgvSVHWi8VA9PO1eKpJ3x 0ghz3Rit6rKYNs/MOvgntVS1X9MGJ0QHoNeVLG/rVycMSHYH+B/fNGI/oHLdYjGo6HBM8b 4ec8kdO/K6Du0PDdb4hV14rI+y6zaLk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-352-R6yLz9NvNsCULUVy6I_V-g-1; Sat, 29 Apr 2023 01:11:04 -0400 X-MC-Unique: R6yLz9NvNsCULUVy6I_V-g-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6741F85A5B1; Sat, 29 Apr 2023 05:11:02 +0000 (UTC) Received: from ovpn-8-24.pek2.redhat.com (ovpn-8-18.pek2.redhat.com [10.72.8.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B6EE5400F4D; Sat, 29 Apr 2023 05:10:54 +0000 (UTC) Date: Sat, 29 Apr 2023 13:10:49 +0800 From: Ming Lei To: Christoph Hellwig Cc: Theodore Ts'o , Baokun Li , Matthew Wilcox , linux-ext4@vger.kernel.org, Andreas Dilger , linux-block@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Dave Chinner , Eric Sandeen , Zhang Yi , yangerkun , ming.lei@redhat.com Subject: Re: [ext4 io hang] buffered write io hang in balance_dirty_pages Message-ID: References: <663b10eb-4b61-c445-c07c-90c99f629c74@huawei.com> <20230429044038.GA7561@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230429044038.GA7561@lst.de> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Rspam-User: X-Rspamd-Queue-Id: 39F3E4000A X-Rspamd-Server: rspam09 X-Stat-Signature: p8983z5pa4t5p3nch6zbucbhdsardnnn X-HE-Tag: 1682745071-438725 X-HE-Meta: U2FsdGVkX1/mVJ6LzjgM4NT3o8kV9WJdjaE4aNXtIHUn6P/+k+OOZCqcQzyghZYDRpLiGVvYdo/NUVDhHRhEHYaThX18mPLQEMIqv3vWaUrqFU+6Qkoyr+wA5TebBn9J4EEwXmCT7wkdHhO3H/KoJM7alWz3GWOgkiUMCNuMO9BXajj+iy5+8ID7YCeSiaLY9+Q1jnR9EX2iOLLpNq6xvYdtHgdYKd/6y6hCOBLgnFFfxmezRxqPEqz5fyB6Oizb6bRjeeoFoJAZ0+vWPyLHtfnb92mZFcutYm+VHKVzF4KxzZHMSqWXJbpOXLN/rbGw1gdeWZtVL14BJWD/ypbpBMSLwsHNNa27Q9JL74oDY87It9HiRDyD/uNgsIRnCTFqBxH8bMl5MERcNneqatBNMg5MLODRvfc1raDxtKPUVdgs8MchLMHYBVWOPJidls8t3eVzWayNKfnuz+/tO4sig0ndGBuW9cvC8Eb57RaiHLuo6+BwLBNNvAyHhe3+U/GgLQrshH4+gDbOAaxRXumLZEzYcaH6aHLkDcylqVfAsCnDlaGyZg3TI4459Xp2X3IbEQz6eNzOJzCgi4qzvsi9gZ/eWGvzW7JRMB70+HsUjqj/g5PKhO1FPIL45EdYlrfmjqiC1iE3SVxoqiYU0Adrp2Cu9wb7OFDODF4GcjhFBReOjsw3snvV4QtmhuhaLm6qI7X08Das6hvD+ajGvRMQNJsC0quJQjT0yjUJJccHBVdQh4+kSX/N3KHGUiQn4JUSenno/fJQyJeWGe2Xytu4skAPp4R/Uv0paiewHxSC6EW7AGLPjvqOgiIy40KWc03ewwOq6ypOapdcBi0vOaU/ZWsqzVY/xF59lEqY6HbzjbO3Hh03nsxSXtuzN41h+dzlXNo27sPssgXEuvbKQSOEuHws5+yHxciObPK8710RNJw/rHIcnDDLF/TDGm4J8+7e7p9B/mXikPh/f0O0pr0 GmBGkZjp 5SMGldqq015PFWBHLwuKi5wsXMgNq11Gr0uBLfrMjk69X6uv5EKpGB03tigbIUTL/OGsgPWkHhFas0LOOZhKB4rjycCl3Bwo89gxPPreuzRtmPpOjRyrMRV8sGvMSFGz5RH+7V8P6LuohUQAIZFFldhdWd+MYH7antNUjScusJXF86MnC9iRAKjAokReUQkwiRqfmdCGxi3LNee+aIm6h/RasfQ== 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 Sat, Apr 29, 2023 at 06:40:38AM +0200, Christoph Hellwig wrote: > On Sat, Apr 29, 2023 at 11:16:14AM +0800, Ming Lei wrote: > > OK, looks both Dave and you have same suggestion, and IMO, it isn't hard to > > add one interface for notifying FS, and it can be either one s_ops->shutdown() > > or shutdown_filesystem(struct super_block *sb). > > It's not that simple. You need to be able to do that for any device used > by a file system, not just s_bdev. This means it needs go into ops > passed by the bdev owner, which is also needed to propagate this through > stackable devices. Not sure if it is needed for non s_bdev , because FS is over stackable device directly. Stackable device has its own logic for handling underlying disks dead or deleted, then decide if its own disk needs to be deleted, such as, it is fine for raid1 to work from user viewpoint if one underlying disk is deleted. > > I have some work on that, but the way how blkdev_get is called in the > generic mount helpers is a such a mess that I've not been happy with > the result yet. Let me see if spending extra time with it will allow > me to come up with something that doesn't suck. > > > But the main job should be how this interface is implemented in FS/VFS side, > > so it looks one more FS job, and block layer can call shutdown_filesystem() > > from del_gendisk() simply. > > This needs to be called from blk_mark_disk_dead for drivers using that, > and from del_gendisk only if GD_DEAD isn't set yet. OK, looks you mean the API needs to be called before GD_DEAD is set, but I am wondering if it makes a difference, given device is already dead. Thanks, Ming