From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 16 05:10:07 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C77E116A4CE; Mon, 16 Feb 2004 05:10:07 -0800 (PST) Received: from relay1.ntu-kpi.kiev.ua (noc.ntu-kpi.kiev.ua [195.245.194.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6897F43D1D; Mon, 16 Feb 2004 05:10:07 -0800 (PST) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.ntu-kpi.kiev.ua (unknown [10.0.1.184]) by relay1.ntu-kpi.kiev.ua (Postfix) with ESMTP id 8640917BE6C; Mon, 16 Feb 2004 15:10:05 +0200 (EET) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)i1GFCItv044212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Feb 2004 15:12:18 GMT Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id A62E52B3; Mon, 16 Feb 2004 15:09:58 +0200 (EET) Date: Mon, 16 Feb 2004 15:09:58 +0200 From: Andrey Simonenko To: freebsd-hackers@freebsd.org Message-ID: <20040216130958.GC304@pm514-9.comsys.ntu-kpi.kiev.ua> References: <20040213090838.GA221@pm514-9.comsys.ntu-kpi.kiev.ua> <200402140249.i1E2ns8R001417@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402140249.i1E2ns8R001417@green.homeunix.org> User-Agent: Mutt/1.4.1i 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 13:10:08 -0000 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. 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. 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. Thanks for your help again.