From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 03:48:38 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5121065675 for ; Wed, 18 Jun 2008 03:48:38 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9B93E8FC1F for ; Wed, 18 Jun 2008 03:48:38 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from glorfindel.gritton.org (c-76-27-80-223.hsd1.ut.comcast.net [76.27.80.223]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5I3mbdF073113 for ; Tue, 17 Jun 2008 21:48:37 -0600 (MDT) Message-ID: <48588595.7020709@gritton.org> Date: Tue, 17 Jun 2008 21:48:37 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean Subject: V_* meta-symbols and locking X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2008 03:48:39 -0000 Like everything I have to say about the V_* issue, perhaps this doesn't apply to the vnet stuff. But to the two symbols I currently care about, hostname and rootvnode, locking is a problem. Current kernel code plays fast and loose with both these symbols. Check out getcredhostname for example: void getcredhostname(struct ucred *cred, char *buf, size_t size) { struct prison *pr; pr = cred->cr_prison; if (pr != &prison0) { mtx_lock(&pr->pr_mtx); strlcpy(buf, (pr->pr_flags & PR_NOHOST) ? hostname : pr->pr_host, size); mtx_unlock(&pr->pr_mtx); } else strlcpy(buf, hostname, size); } In the prison case, it nicely locks the prison record. But for the global hostname, it just copies it. The hostname sysctl is no better about setting it. And rootvnode is referred to all over the place without any sort of lock - pretty safe since it's not expected to change (though it theoretically can). This same no-locking assumption seems to be going on with V_hostname. But now this macro applies not only to the "real" hostname but to the "virtual" one as well - no locking the vimage record. As I try to add a similar macro to my new jail framework, I find I can't. Instead of a mere variable redirection, I need to lock-copy-unlock much like getcredhostname does. Luckily, much hostname access is already jail-aware. But anything using the "real" hostname should have the same locking on prison0. Perhaps not wholly necessary since it's just a string that we know will always have a null byte at the end of the buffer, but still good form and unknown prevention. And in the case of actually virtual hostnames, it's essential since they'll be changing from fixed arrays in struct prison into pointers that may be freed. Rootvnode is a stickier problem. There's much more code that refers to it, and it's a more essential part of the system. I don't relish digging in everywhere and changing the whole rootvnode paradigm with locking. So instead my solution is to make the jail "path" parameter (and thus root vnode) set-once. So as long as the V_rootvnode is taken from a context that will remain for the duration of its use (curthread is a good bet), it will be safe to access it without locks. In particular, the real rootvnode that lives at prison0 isn't going anywhere. So in summary: I won't use V_hostname (or G_hostname), opting for explicit locking. I will V_rootvnode (and perhaps G_rootvnode). All the other network-related V_stuff may deserve a look, but it out of my purview. - Jamie