linux-kernel - Re: [PATCHv2] btrfs: Introduce new BTRFS_IOC_SNAP_DESTROY

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

Message-ID: <20200128173552.GC3929@twin.jikos.cz>
Date:   Tue, 28 Jan 2020 18:35:52 +0100
From:   David Sterba <dsterba@...e.cz>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Marcos Paulo de Souza <marcos.souza.org@...il.com>,
        linux-kernel@...r.kernel.org, dsterba@...e.com,
        josef@...icpanda.com, linux-btrfs@...r.kernel.org,
        Marcos Paulo de Souza <mpdesouza@...e.com>
Subject: Re: [PATCHv2] btrfs: Introduce new BTRFS_IOC_SNAP_DESTROY_V2 ioctl

On Tue, Jan 28, 2020 at 09:31:00AM -0800, Christoph Hellwig wrote:
> On Sun, Jan 26, 2020 at 11:48:17PM -0300, Marcos Paulo de Souza wrote:
> > From: Marcos Paulo de Souza <mpdesouza@...e.com>
> > 
> > This ioctl will be responsible for deleting a subvolume using it's id.
> > This can be used when a system has a file system mounted from a
> > subvolume, rather than the root file system, like below:
> 
> Isn't BTRFS_IOC_SNAP_DESTROY_BY_ID a better name?

I'd prefer to keep it V2 as a more flexible ioctl than just to delete
by id. There are other _V2 ioctls that use matching
btrfs_ioctl_vol_args_v2 structure. In case we want to implement
recursive subvolume deletion we'd have to introduce yet another ioctl
number compared to just a new flag and support both by-name and by-id.
Sounds like a lot of duplication.