Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp613398pxy; Wed, 21 Apr 2021 10:30:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUSA0zstGADQbG0OUfjimuarcokDKCy0R2JyvTlPAUqlfmzT39aPJHhcb6D6FpEtraary8 X-Received: by 2002:a17:907:3e13:: with SMTP id hp19mr30367950ejc.276.1619026242929; Wed, 21 Apr 2021 10:30:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619026242; cv=none; d=google.com; s=arc-20160816; b=Rg2RMs00eWsKdgXXVCVd03KQXtC7cXGAtgJBgUEnkVJA1mfpUfgUNOZm6nQk5LJdMR Jt2J7zSOH0vGfmY1IZod8rt9/yOcDorn2w5upuCXIMZ1VONAdtVuINQPQYF8xU956oEP wDi2k9XyxDRwm4DEdHZpKu2I5Z8AQyrOLHXqa8sVMBQt+2WvGnlgqxpaxyux2Bytb1h7 zs/axdLkKDh4oIqH1kVmb379z4c39VWlVNYIh/y2CxOo8ik3mwb7ZYcjhu5nKDM2YL2p XYfBBuKXmFaPFaNPLphl5FYVJD5zP7aSUR4OhTGiIUN/Crm1B6y+ANMi8/nUbqvPmIjZ dlFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=U4FCt7J61WV73+47NtZTxuFlyU8QUi+HAT8bKuQE8sI=; b=rVuWYVLpx/UNb1OqlKaTMyNinlB2VtXwwyU2xxyEMr0Ax72ZP0t0g/FDdsdid0Bdvj OJfsr2PtSxL1YSWrCprurkuuxsr66+nl6sANdPtu5+++vezGMDBn4i8OBSdiQVS33v9V 6DBt0zatPLIxjDSrdgyRpEQUFTtIL9t5Xet5pwO9qaXfctVbH89GtxClIwRJ3jpYpEqQ /9eGEIu2jTIiYJZtDYBkiO6iQuReam599hChwKl91YLlsbDgpYSh/7yvAw7wDGW5kPmT If0PntglOZPgC0zDPrTsCLHy7NzfmDzdkQbjQkVd6kkvWaQOWXq3DtdNzDg9o5XJ8fvX 9G9A== 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 v13si561779edl.24.2021.04.21.10.30.12; Wed, 21 Apr 2021 10:30:42 -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 S242132AbhDUNrK (ORCPT + 99 others); Wed, 21 Apr 2021 09:47:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:57586 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234093AbhDUNrJ (ORCPT ); Wed, 21 Apr 2021 09:47:09 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id F14E5AF5B; Wed, 21 Apr 2021 13:46:34 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 9043E1F2B69; Wed, 21 Apr 2021 15:46:34 +0200 (CEST) Date: Wed, 21 Apr 2021 15:46:34 +0200 From: Jan Kara To: Christoph Hellwig Cc: Zhang Yi , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, yukuai3@huawei.com Subject: Re: [RFC PATCH v2 7/7] ext4: fix race between blkdev_releasepage() and ext4_put_super() Message-ID: <20210421134634.GT8706@quack2.suse.cz> References: <20210414134737.2366971-1-yi.zhang@huawei.com> <20210414134737.2366971-8-yi.zhang@huawei.com> <20210415145235.GD2069063@infradead.org> <20210420130841.GA3618564@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210420130841.GA3618564@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue 20-04-21 14:08:41, Christoph Hellwig wrote: > On Fri, Apr 16, 2021 at 04:00:48PM +0800, Zhang Yi wrote: > > Now, we use already use "if (bdev->bd_super)" to prevent call into > > ->bdev_try_to_free_page unless the super is alive, and the problem is > > bd_super becomes NULL concurrently after this check. So, IIUC, I think it's > > the same to switch to check the superblock is active or not. The acvive > > flag also could becomes inactive (raced by umount) after we call into > > bdev_try_to_free_page(). > > Indeed. > > > In order to close this race, One solution is introduce a lock to synchronize > > the active state between kill_block_super() and blkdev_releasepage(), but > > the releasing page process have to try to acquire this lock in > > blkdev_releasepage() for each page, and the umount process still need to wait > > until the page release if some one invoke into ->bdev_try_to_free_page(). > > I think this solution may affect performace and is not a good way. > > Think about it in depth, use percpu refcount seems have the smallest > > performance effect on blkdev_releasepage(). > > > > If you don't like the refcount, maybe we could add synchronize_rcu_expedited() > > in ext4_put_super(), it also could prevent this race. Any suggestions? > > I really don't like to put a lot of overhead into the core VFS and block > device code. ext4/jbd does not own the block device inode and really > has no business controlling releasepage for it. I suspect the right > answer might be to simply revert the commit that added this hook. Indeed, after 12 years in kernel .bdev_try_to_free_page is implemented only by ext4. So maybe it is not that important? I agree with Zhang and Christoph that getting the lifetime rules sorted out will be hairy and it is questionable, whether it is worth the additional pages we can reclaim. Ted, do you remember what was the original motivation for this? Honza -- Jan Kara SUSE Labs, CR