Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4146712pxb; Mon, 8 Feb 2021 09:00:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJx6j31qT24/jW02RTyuLN9QdUfNfgvNJyoMdd79RrtAGdZDXjU1tpbAYAwTHheJ2DgKXd+W X-Received: by 2002:a17:906:4442:: with SMTP id i2mr18064370ejp.41.1612803604279; Mon, 08 Feb 2021 09:00:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612803604; cv=none; d=google.com; s=arc-20160816; b=qG/JsEz/DuJniew/PuAtvbhzV0XZraToNSqGUi8n7+4WSdzDNhRQ1Wl1ziXmmk05Ma bNc95R7hDztRr/E1be3i7FpHIq9mz6gShBO9jyOqLnGptkztev/aTyyp87jddycuXELA ZQogRDK+rpL1CH1y2YXPYVNbeqUl+MIU2JB33FEH5BbDreOGF3Wi7ByUsk3FT6FMMVfm yeSPU1YuTCY9lh2klbHmYNrSpwo7MjsYLdZDomNPW8UjciQ5lbGveRsMNTNWD7XDXJvL 70dZjg+md1WaYPxD37Vvtfepo3tCAshL9GjiXjrv3iN85vu17dvG4zTjGKbV4ZreP5wn VDRQ== 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=aNNakJoC8a8V6FeNz8dGXsoplRLtKT3a/8VK48I8Tn8=; b=EeLoU6oe/Z7CJ2aSgLvGWFypKT49f+ETJy+gm7d+LVWU5PKDo7PnBG59R5C5ig8bcJ 5zNuW+DMDlge+KtcOmIRnR/cSvYXowx0vsvxoi1FryJSyLbl8Yb3B0qNSnTU+UoSaotW GlYpuWdUhViA6ALiV8siDC2TBbkNQ99iA2CFzhKagf9KXq2QxqINvPmh2LeV8PRY9nxP 77vN8Xj63SsykvHoU+hPGniKMgG7SyReEfsUOfRlTgIon+5fZqmU9RsD//Q+yweCLi04 G5teyKJ1rj4SluG0+3Av8pJPZuiV7KacXtCcGlJ2+s0u0nBvD6AM2beWgbLNE4bqfTXu 1BGQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 j19si13250476edw.550.2021.02.08.08.59.40; Mon, 08 Feb 2021 09:00:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234521AbhBHQ7C (ORCPT + 99 others); Mon, 8 Feb 2021 11:59:02 -0500 Received: from verein.lst.de ([213.95.11.211]:41777 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233681AbhBHPUF (ORCPT ); Mon, 8 Feb 2021 10:20:05 -0500 Received: by verein.lst.de (Postfix, from userid 2407) id B592868AFE; Mon, 8 Feb 2021 16:19:20 +0100 (CET) Date: Mon, 8 Feb 2021 16:19:20 +0100 From: Christoph Hellwig To: Shiyang Ruan Cc: linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-nvdimm@lists.01.org, linux-fsdevel@vger.kernel.org, darrick.wong@oracle.com, dan.j.williams@intel.com, willy@infradead.org, jack@suse.cz, viro@zeniv.linux.org.uk, linux-btrfs@vger.kernel.org, ocfs2-devel@oss.oracle.com, david@fromorbit.com, hch@lst.de, rgoldwyn@suse.de, Goldwyn Rodrigues Subject: Re: [PATCH 5/7] fsdax: Dedup file range to use a compare function Message-ID: <20210208151920.GE12872@lst.de> References: <20210207170924.2933035-1-ruansy.fnst@cn.fujitsu.com> <20210207170924.2933035-6-ruansy.fnst@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210207170924.2933035-6-ruansy.fnst@cn.fujitsu.com> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 08, 2021 at 01:09:22AM +0800, Shiyang Ruan wrote: > With dax we cannot deal with readpage() etc. So, we create a > funciton callback to perform the file data comparison and pass s/funciton/function/g > +#define MIN(a, b) (((a) < (b)) ? (a) : (b)) This should use the existing min or min_t helpers. > int generic_remap_file_range_prep(struct file *file_in, loff_t pos_in, > struct file *file_out, loff_t pos_out, > - loff_t *len, unsigned int remap_flags) > + loff_t *len, unsigned int remap_flags, > + compare_range_t compare_range_fn) Can we keep generic_remap_file_range_prep as-is, and add a new dax_remap_file_range_prep, both sharing a low-level __generic_remap_file_range_prep implementation? And for that implementation I'd also go for classic if/else instead of the function pointer. > +extern int vfs_dedupe_file_range_compare(struct inode *src, loff_t srcoff, > + struct inode *dest, loff_t destoff, > + loff_t len, bool *is_same); no need for the extern.