Re: struct file reference at VFS level

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

David Holland <dholland-tech%netbsd.org@localhost> 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
manu%netbsd.org@localhost