From owner-p4-projects@FreeBSD.ORG Wed Sep 27 13:27:38 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 1A05D16A47B; Wed, 27 Sep 2006 13:27:38 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B847F16A40F; Wed, 27 Sep 2006 13:27:37 +0000 (UTC) (envelope-from saper@SYSTEM.PL) Received: from mail01.ish.de (pip249.ish.de [80.69.98.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id E683A43D46; Wed, 27 Sep 2006 13:27:36 +0000 (GMT) (envelope-from saper@SYSTEM.PL) Received: from [80.69.97.9] (HELO saperski.saper.info) by mail-fe-02.mail01.ish.de (CommuniGate Pro SMTP 5.0.6) with ESMTPS id 67985462; Wed, 27 Sep 2006 15:27:34 +0200 Received: from [127.0.0.1] (saperski.saper.info [127.0.0.1]) by saperski.saper.info (8.13.8/8.13.8) with ESMTP id k8RDRHdt013274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Sep 2006 15:27:32 +0200 (CEST) (envelope-from saper@SYSTEM.PL) Message-ID: <451A7C35.8050209@SYSTEM.PL> Date: Wed, 27 Sep 2006 15:27:17 +0200 From: Marcin Cieslak User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.7) Gecko/20060926 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Alexander Leidinger , Perforce Change Reviews , saper@SYSTEM.PL References: <200609091856.k89Iu9lN090213@repoman.freebsd.org> <20060928083623.GA1297@FreeBSD.czest.pl> In-Reply-To: <20060928083623.GA1297@FreeBSD.czest.pl> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit Cc: Subject: Re: PERFORCE change 105906 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 13:27:38 -0000 Wojciech A. Koszek wrote: What I basically do is: Try to copy safely whatever caller provided us with: >> + if (bsd_args.level == SOL_SOCKET && name == LOCAL_PEERCRED) { >> + if ((error = copyin(PTRIN(linux_args.optval), >> + &linux_ucred, sizeof(linux_ucred)))) >> + return (error); >> + if ((error = copyin(PTRIN(linux_args.optlen), >> + &optlen, sizeof(optlen)))) >> + return (error); >> + if (optlen < sizeof(linux_ucred)) >> + return (EFAULT); >> + xuclen = sizeof(xuc); I just really need to copy the result into different structure (unfortunately I think I can't use Linux structure provided by the caller). >> + /* XXX get PID */ >> + linux_ucred.pid = 0; >> + linux_ucred.uid = xuc.cr_uid; >> + linux_ucred.gid = xuc.cr_gid; >> + if ((error = copyout(&linux_ucred, >> + PTRIN(linux_args.optval), sizeof(linux_ucred)))) >> + return (error); >> + return (rc); > I'm not sure if this patch is correct. I looked briefly over Marcin's > report, and the code path responsible for handling translation between what > Linux relies on and what FreeBSD requires. We tend to push the whole job in > sogetopt() function, which in turn deploys uipc_ctloutput() function. With > this mechanism, I belive it is possible to handle LOCAL_PEERCRED without a > problem. The only exception is that the SOL_SOCKET has to be mapped to other > value, like 0. This is what we actually do in getpeereid() case: I don't I know if I understand this correctly; I will try to explain why I did it this way - the most important reason being my limited knowledge of BSD kernel inner workings (I only studied Steven's TCP/IP vol. 2 for that purpose long time ago). I faced following design choice: 1) Just wrap FreeBSD call with minimal effort (I only duplicate functionality of sooptcopyin(), sooptcopyout() in my code). Not a nice way, however such approach work for most of the cases in the linuxolator. 2) Provide copy of kern_getsockopt(), sogetopt() etc. just to provide own version of uipc_ctloutput() fragment to write the result down to the Linux structure. This requires some care about lock and freeing memory structures. Also if somebody for some reason restructures FreeBSD networking code there, Linux emulation will be probably left aside - I've seen already one case where Linux emulation mmap() was not up to date with FreeBSD mmap() advances. 3) Provide some other way to plug another return structure for uipc_ctloutput(). Probably the right way will be something between 1) and 2) - decide how deep Linux sockopt functions replace sogetopt() and go immediately to the level below in the respective networking code. But I think I have not enough experience to decide on that. It may happen that implementing delivery of the process ID of the other side of the socket - feature not available AFAIK in the FreeBSD right now - will impose on us much deeper dive into internal socket structures. -- << Marcin Cieslak // saper@system.pl >>