From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 10:48:24 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 41A2D16A4CE; Mon, 16 Feb 2004 10:48:24 -0800 (PST) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.10/8.12.9) with ESMTP id i1GImKpe075445; Mon, 16 Feb 2004 13:48:20 -0500 (EST) (envelope-from green@green.homeunix.org) Received: from localhost (green@localhost)i1GImJIg075442; Mon, 16 Feb 2004 13:48:20 -0500 (EST) Message-Id: <200402161848.i1GImJIg075442@green.homeunix.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Andrey Simonenko In-Reply-To: Message from Andrey Simonenko <20040216130958.GC304@pm514-9.comsys.ntu-kpi.kiev.ua> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Feb 2004 13:48:19 -0500 Sender: green@green.homeunix.org cc: freebsd-hackers@freebsd.org Subject: Re: Changing v_op for vnode on the fly X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2004 18:48:24 -0000 Andrey Simonenko wrote: > On Fri, Feb 13, 2004 at 09:49:53PM -0500, Brian F. Feldman wrote: > > Andrey Simonenko 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@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\