On Fri, Aug 09, 2019 at 12:18:12PM -0700, Eric Biggers wrote:
> On Fri, Aug 09, 2019 at 02:18:31PM -0400, Theodore Ts'o wrote:
> > The new ioctl EXT4_IOC_GETSTATE returns some of the dynamic state of
> > an ext4 inode for debugging purposes.
> >
> > Signed-off-by: Theodore Ts'o <tytso@xxxxxxx>
> > ---
> > fs/ext4/ext4.h | 11 +++++++++++
> > fs/ext4/ioctl.c | 17 +++++++++++++++++
> > 2 files changed, 28 insertions(+)
> >
> > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> > index f6c305b43ffa..58b7a0905186 100644
> > --- a/fs/ext4/ext4.h
> > +++ b/fs/ext4/ext4.h
> > @@ -651,6 +651,7 @@ enum {
> > #define EXT4_IOC_GET_ENCRYPTION_POLICY FS_IOC_GET_ENCRYPTION_POLICY
> > /* ioctl codes 19--2F are reserved for fscrypt */
> > #define EXT4_IOC_CLEAR_ES_CACHE _IO('f', 30)
> > +#define EXT4_IOC_GETSTATE _IOW('f', 30, __u32)
>
> 30 == 0x1e overlaps with the range claimed to be reserved for fscrypt.
>
> Also, these two new ioctls are both number 30, which means they can't be
> controlled separately by SELinux, which only looks at the number.
Yeah, that was my screw up. The range reservation for fscrypt was
intended to be in decimal starting with 19 decimal
(FSIOC_SET_ENCRYPTION_POLICY), and I believe with the new key
management we were up to 26? So If I reserve up to 39, that should be
more than enough, do you agree?
I'll then make EXT4_IOC_CLEAR_ES_CACHE 40 and EXT4_IOC_GETSTATE 41.
If we're in agreement, then I'll add an update to
Documentation/ioctl/ioctl-number.rst, which is badly out of date with
respect to the ioctl's used in ext2 and ext4 (and of course ext3 has
since been removed from the kernel tree).
- Ted
