From owner-freebsd-virtualization@FreeBSD.ORG Sun Jun 14 17:02:10 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C301BC9A for ; Sun, 14 Jun 2015 17:02:10 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9180ED8C for ; Sun, 14 Jun 2015 17:02:10 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: by pdjn11 with SMTP id n11so55952092pdj.0 for ; Sun, 14 Jun 2015 10:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=QH0dfWKCdQZBoVjYPav/SNK/1Y08qwxduC5ZsirL6VE=; b=SfglR3dRf01W7NQgCadOsdLc5RxmOpK8Pt4P55rg0VgnZQv3Jxk8oFpjudW/ER0EN+ v386//DMho7hrFoV8bsfFczDReOeo7ZeO6GC3nFT4l94ZFNqDuZHJP3+oBjVaa2s50WK kT5E0X7wkgQM1flyt4ux+YBmbEuWdkkf4Fau+NV6p/jGEpTRvjjQcdoBUEdkO22eRThl VEOY7skSCmN3a7AFY1tOUT85cr8Flt6pGY2n/9fhscuA/K6vfCqChL2c+Oqxsm26Cefy anZQiZF4kReNz8aztHYBa9VVD9q/g7FisCGYyh0wmMVfqIIrM1chJ76S/FLLpMKacOr/ 1t9g== X-Received: by 10.68.192.98 with SMTP id hf2mr40238779pbc.142.1434301330005; Sun, 14 Jun 2015 10:02:10 -0700 (PDT) Received: from [192.168.1.95] (108-228-13-158.lightspeed.sntcca.sbcglobal.net. [108.228.13.158]) by mx.google.com with ESMTPSA id c1sm9662534pdc.45.2015.06.14.10.02.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jun 2015 10:02:08 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: "freebsd-virtualization@freebsd.org" X-Mailer: iPhone Mail (11D257) From: Neel Natu Subject: Re: How to bind a thread to a CPU? Date: Sun, 14 Jun 2015 10:02:03 -0700 To: Stefan Andritoiu X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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: Sun, 14 Jun 2015 17:02:10 -0000 Hi Stefan, > On Jun 13, 2015, at 12:12 PM, Stefan Andritoiu wrote: >=20 > Hi Neel, >=20 >> On Sat, Jun 13, 2015 at 9:00 PM, Neel Natu wrote: >> Hi Stefan, >>=20 >> On Sat, Jun 13, 2015 at 3:33 AM, Stefan Andritoiu >> wrote: >>> Hi, >>>=20 >>> How can I pin a thread to run only on a specific CPU? >>> Is it enough just to set the "struct cpuset *td_cpuset" of the thread? >>=20 >> sched_bind() is the proper way to do this. >=20 > But in sched_bind() I notice: > KASSERT(td =3D=3D curthread, ("sched_bind: can only bind curthread")); >=20 > How can I bind a thread that is not curthread? I don't know offhand but your original suggestion of 'td_cpuset' does seem l= ike a reasonable place to start. Best Neel >=20 >>=20 >> best >> Neel >>=20 >>> Thank you, >>> Stefan >>> _______________________________________________ >>> freebsd-virtualization@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >>> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@fre= ebsd.org" From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 15 09:54:11 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5341FFE7; Mon, 15 Jun 2015 09:54:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CA9C8AF; Mon, 15 Jun 2015 09:54:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6418725D385E; Mon, 15 Jun 2015 09:53:58 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A0B5CC77036; Mon, 15 Jun 2015 09:53:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id DoU4RFTYq7x1; Mon, 15 Jun 2015 09:53:56 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B88BAC76FD3; Mon, 15 Jun 2015 09:53:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) From: "Bjoern A. Zeeb" In-Reply-To: Date: Mon, 15 Jun 2015 09:53:53 +0000 Cc: freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> References: To: kikuchan@uranus.dti.ne.jp X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 15 Jun 2015 09:54:11 -0000 Hi, removed hackers, added virtualization. > On 12 Jun 2015, at 01:17 , kikuchan@uranus.dti.ne.jp wrote: >=20 > Hello, >=20 > I=E2=80=99m (still) trying to figure out how jail-aware SysV IPC = mechanism should be. The best way probably is to finally get the =E2=80=9Ccommon=E2=80=9D = VIMAGE framework into HEAD to allow easy virtualisation of other = services. That work has been sitting in perforce for a few years and = simply needs updating for sysctls I think. Then use that to virtualise things and have a vipc like we have vnets. = The good news is that you have identified most places and have the = cleanup functions already so it=E2=80=99d be a matter of transforming = your changes (assuming they are correct and working fine; haven=E2=80=99t = actually read the patch in detail;-) to the different infrastructure. = And that=E2=80=99s the easiest part. Bjoern From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 15 10:49:22 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07290941; Mon, 15 Jun 2015 10:49:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9013874D; Mon, 15 Jun 2015 10:49:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wgzl5 with SMTP id l5so40511885wgz.3; Mon, 15 Jun 2015 03:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=JWR5WjCsHQ+v2c2U7c2JWNq7N7NXiD6r2n1qot0odSQ=; b=eSw9rQk7gQFEgNmK/TXNQSSFmmhVZ6Jy4PHN+qax8SpFiSbDNuTkpXcM5S1MRgRmbx 0RfrdTs+eLjdpzaFcQN5pf7W2yihMttFDl35023IUlsqBlM01mONMNIisDhzw3dooy2C OOsB0zfOqwmkkcD4+td7/XmUgBK8w84NQcst8xi1bK1syal5Y93pJvezLl2D1lsXf3vF z2hw13Lv+1eLC04TVoeNOspcA7nfqVrEys4EBNl/yBTWZ5yQ0biTRV1/LgWUFyMKf/tz vltwjYV+H/93xLGw4h6L1xzRt6Ge+fGC5UZc0HkvwrjSdzIF3f9yYfb7Hq0zNkdpdLUP UooA== X-Received: by 10.194.238.233 with SMTP id vn9mr18877453wjc.24.1434365360033; Mon, 15 Jun 2015 03:49:20 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ch2sm15232158wib.18.2015.06.15.03.49.18 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 15 Jun 2015 03:49:18 -0700 (PDT) Date: Mon, 15 Jun 2015 12:49:16 +0200 From: Mateusz Guzik To: "Bjoern A. Zeeb" Cc: kikuchan@uranus.dti.ne.jp, freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) Message-ID: <20150615104915.GA18004@dft-labs.eu> References: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 15 Jun 2015 10:49:22 -0000 On Mon, Jun 15, 2015 at 09:53:53AM +0000, Bjoern A. Zeeb wrote: > Hi, > > removed hackers, added virtualization. > > > > On 12 Jun 2015, at 01:17 , kikuchan@uranus.dti.ne.jp wrote: > > > > Hello, > > > > I’m (still) trying to figure out how jail-aware SysV IPC mechanism should be. > > The best way probably is to finally get the “common” VIMAGE framework into HEAD to allow easy virtualisation of other services. That work has been sitting in perforce for a few years and simply needs updating for sysctls I think. > > Then use that to virtualise things and have a vipc like we have vnets. The good news is that you have identified most places and have the cleanup functions already so it’d be a matter of transforming your changes (assuming they are correct and working fine; haven’t actually read the patch in detail;-) to the different infrastructure. And that’s the easiest part. > > I have not looked at vimage too closely, maybe indeed it's the right to go. Would definitely be interested in seeing it cleaned up and in action. In the meantime, as I tried to explain in the previous thread, a jail-aware sysvshm poses several questions which need to be answered/taken care of before it can hit the tree. I doubt any reasonable implementation can magically avoid problems they pose and I definitely want to get an analysis how proposed implementation behaves (or how it prevents given scenario from occuring). Fundamentally the basic question is how does the implementation cope with processes having sysvshm mappings obtained from 2 different jails (provided they use different sysvshms). Preferably the whole business would be /prevented/. Prevention mechanism would have to deal with shared address spaces (rfork(2) + RFMEM), threads and pre-existing mappings. The patch posted here just puts permission checks in several places, while leaving the namespace shared, which I find to be a user-visible hack with no good justification. There is also no analysis how this behaves when presented with aforementioned scenario. Even if it turns out the resut is harmless with resulting code, this leaves us with a very error-prone scheme. There is no technical problem adding a pointer to struct prison and dereferencing it instead of current global vars. Adding proper sysctls dumping the content for given jail is trivial and so is providing resource limits when creating a first-level jail with a separate sysvshm. Something which cannot be as easily achieved with the patch in question. Possible later switch to vimage would be transparent to users. -- Mateusz Guzik From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 15 17:10:33 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AEBC6695; Mon, 15 Jun 2015 17:10:33 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp07.dti.ne.jp (vsmtp07.dti.ne.jp [202.216.231.142]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0097CF; Mon, 15 Jun 2015 17:10:32 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail01.ga.dti.ne.jp [202.216.229.152]) by vsmtp07.dti.ne.jp (3.11v) with ESMTP AUTH id t5FHAQ4b002127; Tue, 16 Jun 2015 02:10:26 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Tue, 16 Jun 2015 02:10:26 +0900 From: To: "Bjoern A. Zeeb" Cc: , Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) In-Reply-To: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> References: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 15 Jun 2015 17:10:33 -0000 On Mon, 15 Jun 2015 09:53:53 +0000, "Bjoern A. Zeeb" wrote: > Hi, > > removed hackers, added virtualization. > > >> On 12 Jun 2015, at 01:17 , kikuchan@uranus.dti.ne.jp wrote: >> >> Hello, >> >> I$B!G(Bm (still) trying to figure out how jail-aware SysV IPC mechanism should be. > > The best way probably is to finally get the $B!H(Bcommon$B!I(B VIMAGE framework into HEAD to allow easy virtualisation of other services. That work has been sitting in perforce for a few years and simply needs updating for sysctls I think. > > Then use that to virtualise things and have a vipc like we have vnets. The good news is that you have identified most places and have the cleanup functions already so it$B!G(Bd be a matter of transforming your changes (assuming they are correct and working fine; haven$B!G(Bt actually read the patch in detail;-) to the different infrastructure. And that$B!G(Bs the easiest part. > > > Bjoern Hi Bjoern, Thank you for your reply. The "common" VIMAGE framework sounds good, I really want it. I want to know what the IPC system looks like for user-land after virtualized, and what happen if vnet like vipc is implemented. For example, jail 1, 2, 3 join vipc group A, and jail 4, 5, 6 join vipc group B ?? Hmm, it looks good. Regards, Kikuchan From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 15 17:32:55 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A9C3B4A6; Mon, 15 Jun 2015 17:32:55 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 616A9DC0; Mon, 15 Jun 2015 17:32:55 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 44C9225D3891; Mon, 15 Jun 2015 17:32:51 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 56210C77036; Mon, 15 Jun 2015 17:32:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Fvpq1GMwVR0V; Mon, 15 Jun 2015 17:32:48 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6] (orange-tun0-ula.sbone.de [IPv6:fde9:577b:c1a9:4420:cabc:c8ff:fe8b:4fe6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id D8381C76FD3; Mon, 15 Jun 2015 17:32:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) From: "Bjoern A. Zeeb" In-Reply-To: Date: Mon, 15 Jun 2015 17:32:45 +0000 Cc: freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> To: kikuchan@uranus.dti.ne.jp X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 15 Jun 2015 17:32:55 -0000 > On 15 Jun 2015, at 17:10 , kikuchan@uranus.dti.ne.jp wrote: >=20 > On Mon, 15 Jun 2015 09:53:53 +0000, "Bjoern A. Zeeb" = wrote: >> Hi, >>=20 >> removed hackers, added virtualization. >>=20 >>=20 >>> On 12 Jun 2015, at 01:17 , kikuchan@uranus.dti.ne.jp wrote: >>>=20 >>> Hello, >>>=20 >>> I=E2=80=99m (still) trying to figure out how jail-aware SysV IPC = mechanism should be. >>=20 >> The best way probably is to finally get the =E2=80=9Ccommon=E2=80=9D = VIMAGE framework into HEAD to allow easy virtualisation of other = services. That work has been sitting in perforce for a few years and = simply needs updating for sysctls I think. >>=20 >> Then use that to virtualise things and have a vipc like we have = vnets. The good news is that you have identified most places and have = the cleanup functions already so it=E2=80=99d be a matter of = transforming your changes (assuming they are correct and working fine; = haven=E2=80=99t actually read the patch in detail;-) to the different = infrastructure. And that=E2=80=99s the easiest part. >>=20 >>=20 >> Bjoern >=20 > Hi Bjoern, > Thank you for your reply. >=20 > The "common" VIMAGE framework sounds good, I really want it. >=20 > I want to know what the IPC system looks like for user-land after = virtualized, > and what happen if vnet like vipc is implemented. >=20 > For example, jail 1, 2, 3 join vipc group A, and jail 4, 5, 6 join = vipc group B ?? > Hmm, it looks good. That=E2=80=99s not exactly how it works currently and I think the mixing = of options will be harder and something we=E2=80=99l have to figure out = more carefully. You would be able to say jail 1 has a vipc and jail 2 and 3 and =E2=80=9Cc= hild jails=E2=80=9D and inherit it. (similar for 4 + 5,6) so it=E2=80=99s= nested but not side-by-side. If we want more of the =E2=80=9Cmixing=E2=80=9D and independentness = we=E2=80=99ll have to re-think the way we =E2=80=9Cmanage=E2=80=9D = jails. Bjoern= From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 15 18:45:36 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F177EB0; Mon, 15 Jun 2015 18:45:36 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp07.dti.ne.jp (vsmtp07.dti.ne.jp [202.216.231.142]) by mx1.freebsd.org (Postfix) with ESMTP id 3A1501AD; Mon, 15 Jun 2015 18:45:35 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail01.ga.dti.ne.jp [202.216.229.152]) by vsmtp07.dti.ne.jp (3.11v) with ESMTP AUTH id t5FIjYtN004416; Tue, 16 Jun 2015 03:45:34 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Tue, 16 Jun 2015 03:45:34 +0900 From: To: Mateusz Guzik Cc: , Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) In-Reply-To: <20150615104915.GA18004@dft-labs.eu> References: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> <20150615104915.GA18004@dft-labs.eu> Message-ID: <3681b69c41fd9352fef30afed901661a@imap.cm.dream.jp> X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 15 Jun 2015 18:45:36 -0000 On Mon, 15 Jun 2015 12:49:16 +0200, Mateusz Guzik wrote: > On Mon, Jun 15, 2015 at 09:53:53AM +0000, Bjoern A. Zeeb wrote: >> Hi, >> >> removed hackers, added virtualization. >> >> >> > On 12 Jun 2015, at 01:17 , kikuchan@uranus.dti.ne.jp wrote: >> > >> > Hello, >> > >> > I$B!G(Bm (still) trying to figure out how jail-aware SysV IPC mechanism should be. >> >> The best way probably is to finally get the $B!H(Bcommon$B!I(B VIMAGE framework into HEAD to allow easy virtualisation of other services. That work has been sitting in perforce for a few years and simply needs updating for sysctls I think. >> >> Then use that to virtualise things and have a vipc like we have vnets. The good news is that you have identified most places and have the cleanup functions already so it$B!G(Bd be a matter of transforming your changes (assuming they are correct and working fine; haven$B!G(Bt actually read the patch in detail;-) to the different infrastructure. And that$B!G(Bs the easiest part. >> >> > > I have not looked at vimage too closely, maybe indeed it's the right to > go. Would definitely be interested in seeing it cleaned up and in > action. > > In the meantime, as I tried to explain in the previous thread, a > jail-aware sysvshm poses several questions which need to be > answered/taken care of before it can hit the tree. I doubt any > reasonable implementation can magically avoid problems they pose and I > definitely want to get an analysis how proposed implementation behaves > (or how it prevents given scenario from occuring). > > Fundamentally the basic question is how does the implementation cope > with processes having sysvshm mappings obtained from 2 different jails > (provided they use different sysvshms). > > Preferably the whole business would be /prevented/. Prevention mechanism > would have to deal with shared address spaces (rfork(2) + RFMEM), > threads and pre-existing mappings. > > The patch posted here just puts permission checks in several places, > while leaving the namespace shared, which I find to be a user-visible > hack with no good justification. There is also no analysis how this > behaves when presented with aforementioned scenario. Even if it turns > out the resut is harmless with resulting code, this leaves us with a > very error-prone scheme. > > There is no technical problem adding a pointer to struct prison and > dereferencing it instead of current global vars. Adding proper sysctls > dumping the content for given jail is trivial and so is providing > resource limits when creating a first-level jail with a separate > sysvshm. Something which cannot be as easily achieved with the patch in > question. > > Possible later switch to vimage would be transparent to users. Dear Mateusz, I'm sorry if I'm annoying you, but I really want to solve this problems. > Fundamentally the basic question is how does the implementation cope > with processes having sysvshm mappings obtained from 2 different jails > (provided they use different sysvshms). > > Preferably the whole business would be /prevented/. Prevention mechanism > would have to deal with shared address spaces (rfork(2) + RFMEM), > threads and pre-existing mappings. > > The patch posted here just puts permission checks in several places, > while leaving the namespace shared, which I find to be a user-visible > hack with no good justification. There is also no analysis how this > behaves when presented with aforementioned scenario. Even if it turns > out the resut is harmless with resulting code, this leaves us with a > very error-prone scheme. > > There is no technical problem adding a pointer to struct prison and > dereferencing it instead of current global vars. Adding proper sysctls > dumping the content for given jail is trivial and so is providing > resource limits when creating a first-level jail with a separate > sysvshm. Something which cannot be as easily achieved with the patch in > question. Could you try the latest patch, please? I justify user-visibility, make it hierarchical jail friendly, and use EINVAL instead of EACCES to conceal information leak. https://bz-attachments.freebsd.org/attachment.cgi?id=157661 (typo fixed) I realized my method is a bit better, when I'm trying to port/write the real namespace separation. Let me explain (again) why I choose this method for sysv ipc, and could you tell me how it should be, please? struct shmmap_state { vm_offset_t va; int shmid; }; In sysv_shm.c, struct shmmap_state, exist per process as p->p_vmspace->vm_shm, is a lookup-table for va -> shm object lookup. The shmmap_state entry holds a reference (here, shmid) to shm object for further detach, and entries are simply copied on fork. If you split namespace (includes shmid space) completely, shmid would be no longer a unique identifier for IPC object in kernel. To make it unique, adding a reference to prison into shmmap_state like this; struct shmmap_state { vm_offset_t va; struct prison *prison; int shmid; }; would be bad idea, because after a process calls jail_attach(), the process holds a reference to another (creator) prison, or copy the IPC object completely on every jail_attach() occurs? How do you deal with hierarchical jail? How about this; struct shmmap_state { vm_offset_t va; struct shmid_kernel *shmseg; }; looks better, but remember you split shmid space completely by moving global vars to separated namespace for each jail, the *shmseg points inside of each jail's "struct shmid_kernel *shmsegs" list. It would have the same problems as the previous one. To prevent this, make a single shared list of struct shmid_kernel in kernel? It would be the same method what I used. Hmm, or, other smarter way exists, perhaps? What does it look like? I have no more idea... My method didn't touch anything about the mapping stuff, thus it behaves exactly the same as current FreeBSD behave on this point. I'm not sure I could understand properly what the shared address space problem is, (Could someone help me to understand, perhaps in code?) and, I'm not sure whether the current FreeBSD has the shared address space problem for sysvshm combined with jails. If it has the problem, unfortunately my patch doesn't provide any solution for that, but if not, my patch doesn't have the problem either, because I didn't change code structure. The patch just fixes key_t collision for jails, nothing more. So, the patch is harmless for non-jail user, and I believe it's useful for jail user using allow.sysvipc=true. BTW, What do you think about the following design for jail-aware sysvipc? > - IPC objects created on parent jail, are invisible to children. > - IPC objects created on neighbor jail, are also invisible each other. > - IPC objects craeted on child jail, are VISIBLE from parent. > - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. I want to know it because I think the implementation and the behavior design can be discussed independently. Thank you. Regards, Kikuchan From owner-freebsd-virtualization@FreeBSD.ORG Mon Jun 15 21:44:35 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C7F8D80; Mon, 15 Jun 2015 21:44:35 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 941AF6B3; Mon, 15 Jun 2015 21:44:34 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wiga1 with SMTP id a1so91284772wig.0; Mon, 15 Jun 2015 14:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=qN5ok6rJG3E1UCPGCJwfevktPczWXBgca6Aseab4tAc=; b=gBBKefEBGo3HpvREA8qnfW92rCKsezhO+18VjxjQwN/lGaivNZQlALqFyucfHZYHqF bgP8UEPWPVd6n1H41kVhGevMk9JMlJIHCnL8RGZEQ8hhLg0kaJg/CtDeNhBUZiKwtJOl R2WbhyZ/R/vIRoT1t6mxxA5uHv0JFiYlYzOkOzS2Gq1qL7Y5tgPRL7lwteREKCxu9LZ9 RB9HV4UfZbElxYIHwbtd/PJ30XYniM8nj6Ldq/TA7PXDH6O15p4A3iNL9RPNYLDYwWiQ 2jPsGTchUEFWPJpUdcW5HO5FSkm5/Al6hhNkw0jwRB+p+bcIY9HPZUG1wmvdCnHoQMiz CbHQ== X-Received: by 10.194.184.140 with SMTP id eu12mr54337746wjc.78.1434404671982; Mon, 15 Jun 2015 14:44:31 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id o6sm17752918wiz.24.2015.06.15.14.44.30 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 15 Jun 2015 14:44:30 -0700 (PDT) Date: Mon, 15 Jun 2015 23:44:28 +0200 From: Mateusz Guzik To: kikuchan@uranus.dti.ne.jp Cc: freebsd-jail@freebsd.org, freebsd-virtualization@freebsd.org Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) Message-ID: <20150615214427.GB18004@dft-labs.eu> References: <2B7AA933-CB74-4737-8330-6E623A31C6DA@lists.zabbadoz.net> <20150615104915.GA18004@dft-labs.eu> <3681b69c41fd9352fef30afed901661a@imap.cm.dream.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3681b69c41fd9352fef30afed901661a@imap.cm.dream.jp> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 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: Mon, 15 Jun 2015 21:44:35 -0000 On Tue, Jun 16, 2015 at 03:45:34AM +0900, kikuchan@uranus.dti.ne.jp wrote: > On Mon, 15 Jun 2015 12:49:16 +0200, Mateusz Guzik wrote: > > Fundamentally the basic question is how does the implementation cope > > with processes having sysvshm mappings obtained from 2 different jails > > (provided they use different sysvshms). > > > > Preferably the whole business would be /prevented/. Prevention mechanism > > would have to deal with shared address spaces (rfork(2) + RFMEM), > > threads and pre-existing mappings. > > > > The patch posted here just puts permission checks in several places, > > while leaving the namespace shared, which I find to be a user-visible > > hack with no good justification. There is also no analysis how this > > behaves when presented with aforementioned scenario. Even if it turns > > out the resut is harmless with resulting code, this leaves us with a > > very error-prone scheme. > > > > There is no technical problem adding a pointer to struct prison and > > dereferencing it instead of current global vars. Adding proper sysctls > > dumping the content for given jail is trivial and so is providing > > resource limits when creating a first-level jail with a separate > > sysvshm. Something which cannot be as easily achieved with the patch in > > question. > > Could you try the latest patch, please? > I justify user-visibility, make it hierarchical jail friendly, and use EINVAL instead of EACCES to conceal information leak. > https://bz-attachments.freebsd.org/attachment.cgi?id=157661 (typo fixed) > > > I realized my method is a bit better, when I'm trying to port/write the real namespace separation. > Let me explain (again) why I choose this method for sysv ipc, and could you tell me how it should be, please? > > struct shmmap_state { > vm_offset_t va; > int shmid; > }; > > In sysv_shm.c, struct shmmap_state, exist per process as p->p_vmspace->vm_shm, is a lookup-table for va -> shm object lookup. > The shmmap_state entry holds a reference (here, shmid) to shm object for further detach, and entries are simply copied on fork. > > If you split namespace (includes shmid space) completely, shmid would be no longer a unique identifier for IPC object in kernel. > To make it unique, adding a reference to prison into shmmap_state like this; > > struct shmmap_state { > vm_offset_t va; > struct prison *prison; > int shmid; > }; > > would be bad idea, because after a process calls jail_attach(), the process holds a reference to another (creator) prison, or copy the IPC object completely on every jail_attach() occurs? As I explained in the previous thread, with a separate namespace it is a strict requirement to prevent sharing of sysvshm mappings. With the requirement met, there is no issue. As you will see later in the mail, even your approach would benefit greatly from having such a restriction. > How do you deal with hierarchical jail? > If proper resource limiting for hierarchical jails is implemented, the new jail either inherits or gets a new namespace, depending on used options. With only simplistic support first level jails can inherit or get a new namespace, the rest must inherit. There is no issue here due to sharing prevention. > My method didn't touch anything about the mapping stuff, thus it behaves exactly the same as current FreeBSD behave on this point. > Sure it did. As you noticed yourself it makes sense to clean up sysvshms on jail destruction, which you do in sysvshm_cleanup_for_prison_myhook. Your code does: if ((shmseg->u.shm_perm.mode & SHMSEG_ALLOCATED) && shmseg->cred->cr_prison == pr) { shm_remove(shmseg, i); .... which differs from what is executed by kern_shmdt_locked. Now let's consider a process which rforks and shared the address space with it's child. The child enters a jail and grabs a sysvshm mapping, then exits and we kill the jail. In effect we got a process with an address space which used a mapping created in a now-destroyed jail. Is this situation problematic? I don't see any anlysis provided. Maybe it is, maybe it so happens it is not. The mere posibility of this scenario needlessly complicates maintenance, and such a scenario has likely no practical purpose. As such, it is best /prevented/. With it prevented there is nothing positive about your approach that I could see. > I'm not sure I could understand properly what the shared address space problem is, (Could someone help me to understand, perhaps in code?) > and, I'm not sure whether the current FreeBSD has the shared address space problem for sysvshm combined with jails. > If it has the problem, unfortunately my patch doesn't provide any solution for that, > but if not, my patch doesn't have the problem either, because I didn't change code structure. > As I mentioned, you sure did. I don't know if there are any serious problems /as it is/ and I'm too lazy to check. I surely expect any patch doing sysvshm for jails to be provided with an anslysis of its behaviour in that regard though. > The patch just fixes key_t collision for jails, nothing more. > So, the patch is harmless for non-jail user, and I believe it's useful for jail user using allow.sysvipc=true. > > > BTW, What do you think about the following design for jail-aware sysvipc? > > > - IPC objects created on parent jail, are invisible to children. > > - IPC objects created on neighbor jail, are also invisible each other. > > - IPC objects craeted on child jail, are VISIBLE from parent. > > - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. > How about the following: the jail decided whether it wants to share a namespace with a particular child (and by extension grandchildren and so on). Done. There is nothing complicated to do here unless you want to try out named namespace which you e.g. assign to different jails on the same level. -- Mateusz Guzik From owner-freebsd-virtualization@FreeBSD.ORG Thu Jun 18 15:53:37 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35493B0B for ; Thu, 18 Jun 2015 15:53:37 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AF69909 for ; Thu, 18 Jun 2015 15:53:37 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t5IFraUP003808 for ; Thu, 18 Jun 2015 15:53:36 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t5IFrajB003804; Thu, 18 Jun 2015 15:53:36 GMT (envelope-from daemon-user) Date: Thu, 18 Jun 2015 15:53:36 +0000 To: freebsd-virtualization@freebsd.org From: "nvass-gmx.com (Nikos Vassiliadis)" Reply-to: D1944+333+b09c6235d993877b@FreeBSD.org Subject: [Differential] [Updated, 170 lines] D1944: PF and VIMAGE fixes Message-ID: <53b75cd4fc6e337ad2e66310a0bd350c@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFWC6YA= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_53b75cd4fc6e337ad2e66310a0bd350c" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:53:37 -0000 --b1_53b75cd4fc6e337ad2e66310a0bd350c Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit nvass-gmx.com updated this revision to Diff 6288. nvass-gmx.com added a comment. Updated to today's head branch. Please review CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1944?vs=5290&id=6288 REVISION DETAIL https://reviews.freebsd.org/D1944 AFFECTED FILES sys/net/pfvar.h sys/netpfil/pf/pf.c sys/netpfil/pf/pf_if.c sys/netpfil/pf/pf_ioctl.c sys/netpfil/pf/pf_norm.c EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, kristof, gnn, glebius, rodrigc Cc: julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list --b1_53b75cd4fc6e337ad2e66310a0bd350c Content-Type: text/x-patch; charset=utf-8; name="D1944.6288.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D1944.6288.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXRwZmlsL3BmL3BmX25vcm0uYyBiL3N5cy9uZXRwZmlsL3BmL3Bm X25vcm0uYwotLS0gYS9zeXMvbmV0cGZpbC9wZi9wZl9ub3JtLmMKKysrIGIvc3lzL25ldHBmaWwv cGYvcGZfbm9ybS5jCkBAIC0xODAsNyArMTgwLDcgQEAKICNlbmRpZgkvKiBJTkVUICovCiAKIHZv aWQKLXBmX25vcm1hbGl6ZV9pbml0KHZvaWQpCitwZl92bmV0X25vcm1hbGl6ZV9pbml0KHZvaWQp CiB7CiAKIAlWX3BmX2ZyYWdfeiA9IHVtYV96Y3JlYXRlKCJwZiBmcmFncyIsIHNpemVvZihzdHJ1 Y3QgcGZfZnJhZ21lbnQpLApkaWZmIC0tZ2l0IGEvc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwuYyBi L3N5cy9uZXRwZmlsL3BmL3BmX2lvY3RsLmMKLS0tIGEvc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwu YworKysgYi9zeXMvbmV0cGZpbC9wZi9wZl9pb2N0bC5jCkBAIC04Nyw3ICs4Nyw4IEBACiAjaW5j bHVkZSA8bmV0L2FsdHEvYWx0cS5oPgogI2VuZGlmCiAKLXN0YXRpYyBpbnQJCSBwZmF0dGFjaCh2 b2lkKTsKK3N0YXRpYyBpbnQJCSBwZl92bmV0X2luaXQodm9pZCk7CitzdGF0aWMgaW50CQkgcGZf dm5ldF91bmluaXQodm9pZCk7CiBzdGF0aWMgc3RydWN0IHBmX3Bvb2wJKnBmX2dldF9wb29sKGNo YXIgKiwgdV9pbnQzMl90LCB1X2ludDhfdCwgdV9pbnQzMl90LAogCQkJICAgIHVfaW50OF90LCB1 X2ludDhfdCwgdV9pbnQ4X3QpOwogCkBAIC0xNDksNiArMTUwLDcgQEAKICNkZWZpbmUgRFBGUFJJ TlRGKG4sIHgpIGlmIChWX3BmX3N0YXR1cy5kZWJ1ZyA+PSAobikpIHByaW50ZiB4CiAKIHN0cnVj dCBjZGV2ICpwZl9kZXY7CitpbnQgbnVtYmVyX29mX3ZuZXRzID0gMDsKIAogLyoKICAqIFhYWCAt IFRoZXNlIGFyZSBuZXcgYW5kIG5lZWQgdG8gYmUgY2hlY2tlZCB3aGVuIG1vdmVpbmcgdG8gYSBu ZXcgdmVyc2lvbgpAQCAtMjA1LDE3ICsyMDcsMTYgQEAKIHBmbG9nX3BhY2tldF90CQkJKnBmbG9n X3BhY2tldF9wdHIgPSBOVUxMOwogCiBzdGF0aWMgaW50Ci1wZmF0dGFjaCh2b2lkKQorcGZfdm5l dF9pbml0KHZvaWQpCiB7CiAJdV9pbnQzMl90ICpteV90aW1lb3V0ID0gVl9wZl9kZWZhdWx0X3J1 bGUudGltZW91dDsKIAlpbnQgZXJyb3I7CiAKLQlpZiAoSVNfREVGQVVMVF9WTkVUKGN1cnZuZXQp KQotCQlwZl9tdGFnX2luaXRpYWxpemUoKTsKLQlwZl9pbml0aWFsaXplKCk7CisJbnVtYmVyX29m X3ZuZXRzKys7CisJcGZfdm5ldF9pbml0aWFsaXplKCk7CiAJcGZyX2luaXRpYWxpemUoKTsKLQlw ZmlfaW5pdGlhbGl6ZSgpOwotCXBmX25vcm1hbGl6ZV9pbml0KCk7CisJcGZpX3ZuZXRfaW5pdGlh bGl6ZSgpOworCXBmX3ZuZXRfbm9ybWFsaXplX2luaXQoKTsKIAogCVZfcGZfbGltaXRzW1BGX0xJ TUlUX1NUQVRFU10ubGltaXQgPSBQRlNUQVRFX0hJV0FUOwogCVZfcGZfbGltaXRzW1BGX0xJTUlU X1NSQ19OT0RFU10ubGltaXQgPSBQRlNOT0RFX0hJV0FUOwpAQCAtMjg3LDcgKzI4OCw2MyBAQAog CiAJcmV0dXJuICgwKTsKIH0KK1ZORVRfU1lTSU5JVChwZl92bmV0X2luaXQsIFNJX1NVQl9QUk9U T19JRkFUVEFDSERPTUFJTiwgU0lfT1JERVJfQU5ZIC0gMjU1LAorICAgIHBmX3ZuZXRfaW5pdCwg TlVMTCk7CiAKK3N0YXRpYyBpbnQKK3BmX3ZuZXRfdW5pbml0KHZvaWQpCit7CisJaW50IGVycm9y ID0gMDsKKworCW51bWJlcl9vZl92bmV0cy0tOworCUtBU1NFUlQobnVtYmVyX29mX3ZuZXRzID49 IDAsICgibnVtYmVyIG9mIHZuZXRzIDwgMCIpKTsKKworCVBGX1JVTEVTX1JMT0NLKCk7CisJVl9w Zl9lbmRfdGhyZWFkcysrOworCVBGX1JVTEVTX1JVTkxPQ0soKTsKKwl3YWtldXAocGZfcHVyZ2Vf dGhyZWFkKTsKKwl3aGlsZSAoVl9wZl9lbmRfdGhyZWFkcyA8IDIpCisJCXBhdXNlKCJwZnVubGQi LCBoeiAvIDkpOworCisJVl9wZl9zdGF0dXMucnVubmluZyA9IDA7CisJc3dpX3JlbW92ZShWX3Bm X3N3aV9jb29raWUpOworCWVycm9yID0gZGVob29rX3BmKCk7CisJaWYgKGVycm9yKSB7CisJCS8q CisJCSAqIFNob3VsZCBub3QgaGFwcGVuIQorCQkgKiBYWFggRHVlIHRvIGVycm9yIGNvZGUgRVNS Q0gsIGtsZHVubG9hZCB3aWxsIHNob3cKKwkJICogYSBtZXNzYWdlIGxpa2UgJ05vIHN1Y2ggcHJv Y2VzcycuCisJCSAqLworCQlwcmludGYoIiVzIDogcGZpbCB1bnJlZ2lzdGVyYXRpb24gZmFpbFxu IiwgX19GVU5DVElPTl9fKTsKKwkJcmV0dXJuIGVycm9yOworCX0KKwlQRl9SVUxFU19XTE9DSygp OworCXNodXRkb3duX3BmKCk7CisJcGZfbm9ybWFsaXplX2NsZWFudXAoKTsKKwlwZmlfY2xlYW51 cCgpOworCXBmcl9jbGVhbnVwKCk7CisJcGZfb3NmcF9mbHVzaCgpOworCXBmX2NsZWFudXAoKTsK KworCS8qCisJICogRm9yIHRoZSBsYXN0IFZORVQgd2UgcGVyZm9ybSB0aGUgZmluYWwgY2xlYW51 cAorCSAqLworCWlmIChudW1iZXJfb2Zfdm5ldHMgPT0gMCkgeworCQlwZl91bmluaXRfZXZlbnRo YW5kbGVycygpOworCQlwZl9tdGFnX2NsZWFudXAoKTsKKwl9CisJUEZfUlVMRVNfV1VOTE9DSygp OworCWlmIChudW1iZXJfb2Zfdm5ldHMgPT0gMCkgeworCQlkZXN0cm95X2RldihwZl9kZXYpOwor CQlyd19kZXN0cm95KCZwZl9ydWxlc19sb2NrKTsKKwkJc3hfZGVzdHJveSgmcGZfaW9jdGxfbG9j ayk7CisJfQorCisJcmV0dXJuIChlcnJvcik7Cit9CitWTkVUX1NZU1VOSU5JVChwZl92bmV0X3Vu aW5pdCwgU0lfU1VCX1BST1RPX0lGQVRUQUNIRE9NQUlOLCBTSV9PUkRFUl9BTlkgLSAyNTUsCisg ICAgcGZfdm5ldF91bmluaXQsIE5VTEwpOworCiBzdGF0aWMgc3RydWN0IHBmX3Bvb2wgKgogcGZf Z2V0X3Bvb2woY2hhciAqYW5jaG9yLCB1X2ludDMyX3QgdGlja2V0LCB1X2ludDhfdCBydWxlX2Fj dGlvbiwKICAgICB1X2ludDMyX3QgcnVsZV9udW1iZXIsIHVfaW50OF90IHJfbGFzdCwgdV9pbnQ4 X3QgYWN0aXZlLApAQCAtMzcwNywyNyArMzc2NCwxMiBAQAogc3RhdGljIGludAogcGZfbG9hZCh2 b2lkKQogewotCWludCBlcnJvcjsKIAotCVZORVRfSVRFUkFUT1JfREVDTCh2bmV0X2l0ZXIpOwot Ci0JVk5FVF9MSVNUX1JMT0NLKCk7Ci0JVk5FVF9GT1JFQUNIKHZuZXRfaXRlcikgewotCQlDVVJW TkVUX1NFVCh2bmV0X2l0ZXIpOwotCQlWX3BmX3BmaWxfaG9va2VkID0gMDsKLQkJVl9wZl9lbmRf dGhyZWFkcyA9IDA7Ci0JCVRBSUxRX0lOSVQoJlZfcGZfdGFncyk7Ci0JCVRBSUxRX0lOSVQoJlZf cGZfcWlkcyk7Ci0JCUNVUlZORVRfUkVTVE9SRSgpOwotCX0KLQlWTkVUX0xJU1RfUlVOTE9DSygp OwotCiAJcndfaW5pdCgmcGZfcnVsZXNfbG9jaywgInBmIHJ1bGVzZXRzIik7CiAJc3hfaW5pdCgm cGZfaW9jdGxfbG9jaywgInBmIGlvY3RsIik7Ci0KIAlwZl9kZXYgPSBtYWtlX2RldigmcGZfY2Rl dnN3LCAwLCAwLCAwLCAwNjAwLCBQRl9OQU1FKTsKLQlpZiAoKGVycm9yID0gcGZhdHRhY2goKSkg IT0gMCkKLQkJcmV0dXJuIChlcnJvcik7CisJcGZfbXRhZ19pbml0aWFsaXplKCk7CisgICAgICAg IHBmX2luaXRfZXZlbnRoYW5kbGVycygpOwogCiAJcmV0dXJuICgwKTsKIH0KQEAgLTM3MzUsNDAg KzM3NzcsOCBAQAogc3RhdGljIGludAogcGZfdW5sb2FkKHZvaWQpCiB7Ci0JaW50IGVycm9yID0g MDsKIAotCVZfcGZfc3RhdHVzLnJ1bm5pbmcgPSAwOwotCXN3aV9yZW1vdmUoVl9wZl9zd2lfY29v a2llKTsKLQllcnJvciA9IGRlaG9va19wZigpOwotCWlmIChlcnJvcikgewotCQkvKgotCQkgKiBT aG91bGQgbm90IGhhcHBlbiEKLQkJICogWFhYIER1ZSB0byBlcnJvciBjb2RlIEVTUkNILCBrbGR1 bmxvYWQgd2lsbCBzaG93Ci0JCSAqIGEgbWVzc2FnZSBsaWtlICdObyBzdWNoIHByb2Nlc3MnLgot CQkgKi8KLQkJcHJpbnRmKCIlcyA6IHBmaWwgdW5yZWdpc3RlcmF0aW9uIGZhaWxcbiIsIF9fRlVO Q1RJT05fXyk7Ci0JCXJldHVybiBlcnJvcjsKLQl9Ci0JUEZfUlVMRVNfV0xPQ0soKTsKLQlzaHV0 ZG93bl9wZigpOwotCVZfcGZfZW5kX3RocmVhZHMgPSAxOwotCXdoaWxlIChWX3BmX2VuZF90aHJl YWRzIDwgMikgewotCQl3YWtldXBfb25lKHBmX3B1cmdlX3RocmVhZCk7Ci0JCXJ3X3NsZWVwKHBm X3B1cmdlX3RocmVhZCwgJnBmX3J1bGVzX2xvY2ssIDAsICJwZnRtbyIsIDApOwotCX0KLQlQRl9S VUxFU19XVU5MT0NLKCk7Ci0JcGZfbm9ybWFsaXplX2NsZWFudXAoKTsKLQlwZmlfY2xlYW51cCgp OwotCXBmcl9jbGVhbnVwKCk7Ci0JcGZfb3NmcF9mbHVzaCgpOwotCXBmX2NsZWFudXAoKTsKLQlp ZiAoSVNfREVGQVVMVF9WTkVUKGN1cnZuZXQpKQotCQlwZl9tdGFnX2NsZWFudXAoKTsKLQlkZXN0 cm95X2RldihwZl9kZXYpOwotCXJ3X2Rlc3Ryb3koJnBmX3J1bGVzX2xvY2spOwotCXN4X2Rlc3Ry b3koJnBmX2lvY3RsX2xvY2spOwotCi0JcmV0dXJuIChlcnJvcik7CisJcmV0dXJuICgwKTsKIH0K IAogc3RhdGljIGludApkaWZmIC0tZ2l0IGEvc3lzL25ldHBmaWwvcGYvcGZfaWYuYyBiL3N5cy9u ZXRwZmlsL3BmL3BmX2lmLmMKLS0tIGEvc3lzL25ldHBmaWwvcGYvcGZfaWYuYworKysgYi9zeXMv bmV0cGZpbC9wZi9wZl9pZi5jCkBAIC0xMDcsNyArMTA3LDcgQEAKICAgICBNVFhfREVGKTsKIAog dm9pZAotcGZpX2luaXRpYWxpemUodm9pZCkKK3BmaV92bmV0X2luaXRpYWxpemUodm9pZCkKIHsK IAlzdHJ1Y3QgaWZnX2dyb3VwICppZmc7CiAJc3RydWN0IGlmbmV0ICppZnA7CkBAIC0xMjMsMTYg KzEyMywyNCBAQAogCVBGX1JVTEVTX1dVTkxPQ0soKTsKIAogCUlGTkVUX1JMT0NLKCk7Ci0JVEFJ TFFfRk9SRUFDSChpZmcsICZWX2lmZ19oZWFkLCBpZmdfbmV4dCkKKwlUQUlMUV9GT1JFQUNIKGlm ZywgJlZfaWZnX2hlYWQsIGlmZ19uZXh0KSB7CiAJCXBmaV9hdHRhY2hfaWZncm91cChpZmcpOwot CVRBSUxRX0ZPUkVBQ0goaWZwLCAmVl9pZm5ldCwgaWZfbGluaykKKwl9CisJVEFJTFFfRk9SRUFD SChpZnAsICZWX2lmbmV0LCBpZl9saW5rKSB7CisJCUNVUlZORVRfU0VUKGlmcC0+aWZfdm5ldCk7 CiAJCXBmaV9hdHRhY2hfaWZuZXQoaWZwKTsKKwkJQ1VSVk5FVF9SRVNUT1JFKCk7CisJfQogCUlG TkVUX1JVTkxPQ0soKTsKK30KIAordm9pZAorcGZfaW5pdF9ldmVudGhhbmRsZXJzKHZvaWQpIHsK KwogCXBmaV9hdHRhY2hfY29va2llID0gRVZFTlRIQU5ETEVSX1JFR0lTVEVSKGlmbmV0X2Fycml2 YWxfZXZlbnQsCi0JICAgIHBmaV9hdHRhY2hfaWZuZXRfZXZlbnQsIE5VTEwsIEVWRU5USEFORExF Ul9QUklfQU5ZKTsKKwkgICAgcGZpX2F0dGFjaF9pZm5ldF9ldmVudCwgY3Vydm5ldCwgRVZFTlRI QU5ETEVSX1BSSV9BTlkpOwogCXBmaV9kZXRhY2hfY29va2llID0gRVZFTlRIQU5ETEVSX1JFR0lT VEVSKGlmbmV0X2RlcGFydHVyZV9ldmVudCwKLQkgICAgcGZpX2RldGFjaF9pZm5ldF9ldmVudCwg TlVMTCwgRVZFTlRIQU5ETEVSX1BSSV9BTlkpOworCSAgICBwZmlfZGV0YWNoX2lmbmV0X2V2ZW50 LCBjdXJ2bmV0LCBFVkVOVEhBTkRMRVJfUFJJX0FOWSk7CiAJcGZpX2F0dGFjaF9ncm91cF9jb29r aWUgPSBFVkVOVEhBTkRMRVJfUkVHSVNURVIoZ3JvdXBfYXR0YWNoX2V2ZW50LAogCSAgICBwZmlf YXR0YWNoX2dyb3VwX2V2ZW50LCBjdXJ2bmV0LCBFVkVOVEhBTkRMRVJfUFJJX0FOWSk7CiAJcGZp X2NoYW5nZV9ncm91cF9jb29raWUgPSBFVkVOVEhBTkRMRVJfUkVHSVNURVIoZ3JvdXBfY2hhbmdl X2V2ZW50LApAQCAtMTQwLDEzICsxNDgsMTEgQEAKIAlwZmlfZGV0YWNoX2dyb3VwX2Nvb2tpZSA9 IEVWRU5USEFORExFUl9SRUdJU1RFUihncm91cF9kZXRhY2hfZXZlbnQsCiAJICAgIHBmaV9kZXRh Y2hfZ3JvdXBfZXZlbnQsIGN1cnZuZXQsIEVWRU5USEFORExFUl9QUklfQU5ZKTsKIAlwZmlfaWZh ZGRyX2V2ZW50X2Nvb2tpZSA9IEVWRU5USEFORExFUl9SRUdJU1RFUihpZmFkZHJfZXZlbnQsCi0J ICAgIHBmaV9pZmFkZHJfZXZlbnQsIE5VTEwsIEVWRU5USEFORExFUl9QUklfQU5ZKTsKKwkgICAg cGZpX2lmYWRkcl9ldmVudCwgY3Vydm5ldCwgRVZFTlRIQU5ETEVSX1BSSV9BTlkpOwogfQogCiB2 b2lkCi1wZmlfY2xlYW51cCh2b2lkKQotewotCXN0cnVjdCBwZmlfa2lmICpwOworcGZfdW5pbml0 X2V2ZW50aGFuZGxlcnModm9pZCkgewogCiAJRVZFTlRIQU5ETEVSX0RFUkVHSVNURVIoaWZuZXRf YXJyaXZhbF9ldmVudCwgcGZpX2F0dGFjaF9jb29raWUpOwogCUVWRU5USEFORExFUl9ERVJFR0lT VEVSKGlmbmV0X2RlcGFydHVyZV9ldmVudCwgcGZpX2RldGFjaF9jb29raWUpOwpAQCAtMTU0LDcg KzE2MCwxMyBAQAogCUVWRU5USEFORExFUl9ERVJFR0lTVEVSKGdyb3VwX2NoYW5nZV9ldmVudCwg cGZpX2NoYW5nZV9ncm91cF9jb29raWUpOwogCUVWRU5USEFORExFUl9ERVJFR0lTVEVSKGdyb3Vw X2RldGFjaF9ldmVudCwgcGZpX2RldGFjaF9ncm91cF9jb29raWUpOwogCUVWRU5USEFORExFUl9E RVJFR0lTVEVSKGlmYWRkcl9ldmVudCwgcGZpX2lmYWRkcl9ldmVudF9jb29raWUpOworfQogCit2 b2lkCitwZmlfY2xlYW51cCh2b2lkKQoreworCXN0cnVjdCBwZmlfa2lmICpwOworCiAJVl9wZmlf YWxsID0gTlVMTDsKIAl3aGlsZSAoKHAgPSBSQl9NSU4ocGZpX2lmaGVhZCwgJlZfcGZpX2lmcykp KSB7CiAJCVJCX1JFTU9WRShwZmlfaWZoZWFkLCAmVl9wZmlfaWZzLCBwKTsKQEAgLTgxMSw5ICs4 MjMsNyBAQAogcGZpX2F0dGFjaF9ncm91cF9ldmVudCh2b2lkICphcmcgLCBzdHJ1Y3QgaWZnX2dy b3VwICppZmcpCiB7CiAKLQlDVVJWTkVUX1NFVCgoc3RydWN0IHZuZXQgKilhcmcpOwogCXBmaV9h dHRhY2hfaWZncm91cChpZmcpOwotCUNVUlZORVRfUkVTVE9SRSgpOwogfQogCiBzdGF0aWMgdm9p ZApAQCAtODIzLDEzICs4MzMsMTEgQEAKIAogCWtpZiA9IG1hbGxvYyhzaXplb2YoKmtpZiksIFBG SV9NVFlQRSwgTV9XQUlUT0spOwogCi0JQ1VSVk5FVF9TRVQoKHN0cnVjdCB2bmV0ICopYXJnKTsK IAlQRl9SVUxFU19XTE9DSygpOwogCVZfcGZpX3VwZGF0ZSsrOwogCWtpZiA9IHBmaV9raWZfYXR0 YWNoKGtpZiwgZ25hbWUpOwogCXBmaV9raWZfdXBkYXRlKGtpZik7CiAJUEZfUlVMRVNfV1VOTE9D SygpOwotCUNVUlZORVRfUkVTVE9SRSgpOwogfQogCiBzdGF0aWMgdm9pZApkaWZmIC0tZ2l0IGEv c3lzL25ldHBmaWwvcGYvcGYuYyBiL3N5cy9uZXRwZmlsL3BmL3BmLmMKLS0tIGEvc3lzL25ldHBm aWwvcGYvcGYuYworKysgYi9zeXMvbmV0cGZpbC9wZi9wZi5jCkBAIC03NTQsNyArNzU0LDcgQEAK IAogLyogUGVyLXZuZXQgZGF0YSBzdG9yYWdlIHN0cnVjdHVyZXMgaW5pdGlhbGl6YXRpb24uICov CiB2b2lkCi1wZl9pbml0aWFsaXplKCkKK3BmX3ZuZXRfaW5pdGlhbGl6ZSgpCiB7CiAJc3RydWN0 IHBmX2tleWhhc2gJKmtoOwogCXN0cnVjdCBwZl9pZGhhc2gJKmloOwpkaWZmIC0tZ2l0IGEvc3lz L25ldC9wZnZhci5oIGIvc3lzL25ldC9wZnZhci5oCi0tLSBhL3N5cy9uZXQvcGZ2YXIuaAorKysg Yi9zeXMvbmV0L3BmdmFyLmgKQEAgLTE0OTQsNyArMTQ5NCw5IEBACiBWTkVUX0RFQ0xBUkUoc3Ry dWN0IHBmX3J1bGVxdWV1ZSwgcGZfdW5saW5rZWRfcnVsZXMpOwogI2RlZmluZQlWX3BmX3VubGlu a2VkX3J1bGVzCVZORVQocGZfdW5saW5rZWRfcnVsZXMpCiAKLXZvaWQJCQkJIHBmX2luaXRpYWxp emUodm9pZCk7Cit2b2lkCQkJCSBwZl9pbml0X2V2ZW50aGFuZGxlcnModm9pZCk7Cit2b2lkCQkJ CSBwZl91bmluaXRfZXZlbnRoYW5kbGVycyh2b2lkKTsKK3ZvaWQJCQkJIHBmX3ZuZXRfaW5pdGlh bGl6ZSh2b2lkKTsKIHZvaWQJCQkJIHBmX210YWdfaW5pdGlhbGl6ZSh2b2lkKTsKIHZvaWQJCQkJ IHBmX210YWdfY2xlYW51cCh2b2lkKTsKIHZvaWQJCQkJIHBmX2NsZWFudXAodm9pZCk7CkBAIC0x NTkwLDcgKzE1OTIsNyBAQAogCSAgICBzdHJ1Y3QgcGZfYWRkciAqLCBzYV9mYW1pbHlfdCk7CiBp bnQJcGZfbWF0Y2hfcG9ydCh1X2ludDhfdCwgdV9pbnQxNl90LCB1X2ludDE2X3QsIHVfaW50MTZf dCk7CiAKLXZvaWQJcGZfbm9ybWFsaXplX2luaXQodm9pZCk7Cit2b2lkCXBmX3ZuZXRfbm9ybWFs aXplX2luaXQodm9pZCk7CiB2b2lkCXBmX25vcm1hbGl6ZV9jbGVhbnVwKHZvaWQpOwogaW50CXBm X25vcm1hbGl6ZV90Y3AoaW50LCBzdHJ1Y3QgcGZpX2tpZiAqLCBzdHJ1Y3QgbWJ1ZiAqLCBpbnQs IGludCwgdm9pZCAqLAogCSAgICBzdHJ1Y3QgcGZfcGRlc2MgKik7CkBAIC0xNjQ4LDcgKzE2NTAs NyBAQAogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZmlfa2lmICosCQkgcGZpX2FsbCk7CiAjZGVmaW5l CVZfcGZpX2FsbAkgCQkgVk5FVChwZmlfYWxsKQogCi12b2lkCQkgcGZpX2luaXRpYWxpemUodm9p ZCk7Cit2b2lkCQkgcGZpX3ZuZXRfaW5pdGlhbGl6ZSh2b2lkKTsKIHZvaWQJCSBwZmlfY2xlYW51 cCh2b2lkKTsKIHZvaWQJCSBwZmlfa2lmX3JlZihzdHJ1Y3QgcGZpX2tpZiAqKTsKIHZvaWQJCSBw Zmlfa2lmX3VucmVmKHN0cnVjdCBwZmlfa2lmICopOwoK --b1_53b75cd4fc6e337ad2e66310a0bd350c-- From owner-freebsd-virtualization@FreeBSD.ORG Fri Jun 19 12:18:09 2015 Return-Path: Delivered-To: freebsd-virtualization@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B170E85 for ; Fri, 19 Jun 2015 12:18:09 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DECA86BF for ; Fri, 19 Jun 2015 12:18:08 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t5JCI8uJ073450 for ; Fri, 19 Jun 2015 12:18:08 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t5JCI8t5073449; Fri, 19 Jun 2015 12:18:08 GMT (envelope-from daemon-user) Date: Fri, 19 Jun 2015 12:18:08 +0000 To: freebsd-virtualization@freebsd.org From: "robak (Bartek Rutkowski)" Reply-to: D1944+333+b09c6235d993877b@FreeBSD.org Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFWECIA= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 12:18:09 -0000 robak added a comment. Is there any chance to get these changes committed in time for 10.2-RELEASE? It would be great if we could have working VNET/PF before 11.0-R comes out... REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, kristof, gnn, glebius, rodrigc Cc: julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list