All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	 linux-fsdevel@vger.kernel.org,
	Bernd Schubert <bschubert@ddn.com>,
	 Amir Goldstein <amir73il@gmail.com>,
	Chunsheng Luo <luochunsheng@ustc.edu>
Subject: Re: [PATCH v2 3/3] fuse: add COPY_FILE_RANGE_64 that allows large copies
Date: Wed, 13 Aug 2025 21:21:45 +0200	[thread overview]
Message-ID: <lhuwm776n92.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAJnrk1bfoumJHwc5p-WASXYxWG8tzz91LfzpiEkPTSOoTDK1ig@mail.gmail.com> (Joanne Koong's message of "Wed, 13 Aug 2025 10:03:17 -0700")

* Joanne Koong:

> On Wed, Aug 13, 2025 at 8:24 AM Miklos Szeredi <mszeredi@redhat.com> wrote:
>>
>> The FUSE protocol uses struct fuse_write_out to convey the return value of
>> copy_file_range, which is restricted to uint32_t.  But the COPY_FILE_RANGE
>> interface supports a 64-bit size copies and there's no reason why copies
>> should be limited to 32-bit.
>>
>> Introduce a new op COPY_FILE_RANGE_64, which is identical, except the
>> number of bytes copied is returned in a 64-bit value.
>>
>> If the fuse server does not support COPY_FILE_RANGE_64, fall back to
>> COPY_FILE_RANGE.
>
> Is it unacceptable to add a union in struct fuse_write_out that
> accepts a uint64_t bytes_copied?
> struct fuse_write_out {
>     union {
>         struct {
>             uint32_t size;
>             uint32_t padding;
>         };
>         uint64_t bytes_copied;
>     };
> };
>
> Maybe a little ugly but that seems backwards-compatible to me and
> would prevent needing a new FUSE_COPY_FILE_RANGE64.

Even with a capability flag, it encourages the presence of bugs that
manifest only on big-endian systems.

Thanks,
Florian


  parent reply	other threads:[~2025-08-13 19:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-13 15:20 [PATCH v2 0/3] fuse copy_file_range() fixes Miklos Szeredi
2025-08-13 15:20 ` [PATCH v2 1/3] fuse: check if copy_file_range() returns larger than requested size Miklos Szeredi
2025-08-13 15:20 ` [PATCH v2 2/3] fuse: prevent overflow in copy_file_range return value Miklos Szeredi
2025-08-13 15:20 ` [PATCH v2 3/3] fuse: add COPY_FILE_RANGE_64 that allows large copies Miklos Szeredi
2025-08-13 17:03   ` Joanne Koong
2025-08-13 17:18     ` Miklos Szeredi
2025-08-13 19:21     ` Florian Weimer [this message]
2025-08-13 20:35       ` Joanne Koong
2025-08-13 21:23         ` Florian Weimer
2025-08-14 17:04     ` Darrick J. Wong
2025-08-14 17:53       ` Joanne Koong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=lhuwm776n92.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=bschubert@ddn.com \
    --cc=joannelkoong@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=luochunsheng@ustc.edu \
    --cc=mszeredi@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.