From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 23 01:59:34 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 B91FD16A4CE; Mon, 23 Feb 2004 01:59:34 -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 3EEFD43D1D; Mon, 23 Feb 2004 01:59:34 -0800 (PST) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: by relay1.ntu-kpi.kiev.ua (Postfix, from userid 426) id A03CF17B893; Mon, 23 Feb 2004 11:59:32 +0200 (EET) Received: from comsys.ntu-kpi.kiev.ua (unknown [10.0.1.184]) by relay1.ntu-kpi.kiev.ua (Postfix) with ESMTP id 5F59A17B837; Mon, 23 Feb 2004 11:59:32 +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)i1NC1vbA084184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2004 12:01:57 GMT Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 1AD61322; Mon, 23 Feb 2004 11:59:17 +0200 (EET) Date: Mon, 23 Feb 2004 11:59:17 +0200 From: Andrey Simonenko To: "Brian F. Feldman" Message-ID: <20040223095917.GA5461@pm514-9.comsys.ntu-kpi.kiev.ua> References: <20040216130958.GC304@pm514-9.comsys.ntu-kpi.kiev.ua> <200402161848.i1GImJIg075442@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402161848.i1GImJIg075442@green.homeunix.org> User-Agent: Mutt/1.4.2.1i 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, 23 Feb 2004 09:59:34 -0000 On Mon, Feb 16, 2004 at 01:48:19PM -0500, Brian F. Feldman wrote: > > 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? This is not enough, because I need to synchronize access in VOP_GETPAGES on remote system to vnode (content of a file) on its home system. > > > 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. I looked at sources of lomacfs (initial implementation), nullfs and unionfs in 4.x and 5.x, I have to say that not everything clear for me, especially locking and unlocking in top layer and lower layer. Now I understand that changing v_op is not a right way to do what I want. It seems that stackable VFS is what is needed for my purpose. I created stackable VFS and put it on top of the directory, in which files are expected to be shared via network, if some process opens and then modifies files in this directory, then each VOP_* will be caught by my top VFS layer. I didn't check, but it also seems that mmap'ed files also will work, because of VOP_{CREATE|GET|DESTROY}VOBJECT calls usage. I only loose synchronization if some process opened files before top VFS layer is installed and this process will use original vnode (which is lower vnode for top VFS layer). Since top VFS layer completely hides lower layer (there is no separate mount point), then any process always will call VOP_* for top VFS layer, as I understand lomacfs works in this way. Thanks for your help again.