Changing v_op for vnode on the fly

[Brian F. Feldman]

Andrey Simonenko <simon at comsys.ntu-kpi.kiev.ua> wrote:
> On Fri, Feb 13, 2004 at 09:49:53PM -0500, Brian F. Feldman wrote:
> > Andrey Simonenko <simon at comsys.ntu-kpi.kiev.ua> wrote:
> > > 
> > > Is it enough to get exclusive lock on vnode, before changing
> > > v_op pointer?  Here is my code:
> > > 
> > > 	vn_lock(cvp->vp, LK_EXCLUSIVE | LK_RETRY, p);
> > > 
> > > 	if (flag > 0)
> > > 		cvp->vp->v_op = catch_vnode_vnodeop_p;	/* My vnodeop_p. */
> > > 	else
> > > 		cvp->vp->v_op = cvp->vnodeop_p;		/* Original v_op. */
> > > 
> > > 	VOP_UNLOCK(cvp->vp, 0, p);
> > > 
> > > I made some tests and see that most of VOP_xxx require lock (shared
> > > or exclusive) on vnode, as well this is documented in the manual pages.
> > 
> > No, you are not allowed to change v_op, ever.  Can you do what you're trying 
> > to do in the MAC framework?  It seems like that is what you want to be 
> > doing!  The other possibility is using something like umapfs/lomacfs/
> > unionfs.
> > 
> 
> First of all thanks for your answer.
> 
> I need to control activities on vnode not for protecting it from
> processes.  I try to find a way to synchronize shared access (read,
> write, mmap'ed file) to existent vnode (vnode which is currently is
> used on home host by local processes) from process on remote hosts.
> 
> This situation is like NFS, but NFS (or similar systems) has own
> vnode operation vector for their vnodes and can synchronize access
> in their VOPs.  Since in my situation vnodes can have different vnode
> operation vectors (i.e. files can belong to different VFS) I can't
> set v_op for vnode when vnode is created (getnewvnode()).
> 
> Having read documentation and analyzed sources, I think that MAC can't
> help.  MAC allows to synchronize access in read() and write() syscalls,
> but access to VOP_GETPAGES, which is called in vm_fault() for example,
> can't be synchronized using MAC framework.

Well, there is the ability to prevent the mmap(2) in the first place using
mac_check_vnode_mmap().  Is that close to sufficient for those purposes?

> File systems umapfs, lomacfs, unionfs also don't help.  May be it is
> possible to do something with stackable VFS, but I haven't find
> a solution with stackable VFS yet.

Try to look closer at them; I think it's possible to do a lot of what you 
want because the initial LOMAC implementation for FreeBSD, before the MAC 
framework existed, did just such a thing.

> What can be broken when v_op is changed during holding exclusive
> lock on vnode?  Does a moment when v_op is changed can cause any problems?
> Currently I found that nullfs and uniofs will not work if v_op is changed,
> because they compare v_op with their vnodeop_p.

The thing that you're missing if you just modify v_op is synchronization for 
each vnode's v_op field for VOP_*() calls.  In short, there is no 
synchronization for that field at all (if you ignore the special-cased Giant).
In some cases, this matters -- in others, it doesn't -- so if you don't 
actually add any new fields to the vnode then changing the v_op might work 
reasonably well for some filesystems (the ones that don't actually examine 
the value of v_op).

Happy to help,

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\