linux-kernel - Re: [PATCH 5/7] fsdax: Dedup file range to use a compare function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9193e305-22a1-3928-0675-af1cecd28942@cn.fujitsu.com>
Date:   Tue, 9 Feb 2021 17:15:13 +0800
From:   Ruan Shiyang <ruansy.fnst@...fujitsu.com>
To:     Christoph Hellwig <hch@....de>
CC:     <linux-kernel@...r.kernel.org>, <linux-xfs@...r.kernel.org>,
        <linux-nvdimm@...ts.01.org>, <linux-fsdevel@...r.kernel.org>,
        <darrick.wong@...cle.com>, <dan.j.williams@...el.com>,
        <willy@...radead.org>, <jack@...e.cz>, <viro@...iv.linux.org.uk>,
        <linux-btrfs@...r.kernel.org>, <ocfs2-devel@....oracle.com>,
        <david@...morbit.com>, <rgoldwyn@...e.de>,
        Goldwyn Rodrigues <rgoldwyn@...e.com>
Subject: Re: [PATCH 5/7] fsdax: Dedup file range to use a compare function



On 2021/2/8 下午11:19, Christoph Hellwig wrote:
> 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.

The dax dedupe comparison need the iomap_ops pointer as argument, so my 
understanding is that we don't modify the argument list of 
generic_remap_file_range_prep(), but move its code into 
__generic_remap_file_range_prep() whose argument list can be modified to 
accepts the iomap_ops pointer.  Then it looks like this:

```
int dax_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,
				  const struct iomap_ops *ops)
{
	return __generic_remap_file_range_prep(file_in, pos_in, file_out,
			pos_out, len, remap_flags, ops);
}
EXPORT_SYMBOL(dax_remap_file_range_prep);

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)
{
	return __generic_remap_file_range_prep(file_in, pos_in, file_out,
			pos_out, len, remap_flags, NULL);
}
EXPORT_SYMBOL(generic_remap_file_range_prep);
```

Am i right?


--
Thanks,
Ruan Shiyang.

> 
>> +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.
> 
>