Re: struct file reference at VFS level

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Apr 24, 2016 at 04:40:43AM +0200, Emmanuel Dreyfus wrote:
 > > If something in fuse is causing these cases to share the same open and
 > > thus the same struct file, fuse is broken. Fix fuse first.
 > > 
 > > If that isn't what's happening, the next possible problem is that
 > > puffs/refuse/whatnot is the losing IO_NDELAY flag of VOP_WRITE. If so,
 > > fuse is broken. Fix fuse first.
 > 
 > If you want to implement mandatory locks, the O_NONBLOCK / IO_NDELAY
 > just determines how a failure should occur: by waiting for the lock to
 > be released, or by failing with EAGAIN.
 > 
 > In order to decide whether an I/O will succeed or fail because of a
 > mandatory lock, the filesystem must know if there is a lock on the file,
 > and in the case there is a lock, whether it is held by the caller or
 > not.
 > 
 > As I understand, telling if a lock is held by caller requires a
 > reference to the struct file on which the operation was issued.

Ah, I see -- you were talking about access to the flags of the struct
file, and that isn't necessary. 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.

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?

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.)

-- 
David A. Holland
dholland%netbsd.org@localhost