tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: struct file at VFS level (round 1.5)



On Tue, May 03, 2016 at 08:20:02AM +0000, Emmanuel Dreyfus wrote:
> On Tue, May 03, 2016 at 09:30:22AM +0200, Christoph Badura wrote:
> >  - for the write case
> >    off = current_file_offset
> >    VOP_ADVLOCK(F_WRLCK, off, size_of_write)
> >    VOP_WRITE(...)
> >    VOP_ADVLOCK(F_UNLCK, off, size_of_write)

BTW, because it hasn't been mentioned explicitly in this thread and isn't
mention in the Linux document that you cited:  advisory locks and
mandatory locking interact.  If you lock a region with an fcntl() advisory
lock, that region is locked for the mandatory checks too.  The System V
Interface Definition is quite clear about that.

> There is still the problem to set the appropriate lock owner
> (which is struct file * or struct proc * depending of the case).
> vn_write() has struct fiile available. vn_rdwr() does not have
> it, 

Didn't I just explain to you that a struct file is never an owner for
these locks?  Didn't others explain that to you too?

AFAICT the only relevant cases are whether a file has been opend for
writing and whether it has been opened in non-blocking mode. 

For the first case that means a process can't get a write lock if the file
isn't opened for writing.  But that is already handled without further
information because you already need to check every write(2).  For locking
this is done in the same way at the FS-independent syscall level.
This doesn't need any interaction with the VFS as it is a local policy
descision.

The second case is a simple matter of passing F_SETLK or F_SETLKW to
VOP_ADVLOCK from the system call level as appropriate.

The case you describe in
http://mail-index.netbsd.org/tech-kern/2016/04/22/msg020467.html
is completely handled at the syscall level by what I have described to you.

--chris


Home | Main Index | Thread Index | Old Index