From owner-freebsd-arch@FreeBSD.ORG Tue Jun 23 23:23:34 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37BBC1065674; Tue, 23 Jun 2009 23:23:34 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2689E8FC0C; Tue, 23 Jun 2009 23:23:33 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E71551A3C3A; Tue, 23 Jun 2009 16:05:01 -0700 (PDT) Date: Tue, 23 Jun 2009 16:05:01 -0700 From: Alfred Perlstein To: John Baldwin Message-ID: <20090623230501.GH84786@elvis.mu.org> References: <200906231341.43104.jhb@freebsd.org> <863a9q3c7a.fsf@ds4.des.no> <200906231706.33465.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906231706.33465.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Dag-Erling Sm??rgrav , arch@freebsd.org Subject: Re: [PATCH] SYSV IPC ABI rototill X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 23:23:34 -0000 * John Baldwin [090623 14:07] wrote: > On Tuesday 23 June 2009 4:52:09 pm Dag-Erling Sm??rgrav wrote: > > John Baldwin writes: > > > There have been a several issues with the existing ABI of the SYSV IPC > > > structures over the past several years and it has been on the todo list for > > > at least both 7.0 and 8.0. Rather than putting it off until 9.0 I sat down > > > and worked on it this week. > > > > Have you given any thought to virtualization, i.e. separate namespaces > > for each jail? Will your patch make this any easier or harder to > > implement? > > It likely has zero effect on that. The global variables one would need to > virtualize are unchanged by this. John, would it make sense to check for overflow in ipcperm_new2old and return some error so that callers get back some nasty error so that they don't make a mistake about permissions when an overflow happens? A crash/error sounds better than silent truncating of credential information, but I could be wrong. -Alfred