Messages in this thread | | | From | Andreas Gruenbacher <> | Subject | Re: [PATCH 1/6] xattr consolidation v2 - generic xattr API | Date | Sun, 19 Sep 2004 12:13:57 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |