Re: [PATCH v3 0/9] Add a new LOOP_SET_FD_AND_STATUS ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 27, 2020 at 10:34:35PM +0200, Martijn Coenen wrote:
> > Also maybe an explicit direct I/O flag, and maybe
> > enough padding with a future proof flags bitmap that we can easily
> > extend it for new features if they pop up?
> 
> Sounds good. I'm thinking these flags should be separate from
> LO_FLAGS_; even though there is already a LO_FLAGS_DIRECT_IO, as far
> as I can tell it can only be used to tell whether it's enabled, not to
> actually enable it. And it would just get confusing if we add more
> flags later. Maybe something like LO_FD_STATUS_FLAG_DIRECT_IO ?

I think reusing LO_FLAGS_DIRECT_IO makes sense to me - we have 32
flags in the existing flags field (at least for loop_info64), so
we might as well use the field and the flags.  Then we need flags
validation in that we don't accept new flags through the old
interface, and the new one validates that no unknown flags are passed.

E.g. in the LOOP_SET_STATUS / LOOP_SET_STATUS64 handler do:

	lo->lo_flags &= ~(LO_LEGACY_FLAGS);

and then in the main function reject anything not known.

And then maybe add something like 64 bytes of padding to the end of the
new structure, so that we can use flags to expand to it.



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux