linux-kernel - Re: (subset) [PATCH v2 0/4] io_uring/btrfs: remove struct io_uring_cmd

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: <175286378826.415706.5386510015448817454.b4-ty@kernel.dk>
Date: Fri, 18 Jul 2025 12:36:28 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>, 
 David Sterba <dsterba@...e.com>, 
 Caleb Sander Mateos <csander@...estorage.com>
Cc: Mark Harmstone <maharmstone@...com>, linux-btrfs@...r.kernel.org, 
 io-uring@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: (subset) [PATCH v2 0/4] io_uring/btrfs: remove struct
 io_uring_cmd_data


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