Hmm. This patch looks very sane, but it's been that way - ignoring the 'flags' value - since 2009. Does anybody actually _use_ the flags field? Judging by commit 431547b3c453 (that introduced the thing), it looks like a plain mistake, and the previous "flags" was replaced by a "0" in the call when it added the "hander->flags" argument at the end. But the fact that it's been two years, and nobody noticed, makes me go "hmm.." Christoph added to participants, since he's the cause of that change. On Wed, Apr 20, 2011 at 11:30 AM, Jan Kara <jack@xxxxxxx> wrote: > For some reason generic_setxattr() did not pass flags (XATTR_CREATE, > XATTR_REPLACE) to the filesystem specific helper. This caused that > setxattr(2) syscall just ignored these flags. > > Fix the bug by passing flags correctly. > > Signed-off-by: Jan Kara <jack@xxxxxxx> > --- > fs/xattr.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Who's handling VFS changes when Al is away? Andrew? I guess it's mostly me for at least the path handling, but for something like this I'd like Christoph to take a look too. Even if it _looks_ like a really obvious fix. > > diff --git a/fs/xattr.c b/fs/xattr.c > index a19acdb..f1ef949 100644 > --- a/fs/xattr.c > +++ b/fs/xattr.c > @@ -666,7 +666,7 @@ generic_setxattr(struct dentry *dentry, const char *name, const void *value, siz > handler = xattr_resolve_name(dentry->d_sb->s_xattr, &name); > if (!handler) > return -EOPNOTSUPP; > - return handler->set(dentry, name, value, size, 0, handler->flags); > + return handler->set(dentry, name, value, size, flags, handler->flags); > } > > /* > -- > 1.7.1 > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
