Re: Locking rules for fscrypt_operations->set_context()

2016-09-21 Thread Eric Biggers
On Tue, Sep 20, 2016 at 04:30:06PM +0200, Richard Weinberger wrote: > Hi! > > To my understanding ->setxattr() is always being called with i_mutex held. > ->set_context() in ext4 stores the security context using ext4_xattr_set(), > but the fs crypto framework does not lock the inode itself. >

Re: Locking rules for fscrypt_operations->set_context()

2016-09-21 Thread Eric Biggers
On Tue, Sep 20, 2016 at 04:30:06PM +0200, Richard Weinberger wrote: > Hi! > > To my understanding ->setxattr() is always being called with i_mutex held. > ->set_context() in ext4 stores the security context using ext4_xattr_set(), > but the fs crypto framework does not lock the inode itself. >

Locking rules for fscrypt_operations->set_context()

2016-09-20 Thread Richard Weinberger
Hi! To my understanding ->setxattr() is always being called with i_mutex held. ->set_context() in ext4 stores the security context using ext4_xattr_set(), but the fs crypto framework does not lock the inode itself. So, depending on the call path, ext4_xattr_set() is sometimes being called with

Locking rules for fscrypt_operations->set_context()

2016-09-20 Thread Richard Weinberger
Hi! To my understanding ->setxattr() is always being called with i_mutex held. ->set_context() in ext4 stores the security context using ext4_xattr_set(), but the fs crypto framework does not lock the inode itself. So, depending on the call path, ext4_xattr_set() is sometimes being called with