Re: [PATCH 1/6] xattr consolidation v2 - generic xattr API

From: Andreas Gruenbacher
Date: Sun Sep 19 2004 - 05:19:24 EST


On Sunday 19 September 2004 01:47, James Morris wrote:
> On Sun, 19 Sep 2004, Andreas Gruenbacher wrote:
> > This currently is only relevant for the security attribute. Selinux
> > always returns the same attribute name so it can't trigger this problem,
> > but other LSMs might do something different.
> >
> > We can add a list_size parameter to xattr_handler->list to get this
> > fixed. We should change the name_len parameter of xattr_handler->list
> > from int to size_t:
>
> Ahh, I thought we had the inode semaphore (never trust documentation).
> Why don't we take that instead in listxattr() ?

Documentation/filesystems/Locking seems to be accurate. Originally we were
taking inode->i_sem for all four xattr operations. It turned out that this
caused lock contention for acls. Selinux increases the frequency of xattr
operations, so always taking i_sem would be even worse now.

> The name_len thing seems kludgy.

The old handler API was fine at the FS level where locking was guaranteed
anyways. At the VFS level we should do better. Passing in the buffer and the
buffer size at the same time gets us rid of the problem without requiring any
locking.

> > I also noticed that your additions to fs/xattr.c use a slightly different
> > coding style than the rest of the file. You might want to change that as
> > well.
>
> I was using Linus-recommended coding style, but it can be changed I guess.

Both styles are being used in VFS. Choose one; I don't mind much.

-- Andreas.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/