On Thu, Jul 20, 2017 at 01:41:26AM +0800, weiping zhang wrote: > tmpfs not support O_DIRECT, when user open with O_DIRECT , the errno > -EINVAL return to userspace by open_check_o_direct, but the file has > been created, it's a strange thing. Add a checking for tmpfs that can > avoid creating that file. > > Signed-off-by: weiping zhang <zhangweiping@xxxxxxxxxxxxxxx> > --- > fs/namei.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/fs/namei.c b/fs/namei.c > index ddb6a7c..a2a8cb9 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -3106,6 +3106,10 @@ static int lookup_open(struct nameidata *nd, struct path *path, > if (unlikely(IS_DEADDIR(dir_inode))) > return -ENOENT; > > + if (unlikely(open_flag & (O_CREAT | O_DIRECT) && > + strcmp(dir->d_sb->s_type->name, "tmpfs") == 0)) > + return -EINVAL; Hell, _no_. Kludges of that sort are flat-out wrong - string comparisons on the fs type name, no less... For one thing, tmpfs is not the only such filesystem. Should we turn that into a long list of "forbidden" types, patching it every time somebody comes up with a filesystem that fails O_DIRECT open? Not to mention the modules, or filesystems where that depends upon e.g. mount flags...
