David Holland <dholland-t...@netbsd.org> wrote: > Ah, I see -- you were talking about access to the flags of the struct > file, and that isn't necessary.
Yes, sorry for that confusing part. In fact, the file flags are quite useful to spot the problem in a test case and this is why I insisted on them, but indeed they are not the core of the problem. > What you need is the locking > principal, which for some glusterfs reason is supposed to be the open > (potentially shared by many processes) and not the current process. Correct. > Since you said fuse has a way to do that but it doesn't work for our > fuse, I guess the right way forward is to make it work in our fuse. > What's required? Just send an arbitrary ID associated with the open > through puffs to userland? My understanding is that we need to send an opaque reference for struct file (which could just be the struct file pointer itself). > Which vnode operations need this information to make the fuse thing > work fully? (Whether or not glusterfs needs them all is less relevant; > something else will eventually anyway.) Any operation that deals with file content may hit a lock: VOP_READ, VOP_READLINK, VOP_WRITE, etc... Fortunately all of them send a kauth_cred_t, and that structure was designed with the ability to cary extra data: we can attach struct file * without changing the VFS interface, and this could be done based on a mount option. I have still to make sure other operations (which do not access file content) do not need reference to struct file, but I see no reason why they would. PUFFS is another story. Everywhere VFS has a kauth_cred_t, PUFFS has a struct puffs_kcred in the message, but that was not designed to be variable-length, hence adding data here means adding new message versions. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org