fs/btrfs/ioctl.c | 41 +++++++++++++++++++++++++----------- include/linux/io_uring/cmd.h | 11 ++-------- io_uring/uring_cmd.c | 18 ++++++---------- io_uring/uring_cmd.h | 1 - 4 files changed, 37 insertions(+), 34 deletions(-)
btrfs's ->uring_cmd() implementations are the only ones using io_uring_cmd_data to store data that lasts for the lifetime of the uring_cmd. But all uring_cmds have to pay the memory and CPU cost of initializing this field and freeing the pointer if necessary when the uring_cmd ends. There is already a pdu field in struct io_uring_cmd that ->uring_cmd() implementations can use for storage. The only benefit of op_data seems to be that io_uring initializes it, so ->uring_cmd() can read it to tell if there was a previous call to ->uring_cmd(). Introduce a flag IORING_URING_CMD_REISSUE that ->uring_cmd() implementations can use to tell if this is the first call to ->uring_cmd() or a reissue of the uring_cmd. Switch btrfs to use the pdu storage for its btrfs_uring_encoded_data. If IORING_URING_CMD_REISSUE is unset, allocate a new btrfs_uring_encoded_data. If it's set, use the existing one in op_data. Free the btrfs_uring_encoded_data in the btrfs layer instead of relying on io_uring to free op_data. Finally, remove io_uring_cmd_data since it's now unused. Caleb Sander Mateos (4): btrfs/ioctl: don't skip accounting in early ENOTTY return io_uring/cmd: introduce IORING_URING_CMD_REISSUE flag btrfs/ioctl: store btrfs_uring_encoded_data in io_btrfs_cmd io_uring/cmd: remove struct io_uring_cmd_data fs/btrfs/ioctl.c | 41 +++++++++++++++++++++++++----------- include/linux/io_uring/cmd.h | 11 ++-------- io_uring/uring_cmd.c | 18 ++++++---------- io_uring/uring_cmd.h | 1 - 4 files changed, 37 insertions(+), 34 deletions(-) v2: - Don't branch twice on -EAGAIN in io_uring_cmd() (Jens) - Rebase on for-6.17/io_uring -- 2.45.2
Hi Jens, Are you satisfied with the updated version of this series? Let me know if there's anything else you'd like to see. Thanks, Caleb On Tue, Jul 8, 2025 at 4:22 PM Caleb Sander Mateos <csander@purestorage.com> wrote: > > btrfs's ->uring_cmd() implementations are the only ones using io_uring_cmd_data > to store data that lasts for the lifetime of the uring_cmd. But all uring_cmds > have to pay the memory and CPU cost of initializing this field and freeing the > pointer if necessary when the uring_cmd ends. There is already a pdu field in > struct io_uring_cmd that ->uring_cmd() implementations can use for storage. The > only benefit of op_data seems to be that io_uring initializes it, so > ->uring_cmd() can read it to tell if there was a previous call to ->uring_cmd(). > > Introduce a flag IORING_URING_CMD_REISSUE that ->uring_cmd() implementations can > use to tell if this is the first call to ->uring_cmd() or a reissue of the > uring_cmd. Switch btrfs to use the pdu storage for its btrfs_uring_encoded_data. > If IORING_URING_CMD_REISSUE is unset, allocate a new btrfs_uring_encoded_data. > If it's set, use the existing one in op_data. Free the btrfs_uring_encoded_data > in the btrfs layer instead of relying on io_uring to free op_data. Finally, > remove io_uring_cmd_data since it's now unused. > > Caleb Sander Mateos (4): > btrfs/ioctl: don't skip accounting in early ENOTTY return > io_uring/cmd: introduce IORING_URING_CMD_REISSUE flag > btrfs/ioctl: store btrfs_uring_encoded_data in io_btrfs_cmd > io_uring/cmd: remove struct io_uring_cmd_data > > fs/btrfs/ioctl.c | 41 +++++++++++++++++++++++++----------- > include/linux/io_uring/cmd.h | 11 ++-------- > io_uring/uring_cmd.c | 18 ++++++---------- > io_uring/uring_cmd.h | 1 - > 4 files changed, 37 insertions(+), 34 deletions(-) > > v2: > - Don't branch twice on -EAGAIN in io_uring_cmd() (Jens) > - Rebase on for-6.17/io_uring > > -- > 2.45.2 >
On 7/17/25 2:04 PM, Caleb Sander Mateos wrote: > Hi Jens, > Are you satisfied with the updated version of this series? Let me know > if there's anything else you'd like to see. I'm fine with it, was hoping some of the CC'ed btrfs folks would ack or review the btrfs bits. OOO until late sunday, if I hear nothing else by then, I'll just tentatively stage it in a separate branch for 6.17. What test cases did you run? -- Jens Axboe
On Fri, Jul 18, 2025 at 10:58:07AM -0600, Jens Axboe wrote: > On 7/17/25 2:04 PM, Caleb Sander Mateos wrote: > > Hi Jens, > > Are you satisfied with the updated version of this series? Let me know > > if there's anything else you'd like to see. > > I'm fine with it, was hoping some of the CC'ed btrfs folks would ack or > review the btrfs bits. OOO until late sunday, if I hear nothing else by > then, I'll just tentatively stage it in a separate branch for 6.17. I've taken the first patch to btrfs' for-next but if you want to add it to your queue then git will deal with that too. For the btrfs changes Acked-by: David Sterba <dsterba@suse.com>
On 7/18/25 11:26 AM, David Sterba wrote: > On Fri, Jul 18, 2025 at 10:58:07AM -0600, Jens Axboe wrote: >> On 7/17/25 2:04 PM, Caleb Sander Mateos wrote: >>> Hi Jens, >>> Are you satisfied with the updated version of this series? Let me know >>> if there's anything else you'd like to see. >> >> I'm fine with it, was hoping some of the CC'ed btrfs folks would ack or >> review the btrfs bits. OOO until late sunday, if I hear nothing else by >> then, I'll just tentatively stage it in a separate branch for 6.17. > > I've taken the first patch to btrfs' for-next but if you want to add it > to your queue then git will deal with that too. For the btrfs changes > > Acked-by: David Sterba <dsterba@suse.com> Thanks! I guess that works fine, it can go in separately. I've queued up the rest. -- Jens Axboe
On Tue, 08 Jul 2025 14:22:08 -0600, Caleb Sander Mateos wrote:
> btrfs's ->uring_cmd() implementations are the only ones using io_uring_cmd_data
> to store data that lasts for the lifetime of the uring_cmd. But all uring_cmds
> have to pay the memory and CPU cost of initializing this field and freeing the
> pointer if necessary when the uring_cmd ends. There is already a pdu field in
> struct io_uring_cmd that ->uring_cmd() implementations can use for storage. The
> only benefit of op_data seems to be that io_uring initializes it, so
> ->uring_cmd() can read it to tell if there was a previous call to ->uring_cmd().
>
> [...]
Applied, thanks!
[2/4] io_uring/cmd: introduce IORING_URING_CMD_REISSUE flag
commit: 733c43f1df34f9185b945e6f12ac00c8556c6dfe
[3/4] btrfs/ioctl: store btrfs_uring_encoded_data in io_btrfs_cmd
commit: 9aad72b4e3f0233e747bb6b1ec05ea71365f4246
[4/4] io_uring/cmd: remove struct io_uring_cmd_data
commit: 2e6dbb25ea15844c8b617260d635731c37c85ac9
Best regards,
--
Jens Axboe
© 2016 - 2025 Red Hat, Inc.