| Message ID | 20170719174120.GA16327@bogon.didichuxing.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@didichuxing.com> > --- > 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...
On Thu, Jul 20, 2017 at 04:19:31AM +0100, Al Viro wrote: > 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@didichuxing.com> > > --- > > 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... Hi Viro, Thanks your comments, sorry to late reply, as you say, tmpfs is not the only such filesystem, we cann't add long list to prevent create file. I try to find a mount flag to get a fs whether support direct_io directly or indirectly, but I have no result. Do you mean add a new mount flag to indicate a fs support direct_io or not? and then check that flag at may_o_create. Looking forward to hearing from you.
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; + *opened &= ~FILE_CREATED; dentry = d_lookup(dir, &nd->last); for (;;) {
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@didichuxing.com> --- fs/namei.c | 4 ++++ 1 file changed, 4 insertions(+)