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

[Andreas Gruenbacher <agruen@suse.de>]

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.