On Tue, Apr 28, 2020 at 9:02 AM Christoph Hellwig <hch@xxxxxx> wrote: > 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); > mmm, I thought lo_flags was read-only in LOOP_SET_STATUS(64): __u32 lo_flags; /* ioctl r/o */ but it looks LO_FLAGS_AUTOCLEAR is writable: if ((lo->lo_flags & LO_FLAGS_AUTOCLEAR) != (info->lo_flags & LO_FLAGS_AUTOCLEAR)) lo->lo_flags ^= LO_FLAGS_AUTOCLEAR; and it allows requesting a partition scan. It makes sense to maintain that behavior, but what about LO_FLAGS_DIRECT_IO? I think you're proposing LOOP_SET_STATUS(64) should keep ignoring that like it used to? Thanks, Martijn > 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.