<snip> > > I'm not sure how the deadlock issues can be 'solved.' The fuse people > have repeatedly stated that until mount(8) (not even mount (2)) is > finished it is illegal to call call getxattr() and they have every right > to deadlock. They will not budge on this position. > > The only possibility I can think of is to extend fuse such that the > support of xattrs is known during mount(2). No idea what that would > look like. > > I believe that my autodetection patch is dead in the water with fuse as > it stands today.... > > -Eric So where is this dead locking occuring? The only thing kernel side that I can think might deadlock is mount will probably lock the new super block for writing (although it shouldn't be available yet so maybe not) and when we call vfs_getxattr on the mount point it might need to grab a lock on the sb for something. I don't think this is the case since I looked through the code from vfs_getxattr through the fuse getxattr handler and I don't see any locking in there for the SB. I'm more inclined to believe that it is the userspace code for fuse or the interface they use to send the requests to user space. Actually the latter sounds more reasonable since fuse_send_request places the request in a queue. So if we are waiting on mount to finish before we send the getxattr request but mount depends on the getxattr request we can have a problem. Maybe the mount request can be modified to make a nested getxattr call on the file system to find out of it is supported and if it is add something to indicate xattr support? Dave -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
