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 95755C433F5 for ; Fri, 21 Jan 2022 07:16:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E91456B0080; Fri, 21 Jan 2022 02:16:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E401E6B0081; Fri, 21 Jan 2022 02:16:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D56646B0082; Fri, 21 Jan 2022 02:16:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay040.a.hostedemail.com [64.99.140.40]) by kanga.kvack.org (Postfix) with ESMTP id C77436B0080 for ; Fri, 21 Jan 2022 02:16:29 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 86292230BE for ; Fri, 21 Jan 2022 07:16:29 +0000 (UTC) X-FDA: 79053436098.03.F587790 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf27.hostedemail.com (Postfix) with ESMTP id BC43140003 for ; Fri, 21 Jan 2022 07:16:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sww/wwaWy03hlZ/EaFDFfo+1Npwvs31lVzyDCnqKm+M=; b=3z9uw5j+S2pf6nD2ooQW91WtxK aPSDnO2M+uQJBElEk9lMsC/znXs6RQZ6CJhLkqIX0Iu9skcFdAY+ejjQCQyV/feQLF6NPePEK3nVR yBYKmHkRI/ytKK50oeZOBQQZJsGHb9Fyni/SDutvloNOoHUSGtQWStctL2Cmrw4ER5WnVDqZolW4G jDUhKW0OAwKdvwZIOp2Wlc0EK/QsfKDkbxW1gbf+VRxbSNt+YBfz54NvNhNFMzeX8OilBhT4XCMZt 5P7RkYEOjRPDUpOG8w2WElZiTVMC9hv/8WWSQIRDecZcHs4YOP4XvDyiiTJEZSq71XQvOKhYbCfIT KmYItTGg==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nAo9l-00E2By-OP; Fri, 21 Jan 2022 07:16:21 +0000 Date: Thu, 20 Jan 2022 23:16:21 -0800 From: Christoph Hellwig To: Shiyang Ruan Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, nvdimm@lists.linux.dev, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, djwong@kernel.org, dan.j.williams@intel.com, david@fromorbit.com, jane.chu@oracle.com Subject: Re: [PATCH v9 10/10] fsdax: set a CoW flag when associate reflink mappings Message-ID: References: <20211226143439.3985960-1-ruansy.fnst@fujitsu.com> <20211226143439.3985960-11-ruansy.fnst@fujitsu.com> <70a24c20-d7ee-064c-e863-9f012422a2f5@fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <70a24c20-d7ee-064c-e863-9f012422a2f5@fujitsu.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: BC43140003 X-Stat-Signature: jwe1nq8i68hg5t7ymxcr8fscbt4kqg9u Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=3z9uw5j+; spf=none (imf27.hostedemail.com: domain of BATV+e38482cd6722563dea4e+6725+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+e38482cd6722563dea4e+6725+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none X-HE-Tag: 1642749388-844699 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, Jan 21, 2022 at 10:33:58AM +0800, Shiyang Ruan wrote: > > > > But different question, how does this not conflict with: > > > > #define PAGE_MAPPING_ANON 0x1 > > > > in page-flags.h? > > Now we are treating dax pages, so I think its flags should be different from > normal page. In another word, PAGE_MAPPING_ANON is a flag of rmap mechanism > for normal page, it doesn't work for dax page. And now, we have dax rmap > for dax page. So, I think this two kinds of flags are supposed to be used > in different mechanisms and won't conflect. It just needs someone to use folio_test_anon in a place where a DAX folio can be passed. This probably should not happen, but we need to clearly document that. > > Either way I think this flag should move to page-flags.h and be > > integrated with the PAGE_MAPPING_FLAGS infrastucture. > > And that's why I keep them in this dax.c file. But that does not integrate it with the infrastructure. For people to debug things it needs to be next to PAGE_MAPPING_ANON and have documentation explaining why they are exclusive.