Message ID | 6c87faf8a6ff6172019faed9988adb9fb99689b4.1664216021.git.boris@bur.io (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | btrfs: send: gate SEND_A_MAX and SEND_C_MAX V3 | expand |
On Mon, Sep 26, 2022 at 11:15:22AM -0700, Boris Burkov wrote: > We haven't finalized send stream v3 yet, so gate setting the max command > values behind CONFIG_BTRFS_DEBUG. > > In my testing, and judging from the code, this is a cosmetic change; > verity send commands are still produced (and processed by a compatible > btrfs-progs), even with CONFIG_BTRFS_DEBUG=n set. There must be some misunderstanding and what you implemented is not what I had in mind. The debug protection should have been for BTRFS_SEND_STREAM_VERSION so we have v3 available for debug builds and not otherwise. The version support is not determined by the command definitions but by the BTRFS_SEND_STREAM_VERSION macro exported to sysfs.
On Tue, Sep 27, 2022 at 02:24:12PM +0200, David Sterba wrote: > On Mon, Sep 26, 2022 at 11:15:22AM -0700, Boris Burkov wrote: > > We haven't finalized send stream v3 yet, so gate setting the max command > > values behind CONFIG_BTRFS_DEBUG. > > > > In my testing, and judging from the code, this is a cosmetic change; > > verity send commands are still produced (and processed by a compatible > > btrfs-progs), even with CONFIG_BTRFS_DEBUG=n set. > > There must be some misunderstanding and what you implemented is not what > I had in mind. The debug protection should have been for > BTRFS_SEND_STREAM_VERSION so we have v3 available for debug builds and > not otherwise. The version support is not determined by the command > definitions but by the BTRFS_SEND_STREAM_VERSION macro exported to > sysfs. This makes way more sense, thanks! Working on fixing it. I will also block sending verity based on the proto being >= 3. Sorry for misunderstanding you in the first place.
diff --git a/fs/btrfs/send.h b/fs/btrfs/send.h index 0a4537775e0c..23661b37ea64 100644 --- a/fs/btrfs/send.h +++ b/fs/btrfs/send.h @@ -94,9 +94,13 @@ enum btrfs_send_cmd { /* Version 3 */ BTRFS_SEND_C_ENABLE_VERITY = 26, +#ifndef CONFIG_BTRFS_DEBUG + BTRFS_SEND_C_MAX = 25, +#else BTRFS_SEND_C_MAX_V3 = 26, /* End */ BTRFS_SEND_C_MAX = 26, +#endif }; /* attributes in send stream */ @@ -168,9 +172,14 @@ enum { BTRFS_SEND_A_VERITY_BLOCK_SIZE = 33, BTRFS_SEND_A_VERITY_SALT_DATA = 34, BTRFS_SEND_A_VERITY_SIG_DATA = 35, + +#ifndef CONFIG_BTRFS_DEBUG + __BTRFS_SEND_A_MAX = 31, +#else BTRFS_SEND_A_MAX_V3 = 35, __BTRFS_SEND_A_MAX = 35, +#endif }; long btrfs_ioctl_send(struct inode *inode, struct btrfs_ioctl_send_args *arg);
We haven't finalized send stream v3 yet, so gate setting the max command values behind CONFIG_BTRFS_DEBUG. In my testing, and judging from the code, this is a cosmetic change; verity send commands are still produced (and processed by a compatible btrfs-progs), even with CONFIG_BTRFS_DEBUG=n set. Signed-off-by: Boris Burkov <boris@bur.io> --- fs/btrfs/send.h | 9 +++++++++ 1 file changed, 9 insertions(+)