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 C90B3C77B73 for ; Tue, 25 Apr 2023 15:18:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 32EEA6B0071; Tue, 25 Apr 2023 11:18:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DEEC6B0072; Tue, 25 Apr 2023 11:18:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1CE296B0075; Tue, 25 Apr 2023 11:18:05 -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 0C78B6B0071 for ; Tue, 25 Apr 2023 11:18:05 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CCE72A0250 for ; Tue, 25 Apr 2023 15:18:04 +0000 (UTC) X-FDA: 80720268888.09.02E55B6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id E751540006 for ; Tue, 25 Apr 2023 15:18:02 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JwuiYzoE; spf=pass (imf01.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682435883; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ihYC3cN1iL8c5ZpYiA69jGqbLlbdsJGtqKtHptCvdhU=; b=2OQ86IitNvoAn7OOP+ASIyG/YM7JSN5HipAgQI5gixFhjOSbPy2/XDztGaW7un8vqHf6mX mNvr6o7IP26N5J4O6oP6tIEAEoePtXylEqqQSQGLhqjHoW8dZC/LGGXaaXFkCDK3ekE5HC X3bKrC2nqV2Rq8KhDVcH+1Ev8QMi2m0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JwuiYzoE; spf=pass (imf01.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682435883; a=rsa-sha256; cv=none; b=rX6MRnXN8FviI8AJamciZgC9PQqzgzNwVRJbDgt1luYIMIXWzV2e8qjRG8uxUexxpZQVV1 zBwvRhqD2PDL1m2ebRH222/P/DLCVVNj/yxwIstpA3YL55VAfEYkv8wjgGrX+gKz1AL3OR kIEszr/5TfufKuxlv3f4En3jvaxRYuA= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BF9A861765; Tue, 25 Apr 2023 15:18:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1C680C433EF; Tue, 25 Apr 2023 15:18:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682435881; bh=OZVtwFWo7+1hR1E/XFg8v7jLksChEj4wIb247kHrI2I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JwuiYzoE9l78rA8VNEL7AMkMtYghXYh1MhzRtXMnCSRA9FgM/K0NzCyfCHGaNdnVt aIeHzHmeqbLKat4hJ1Oq7PBAve2s18Wh05BcH+6o+l3mw/nfuKNmuoUu4rx6nq7g+I Z4YGADE1utvo86K7C8mGq3AvAeE0iCJ9R1GozHBCQej9h/5kUxhnzH27StZlEJBXyg 5fq/WsC893YV8eOQcHWIFwJmnaio0ljNHnr2lGifbygRZQE0lQDHbdRUnBQdkJGtWm sLdv/HCbVAk0eywgGBVhF0anUGlHajCypKtFawvQrMWdKWhSWY4jjHwGsCYJ5avSc0 Gc1cfGvS7qmlw== Date: Tue, 25 Apr 2023 08:18:00 -0700 From: "Darrick J. Wong" To: Jan Kara Cc: Shiyang Ruan , Luis Chamberlain , linux-fsdevel@vger.kernel.org, nvdimm@lists.linux.dev, linux-xfs@vger.kernel.org, linux-mm@kvack.org, dan.j.williams@intel.com, willy@infradead.org, akpm@linux-foundation.org Subject: Re: [RFC PATCH v11.1 2/2] mm, pmem, xfs: Introduce MF_MEM_REMOVE for unbind Message-ID: <20230425151800.GS360889@frogsfrogsfrogs> References: <1679996506-2-3-git-send-email-ruansy.fnst@fujitsu.com> <1681296735-2-1-git-send-email-ruansy.fnst@fujitsu.com> <0a53ee26-5771-0808-ccdc-d1739c9dacac@fujitsu.com> <20230420120956.cdxcwojckiw36kfg@quack3> <20230425132315.u5ocvbneeqzzbifl@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230425132315.u5ocvbneeqzzbifl@quack3> X-Stat-Signature: yg58xcr3fogfza87u4n6omtrd5msyr4y X-Rspam-User: X-Rspamd-Queue-Id: E751540006 X-Rspamd-Server: rspam06 X-HE-Tag: 1682435882-115668 X-HE-Meta: U2FsdGVkX1/1d8XqIMsjMag/HzW8TaORZW8VSL2npLd5FWfXS+p9hyH29o/GFM0MIi1n0FpPTeAFuGRDV3LNmVEwJ1Z+IbMpe0SQwax3AX9g3sbUOg3nz6V11VnK2LzD+MC41vZWF4+0wDQNg2fBWlRmGVRtaS8EfR8D1+rdct8yrRuUzxvpk4yX4yPkG6xzXlOti7x+h4dT3ePRYSDg80vNJB15y/ecW9nQCGxYn+C5DvQIClvNRRyJ8a6bY8Kx3ljJjxTdhg1ZknhYHxdYttKvVnv9DyPPy36By6RLSZvNZYJD/FaKNLtHWlCQHvW1Ska8EQVk9utpx7WF32Z6WOTsEl5hVBHtQ4QudPWhNkbMgmUK7JgKvuO8gz2nleEF7HSElhdhXfpYxzQdVS6N5Vf0BCrqyOOdmXdcMjy2Gg8XSdOxzIl09WFcymWPc3OEV/mpjV3ol0R+NPr5zSc/1rB2XvJud4EPLAtUoj8etm4g7WQbsXBBReUMKG7BsJ4bCn3NC6dtwmrZp3pgzNkau2ioSexkBp6H6d8qTm7nucpPJ23nZxT67EDD4eTPP0MGs5RKRGna/jHQELjA1/MQsWB76eWQzKDUUbCUxOqN5tFybE86So0OWANkS3Za7y/GF2OzGquq+o29mWMZp7IBQr9tS6AicLhVOEYJl9dW3y1diOvFB809qLMdj+ruULSiRCMRWa4lG8d21GgRre5B8DA5iq/40yVkxqdcJkdtJsHSESNNVo4f3cZqVGxB1zrr9S2ekOba/zQKbnEFomJdvJ/L2iAesYH0EUgOKJTVIRjx31dkmOHFsekwl1p8OB5hx+WAyhYBtHcrQYM5hTTWjnur4NnqICpJG5VI+E/2cp74wKu41iJI0CbqTrDjuH0SOa4TePOsP/qk8M58ewwWGbh00y8L2/8tOSS092UD3U91aIUZlAyxZFYBmsDkmHYlUSwUzH8XA9nKYlJNRHw EtPopsrI oZk5J+eZb9VrHDjNy6zW2Lu0yPehdKGDPVwNQL10av6w3TmqORBvZiJ79eCgLwVvLAQwhk40y4kd/n7613nD3t8rT4SHb4hwYmjMCFl2TGxaLoYgvHfVV9nDpkbNe5ypuhcy8sOvthUBmHsVfjkTxAEzJcG3HV7MX0O00KYqGMjRbIPTtofN4wJj1EtFMcPRcOq0izSCnSTity9iTNsh2S1M2t23JyIKZ3pp8PU2j141GHwPwPooHDUcf5vupurHAEtLu+HmS3S+3y3q7c/AKwrRm3K8EcClb5u+TvbRMLqc+ugRwluiD9DibFt8xWVxPNxeBgz8txXAbHcDR4E40DhDEYb1hJ9hyNU8e8YQw0KAAyTXcaIXbFc5LxRDjUAPSX4d+pg5lGycWaRrVeDUdXR8A57L6H4DmwiiOYcpAyUJgbSaK/zq+R1PTlMBnzT88f0bLGn0tu3lTjAY= 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 Tue, Apr 25, 2023 at 03:23:15PM +0200, Jan Kara wrote: > On Tue 25-04-23 20:47:35, Shiyang Ruan wrote: > > > > > > 在 2023/4/20 20:09, Jan Kara 写道: > > > On Thu 20-04-23 10:07:39, Shiyang Ruan wrote: > > > > 在 2023/4/12 18:52, Shiyang Ruan 写道: > > > > > This is a RFC HOTFIX. > > > > > > > > > > This hotfix adds a exclusive forzen state to make sure any others won't > > > > > thaw the fs during xfs_dax_notify_failure(): > > > > > > > > > > #define SB_FREEZE_EXCLUSIVE (SB_FREEZE_COMPLETE + 2) > > > > > Using +2 here is because Darrick's patch[0] is using +1. So, should we > > > > > make these definitions global? > > > > > > > > > > Another thing I can't make up my mind is: when another freezer has freeze > > > > > the fs, should we wait unitl it finish, or print a warning in dmesg and > > > > > return -EBUSY? > > > > > > > > > > Since there are at least 2 places needs exclusive forzen state, I think > > > > > we can refactor helper functions of freeze/thaw for them. e.g. > > > > > int freeze_super_exclusive(struct super_block *sb, int frozen); > > > > > int thaw_super_exclusive(struct super_block *sb, int frozen); > > > > > > > > > > [0] https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/commit/?h=repair-fscounters&id=c3a0d1de4d54ffb565dbc7092dfe1fb851940669 > > > > > > I'm OK with the idea of new freeze state that does not allow userspace to > > > thaw the filesystem. But I don't really like the guts of filesystem > > > freezing being replicated inside XFS. It is bad enough that they are > > > replicated in [0], replicating them *once more* in another XFS file shows > > > we are definitely doing something wrong. And Luis will need yet another > > > incantation of the exlusive freeze for suspend-to-disk. So please guys get > > > together and reorganize the generic freezing code so that it supports > > > exclusive freeze (for in-kernel users) and works for your usecases instead > > > of replicating it inside XFS... > > > > I agree that too much replicating code is not good. It's necessary to > > create a generic exclusive freeze/thaw for all users. But for me, I don't > > have the confidence to do it well, because it requires good design and code > > changes will involve other filesystems. It's diffcult. > > > > However, I hope to be able to make progress on this unbind feature. Thus, I > > tend to refactor a common helper function for xfs first, and update the code > > later when the generic freeze is done. > > I think Darrick was thinking about working on a proper generic interface. > So please coordinate with him. I'll post a vfs generic kernelfreeze series later today. One thing I haven't figured out yet is what's supposed to happen when PREREMOVE is called on a frozen filesystem. We don't want userspace to be able to thaw the fs while PREREMOVE is running, so I /guess/ that means we need some method for the kernel to take over a userspace freeze and then put it back when we're done? --D > Honza > > -- > Jan Kara > SUSE Labs, CR