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 63ADDC77B60 for ; Sat, 29 Apr 2023 04:40:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B160B6B0075; Sat, 29 Apr 2023 00:40:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC6B96B0078; Sat, 29 Apr 2023 00:40:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B5436B007B; Sat, 29 Apr 2023 00:40:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 88C286B0075 for ; Sat, 29 Apr 2023 00:40:45 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3A1C812033B for ; Sat, 29 Apr 2023 04:40:45 +0000 (UTC) X-FDA: 80733178050.18.419AD31 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf22.hostedemail.com (Postfix) with ESMTP id 4A6FBC000B for ; Sat, 29 Apr 2023 04:40:43 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=none (imf22.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682743243; 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; bh=LZED551cPg/Me3kYmpD1y1Iqb6yZqgG1tIvc3018i8U=; b=10Av21cGti9qRnHNNxYrVvTsDqx9+2aODKShz+yoTgDVnskux28ocsAUBbTIygwMA4HBEz r45TDDxyOvx01NkUB7lRuYtiL9ltd54VDznUl0d19+KptYzOt0Mn5e7fGaUkgXZR+4Is4o PA1Xu9/ZlCEgq+FwQFxEv7RQuRw2lMo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=none (imf22.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682743243; a=rsa-sha256; cv=none; b=NyEoGsqbseMXaomjzOAsYuKvjoKIVEDu/MLYY3QFGbDLIvHwFbFInp8JkN670OrNBI229T Qcd3vG2p1RikgzvvDagdtij9AxpmdzKt57YFNusXzP3+1Sj8xFx7CEsw16f1CcY97TZZJw oZNkgFAK9dhHwzpNmrbQD25LRf20nr4= Received: by verein.lst.de (Postfix, from userid 2407) id 9BE0268D13; Sat, 29 Apr 2023 06:40:38 +0200 (CEST) Date: Sat, 29 Apr 2023 06:40:38 +0200 From: Christoph Hellwig To: Ming Lei 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 , Christoph Hellwig , Zhang Yi , yangerkun Subject: Re: [ext4 io hang] buffered write io hang in balance_dirty_pages Message-ID: <20230429044038.GA7561@lst.de> References: <663b10eb-4b61-c445-c07c-90c99f629c74@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4A6FBC000B X-Stat-Signature: i1zo7s1y9fizy3fzg7kn5pebox7xeiab X-HE-Tag: 1682743243-482683 X-HE-Meta: U2FsdGVkX1+WWUzBfpAV683jHuUKsLaSJ/P0B5sqHbgjTnh/Ht+bqezy9LcPhSa1PKAfZefnjkL4wntAlr/sYlYdZElQiwyt5/sZt944hydlmeml31XbKnVcsw5Viq/U/6Axbaz3wOBio2n5Hje9twlABI1jstIlau4bGUCxZ9zGsNO6pJExk9V7LEQ8oBZBOIJ+5zFie8JoS9mC6/rXbg7KbNmCiQls742kVysl576TPB5+LeO/3dbNY4ahweivhilzcZypBX/DhXSwXwa8qv8nYJufnU8L90ayPeeBHlMbLKoJixa30gklKRXqSMRs18e8HJkxCKswVCG2HUwmcHLHXRsZfokX7V7EWZlX8TqQ0DBKB2l1Zp5v5UNVKXJZHeckfW6eJYAqRGjqg9gql0X151ErBLABm0801jbwstTrnPucKKsU/d7tTrCRrQkpja+VS4xl0dWrZgD34l+2Aeeoaa9HnqzSZYJJcvqS/GFGocj8GyqTLzP0g/QJCTMTmRBYaBi/TTZH3D07c5x+dsym2k5gcehVja6Bn+6Tb3mPM95XEeFzwokEH4ipgCJjW1MuDj+/61FPh0RNlG0Qs3/zJk8dwQXjVgvFCtAo0zYONZlu3e6b4wx7lDu9gD51fuIRaaazfWbmIZkTVjsT5/LRIm+Zj7QV7DoAkEQF/ISEt57ZRX3Nd4iGjr3hnob8ZhcucVknVIMQFfM8+8rUQ4AsbXc9w+jjl1e+vMWboBObZbdN4yrx3IXag+6Q1CC+dCsjukrGCo8upVt3PBxZqlJhn5MqxOXwf9ZmrOuVLrHHjGJd861KsSYUgWL08WmCxrARGScTYt7jpYixe0EjHxqB4VRWeCid2dKXdaLSpS0g//RNGBNOfG+1LkDOjqF4IzSakcTtqqa/1+ngDGRyeK/vS/HALyGl1YhQjkK1gT1wTIknAXUfrQ4KIiNdP20ygAUs9VycJsWiskKp5NS EVzUmAmN 26dexweZYd6v9JjlSP3mO2uNCpbYMrq24xCcpuAU47jvdprCAgSKlaZQJ4l9oKjUDeaxmuYghiDfl6pSWwfWm6E5oeG6shUCOhncV8w6F1PuhF8s= 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 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. 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.