On Mon, Oct 15, 2018 at 3:47 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Mon, Oct 15, 2018 at 09:04:13AM +0300, Amir Goldstein wrote: > > I supposed you figured out the reason already. > > No, I hadn't. > > > It makes it appearance in patch 16/25 as RFR_VFS_FLAGS. > > All those "advisory" flags, we want to pass them in to filesystem as FYI, > > but we don't want to explicitly add support for e.g. RFR_CAN_SHORTEN > > to every filesystem, when vfs has already taken care of the advice. > > I don't think this model makes sense. If they really are purely > handled in the VFS we can mask them before passing them to the file > system, if not we need to check them, or the they are avisory and > we can have a simple #define instead of the helper. > > RFR_TO_SRC_EOF is checked in generic_remap_file_range_prep, > so the file system should know about it Also looking at it again now > it seems entirely superflous - we can just pass down then len == we > use in higher level code instead of having a flag and will side step > the issue here. > > RFR_CAN_SHORTEN is advisory as no one has to shorten, but that can > easily be solved by including it everywhere. > > RFR_SHORT_DEDUPE is as far as I can tell entirely superflous to > start with, as RFR_CAN_SHORTEN can be used instead. > > So something like this in fs.h: > > #define REMAP_FILE_ADVISORY_FLAGS REMAP_FILE_CAN_SHORTEN > > And then in the file system: > > if (flags & ~REMAP_FILE_ADVISORY_FLAGS) > -EINVAL; > > or > > if (flags & ~(REMAP_FILE_ADVISORY_FLAGS | REMAP_FILE_DEDUP)) > -EINVAL; > > should be all that is needed. Yeh, I suppose that makes sense. Thanks, Amir.
