Tejun Heo <[EMAIL PROTECTED]> writes:

> Hello,
>
> Eric W. Biederman wrote:
>> Ugh.  I need to step back and carefully define what I'm seeing but it
>> looks like the current sysfs locking is wrong.
>> 
>> I'm starting to find little inconsistencies all over the place
>> such as:
>> 
>> Which lock actually protects sd->s_children?
>> - It isn't sysfs_mutex.  (see sysfs_lookup)
>> - It isn't inode->i_mutex (we only get it if we happen to have the inode
>>   in core)
>
> Yeah, I missed two places while converting to sysfs_mutex.
> sysfs_lookup() and rename().  I'm about to post patch to fix it.

Yes.  Make certain to get the name change under sysfs_mutex
while you are at it.

What do we use inode->i_mutex for?  I think we might be able
to kill that.

I'm starting to wonder if we can completely remove sysfs
from grabbing inode->i_mutex.

>> At first glance sysfs_assoc_lock looks just as bad.
>
> I think sysfs_assoc_lock is okay.  It's tricky tho.  Why do you think
> it's bad?

I'm still looking.  I just have a weird vibe so far.  sysfs_get_dentry
is really nasty with respect to locking.

Eric
_______________________________________________
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/mailman/listinfo/containers

_______________________________________________
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel

Reply via email to