linux-kernel - Re: [PATCH] fuse: clarify extending writes handling

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: <20250820052043.GJ7942@frogsfrogsfrogs>
Date: Tue, 19 Aug 2025 22:20:43 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Chunsheng Luo <luochunsheng@...c.edu>
Cc: miklos@...redi.hu, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fuse: clarify extending writes handling

On Wed, Aug 20, 2025 at 10:11:43AM +0800, Chunsheng Luo wrote:
> Tue, 19 Aug 2025 16:07:19 Miklos Szeredi wrote:
> 
> >>
> >> Only flush extending writes (up to LLONG_MAX) for files with upcoming
> >> write operations, and Fix confusing 'end' parameter usage.
> >
> > Patch looks correct, but it changes behavior on input file of
> > copy_file_range(), which is not explained here.
> 
> Thank you for your review.
> 
> For the copy_file_range input file, since it only involves read operations,
> I think it is not necessary to flush to LLONG_MAX. Therefore, for the input file, 
> flushing to the end is sufficient.
> 
> If you think my understanding is correct, I can resend a revised version of
> the patch to update the commit log and include a clear explanation regarding
> the behavior changes in 'fuse_copy_file_range' and 'fuse_file_fallocate' operations.

I don't understand the current behavior at all -- why do the callers of
fuse_writeback_range pass an @end parameter when it ignores @end in
favor of LLONG_MAX?  And why is it necessary to flush to EOF at all?
fallocate and copy_file_range both take i_rwsem, so what could they be
racing with?  Or am I missing something here?

fuse-iomap flushes and unmaps only the given file range, and afaict
that's just fine ... but there is this pesky generic/551 failure I keep
seeing, so I might actually be missing some subtlety. :)

--D

> Thanks
> Chunsheng Luo
>