linux-kernel - Re: [PATCH] cifs: Fix non-availability of dedup breaking generic/304

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] [day] [month] [year] [list]

Date:   Tue, 5 Dec 2023 11:20:17 +1100
From:   Dave Chinner <david@...morbit.com>
To:     David Howells <dhowells@...hat.com>
Cc:     Steve French <sfrench@...ba.org>,
        Xiaoli Feng <fengxiaoli0714@...il.com>,
        Shyam Prasad N <nspmangalore@...il.com>,
        Rohith Surabattula <rohiths.msft@...il.com>,
        Jeff Layton <jlayton@...nel.org>,
        Darrick Wong <darrick.wong@...cle.com>,
        fstests@...r.kernel.org, linux-cifs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cifs: Fix non-availability of dedup breaking generic/304

On Mon, Dec 04, 2023 at 02:01:59PM +0000, David Howells wrote:
> Deduplication isn't supported on cifs, but cifs doesn't reject it, instead
> treating it as extent duplication/cloning.  This can cause generic/304 to go
> silly and run for hours on end.

This should also mention that it cloning rather than comparing data
can cause server-side data corruption in the destination file for
the benefit of anyone trying to track down weird data corruption
problems....

> Fix cifs to indicate EOPNOTSUPP if REMAP_FILE_DEDUP is set in
> ->remap_file_range().
> 
> Note that it's unclear whether or not commit b073a08016a1 is meant to cause
> cifs to return an error if REMAP_FILE_DEDUP.
>
> Fixes: b073a08016a1 ("cifs: fix that return -EINVAL when do dedupe operation")
> Suggested-by: Dave Chinner <david@...morbit.com>
> cc: Steve French <sfrench@...ba.org>
> cc: Xiaoli Feng <fengxiaoli0714@...il.com>
> cc: Shyam Prasad N <nspmangalore@...il.com>
> cc: Rohith Surabattula <rohiths.msft@...il.com>
> cc: Jeff Layton <jlayton@...nel.org>
> cc: Darrick Wong <darrick.wong@...cle.com>
> cc: fstests@...r.kernel.org
> cc: linux-cifs@...r.kernel.org
> cc: linux-fsdevel@...r.kernel.org
> Link: https://lore.kernel.org/r/3876191.1701555260@warthog.procyon.org.uk/
> ---
>  fs/smb/client/cifsfs.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c
> index 4d8927b57776..96a65cf9b5ec 100644
> --- a/fs/smb/client/cifsfs.c
> +++ b/fs/smb/client/cifsfs.c
> @@ -1276,7 +1276,9 @@ static loff_t cifs_remap_file_range(struct file *src_file, loff_t off,
>  	unsigned int xid;
>  	int rc;
>  
> -	if (remap_flags & ~(REMAP_FILE_DEDUP | REMAP_FILE_ADVISORY))
> +	if (remap_flags & REMAP_FILE_DEDUP)
> +		return -EOPNOTSUPP;
> +	if (remap_flags & ~REMAP_FILE_ADVISORY)
>  		return -EINVAL;
>  
>  	cifs_dbg(FYI, "clone range\n");

Apart from updating the commit message, the fix looks fine to me.

Reviewed-by: Dave Chinner <dchinner@...hat.com>
-- 
Dave Chinner
david@...morbit.com