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

Message-ID: <CAJfpegtXUekKPaCxEG29SWAK0CTz-fdGvH=_1G5rcK9=eHt6wQ@mail.gmail.com>
Date: Wed, 20 Aug 2025 08:52:35 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Chunsheng Luo <luochunsheng@...c.edu>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fuse: clarify extending writes handling

On Wed, 20 Aug 2025 at 07:20, Darrick J. Wong <djwong@...nel.org> wrote:

> 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?

commit 59bda8ecee2f ("fuse: flush extending writes")

The issue AFAICS is that if writes beyond the range end are not
flushed, then EOF on backing file could be below range end (if pending
writes create a hole), hence copy_file_range() will stop copying at
the start of that hole.

So this patch is incorrect, since not flushing copy_file_range input
file could result in a short copy.

Thanks,
Miklos