From owner-freebsd-current@freebsd.org Sun Jan 29 17:13:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3531CC7588; Sun, 29 Jan 2017 17:13:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AD14337; Sun, 29 Jan 2017 17:13:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-241-75.lns20.per4.internode.on.net [121.45.241.75]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0THDlUr000341 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 Jan 2017 09:13:51 -0800 (PST) (envelope-from julian@freebsd.org) To: freebsd-current , FreeBSD Stable From: Julian Elischer Subject: ldd linker script /usr/lib/libc.so fail Message-ID: <5278922c-a736-26ec-17a8-d9a1a684439e@freebsd.org> Date: Mon, 30 Jan 2017 01:13:42 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 17:13:59 -0000 Hi the linker script /usr/lib/libc.so fails when you are using the --sysroot options because it contains absolute paths. Does anyone know if there is a way to add the sysroot to the script? currently teh on ein our sysroot looks like: $ cat /usr/build/buildroot/tools/x86_FBSD1X_gcc4.2.4/usr/lib/libc.so /* $FreeBSD$ */ GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a /usr/lib/libssp_nonshared.a ) but I'd like to do something like: GROUP ( ${sysroot}/lib/libc.so.7 ${sysroot}/usr/lib/libc_nonshared.a ${sysroot}/usr/lib/libssp_nonshared.a ) but don't think I can do that from what I see below however it shouldn't be needed. Is this a bug in our version of ld? or am I misreading it? I quote from one such source : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/simple-commands.html ================================================ INPUT(file, file, …), INPUT(file file …) The INPUT command directs the linker to include the named files in the link, as though they were named on the command line. For example, if you always want to include subr.o any time you do a link, but you can't be bothered to put it on every link command line, then you can put INPUT (subr.o) in your linker script. In fact, if you like, you can list all of your input files in the linker script, and then invoke the linker with nothing but a -T option. In case a /sysroot prefix/ is configured, and the filename starts with the / character, and the script being processed was located inside the /sysroot prefix/, the filename will be looked for in the /sysroot prefix/. Otherwise, the linker will try to open the file in the current directory. If it is not found, the linker will search through the archive library search path. See the description of -L in Section 3.1 /Command Line Options/ . If you use INPUT (-lfile), ld will transform the name to libfile.a, as with the command line argument -l. When you use the INPUT command in an implicit linker script, the files will be included in the link at the point at which the linker script file is included. This can affect archive searching. GROUP(file, file, …), GROUP(file file …) The GROUP command is like INPUT, except that the named files should all be archives, and they are searched repeatedly until no new undefined references are created. ========================================= From owner-freebsd-current@freebsd.org Sun Jan 29 17:36:56 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B3BFCC7DB6; Sun, 29 Jan 2017 17:36:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D098135B; Sun, 29 Jan 2017 17:36:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-241-75.lns20.per4.internode.on.net [121.45.241.75]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0THap9Y000435 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 Jan 2017 09:36:54 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: [IGNORE] ldd linker script /usr/lib/libc.so fail [IGNORE] To: freebsd-current , FreeBSD Stable References: <5278922c-a736-26ec-17a8-d9a1a684439e@freebsd.org> From: Julian Elischer Message-ID: <4439daf4-4173-110d-bd15-d144fed91ceb@freebsd.org> Date: Mon, 30 Jan 2017 01:36:45 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <5278922c-a736-26ec-17a8-d9a1a684439e@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 17:36:56 -0000 Tracked this down to a rogue copy of libc.so in an unexpected place which was being found earlier than the real one. On 30/1/17 1:13 am, Julian Elischer wrote: > Hi > > the linker script /usr/lib/libc.so fails when you are using the > --sysroot options because it > > contains absolute paths. > > > Does anyone know if there is a way to add the sysroot to the script? > > currently teh on ein our sysroot looks like: > > $ cat /usr/build/buildroot/tools/x86_FBSD1X_gcc4.2.4/usr/lib/libc.so > /* $FreeBSD$ */ > GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a > /usr/lib/libssp_nonshared.a ) > > but I'd like to do something like: > > GROUP ( ${sysroot}/lib/libc.so.7 ${sysroot}/usr/lib/libc_nonshared.a > ${sysroot}/usr/lib/libssp_nonshared.a ) > > but don't think I can do that > > from what I see below however it shouldn't be needed. > > Is this a bug in our version of ld? or am I misreading it? > > > I quote from one such source : > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/simple-commands.html > > > ================================================ > INPUT(file, file, …), INPUT(file file …) > > The INPUT command directs the linker to include the named files in > the link, as though they were named on the command line. > > For example, if you always want to include subr.o any time you do > a link, but you can't be bothered to put it on every link command > line, then you can put INPUT (subr.o) in your linker script. > > In fact, if you like, you can list all of your input files in the > linker script, and then invoke the linker with nothing but a -T > option. > > In case a /sysroot prefix/ is configured, and the filename starts > with the / character, and the script being processed was located > inside the /sysroot prefix/, the filename will be looked for in > the /sysroot prefix/. Otherwise, the linker will try to open the > file in the current directory. If it is not found, the linker will > search through the archive library search path. See the > description of -L in Section 3.1 /Command Line Options/ > . > > > If you use INPUT (-lfile), ld will transform the name to > libfile.a, as with the command line argument -l. > > When you use the INPUT command in an implicit linker script, the > files will be included in the link at the point at which the > linker script file is included. This can affect archive searching. > > GROUP(file, file, …), GROUP(file file …) > > The GROUP command is like INPUT, except that the named files > should all be archives, and they are searched repeatedly until no > new undefined references are created. > > ========================================= > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@freebsd.org Tue Jan 31 23:30:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D3D34CCA4FF for ; Tue, 31 Jan 2017 23:30:31 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) (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 8EC861990 for ; Tue, 31 Jan 2017 23:30:31 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from amavis-ori.ijs.si (localhost [IPv6:::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.ijs.si (Postfix) with ESMTPS id 3vCjBs726Tz1QD for ; Wed, 1 Feb 2017 00:29:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:from:from:date:date:content-transfer-encoding :content-type:content-type:mime-version:received:received :received:received; s=jakla4; t=1485905346; x=1488497347; bh=y6q S5Q03dBODpKlDOGIiXnOniZDCzalpd55P1R+z1FE=; b=nvBfBewsn93DWx4y/QT Cb4I3JAKz8JXZ3V3pwThrcsTZpih78R0BZrD+ngHu7uq961cIGnJ/qWtcgliOgwq xCMvLAua1iFFqTt/BsBv8Dw1TKItzIheqctcYqMBOjRbCLNiexW1r/R+EqDkTr+o KkzKRN5ApCMsqv3KydD8gbcg= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10026) with LMTP id bDWl7k9mhSkC for ; Wed, 1 Feb 2017 00:29:06 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP id 3vCjBp2TVtz1QC for ; Wed, 1 Feb 2017 00:29:06 +0100 (CET) Received: from nabiralnik.ijs.si (nabiralnik.ijs.si [IPv6:2001:1470:ff80::80:16]) by mildred.ijs.si (Postfix) with ESMTP id 3vCjBp1gJ8z6V for ; Wed, 1 Feb 2017 00:29:06 +0100 (CET) Received: from neli.ijs.si ([193.2.4.95]) by webmail.ijs.si with HTTP (HTTP/1.1 POST); Wed, 01 Feb 2017 00:29:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Feb 2017 00:29:06 +0100 From: Mark Martinec To: freebsd-current@freebsd.org Subject: Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat Organization: Jozef Stefan Institute In-Reply-To: References: Message-ID: X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:30:31 -0000 2017-01-27 01:09, Allan Jude wrote: > Yeah, most of the size is from the GELI support, not Skein, so that is > your best starting place. On a tangential ... does the gptzfsboot really support skein checksums in 11.0? If so, then why does zfs not allow setting skein on a root pool? # zfs set checksum=skein xxx cannot set property for 'xxx': property setting is not allowed on root pools Mark From owner-freebsd-current@freebsd.org Tue Jan 31 23:44:17 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F73ECCAE48 for ; Tue, 31 Jan 2017 23:44:17 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA8CAE5 for ; Tue, 31 Jan 2017 23:44:17 +0000 (UTC) (envelope-from arcade@b1t.name) Received: by mailman.ysv.freebsd.org (Postfix) id 5844CCCAE47; Tue, 31 Jan 2017 23:44:17 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56444CCAE46 for ; Tue, 31 Jan 2017 23:44:17 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from limbo.b1t.name (limbo.b1t.name [78.25.32.206]) (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 A7A23AE4 for ; Tue, 31 Jan 2017 23:44:15 +0000 (UTC) (envelope-from arcade@b1t.name) Received: from [172.29.1.53] (probe.42.lan [172.29.1.53]) by limbo.b1t.name (Postfix) with ESMTPSA id 623757D for ; Wed, 1 Feb 2017 01:44:09 +0200 (EET) Subject: Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat References: <444df1a4-1f27-49a8-6fa6-81f5853e6d80@freebsd.org> <20170127173338.wv6dul7zhxaaw4f4@mutt-hardenedbsd> From: Volodymyr Kostyrko To: "current@freebsd.org" Message-ID: Date: Wed, 1 Feb 2017 01:44:06 +0200 User-Agent: Mozilla/5.0 (X11; DragonFly x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: <20170127173338.wv6dul7zhxaaw4f4@mutt-hardenedbsd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Feb 2017 02:38:18 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:44:17 -0000 Shawn Webb wrote: > On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote: >> On 2017-01-27 12:05, Warner Losh wrote: >>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome wrote: >>>> >>>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) wrote: >>>>> >>>>> Hi, >>>>> I tried upgrading one of my workstations and unfortunately the freebsd-boot partition is too small (I follow manpage directions, exactly, and those seem to be too small as of 10.3-RELEASE timeframe), and I don???t have enough space or ability to resize the partition and make it bigger. So, I???m in need of a build knob to control the bloat, and/or having an alternative boot loader without geli/skein/crypto support compiled in. Would you be opposed to the work? >>>>> Thanks, >>>>> -Ngie >>>> >>>> >>>> I do agree that since the geli knob is already there, it may do. Of course we also can think of additional knobs, but there is an issue - it wont help just to exclude some files, the additional features also do sit in the code, so the replacement stubs will be needed, also testing them all over will take some time. And the preprocessor spaghetti really is nasty thing to deal with;) >>>> >>>> And then there is another issue (partly why I did the feature support in first place) - as the kernel does not block user from enabling the features, the user can end up facing non-bootable setup which is also not good, as user is using perfectly legal options, and still the whole thing is just rendered unusable??? >>> >>> I'm curious why you can't find the space for a bigger partition? >>> Almost all drives these days are partitioned with a little wasted >>> space, and that wasted space should be more than enough to cover us >>> here. Also, most drives have a swap partition that can be shrunk a >>> trivial amount to get space for this... >>> >>> Warner >>> >> >> I need to do some testing to make a recipe that works for it, but the >> other option is to use the ZFS bootcode area. >> >> ZFS it self, reserves something like 3.5 mb of space in the ZFS >> partition, for boot code. This is how we boot ZFS on MBR. >> >> It should be possible to use this on GPT as well, we just don't. > > In the future, maybe it'd be a good idea for the installer to leave > more space (a few MB, perhaps?) between the freebsd-boot and > freebsd-swap partitions? At least, for ZFS installs. This would do anything. If you have swap after the boot partition you always can drop the swap, make larger boot and create the swap back on the free space. -- Sphinx of black quartz judge my vow. From owner-freebsd-current@freebsd.org Wed Feb 1 09:09:19 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20764CCAE35 for ; Wed, 1 Feb 2017 09:09:19 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EEA2C1F9A for ; Wed, 1 Feb 2017 09:09:18 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OKO00J00ULVQ400@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Wed, 01 Feb 2017 09:09:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1485940152; bh=GLIopJ/i1tKKYP9dF9OS8Z3uuI5RPt5c1A3uJxBht7k=; h=From:Content-type:MIME-version:Subject:Message-id:Date:To; b=jt+TVsrHU4w4GAxvRvu660du8xyIv36NyokhozIbQWnMGqPSn5lL3YNukuxmJBH4G luf+Fc5TdLDapwK3WzMrGTzuPexJXjGXT64LTBkAQYJxAGsvRuKqX/keoa10jnDRgJ L8KidPCuOj+2o35e+oFKv87IzT8zspkRyr1xvYwdtfVSqmc2SUyIkqCYRWByFFGdKm Ya1kWftkdnSv9+6YfhXEwQUm5m4wId5azCq8cZTWciQyolrY/2QB4IdtfTb5mJc/Gj kE5+Kx177ZWdCqwaVmypTMYh3JGaNhTTR394xuO/QlRFR3LFPVbuzhKbl3lpuYRBo7 6BMHutJqYbiHg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OKO0091QURACN30@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Wed, 01 Feb 2017 09:09:12 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-01_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702010091 From: Toomas Soome MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: review: loader: disk/part api needs to use uint64_t offsets Message-id: Date: Wed, 01 Feb 2017 11:09:11 +0200 To: FreeBSD CURRENT X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 09:09:19 -0000 Hi! I would like to have some eyes on https://reviews.freebsd.org/D8710 = :) thanks, toomas= From owner-freebsd-current@freebsd.org Wed Feb 1 09:21:50 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0BD6CCB31C for ; Wed, 1 Feb 2017 09:21:50 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DDF3B1D for ; Wed, 1 Feb 2017 09:21:46 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lx4dh-1cNUIA32vx-016j7Q; Wed, 01 Feb 2017 10:21:35 +0100 Date: Wed, 1 Feb 2017 10:21:28 +0100 From: "O. Hartmann" To: freebsd-poudriere@freebsd.org, freebsd-current@freebsd.org Subject: install jail from precompiled world fails due to different MAKEDIROBJPREFIX Message-ID: <20170201102128.5073182b@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:g97o/070hwqCoC1aTw6WL5gtnDVUQNo7bdGrLDNMgwNZc4i/leC i5IYUIQHw0pL/shEV/CkuiGwTvE9JIa0Tzn/HuWw22im6SL7xJWVXzmr8nY0xPN8PCIS76N 2ouMh0j0NpNhvvUnr3JJLS83JStWgFYaZzepg0oN860j6AzVmDwqbiWxDU1/9BR69yE/h8l qt0qkgmo54Xhz4QzHA5Kg== X-UI-Out-Filterresults: notjunk:1;V01:K0:kiLvXD/nobg=:+3yNU4CJtEGnd5A6YBOcOs 8YNWk/xd6RC+KMmVgGD0cSNmkjVbLtKij9pDxonIqqX6ImkJe2FooL2dprpNHJd5ExeZncytM 6zhPLZOSp6LpJVuZVjub6kTOgpj245vDpgl1qdivc/m1T6kuNtk4RpFBqInFZtEI0Vysi834O o6cONS7oqEY/KsBgnD/CwnrmH5phtqv6rdJx9ctPdU8DggkXCqVSQMddrctpx40k5TCzXSN7N MUEEB6ExC8U5OQFMDi7qjewGR6ArHYUvftZ8Y7JIAcKDvRMjBi1ArmfwWLF+edsudZVthSM0c AeBrCE1fgm1Azvd3OKEs4kwgAPnoDBBJZuy/a8B+31jFLXq7ZJSUq3l5WiL9F7Sokoxdq8sd+ /uwcMhz/UXMaB6GvVAFeSgTCrpOQRyiP15uDMXqlOfWp2jh843F6bUZs1oamryKbOlJozL3QO wu0Jvojv6UM6DsTLIVvm9Vq99vVb1K6r02No3b7JXnSTOTBq8hYZ0EqD/v1XmK9CjpsteQ6Z0 tiAaIqqfAprG888+ROC6i2LVoRJpIBZubMRigg2N/E+o3KRy3aFuBzxD99Lhw5lZI00qPt95n ZsPV+KJbYJd8svX2hgqbxf3S9VbjJWiCqJTznNgAxb7rLsGsv9Pp4P2CtTQyrBFRpY63HC64z WOh2U0vwbrIYwWKJ6p9LDV6RsecYSboejRVsZIJPJ5Qu+3G2JI/RO6yZgAKeRaTlv72L5EHHA sKP8ANZToPG1Ej6t37dIeYlc+9k5zrZceDQRh39sBMpwQLw8j2ANsAcF0gBQZ1eeQv0RvWe3s /ISCkeUG+BX566DA7gH9wfDxbidNtT3B7ZlcyCzlQiIFOIuycRVg1zqFHnhRuppw9RdSIO/aA i7Ifbc3ARfm/iZEQDzZ+1/PX2OHmMdFfTxsdtASqdQv2y3/84UX1/ehrYqax7EJBtUSQO7ivj uZhtmdg5viFy8SWRDUNbUTfA87rXrun15ZdQG7lX3bj73KzX3X9BgbI6l+5POMTqe9y9E5iHD bxY65Coq/4Ta7qy4Gye3Pqv94nRyLrw+50cRPb6TMmSGR2PJYeUIuPkhE3nw3/7QBQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 09:21:51 -0000 For several projects managed with NanoBSD I need different source trees (10.3, 10-STABLE, 11-STABLE, CURRENT). The source resides in /foo/bar/CURRENT/src or /foo/bar/10.3-RELEASE/src. For the build of AARCH64 ports, I have also already built CURRENT for arm64.aarch64. ARM64 buildworld is sensitive to compiler optimisation, libc fails to build if -O3 is set (which is _my_ standard on AMD64, given in /etc/src.conf). Since I do not want to have a waste of space, /foo/bar/CURRENT/src holds CURRENT sources and with MAKEOBJDIRPREFIX=/foo/bar/CURRENT/obj/arm64 set a conflicting libc issue (as mentioned above) can be avoided from a prebuild AMD64 world. My thinking was, that "make TARGET=arm64 buildworld" will not use /foo/bar/CURRENT/obj, but rather /foo/bar/CURRENT/obj/arm64.aarch64 as the base for the resulting world, but this is a mistake. So, setting MAKEOBJDIRPREFIX=/foo/bar/CURRENT/obj/arm64 is a way out of this dilemma. In any environment capable of taking MAKEOBJDIRPREFIX there is no problem, but with poudriere, I have unexpected trouble. I need to install the world for arm64.aarch64, therefore, I ran in the first place the command as follows to install a jail(while believeing /foo/bar/CURRENT/obj/arm64.aarch64 is the base of the world for arm64 target): poudriere jail -c -v head -j arm64 -m src=/foo/bar/CURRENT/src -M /somewhere/in/the/tree That fails, since /foo/bar/CURRENT/obj contains the AMD64 world and /foo/bar/CURRENT/obj/arm64.aarch64 seems to be insufficient respected. Wasn't the idea of /usr/src and /usr/obj to have one source tree, but different trees for the resulting world and kernel? A "native" build on AMD64 doesn't go into /usr/obj/amd64, it has its root at /usr/obj, but for the cross compiled world, it is then /usr/obj/arm64.aarch64. The problem then starts to get critical for poudriere. I neither do not want to compile a fresh world via setting -m svn+https nor do I want to installed precompiled binaries from remote. I already have(!) a successfully built word, so all I need seems to apply the right delegatin of that what "MAKEOBJDIRPREFIX" represents. Am I missing here something or is poudriere not capable of handling this view? Thank you in advance, Oliver From owner-freebsd-current@freebsd.org Wed Feb 1 09:54:12 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9DC0CCBA97 for ; Wed, 1 Feb 2017 09:54:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52B0E1AAA for ; Wed, 1 Feb 2017 09:54:11 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhB9P-1c5G9649mJ-00oVet; Wed, 01 Feb 2017 10:54:04 +0100 Date: Wed, 1 Feb 2017 10:54:02 +0100 From: "O. Hartmann" To: "O. Hartmann" Cc: freebsd-poudriere@freebsd.org, freebsd-current@freebsd.org Subject: Re: install jail from precompiled world fails due to different MAKEDIROBJPREFIX Message-ID: <20170201105402.0a0ad09c@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170201102128.5073182b@freyja.zeit4.iv.bundesimmobilien.de> References: <20170201102128.5073182b@freyja.zeit4.iv.bundesimmobilien.de> Organization: Walstatt X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:4smS+6wWAtji6lxn7jTMY9+/V1xvX0az18WQU5jS4ja71q9R83i tV4kykS/gglgqTfkO7dkBAJFzd8QE1+WqF8j9dz5kHO3Wt8jx4DlDD+GObQkZio9PVg7NcQ uZfeUnjRrZsaupN1JwzikKgeKJPXlJoM674cpye/aDQsPw+ANUCz+JhBDv1wYy7sMNabXIX DBIE0vAlzZd9umfHHk9nQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:JA3tKXaRp6Y=:W6fCFEnCoZlqkAKSOGU/iY Enzmu0OPqurhlpmZxSTHvqiBUAGWmvXieTW4f22rP9kT0wjVgm3mKJ7BbxodJndZB9MZkn/My 8qAnEJOqyomsIVe9BUqy4YlLv9HsZebV3zxH2Ni5YSZd4ftdBiEzNDeZ2YeszalwDygFIlkrw btnbo5DNHpJhvv9dUHPutEMQDx1xuoSdF1O6+LXuW09B/dNeIsLbk6+XfTqXm1kTaJtolIeiH TaHDBnt8DUMEKmZ7uzmvFfHhPDSMvadvJ7rzJElnsffnAQpUrqSanMdNqTflX/PlpOBStzYQJ 8J3FMUtTArCXFUib+5v7bFe3HnB0Z1ESjBZCm49TUJ4UzW062wMxyThjWZc2dOX8wvc4MxieU Y8oamkAEfbVPQQuff2IMiYD/NI4e7LfBJCH1iuXUo/gQPgicO64NIyALYQC8qYMI8lr6KRzti fV3gRyE84I/Q2bzHtm2moodpUIeaHW+SkEGeeuj2osNf3oD6UKi6yMwOYe1jmw3/6l3fBscOg V8hW/DTpEJMQ/ehfWIU5wTuOdFUTW7o2zJRsyAzj4JzS+fuyvMHHdu2RHjs7VaolWM5xrSxEl P5fSbA/Y0671E9Q0IBdR8dTgIkVUahDS+YoF2CzORi6Y1ghbcQ57ZVSQjyPQ2PacZF/b/T6NC ERceNXfJE9BQzlXTxeMSDq7LFT03GHAIqfmakLxsXG/c2zubj5snJrp8fD6m7b4TY7/wrjL0C s/ZrjO1DK68Ti7TsADc992kER9/6MtAbIcGka5deSFEIgtDJ2Z4qT9sJJXzHnJqS14AEtg+fR /nopPVb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 09:54:12 -0000 On Wed, 1 Feb 2017 10:21:28 +0100 "O. Hartmann" wrote: > For several projects managed with NanoBSD I need different source trees (10.3, > 10-STABLE, 11-STABLE, CURRENT). The source resides in /foo/bar/CURRENT/src > or /foo/bar/10.3-RELEASE/src. > > For the build of AARCH64 ports, I have also already built CURRENT for > arm64.aarch64. > > ARM64 buildworld is sensitive to compiler optimisation, libc fails to build > if -O3 is set (which is _my_ standard on AMD64, given in /etc/src.conf). > Since I do not want to have a waste of space, /foo/bar/CURRENT/src holds > CURRENT sources and with MAKEOBJDIRPREFIX=/foo/bar/CURRENT/obj/arm64 set a > conflicting libc issue (as mentioned above) can be avoided from a prebuild > AMD64 world. My thinking was, that "make TARGET=arm64 buildworld" will not > use /foo/bar/CURRENT/obj, but rather /foo/bar/CURRENT/obj/arm64.aarch64 as > the base for the resulting world, but this is a mistake. So, > setting MAKEOBJDIRPREFIX=/foo/bar/CURRENT/obj/arm64 is a way out of this > dilemma. > > In any environment capable of taking MAKEOBJDIRPREFIX there is no problem, > but with poudriere, I have unexpected trouble. > > I need to install the world for arm64.aarch64, therefore, I ran in the first > place the command as follows to install a jail(while > believeing /foo/bar/CURRENT/obj/arm64.aarch64 is the base of the world for > arm64 target): > > poudriere jail -c -v head -j arm64 -m src=/foo/bar/CURRENT/src > -M /somewhere/in/the/tree > > That fails, since /foo/bar/CURRENT/obj contains the AMD64 world > and /foo/bar/CURRENT/obj/arm64.aarch64 seems to be insufficient respected. > > Wasn't the idea of /usr/src and /usr/obj to have one source tree, but > different trees for the resulting world and kernel? A "native" build on AMD64 > doesn't go into /usr/obj/amd64, it has its root at /usr/obj, but for the > cross compiled world, it is then /usr/obj/arm64.aarch64. > > The problem then starts to get critical for poudriere. I neither do not want > to compile a fresh world via setting -m svn+https nor do I want to installed > precompiled binaries from remote. I already have(!) a successfully built word, > so all I need seems to apply the right delegatin of that what > "MAKEOBJDIRPREFIX" represents. > > Am I missing here something or is poudriere not capable of handling this view? > > Thank you in advance, > > Oliver > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Assuming a prebuild world for arm64.aarch64 at /pool/sources/CURRENT/src and have this path given to poudriere with option "-m src=" when creating the jail, I get this error message: [...] -------------------------------------------------------------- >>> Installing everything -------------------------------------------------------------- cd /pool/sources/CURRENT/src; make -f Makefile.inc1 install ===> lib (install) ===> lib/csu (install) ===> lib/csu/aarch64 (install) cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/pool/sources/CURRENT/src/tmp -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -O3 -O3 -I/pool/sources/CURRENT/src/lib/csu/common -I/pool/sources/CURRENT/src/lib/libc/include -DNDEBUG -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments ERROR-tried-to-rebuild-during-make-install -S -o crt1.s /pool/sources/CURRENT/src/lib/csu/aarch64/crt1.c /tmp/install.RHDj388k/sh: cc: not found *** Error code 127 [...] See the systroot=usr/obj/arm64.aarch64/pool/sources/CURRENT/src/tmp which is definitely wrong. The command sequence in full detail is: poudriere jail -cj headarm64 -v head -a arm64.aarch64 -m src=/pool/sources/CURRENT/src From owner-freebsd-current@freebsd.org Wed Feb 1 14:31:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EC6FCCBD41 for ; Wed, 1 Feb 2017 14:31:30 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5BD3D2 for ; Wed, 1 Feb 2017 14:31:29 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from localhost ([83.193.128.235]) by mwinf5d42 with ME id fSPq1u00A54s3Hf03SPqKe; Wed, 01 Feb 2017 15:23:51 +0100 X-ME-Helo: localhost X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI= X-ME-Date: Wed, 01 Feb 2017 15:23:51 +0100 X-ME-IP: 83.193.128.235 To: FreeBSD Current Cc: FreeBSD-STABLE Mailing List From: Claude Buisson Subject: Recent FreeBSD, NFSv4 and /var/db/mounttab Message-ID: <20c2baca-ba91-19b4-db95-5352b56019c1@orange.fr> Date: Wed, 1 Feb 2017 15:23:49 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:31:30 -0000 Hi, Last month, I started switching all my systems (stable/9, stable/10, stable/11 and current) to NFSv4, and I found that: on current (svn 312652) an entry is added to /var/db/mounttab by mount_nfs(8), but not suppressed by umount(8). It can be suppressed by rpc.umntall(8). The same anomaly appears on stable/11 after upgrading to svn 312950. It is relatively easy to trace this anomaly to r308871 on current and its MFHs (r309517 for stable/11). Patching sbin/umount/umount.c to restore the RPC call for NFSv4 makes umount(8) suppress the mounttab entry as before. I do not know what is the proper solution, as suppressing the modification of mounttab by mount_nfs(8) for NFSv4 could be an (more complicated) alternative ! Thanks for your attention, Claude Buisson From owner-freebsd-current@freebsd.org Wed Feb 1 21:05:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8B6CCCC60D for ; Wed, 1 Feb 2017 21:05:40 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st13p35im-asmtp001.me.com (st13p35im-asmtp001.me.com [17.164.199.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B19B51720 for ; Wed, 1 Feb 2017 21:05:40 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.st13p35im-asmtp001.me.com by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OKP00H00RRH3V00@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Wed, 01 Feb 2017 21:05:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1485983108; bh=UK2d9ggjE8stduKR0SRwNH0cxqYmg68lj/CwzeNko88=; h=From:Content-type:MIME-version:Subject:Message-id:Date:To; b=S/6CMSrQlGsFLS5iNVaKy73Wz6atalwUwP1Lu13uLvq3VG5PQPo4yBJtg/KHaw89i e5EwWdo7qlEa54yV7diFxAd/WqOTfrGRktSVHIUZ50ce7lugyZqurg1pAjY9R16lE5 C1JHlMi8WYDPznw5Y/e/SpDufwi2iBjG8qVC3ctBQcUabS1T4Q+8vhlxN6wYujv12t 1AYkAvkItcw2qK/gQtP0Awsi9hX8GI3TBn31+WBVb7LomB7sYeblZJEpNlG5r+iXaE eBcQyh9q24X87ofSH5IT3KksshdbONGteFldgt8Gej7VTSgQFOt/jZPz9HkzIumyxD Cm5gNH5GFOAWg== Received: from icloud.com ([127.0.0.1]) by st13p35im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OKP00DZHRWI1H30@st13p35im-asmtp001.me.com> for freebsd-current@freebsd.org; Wed, 01 Feb 2017 21:05:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-01_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702010207 From: Toomas Soome MIME-version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: review: Implement disk_ioctl() to support DIOCGSECTORSIZE and DIOCGMEDIASIZE. Message-id: <35CEF160-0615-4A8C-82B1-8A895FD527C7@me.com> Date: Wed, 01 Feb 2017 23:05:05 +0200 To: FreeBSD CURRENT X-Mailer: Apple Mail (2.3259) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:05:40 -0000 Hi! Looking for more eyes on: https://reviews.freebsd.org/D8594 = thanks, toomas= From owner-freebsd-current@freebsd.org Wed Feb 1 21:49:15 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40815CCB92E; Wed, 1 Feb 2017 21:49:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670082.outbound.protection.outlook.com [40.107.67.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EC73EDAA; Wed, 1 Feb 2017 21:49:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Wed, 1 Feb 2017 21:49:12 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0874.021; Wed, 1 Feb 2017 21:49:12 +0000 From: Rick Macklem To: Claude Buisson , FreeBSD Current CC: FreeBSD-STABLE Mailing List Subject: Re: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Topic: Recent FreeBSD, NFSv4 and /var/db/mounttab Thread-Index: AQHSfJfpteLPu545NESwV/c/JyXxzaFUr0tB Date: Wed, 1 Feb 2017 21:49:12 +0000 Message-ID: References: <20c2baca-ba91-19b4-db95-5352b56019c1@orange.fr> In-Reply-To: <20c2baca-ba91-19b4-db95-5352b56019c1@orange.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: f1dafccb-6ce1-4b13-4fa7-08d44aec28ca x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0189; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0189; 7:G/FvNf6N6gdavP23DJnat0zCSG2ionBfpWS8ahuA2kxPxrMTankMWpP4gVDojZkza1UlyDbxuXsBHCCyiBI7NrrBkPHMarOIaO7joWG/9TgfDx+nAv+x5fpsjwxQfqeBXgEQtnOayGzPX9hrg4HYIolblNS5aeOu9MqwmyZrDe1CtVG8/xxXJtSXXkpFuDhg5WI+PJSXD29DSUzvaRjSIJx+g4CPHwNPiwUKyM2MoR8ZrjfYWVSE+RK2vSqWBMQpJs+dwXAwnpOzXaaeEsqqvyZotI8uK3jjuk78vN2JwLRZL86Jo1Sxcdxdwb5Arf+3R3aX62wHxB2KxKEMb+zIFRDLw1bsTxtNRjlPDZl1mDnYLm2cg76eSRv8kvbYhHSSmqF486+4vT9eagcCFeBpMgmBCLOwXLglAh44SlV6qlOJ2PNw/tsOK53ALIhwjOICFP5+AknI6NLGCOo52d/7LV/duxxnFEah+rfwnvBEj1e2FJUUq7PFrCOB5zn77xDy9okX28GcgIJncROaB7P5IjeQLqptCK4OJ8O9LDvMZwRomIsGw/G6rUSa7Kfq5lbp x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558025)(20161123555025)(6042181)(6072148); SRVR:YTXPR01MB0189; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0189; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(199003)(2906002)(305945005)(53936002)(3280700002)(81156014)(50986999)(106116001)(101416001)(8936002)(74316002)(9686003)(105586002)(229853002)(76176999)(54356999)(6436002)(38730400001)(77096006)(6506006)(33656002)(55016002)(81166006)(4326007)(74482002)(106356001)(92566002)(68736007)(102836003)(2900100001)(3660700001)(97736004)(2950100002)(122556002)(7696004)(5660300001)(86362001)(8676002)(5001770100001)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0189; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 21:49:12.1695 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0189 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 21:49:15 -0000 Claude Buisson wrote: >Hi, > >Last month, I started switching all my systems (stable/9, stable/10, >stable/11 and current) to NFSv4, and I found that: > > on current (svn 312652) an entry is added to /var/db/mounttab by >mount_nfs(8), but not suppressed by umount(8). It can be suppressed by >rpc.umntall(8). > >The same anomaly appears on stable/11 after upgrading to svn 312950. > >It is relatively easy to trace this anomaly to r308871 on current and >its MFHs (r309517 for stable/11). > >Patching sbin/umount/umount.c to restore the RPC call for NFSv4 makes >umount(8) suppress the mounttab entry as before. > >I do not know what is the proper solution, as suppressing the >modification of mounttab by mount_nfs(8) for NFSv4 could be an (more >complicated) alternative ! This would be the correct fix. The entries in mounttab are meaningless. Even for NFSv3, all they do is provide a "best guess" answer for "showmount". - The Mount protocol is not part of NFSv4. I had a patch which disabled it for NFSv4 servers, but some folk liked the idea of having "showmount -= e" to work, so I didn't commit it. rick ps: I had actually thought mount_nfs(8) didn't do a Mount protocol RPC for NFSv4, but I guess it is. That needs to be fixed, since NFSv4 ser= vers don't need to support Mount at all. From owner-freebsd-current@freebsd.org Wed Feb 1 23:53:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8225BCCCDE7 for ; Wed, 1 Feb 2017 23:53:42 +0000 (UTC) (envelope-from brunolauze@msn.com) Received: from BAY004-OMC3S15.hotmail.com (bay004-omc3s15.hotmail.com [65.54.190.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55033819 for ; Wed, 1 Feb 2017 23:53:42 +0000 (UTC) (envelope-from brunolauze@msn.com) Received: from NAM01-BN3-obe.outbound.protection.outlook.com ([65.54.190.189]) by BAY004-OMC3S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 1 Feb 2017 15:52:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tkoGV4UQ5byC6H1vzBm6QM09V+FnoJCr1IguS12C6VU=; b=QSfCL2Zoz6jJj3/l67x8uEn7GlMjenmdVzNH4C+RQZC6a8EjyazsWcw623q4dD1dAmhAVc1Jd6Y8jyMMOa8Jbdj++QgPo4uUT6Zq9H+nNqpCxyV1jjs2Wh3WCE4+pzvQWMoI7BoKDV/9OF6lxBSIAynNYqPQTKPontlUXe1WwoqU3h65UBlipO0jpo8XyT0CvBfzi+imZxqHRRXSjYe9yoAPORCRzpYZ+dKeDvlhgt/34wFECe0SEbRHJQOAt1RGFmfeXRSLgRn68DL218io5GiJGwEqn3jEkfqHi1M0fJi1M/srdkAw3BUpSaJyCiMtyq+by0Uw6vxAobbOL0wWHQ== Received: from BN3NAM01FT021.eop-nam01.prod.protection.outlook.com (10.152.66.59) by BN3NAM01HT017.eop-nam01.prod.protection.outlook.com (10.152.67.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2; Wed, 1 Feb 2017 23:52:35 +0000 Received: from SN1PR16MB0640.namprd16.prod.outlook.com (10.152.66.58) by BN3NAM01FT021.mail.protection.outlook.com (10.152.67.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2 via Frontend Transport; Wed, 1 Feb 2017 23:52:35 +0000 Received: from SN1PR16MB0640.namprd16.prod.outlook.com ([10.165.28.138]) by SN1PR16MB0640.namprd16.prod.outlook.com ([10.165.28.138]) with mapi id 15.01.0845.028; Wed, 1 Feb 2017 23:52:34 +0000 From: =?iso-8859-1?Q?Bruno_Lauz=E9?= To: freebsd-current Subject: mlock and jail Thread-Topic: mlock and jail Thread-Index: AQHSfOM6KDHfJeZzq062UKsd7j9HtA== Date: Wed, 1 Feb 2017 23:52:34 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=msn.com; x-incomingtopheadermarker: OriginalChecksum:0A7C5C85C0664DDBDFC555AB0E4B0D9D1063D7B63D8B5DD1851F3541ED15938B; UpperCasedChecksum:67CDEE3200D0C79DA8F8A0DA48945EC026213CF93DD49146B5CE7693BB7F0AC0; SizeAsReceived:7555; Count:37 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [tkGCwxlKCD7l2rFPzkSZzYuOwZ5NOJyI] x-incomingheadercount: 37 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BN3NAM01HT017; 5:alaCBE/NgyxOOVn2bW++irwKZsF/ViN2Jg30vjcWiFr5HV8gLqVm42AAQ7CWFctGo5NZRCz+8DXj0Cc0jkzWYII4n135OMaRPsSyOy0/8dyhrwYr488dJza33Hr//l+2DxII12xd8+DzE6tp4X7NCc/Q2Z6h9wTWdAEcEzJjf1Q=; 24:U8hbPDXTFDEKqs4zsIfrCTaQgYUc/Su4ZJ4AVLbL53ZYivOv6LuIN327F/MoO7Getkz+hIsI04dwVqwsX4M/nn0rl2IqOHzPUhqOirfXnIo=; 7:YvFLRkdO5CXhV6rSwfuAQMprCFVtalGYJ8/0jxmUfivJWZpdmceDZo88G41vjROImywT/vcYANEoSwOqjTLSBhi2llwDLT/rxJCsDrE5HtxpdUO55RGxiFYVDMQZ0niCTIpmH1WDaWuHhzLahOeXXkV4yi5y6eq6GMgJ4jHdr7F53A40R8W3islWMP6KE7ITT1mWfQIYwmweApSxa3aMw9iUzAUXtbi1Y3ozEdDs9p6DLFHxbOdLXjhe9f7+ISrNXB7xlkUo9sFybTiDAi3nwVPwDT39wjYj79JmXa3gw5igu2ekU3I+NUzNIMdmhaArMXH7yLpL4Ow0yxKd3PcwqoxSGA015cALeDRYkFVl320H6Ok4/dW72hMECeA7qrEyMhvv65Xh8a2gNaD/ya9oWq8AlLemDGWaudADQt8d6GmYrQSyXs6bS2TSa8tE57L3We1GwIXyVwBYfyT7Wv1gM3tvlRBMZPhJyYeT1YCvUPQ4Lx7A6VBUygV6R0J0gwt1niLQD8+yVkm/tUbMqcbToA== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM01HT017; H:SN1PR16MB0640.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 55688abd-c3cf-45f2-893c-08d44afd651f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(5061506344)(1603103128)(1601125047)(1603101355)(1701031038); SRVR:BN3NAM01HT017; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(432015012)(82015046); SRVR:BN3NAM01HT017; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT017; x-forefront-prvs: 0205EDCD76 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 23:52:34.8423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT017 X-OriginalArrivalTime: 01 Feb 2017 23:52:36.0239 (UTC) FILETIME=[436831F0:01D27CE6] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:53:42 -0000 I would like to ask if there is a reason I would have to applythe patch be= low to make an application work in a jail. And who's bad? the app too intrusive or the bsd not flexible enough (allow.= mlock?) Index: sys/kern/kern_jail.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/kern/kern_jail.c =A0 =A0 =A0 =A0(revision 313033) +++ sys/kern/kern_jail.c =A0 =A0 =A0 =A0(working copy) @@ -3340,6 +3340,11 @@ =A0 =A0 =A0 =A0 case PRIV_PROC_SETLOGINCLASS: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (0); + =A0 =A0 =A0 =A0case PRIV_VM_MADV_PROTECT: + =A0 =A0 =A0 =A0case PRIV_VM_MLOCK: + =A0 =A0 =A0 =A0case PRIV_VM_MUNLOCK: + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (0); + =A0 =A0 =A0 =A0 default: From owner-freebsd-current@freebsd.org Thu Feb 2 01:31:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8A67CCCBE1 for ; Thu, 2 Feb 2017 01:31:38 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 3F330AB4 for ; Thu, 2 Feb 2017 01:31:38 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id b65so67004290wmf.0 for ; Wed, 01 Feb 2017 17:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=inHQTkb4FQfV/R5KbZNrrgDqlEvYU+KETepBtclNQkk=; b=Y8ygKeXly/WxCUYJ/WkvA0pWfoSkh2yI4Qn3t53F+Wjv+zJEuONiVQvtcQvzeVoYrS NBQr+MhToRAoddWjnxFsk7JkuVOP88kgyw3p1Vi1NMw3pJqj0+6+zVNt2O22TsAiQKuA eDlFZLK0SITspNkgkb/H12nCwiORQB4tInCb9NQlzBPiFiLhLeSWok9rCg4LInEp2bU+ ihdnsiM4fxq2zY0nvVNZiU6cHOMMKxfhIF8LtK73Irh/R21DNAw1Z+80vyMt3bCTScTw b26zEfP+gaU1PSaZLcqjY7zjb+oxHZBYUmdloctMye0IcC+X1oKvphaJCxMp5fXiDFnE o/iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=inHQTkb4FQfV/R5KbZNrrgDqlEvYU+KETepBtclNQkk=; b=izmMngE5yBZj1+Hi5wYg6pcNpYBCSqcj39PagWhcXmWpFdvemE+1c4d3ocN3jhXO1n b1OEhlWDaW2kR4crkGakmf79Om0txl1Mzj+kC6kMfimTNQKULi/mI/LAwKS1rDzrMDyt xPFYH7OqyYfXHdgjSVFxyKyqs5GmrVthbTqVoq2abtFSQhwWOEnYuW5SMUi1YgBttOkR Fm5ip8dub9W5BlSSpcAIJbJ7A50YZU6RLa5TfZhNMr0i53RwjTQkzqgjV28LebAYHFz5 JxTbGXGYb8ZMkUWDRjLwIe80opkR5vorY5driViAIEnfs7mulyxUAZimyQhdxJeFs2/S L1wg== X-Gm-Message-State: AIkVDXI3tdIR6sA1Ml7+9nPuMDpYMA2cD70Ffc43wkOT7H7FKafFOKOR/+HxJpOGTFT6KR9vFr7+thvonjNX0w== X-Received: by 10.223.151.99 with SMTP id r90mr4872588wrb.183.1485999096543; Wed, 01 Feb 2017 17:31:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.145.133 with HTTP; Wed, 1 Feb 2017 17:31:35 -0800 (PST) In-Reply-To: References: From: Xin LI Date: Wed, 1 Feb 2017 17:31:35 -0800 Message-ID: Subject: Re: mlock and jail To: =?UTF-8?B?QnJ1bm8gTGF1esOp?= Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 01:31:38 -0000 I like this idea. Note that potentially your patch would make it possible for a jailed root to DoS the whole system by locking too much of pages in memory. I think it would be sensible to provide a per-jail flag to enable doing it, or better, have some finer grained control (e.g. per jail quota of permitted locked pages). Why did the application want to lock pages in main memory, though? On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauz=C3=A9 wrote= : > > I would like to ask if there is a reason I would have to applythe patch = below to make an application work in a jail. > And who's bad? the app too intrusive or the bsd not flexible enough (allo= w.mlock?) > > > Index: sys/kern/kern_jail.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_jail.c (revision 313033) > +++ sys/kern/kern_jail.c (working copy) > @@ -3340,6 +3340,11 @@ > case PRIV_PROC_SETLOGINCLASS: > return (0); > > > + case PRIV_VM_MADV_PROTECT: > + case PRIV_VM_MLOCK: > + case PRIV_VM_MUNLOCK: > + return (0); > + > default: > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Thu Feb 2 03:00:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D98BCCCC2D5 for ; Thu, 2 Feb 2017 03:00:49 +0000 (UTC) (envelope-from alex.deiter@gmail.com) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 614561F87; Thu, 2 Feb 2017 03:00:49 +0000 (UTC) (envelope-from alex.deiter@gmail.com) Received: by mail-lf0-x242.google.com with SMTP id h65so203538lfi.3; Wed, 01 Feb 2017 19:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=du5r/BNZnmK5cWUXg2LnoS4ZyyHZkaAM8v8NDsdlLmY=; b=LztF5a5IuKapK6EVcB1hSULgBPKGTRhcsgeNV9krJlGTb8TFI6tuVYjOTxcsHdpQt8 qQhw11vA6JHJJAmCdnqsu9gvDWLkJUHJWEk5DK95YUifr8IJ2pQnxEL9yi2dBbQPR30V 3KnnXj4RUlmz8nji3xYcOMbcl9J3rYbFonatIkaRuJf2jUPLPpkpcXoo3yUpSUDYD+yM NGzM8dGH1bSNwmQDQDqSFtTxW+MWSxmEypHJkrQZjVBCpNpIaHuiTnR0Kggn9BeEC8Wp gy2QN4XJrCntVZQLHtQjjrOTVr+Uhku8YTiHgo2JrPX4G7fSxAXkBWpj53cEeMmcnL7w aeIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=du5r/BNZnmK5cWUXg2LnoS4ZyyHZkaAM8v8NDsdlLmY=; b=q9N5Ye8wyD1yb1KBarl0XImZkdVBlM1o6NYAUgRP30bUV0SrscaZ/JFT8+6LuH+lQp sMcDjA197CCbj17yoLbCj4GtPCBKxQfsfRIoyQM/Pwoz4PQykqL7fQ+JwMvyecqJgvS1 a9rrhLXMHUQiwvTl+anCOlivPuONCozpVtDFe7/mpPYJvFBfflcR2wJo7mrGFT6MDWI1 s4jfyLpuU/noeXP9bwXI2wBJQsdLUumYocUBlS6GJ3dcrXOSV3AKw0bIj6tIO8oOQxxa vA+Q0dt9z0/E2IBLSsJdEKX2+h8EtjPjLEijsAUurE5FTPcRJW3fNq+PnVrJks62pEA5 r8RQ== X-Gm-Message-State: AIkVDXLel1/I+tfBnLBCDa2EEMA7F+RH7po9Bh7t3ZjxPjGCp0djqPH2Ek7F13pBRXt6GA== X-Received: by 10.46.22.6 with SMTP id w6mr2337580ljd.31.1486004447648; Wed, 01 Feb 2017 19:00:47 -0800 (PST) Received: from tiamat.deiter.ru ([109.167.157.231]) by smtp.gmail.com with ESMTPSA id j87sm6263598lfi.25.2017.02.01.19.00.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 19:00:47 -0800 (PST) From: Alex Deiter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 2 Feb 2017 06:00:45 +0300 Subject: HEAD [r313048] WITHOUT_INET6: tcpdump build failure Message-Id: To: glebius@freebsd.org, freebsd-current X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:00:49 -0000 Hello, Please take a look HEAD [r313048] - buildworld failed for IPv4-only = system (WITHOUT_INET6): cc -target x86_64-unknown-freebsd12.0 = --sysroot=3D/export/freebsd/obj/export/freebsd/src/tmp = -B/export/freebsd/obj/export/freebsd/src/tmp/usr/bin -O2 -pipe = -I/export/freebsd/sr c/usr.bin/ftp -I/export/freebsd/src/usr.bin/ftp/../../contrib/tnftp = -DNDEBUG -MD -MF.depend.util.o -MTutil.o -std=3Dgnu99 = -fstack-protector-strong -Wsystem-headers -Wall -Wno-for mat-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body = -Wno-string-plus-int -Wno-unused-const-variable = -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit y -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Qunused-arguments -c /export/freebsd/src/usr.bi n/ftp/../../contrib/tnftp/src/util.c -o util.o --- all_subdir_usr.sbin --- print-ip6.o: In function `ip6_print': = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-ip6.c:(.text+0x4c6): undefined reference to `hbhopt_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-ip6.c:(.text+0x4d9): undefined reference to `rt6_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-ip6.c:(.text+0x530): undefined reference to `dstopt_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-ip6.c:(.text+0x574): undefined reference to `frag6_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-ip6.c:(.text+0x60b): undefined reference to `mobility_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-ip6.c:(.text+0x6ba): undefined reference to `icmp6_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-ip6.c:(.text+0x6da): undefined reference to `ospf6_print' print-udp.o: In function `udp_print': = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-udp.c:(.text+0x13e0): undefined reference to `ripng_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-udp.c:(.text+0x13ff): undefined reference to `dhcp6_print' = /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/prin= t-udp.c:(.text+0x143d): undefined reference to `babel_print' cc: error: linker command failed with exit code 1 (use -v to see = invocation) *** [tcpdump] Error code 1 make[5]: stopped in /export/freebsd/src/usr.sbin/tcpdump/tcpdump 1 error Thank you! Alex Deiter alex.deiter@gmail.com From owner-freebsd-current@freebsd.org Thu Feb 2 03:28:55 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2BC8CCB1A2 for ; Thu, 2 Feb 2017 03:28:55 +0000 (UTC) (envelope-from alex.deiter@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 56ED415C9; Thu, 2 Feb 2017 03:28:55 +0000 (UTC) (envelope-from alex.deiter@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id v186so1780948lfa.1; Wed, 01 Feb 2017 19:28:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:date:subject:in-reply-to:to:references; bh=CVovzY/OY+VqBtUEWZsb/Kd//7fx6dqqZATGJDbQu3U=; b=ngejiztcrL0ZNLUJRReeAxIp3WtZlX8iiYHZsIflnXjQ8IiW0gTfHXk1WxK+iyv5Ph 78oaC4hwhNVKvkNQ0q5/G5DFMR2W067JTEaSRguMMASGARuJ40Bqo6A9FfoWJryYbfIr UsRC3kbtyF1AqpHHxBLz5ZjYzqP3CjL4tJakwzhDG/N/UeCQhpLkLLd6uFA845gI7uxp 4pVhBYrNEZqxhby0KU3D1wPCmpkdePjcjFXrJQxAwfbN22rB7wv+k8WB2T+aVS1MWhKi 4Q+KRQFnT/FIlCNo0tlxF0Ig+B8OdbuojYxZ5EQxmktNtcg/eGd8P57CZChEGcVgh3mi 1IPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:date:subject :in-reply-to:to:references; bh=CVovzY/OY+VqBtUEWZsb/Kd//7fx6dqqZATGJDbQu3U=; b=VRqidlnsfDDSgJ6+h1Dqo5fEHc5gohs2DFLTAC8Z++49EAAY37ytjjqRG8XPSG9tmC EInbr3oRJAWYWdeeFPwf56yMLk2Dcm11gje3XkEq/zq2C2dUJ/1R5et+Tp1l48qcURaK edPseJ8Y735IHeLG2UUZuB0nWKKjX3as5xc+lPu7iHOCMcUNm25F4asKY44i1857K58z hBMTZ0amYDkKUP5V8yi3oDQXQQ5toRshzPH7cv54R57jBA8NuETV72lE0uqrRYuSCBOP 2kTlqmBiQw6m+XKGmBcfYi46IotBekxkhb+0NMJ5933vge6lX+Rxg9unzY8YV2ZdHs5D 49uw== X-Gm-Message-State: AIkVDXKD3imOKS/Gsv5Dxt7oDwn63GQBHaaIZCOZnpabOa7KYR+ARf8VVa5oV2JxFhhlUA== X-Received: by 10.25.213.78 with SMTP id m75mr2157286lfg.36.1486006132417; Wed, 01 Feb 2017 19:28:52 -0800 (PST) Received: from tiamat.deiter.ru ([109.167.157.231]) by smtp.gmail.com with ESMTPSA id b7sm6201053lfe.33.2017.02.01.19.28.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 19:28:51 -0800 (PST) From: Alex Deiter Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_19A6D1E9-B026-4C32-A01E-F51ABB0E0E02" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 2 Feb 2017 06:28:50 +0300 Subject: Re: HEAD [r313048] WITHOUT_INET6: tcpdump build failure In-Reply-To: To: glebius@freebsd.org, freebsd-current References: X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:28:55 -0000 --Apple-Mail=_19A6D1E9-B026-4C32-A01E-F51ABB0E0E02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hello, Please review attached patch. Thank you! Alex Deiter alex.deiter@gmail.com --Apple-Mail=_19A6D1E9-B026-4C32-A01E-F51ABB0E0E02 Content-Disposition: attachment; filename=usr.sbin-tcpdump-tcpdump-Makefile.diff.txt Content-Type: text/plain; x-unix-mode=0644; name="usr.sbin-tcpdump-tcpdump-Makefile.diff.txt" Content-Transfer-Encoding: 7bit Index: usr.sbin/tcpdump/tcpdump/Makefile =================================================================== --- usr.sbin/tcpdump/tcpdump/Makefile (revision 313074) +++ usr.sbin/tcpdump/tcpdump/Makefile (working copy) @@ -36,6 +36,7 @@ print-ascii.c \ print-atalk.c \ print-atm.c \ + print-babel.c \ print-beep.c \ print-bfd.c \ print-bgp.c \ @@ -50,6 +51,7 @@ print-cnfp.c \ print-dccp.c \ print-decnet.c \ + print-dhcp6.c \ print-domain.c \ print-dtp.c \ print-dvmrp.c \ @@ -62,6 +64,7 @@ print-fddi.c \ print-forces.c \ print-fr.c \ + print-frag6.c \ print-ftp.c \ print-geneve.c \ print-geonet.c \ @@ -70,10 +73,12 @@ print-hsrp.c \ print-http.c \ print-icmp.c \ + print-icmp6.c \ print-igmp.c \ print-igrp.c \ print-ip.c \ print-ip6.c \ + print-ip6opts.c \ print-ipcomp.c \ print-ipfc.c \ print-ipnet.c \ @@ -96,6 +101,7 @@ print-m3ua.c \ print-medsa.c \ print-mobile.c \ + print-mobility.c \ print-mpcp.c \ print-mpls.c \ print-mptcp.c \ @@ -109,6 +115,7 @@ print-openflow.c \ print-openflow-1.0.c \ print-ospf.c \ + print-ospf6.c \ print-otv.c \ print-pgm.c \ print-pim.c \ @@ -121,9 +128,11 @@ print-raw.c \ print-resp.c \ print-rip.c \ + print-ripng.c \ print-rpki-rtr.c \ print-rrcp.c \ print-rsvp.c \ + print-rt6.c \ print-rtsp.c \ print-rx.c \ print-sctp.c \ @@ -171,15 +180,6 @@ CFLAGS+= -D_U_="__attribute__((unused))" .if ${MK_INET6_SUPPORT} != "no" -SRCS+= print-babel.c \ - print-dhcp6.c \ - print-frag6.c \ - print-icmp6.c \ - print-ip6opts.c \ - print-mobility.c \ - print-ospf6.c \ - print-ripng.c \ - print-rt6.c CFLAGS+= -DINET6 -DHAVE_OS_IPV6_SUPPORT .endif .if ${MACHINE_CPUARCH} != "i386" --Apple-Mail=_19A6D1E9-B026-4C32-A01E-F51ABB0E0E02-- From owner-freebsd-current@freebsd.org Thu Feb 2 03:31:01 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B650DCCB372 for ; Thu, 2 Feb 2017 03:31:01 +0000 (UTC) (envelope-from brunolauze@msn.com) Received: from SNT004-OMC3S16.hotmail.com (snt004-omc3s16.hotmail.com [65.55.90.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69F35192A for ; Thu, 2 Feb 2017 03:31:01 +0000 (UTC) (envelope-from brunolauze@msn.com) Received: from NAM03-CO1-obe.outbound.protection.outlook.com ([65.55.90.136]) by SNT004-OMC3S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 1 Feb 2017 19:29:55 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ENRG2OCFQOfyo21gS6HXtRf1Wyb1r/abEqJTklVMdTs=; b=iIiP45QFOeV/aZH9VteDeHmHZvUofSJfUGbbjd3Stn7c4daObc7t5dxWeyIYnZgt1AWrvwzBX0y9alJwOjBzf9XsbOBgFu0669fs7P/oDo4dVAEGEWpiYNzgLRU7XKd0mLiqnLJJxbEIFUt8NAHBD1RiRSsk63VM5L9OkvmEKCYBgO4G0G5WrNGeK24pIFLCl2KnEKYpLMCpG5iU4cNq5wpgNPKfpuFWhl64Mr+uxYbyMgtPItUNIxWhWUAqCnPAUNjZNNUktXst+14c5RoYDJut7QbdfmfaBKn16F+C3vz3g9S9wGUzQRJDlhKeLSWQ7loWvORhPfgMv1NxhuZd3Q== Received: from CO1NAM03FT047.eop-NAM03.prod.protection.outlook.com (10.152.80.58) by CO1NAM03HT015.eop-NAM03.prod.protection.outlook.com (10.152.80.239) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.7; Thu, 2 Feb 2017 03:29:54 +0000 Received: from SN1PR16MB0640.namprd16.prod.outlook.com (10.152.80.52) by CO1NAM03FT047.mail.protection.outlook.com (10.152.81.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.7 via Frontend Transport; Thu, 2 Feb 2017 03:29:54 +0000 Received: from SN1PR16MB0640.namprd16.prod.outlook.com ([10.165.28.138]) by SN1PR16MB0640.namprd16.prod.outlook.com ([10.165.28.138]) with mapi id 15.01.0845.028; Thu, 2 Feb 2017 03:29:53 +0000 From: =?iso-8859-1?Q?Bruno_Lauz=E9?= To: Xin LI CC: freebsd-current Subject: Re: mlock and jail Thread-Topic: mlock and jail Thread-Index: AQHSfOM6KDHfJeZzq062UKsd7j9HtKFU7meAgAAd7J0= Date: Thu, 2 Feb 2017 03:29:53 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=msn.com; x-incomingtopheadermarker: OriginalChecksum:81B7093006218D9C0DA62A26AF24232E0C9124FF34D5E528D82D716206D61E66; UpperCasedChecksum:38FCF965028D85A2FD08CD67D5FA74315C2596F98E98D869D997BB79AAD31C4B; SizeAsReceived:7845; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [DhpMKF4ma3UnYr9YDxweNJmnnAABgfqK] x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CO1NAM03HT015; 5:qrTzlYSq4lFVkc/bnkAxYHSX/O9Je+qTalUcvdC78pddz6NDim17bZgbWVwsh21nrArHbz5cxcptHgNaqo0hZzzOEG6cMl1XwqVAcuKt1bxqcEp7vdfGCJrtZWb9OVwbtx4UlFYKj/YOJlRRvrDS+W5XWaF/ph93iLCbkPm+cQQ=; 24:2505oyV9oLvQW94QQZxgDOPOt2/OaHBXYOwmxUyiJdOfryU8U3vyiOb2Y1hmhPK5Rs3ocS6eMyl1Op7CmH5lTxlRCZlUeY2Uag9mrsuhR2M=; 7:XA+AAnW8I9O2ygdOFanB21Xbo2OTG+G+Rcd6/4Cw8jmT896nQok0jd7EluddFcOm3MwgRr0f26dV+RX/k0muL4rwARb+j/8D5VacMFaRHikCv2pRLn3z3t+gqgTbsl86GqRycgkjzO7RQ34GpndDmNduvIwPzXLQbM/QHZ/aEsyEF2g+H1kG1FbaLoWHh1+jSjGBkXRP0n1QkMsytINuhecrku915z9uo7x9u4EB4tEfPofz3wY0oTdM/l/Iuqm5fTYy0mK26r/0HUOA3i24rSMtDaCBUZNzY6GJThbgQjF5h4Vq9asCd6+TuBInYtHH6RGQ80YqtkUX1QHR5JOrmKhqFkf2/plRqRP4pXAcVDIXPuGwdxEyyCNBMjM7CaVMsvGRlKfjfcMx4M4euPBl2sEhNjPpVeUxQ8eONu2MXMdGl/iM7U7r452cVYyNbLrmuLL+S3+v6OHi1NyPE6agWKAtC/VAbfm1we4IBXzlvgeFKJtSnx3VNd7ltn4SwMl9MLTAzm6Z0dO9IZi4MxeYfg== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM03HT015; H:SN1PR16MB0640.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 4bc63f60-0b9d-411b-f53f-08d44b1bc0eb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(5061506344)(5061507327)(1603103130)(1601125047)(1603101358)(1701031040); SRVR:CO1NAM03HT015; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(432015012)(82015046); SRVR:CO1NAM03HT015; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT015; x-forefront-prvs: 02065A9E77 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 03:29:53.8190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT015 X-OriginalArrivalTime: 02 Feb 2017 03:29:55.0866 (UTC) FILETIME=[9FA15FA0:01D27D04] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:31:01 -0000 Thanks you. The app in fact is dotnet https://github.com/dotnet/coreclr And since it's already possible to cap overall memory with rctl ( -- jail:h= ttpd:memoryuse:deny=3D2G/jail -- or -- jail:httpd:memorylocked:deny=3D1G/ja= il -- ) it seems correct to say the lock weight could only be within those= limits? But right now memorylocked rctl does apply since prison is denied mlock. I = might be missing something. Thanks for your help. By the way, FreeBSD would gain a lot pushing for dotnet support as it did w= ith Java in the days. ________________________________ From: Xin LI Sent: February 1, 2017 8:31:35 PM To: Bruno Lauz=E9 Cc: freebsd-current Subject: Re: mlock and jail I like this idea. Note that potentially your patch would make it possible for a jailed root to DoS the whole system by locking too much of pages in memory. I think it would be sensible to provide a per-jail flag to enable doing it, or better, have some finer grained control (e.g. per jail quota of permitted locked pages). Why did the application want to lock pages in main memory, though? On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauz=E9 wrote: > > I would like to ask if there is a reason I would have to applythe patch = below to make an application work in a jail. > And who's bad? the app too intrusive or the bsd not flexible enough (allo= w.mlock?) > > > Index: sys/kern/kern_jail.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_jail.c (revision 313033) > +++ sys/kern/kern_jail.c (working copy) > @@ -3340,6 +3340,11 @@ > case PRIV_PROC_SETLOGINCLASS: > return (0); > > > + case PRIV_VM_MADV_PROTECT: > + case PRIV_VM_MLOCK: > + case PRIV_VM_MUNLOCK: > + return (0); > + > default: > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Thu Feb 2 04:48:44 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6AC4CCDE62 for ; Thu, 2 Feb 2017 04:48:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 911CD1D93 for ; Thu, 2 Feb 2017 04:48:44 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v124mh5N016806 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Feb 2017 20:48:43 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v124mh3H016805; Wed, 1 Feb 2017 20:48:43 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 1 Feb 2017 20:48:43 -0800 From: Gleb Smirnoff To: Alex Deiter Cc: freebsd-current Subject: Re: HEAD [r313048] WITHOUT_INET6: tcpdump build failure Message-ID: <20170202044843.GI3334@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 04:48:44 -0000 On Thu, Feb 02, 2017 at 06:28:50AM +0300, Alex Deiter wrote: A> Please review attached patch. Thanks. It seems strange to me to reduce functionality of tcpdump when a build doesn't support INET6. I still want it able to parse packets I see on a network. -- Totus tuus, Glebius. From owner-freebsd-current@freebsd.org Thu Feb 2 04:54:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 754CDCCD14D for ; Thu, 2 Feb 2017 04:54:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 55547769 for ; Thu, 2 Feb 2017 04:54:34 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id v124iqCU016790 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Feb 2017 20:44:52 -0800 (PST) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id v124iq3E016789; Wed, 1 Feb 2017 20:44:52 -0800 (PST) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 1 Feb 2017 20:44:52 -0800 From: Gleb Smirnoff To: Alex Deiter Cc: freebsd-current Subject: Re: HEAD [r313048] WITHOUT_INET6: tcpdump build failure Message-ID: <20170202044452.GH3334@FreeBSD.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 04:54:35 -0000 Thanks for report, I will look at it. On Thu, Feb 02, 2017 at 06:00:45AM +0300, Alex Deiter wrote: A> Hello, A> A> Please take a look HEAD [r313048] - buildworld failed for IPv4-only system (WITHOUT_INET6): A> A> cc -target x86_64-unknown-freebsd12.0 --sysroot=/export/freebsd/obj/export/freebsd/src/tmp -B/export/freebsd/obj/export/freebsd/src/tmp/usr/bin -O2 -pipe -I/export/freebsd/sr A> c/usr.bin/ftp -I/export/freebsd/src/usr.bin/ftp/../../contrib/tnftp -DNDEBUG -MD -MF.depend.util.o -MTutil.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-for A> mat-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equalit A> y -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /export/freebsd/src/usr.bi A> n/ftp/../../contrib/tnftp/src/util.c -o util.o A> --- all_subdir_usr.sbin --- A> print-ip6.o: In function `ip6_print': A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x4c6): undefined reference to `hbhopt_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x4d9): undefined reference to `rt6_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x530): undefined reference to `dstopt_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x574): undefined reference to `frag6_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x60b): undefined reference to `mobility_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x6ba): undefined reference to `icmp6_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-ip6.c:(.text+0x6da): undefined reference to `ospf6_print' A> print-udp.o: In function `udp_print': A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x13e0): undefined reference to `ripng_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x13ff): undefined reference to `dhcp6_print' A> /export/freebsd/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-udp.c:(.text+0x143d): undefined reference to `babel_print' A> cc: error: linker command failed with exit code 1 (use -v to see invocation) A> *** [tcpdump] Error code 1 A> A> make[5]: stopped in /export/freebsd/src/usr.sbin/tcpdump/tcpdump A> 1 error A> A> Thank you! A> A> Alex Deiter A> alex.deiter@gmail.com A> A> A> A> -- Totus tuus, Glebius. From owner-freebsd-current@freebsd.org Thu Feb 2 12:39:00 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D86F6CCD122 for ; Thu, 2 Feb 2017 12:39:00 +0000 (UTC) (envelope-from freebsd@gomor.org) Received: from mail2.secure-side.com (sys2.secure-side.com [94.23.25.71]) by mx1.freebsd.org (Postfix) with ESMTP id 4846F1FE0 for ; Thu, 2 Feb 2017 12:38:59 +0000 (UTC) (envelope-from freebsd@gomor.org) Received: (qmail 62385 invoked by uid 0); 2 Feb 2017 12:32:16 -0000 Received: from unknown (HELO www.secure-side.com) (192.168.0.133) by smtpout.jail with ESMTP; 2 Feb 2017 12:32:16 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 02 Feb 2017 13:32:16 +0100 From: GomoR To: freebsd-current , owner-freebsd-current@freebsd.org Subject: Re: mlock and jail (Elasticsearch/Java use case) In-Reply-To: References: Message-ID: X-Sender: freebsd@gomor.org User-Agent: Roundcube Webmail/1.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:39:00 -0000 Hello, Giving mlock support to jails would also allow Elasticsearch (Java-based) to run as a jailed process. In fact, Java can use a memory optimization trick for better performances by locking a specified amount of memory. Thus, Elasticsearch has the need for such a setting to let it run at its full power. Without this tunable, one cannot take advantage of this and Elasticsearch cannot run jailed to its full performance. Furthermore, putting it outside of a jail is less confortable regarding overall system security. Best regards, On 2017-02-02 02:31, Xin LI wrote: > I like this idea. > > Note that potentially your patch would make it possible for a jailed > root to DoS the whole system by locking too much of pages in memory. > I think it would be sensible to provide a per-jail flag to enable > doing it, or better, have some finer grained control (e.g. per jail > quota of permitted locked pages). > > Why did the application want to lock pages in main memory, though? > > On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauzé wrote: >> >> I would like to ask if there is a reason I would have to applythe >> patch below to make an application work in a jail. >> And who's bad? the app too intrusive or the bsd not flexible enough >> (allow.mlock?) >> >> >> Index: sys/kern/kern_jail.c >> =================================================================== >> --- sys/kern/kern_jail.c (revision 313033) >> +++ sys/kern/kern_jail.c (working copy) >> @@ -3340,6 +3340,11 @@ >> case PRIV_PROC_SETLOGINCLASS: >> return (0); >> >> >> + case PRIV_VM_MADV_PROTECT: >> + case PRIV_VM_MLOCK: >> + case PRIV_VM_MUNLOCK: >> + return (0); >> + >> default: >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Feb 2 15:54:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4872CCCDC90 for ; Thu, 2 Feb 2017 15:54:30 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 175FBF7C for ; Thu, 2 Feb 2017 15:54:30 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ua0-x22a.google.com with SMTP id 96so14208229uaq.3 for ; Thu, 02 Feb 2017 07:54:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7SfHgUYW3sJSyO8vSi+zaddesvkGN+3DGwkMwKxiuKw=; b=h3BtGn7wnlWBz6VJ8wsLvt3n98o28aM5NiTrzKDajV9sMbmILrWJcwR21YZYAEVTFw 8M32zO5IXBtb99e7OqbhtFi9DHRwxNXjNiEM8f+lHIF/tg7XH5aqp7RwBQ+xHjLgrHrA K5MOu6fM//KAvcQBCRWmgBrbOHWqRXMp/AHsdVp4Btu8l4Ext+xUtgZPi73FFSr3k26B YfP/n2jOvthZhICySjoapZ52gaBDMSzCfvFEWxxxNnxcYRX2/m8dPe6PZ4NuYZXAngvG COI12AVXzPt5hSbl8t0SgpYMetvFyFd8sZ/OZLmAEYqiiFTxsRCV/1Wt5ddwbLzHcsSA 8HEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7SfHgUYW3sJSyO8vSi+zaddesvkGN+3DGwkMwKxiuKw=; b=ksEwn8nl7Ke99zj+aTPkXDN9VWa8raxyoyJ5z+O8X4GNYFx7qvJ4wdweddeXoAK2cp aOT3HtvVpjMbuZqB0TqJBcBNdMgfISS3f9SezW5uBKXZloz4aHeQsQ+p8yEg+N+f1axM m4IOdxQ1ev8po4QZoLyNwJN/OqgIyHE+k+69bXKFupZzwFRkfM3znCz9+IZIetsg1saS 1agRVPTS7ZPxPO6h26d4+PqeF/OnuhylcwHKdAjDvNCHGwnrUubPsc0y75JTDgID5Nqp bGGZQEcArSCD1dKeC7UnkNgQYEEVQH73C8NofM6A/qerJWr8Hn+zz/fLxvMqGEwdf18r a4ng== X-Gm-Message-State: AIkVDXIvYYyFr75ab95jenapvvAdVUpGzFYry6NucHEEIlzm8zSq8xcDz+x8xbbhsBL4JnjEThNo30wm/LxvyQ== X-Received: by 10.176.71.91 with SMTP id i27mr4491477uac.149.1486050869149; Thu, 02 Feb 2017 07:54:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.5 with HTTP; Thu, 2 Feb 2017 07:54:28 -0800 (PST) In-Reply-To: References: From: Pavel Timofeev Date: Thu, 2 Feb 2017 18:54:28 +0300 Message-ID: Subject: Re: mlock and jail To: Xin LI Cc: =?UTF-8?B?QnJ1bm8gTGF1esOp?= , freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:54:30 -0000 2017-02-02 4:31 GMT+03:00 Xin LI : > I like this idea. > > Note that potentially your patch would make it possible for a jailed > root to DoS the whole system by locking too much of pages in memory. > I think it would be sensible to provide a per-jail flag to enable > doing it, or better, have some finer grained control (e.g. per jail > quota of permitted locked pages). > > Why did the application want to lock pages in main memory, though? For example, this secret management tool https://www.vaultproject.io/docs/config/ wants to lock memory for security (surprise) reason. It's available as security/vault in our ports tree. > > On Wed, Feb 1, 2017 at 3:52 PM, Bruno Lauz=C3=A9 wro= te: >> >> I would like to ask if there is a reason I would have to applythe patch= below to make an application work in a jail. >> And who's bad? the app too intrusive or the bsd not flexible enough (all= ow.mlock?) >> >> >> Index: sys/kern/kern_jail.c >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/kern/kern_jail.c (revision 313033) >> +++ sys/kern/kern_jail.c (working copy) >> @@ -3340,6 +3340,11 @@ >> case PRIV_PROC_SETLOGINCLASS: >> return (0); >> >> >> + case PRIV_VM_MADV_PROTECT: >> + case PRIV_VM_MLOCK: >> + case PRIV_VM_MUNLOCK: >> + return (0); >> + >> default: >> >> >> _______________________________________________ From owner-freebsd-current@freebsd.org Thu Feb 2 18:13:31 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61BF6CCE426 for ; Thu, 2 Feb 2017 18:13:31 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 EC834C10 for ; Thu, 2 Feb 2017 18:13:30 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id v77so99446595wmv.0 for ; Thu, 02 Feb 2017 10:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WTiW/OfcYg4nGg0DjDLEzB97Hp9cD1Bp23sQGUnbQ5c=; b=O9dNoM+KUwSwFG6Ikwe3T+kIHQwiAYx+xzYBThq+FuBP6M/+dha0RwSltfnLVP6Y3X m0InpEqpNEy8Tyuyfmz4qBf8nycqB1gVjMX8O4gAyDnz1uVib/01cNYGcs7ASn+hcS/E Mv1dqeS8vaapgUafd0hltR8t1F9S7R1A4uDhmmkSKlAoQsrveU4vDdXouHIVihnP1G3J z+CwyFKRUqTBGnZLllaXwjJ750LaeEdO2O/5f4oRDlYqbggdK48gxosgw9N2jYnUggms 3ThxQTkoz7zh4UbqP9+l2DX98jjaoMPhKqNHyQ5bC/Fa4oLE4GJ3M9Y0WrYCALap0ZRC kngA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WTiW/OfcYg4nGg0DjDLEzB97Hp9cD1Bp23sQGUnbQ5c=; b=JMnUjjtnLIRToRTWi0rYU4Vo2b8E2hdQNKHc63Fex253XdrrJoFv2HHlzkn8QfnbaH CQNk1PcS7BITLjO8MrVcSZwvHFx5DfcqhS01M1cHZBrA80esh67Q2a7otgHjI/IMlmh8 LYxS+FbXKGg09uAOgHNWCBkth73FJ5rjhC5Pl8OEMwjC6TkgDHcQReGdRHMZ4a6UVjxn YOH6miJr6mXquFeLDgVd9LwdvP3U8pIZHoEcLIfsTr+qw9b59i8G6eoMwoUzwMFr/QcW JFam2RMt7ClGqSUIjpnwqtdP7m/2d8ZW6GtKE3/u+a6cEABUT7VJCkVzncduu21fJxB/ cHlA== X-Gm-Message-State: AIkVDXLfauiWw8VCHp1ZsmxuWsq8LgxVAtHBCfQquWaEm4Vjw4ncYkfXOwe1QRvSoNYLOgRJJ34irj2QcZrB1g== X-Received: by 10.28.91.19 with SMTP id p19mr26997883wmb.49.1486059209336; Thu, 02 Feb 2017 10:13:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.145.133 with HTTP; Thu, 2 Feb 2017 10:13:28 -0800 (PST) In-Reply-To: References: From: Xin LI Date: Thu, 2 Feb 2017 10:13:28 -0800 Message-ID: Subject: Re: mlock and jail To: Pavel Timofeev Cc: =?UTF-8?B?QnJ1bm8gTGF1esOp?= , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:13:31 -0000 On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev wrote: > 2017-02-02 4:31 GMT+03:00 Xin LI : >> I like this idea. >> >> Note that potentially your patch would make it possible for a jailed >> root to DoS the whole system by locking too much of pages in memory. >> I think it would be sensible to provide a per-jail flag to enable >> doing it, or better, have some finer grained control (e.g. per jail >> quota of permitted locked pages). >> >> Why did the application want to lock pages in main memory, though? > > For example, this secret management tool > https://www.vaultproject.io/docs/config/ wants to lock memory for > security (surprise) reason. > It's available as security/vault in our ports tree. No it's not surprise but overkill IMHO. Here is why: Locking memory does prevent swapping, but in a typical multi-user system, if an attacker is already able to read swap (keep in mind that disks are by default owned by root and can not be read in a typical setup), then the administrator already have much bigger problem to worry about, and the attacker would have much more powerful tools to steal the secrets. Additionally, if one really cares about safety of swap, they should have used encrypted swap in the first place. On FreeBSD, appending '.eli' to the swap device in fstab (e.g. /dev/ada0p3 -> /dev/ada0p3.eli) would automatically do one-time keyed swapping. Moreover, I don't think it's a good idea to use an application that advocates locking all memory that it owns for "security" reasons: if the application writer does not know which memory pages would contain sensitive information, good chances that the application writer have no idea what is privilege separation and the design they have created could be fundamentally flawed. Cheers, From owner-freebsd-current@freebsd.org Thu Feb 2 20:03:43 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70310CCDFE6 for ; Thu, 2 Feb 2017 20:03:43 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E1811354 for ; Thu, 2 Feb 2017 20:03:43 +0000 (UTC) (envelope-from null@pozo.com) Received: from octo.pozo.com (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v12K3YxA003850 for ; Thu, 2 Feb 2017 12:03:34 -0800 (PST) (envelope-from null@pozo.com) From: Manfred Antar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Thu, 2 Feb 2017 12:03:33 -0800 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v12K3YxA003850 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Subject: tcpdump broken on current and64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:03:43 -0000 tcpdump breaks buildworld since it was updated yesterday. this is on 12.0 C= urrent amd64 r313099 kernel Here is the error: (tcpdump)5026}make =3D=3D=3D> tcpdump (all) /usr/local/bin/ccache cc -O2 -pipe -I/usr/src/usr.sbin/tcpdump/tcpdump -= I/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump -DHAVE_CONFIG_H= -D_U_=3D"__attribute__((unused))" -DINET6 -DHAVE_OS_IPV6_SUPPORT -DLBL_ALI= GN -I/usr/include/openssl -DHAVE_LIBCRYPTO -DHAVE_OPENSSL_EVP_H -DHAVE_NET_= PFVAR_H -DHAVE_NET_IF_PFLOG_H -MD -MF.depend.tcpdump.o -MTtcpdump.o -std= =3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W= -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Qunused-arguments -c /usr/src/usr.sbin/tcpdump/tcpdum= p/../../../contrib/tcpdump/tcpdump.c -o tcpdump.o /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:4= 1: warning: implicit declaration of function '_IOR' is invalid in C99 [-Wim= plicit-function-declaration] static const unsigned long cmds[] =3D { BIOCGSTATS, BIOCROTZ= BUF }; ^ /usr/include/net/bpf.h:128:20: note: expanded from macro 'BIOCGSTATS' #define BIOCGSTATS _IOR('B', 111, struct bpf_stat) ^ /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:4= 1: error: expected expression /usr/include/net/bpf.h:128:35: note: expanded from macro 'BIOCGSTATS' #define BIOCGSTATS _IOR('B', 111, struct bpf_stat) ^ /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:5= 3: error: expected expression static const unsigned long cmds[] =3D { BIOCGSTATS, BIOCROTZ= BUF }; ^ /usr/include/net/bpf.h:145:36: note: expanded from macro 'BIOCROTZBUF' #define BIOCROTZBUF _IOR('B', 128, struct bpf_zbuf) ^ /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1934:1= 3: error: invalid application of 'sizeof' to an incomplete type 'const unsi= gned long []' sizeof(cmds) / sizeof(cmds[0])) < 0 && errno !=3D ENOSYS= ) { ^~~~~~ 1 warning and 3 errors generated. *** Error code 1 Stop. make[1]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. make: stopped in /usr/src/usr.sbin/tcpdump Looks like someone just fixed it !!!!! From owner-freebsd-current@freebsd.org Thu Feb 2 20:14:04 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CFF8CCC298 for ; Thu, 2 Feb 2017 20:14:04 +0000 (UTC) (envelope-from null@pozo.com) Received: from pozo.com (pozo.com [50.197.129.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "pozo.com", Issuer "pozo.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 858EE194B for ; Thu, 2 Feb 2017 20:14:04 +0000 (UTC) (envelope-from null@pozo.com) Received: from octo.pozo.com (octo.pozo.com [192.168.0.2]) (authenticated bits=128) by pozo.com (8.15.2/8.15.2) with ESMTPA id v12K1mCk092094 for ; Thu, 2 Feb 2017 12:01:48 -0800 (PST) (envelope-from null@pozo.com) From: Manfred Antar Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Thu, 2 Feb 2017 12:01:47 -0800 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.3259) X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.1, No X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on pozo.com X-pozocom-MailScanner-Information: Please contact the ISP for more information X-pozocom-MailScanner-ID: v12K1mCk092094 X-pozocom-MailScanner: Found to be clean X-pozocom-MailScanner-From: null@pozo.com Subject: tcpdump broken on current and64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 20:14:04 -0000 tcpdump breaks buildworld since it was updated yesterday. this is on 12.0 C= urrent amd64 r313099 kernel Here is the error: (tcpdump)5026}make =3D=3D=3D> tcpdump (all) /usr/local/bin/ccache cc -O2 -pipe -I/usr/src/usr.sbin/tcpdump/tcpdump -= I/usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump -DHAVE_CONFIG_H= -D_U_=3D"__attribute__((unused))" -DINET6 -DHAVE_OS_IPV6_SUPPORT -DLBL_ALI= GN -I/usr/include/openssl -DHAVE_LIBCRYPTO -DHAVE_OPENSSL_EVP_H -DHAVE_NET_= PFVAR_H -DHAVE_NET_IF_PFLOG_H -MD -MF.depend.tcpdump.o -MTtcpdump.o -std= =3Dgnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -W= -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a= rith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-= int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-un= used-local-typedef -Qunused-arguments -c /usr/src/usr.sbin/tcpdump/tcpdum= p/../../../contrib/tcpdump/tcpdump.c -o tcpdump.o /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:4= 1: warning: implicit declaration of function '_IOR' is invalid in C99 [-Wim= plicit-function-declaration] static const unsigned long cmds[] =3D { BIOCGSTATS, BIOCROT= ZBUF }; ^ /usr/include/net/bpf.h:128:20: note: expanded from macro 'BIOCGSTATS' #define BIOCGSTATS _IOR('B', 111, struct bpf_stat) ^ /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:4= 1: error: expected expression /usr/include/net/bpf.h:128:35: note: expanded from macro 'BIOCGSTATS' #define BIOCGSTATS _IOR('B', 111, struct bpf_stat) ^ /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1921:5= 3: error: expected expression static const unsigned long cmds[] =3D { BIOCGSTATS, BIOCROT= ZBUF }; ^ /usr/include/net/bpf.h:145:36: note: expanded from macro 'BIOCROTZBUF' #define BIOCROTZBUF _IOR('B', 128, struct bpf_zbuf) ^ /usr/src/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/tcpdump.c:1934:1= 3: error: invalid application of 'sizeof' to an incomplete type 'const unsi= gned long []' sizeof(cmds) / sizeof(cmds[0])) < 0 && errno !=3D ENOSY= S) { ^~~~~~ 1 warning and 3 errors generated. *** Error code 1 Stop. make[1]: stopped in /usr/src/usr.sbin/tcpdump/tcpdump *** Error code 1 Stop. make: stopped in /usr/src/usr.sbin/tcpdump From owner-freebsd-current@freebsd.org Thu Feb 2 21:28:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8F07CCE5AD for ; Thu, 2 Feb 2017 21:28:32 +0000 (UTC) (envelope-from brunolauze@msn.com) Received: from BAY004-OMC2S22.hotmail.com (bay004-omc2s22.hotmail.com [65.54.190.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A39581DAB for ; Thu, 2 Feb 2017 21:28:32 +0000 (UTC) (envelope-from brunolauze@msn.com) Received: from NAM01-BN3-obe.outbound.protection.outlook.com ([65.54.190.123]) by BAY004-OMC2S22.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 2 Feb 2017 13:28:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xytWk5HZh7kK33jOfGd38PNZH5OxMYk5VhrQSTUK15M=; b=MDYtbathyGr3EaYD2u/lmHAZqLVfvY0R+ioGM+aPU3T7ljznbau1UqSGovRPsdlgIuoECrbmE16lnxprikKobnmKW3iDQ8zNRvER2wAYzISOvbsSeJDaLDnP0n23Xj5u9T0hCvZtoE4xuwcia2vcMhHqTfqXEv9HJM64nW03wbNpzL3N4t9tSozqIbYtOPH9ioCT2CSM02Ta+gvU/AIlq44lb1gJEszPGQCJRCKL1JV1zHyw+Qt4f/hOK4KABYtXphNIslMvwtBXbIMnSQUOdmdh1sHz9r1MIJ6Mxm6v7wpRBIWAdmakycP7gGq34dew7ZctsAHUG9XdOFLwZrnH0w== Received: from BN3NAM01FT056.eop-nam01.prod.protection.outlook.com (10.152.66.59) by BN3NAM01HT053.eop-nam01.prod.protection.outlook.com (10.152.66.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2; Thu, 2 Feb 2017 21:28:25 +0000 Received: from SN1PR16MB0640.namprd16.prod.outlook.com (10.152.66.59) by BN3NAM01FT056.mail.protection.outlook.com (10.152.67.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.2 via Frontend Transport; Thu, 2 Feb 2017 21:28:25 +0000 Received: from SN1PR16MB0640.namprd16.prod.outlook.com ([10.165.28.138]) by SN1PR16MB0640.namprd16.prod.outlook.com ([10.165.28.138]) with mapi id 15.01.0845.028; Thu, 2 Feb 2017 21:28:25 +0000 From: =?iso-8859-1?Q?Bruno_Lauz=E9?= To: freebsd-current Subject: RE: mlock and jail Thread-Topic: mlock and jail Thread-Index: AQHSfOM6KDHfJeZzq062UKsd7j9HtKFU7meAgADxFwCAACbWAIAANnWC Date: Thu, 2 Feb 2017 21:28:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=msn.com; x-incomingtopheadermarker: OriginalChecksum:49A902C9A0DE1DE3574C67C39B7DEA7CBB03ADCAD0B5B8463A996C7804529A5A; UpperCasedChecksum:1FC0093EA8D0A367ACFA059DA43B538776EF317E02CDFAC1A8D73AC550D85E4C; SizeAsReceived:7988; Count:39 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ZGEf3cP8r03iVeeD37Fap8hUypJ407Khz/fhYmVoQBs=] x-incomingheadercount: 39 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BN3NAM01HT053; 5:sMHM8Shr6HSUMmiN8XMiuyjfiwtgIYFMQ1URZnPP5ZYOpcVspAeBkPo7ZlSNwM20rm3YSHNOG4Nhx2U7cQ3JPtFYZ1DNWVc23kctxddEIofLEOqbl65uBjoZF5BkhZHCkR/iiP7/Zgb66/moOM8OmQ==; 24:LAM5FzqP1h7jPJDAD130Vfa9L5c0R0YMnqn+EZdSauidpSGhgoWJKz7z2W+NA/5DFZhYIFNYbmnDCG6oNf+W7JWfP6I/tV/XdDtXlzZBXSY=; 7:Zi1tk05fvjNJZ7OxjIQ0QM79+sKI4eUQ4ULkPAJqH5F5mdawQRs+vnsfOYrMHyag34uFUoIF3Dp9C7PCsuu39IH1IP5XHYS+Z3E9vQD1UtDaKUDnS0mZSvChKZ+kpoyncP2vT2ODkpkF5qN3corQhmQlDp+h851TZssaZJGiF0HR1t0QGzN4bRwom2Fu1HBZ3mBMez6rTKghlgiWLRjiM4ZHzBqRfxqBuxpI+jhJl5ngVyEcfQ+Kl5Or4FjZI73Z1C9h12wwCiZLfFZkVYgEXnnBZJwcK5bVTbutba8cvBOW2EPrkofTwmUOtXrQ/XR4d/PzG8PWJvHld6XvYCHcvBZ8ESg1KH3oa/sIwKO4gv0IYNfH6znE+iu67Tmyp1O1P1m1g4jcnTZKYMPWqTNJ2gSZ4b3fMRtJvGF78zY+pBvigI76gqV9r5lFjipdp285JDTJifOqY19xYIif4glFh/Y592ZfpCAONps9de/ybhvMhDB5p9ab5WK61hu2R+DFiHQGE3UJC+qSO8N5an+twA== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3NAM01HT053; H:SN1PR16MB0640.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 856fa8aa-e78f-4276-dee9-08d44bb26bd3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(5061506425)(5061507331)(1603103135)(1603101367)(1601125101)(1701031045); SRVR:BN3NAM01HT053; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(432015058)(82015046); SRVR:BN3NAM01HT053; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT053; x-forefront-prvs: 02065A9E77 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 21:28:25.0610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT053 X-OriginalArrivalTime: 02 Feb 2017 21:28:26.0821 (UTC) FILETIME=[4A5D7F50:01D27D9B] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:28:32 -0000 But a simple user with no rights can mlock (64kb by default) why a jail wou= ld not be able? From: Xin LI Sent: Thursday, February 2, 2017 1:13 PM To: Pavel Timofeev Cc: Bruno Lauz=E9; freebsd-current Subject: Re: mlock and jail On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev wrote: > 2017-02-02 4:31 GMT+03:00 Xin LI : >> I like this idea. >> >> Note that potentially your patch would make it possible for a jailed >> root to DoS the whole system by locking too much of pages in memory. >> I think it would be sensible to provide a per-jail flag to enable >> doing it, or better, have some finer grained control (e.g. per jail >> quota of permitted locked pages). >> >> Why did the application want to lock pages in main memory, though? > > For example, this secret management tool > https://www.vaultproject.io/docs/config/ wants to lock memory for > security (surprise) reason. > It's available as security/vault in our ports tree. No it's not surprise but overkill IMHO. Here is why: Locking memory does prevent swapping, but in a typical multi-user system, if an attacker is already able to read swap (keep in mind that disks are by default owned by root and can not be read in a typical setup), then the administrator already have much bigger problem to worry about, and the attacker would have much more powerful tools to steal the secrets. Additionally, if one really cares about safety of swap, they should have used encrypted swap in the first place. On FreeBSD, appending '.eli' to the swap device in fstab (e.g. /dev/ada0p3 -> /dev/ada0p3.eli) would automatically do one-time keyed swapping. Moreover, I don't think it's a good idea to use an application that advocates locking all memory that it owns for "security" reasons: if the application writer does not know which memory pages would contain sensitive information, good chances that the application writer have no idea what is privilege separation and the design they have created could be fundamentally flawed. Cheers, From owner-freebsd-current@freebsd.org Thu Feb 2 22:01:42 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55B05CCEF3D for ; Thu, 2 Feb 2017 22:01:42 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 EE4AB124E for ; Thu, 2 Feb 2017 22:01:41 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id 196so9082024wmm.1 for ; Thu, 02 Feb 2017 14:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yIXSfqxgSExlcZm56RVukkhOQs657V090S+YNlaRyzU=; b=DVlD8bs9iDInOCx/GxJtL0Z629mon9dDLSJiFAzaIHPoT0hvWFNwWMUV6mUsTyYFvA YObLCJqAlVr/8nsUPy8DpNZFnI4qivwTY0GFj34MSq0sqkKyoCcRhD3+n3CbAqfNuFjw ZkdNGsb5g9TRuc5wLkKnS5wIDIytrRPCAGrmRi+wk9wjCHnWrjciVTzt2PGSQI7H9sLI jjNPY80kFAxAibOTGaDIhvaMx4rWiu9Vk6apL5tZC+o8JIzFsGSQV5uRO8LJpTcbxM8z yXHiuuWq0Z5yha+oxCkmtmO3HpW4GcQqmSCN16Qjo1olTaL2/1EL1IHWir9DwAvJxnex qV+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yIXSfqxgSExlcZm56RVukkhOQs657V090S+YNlaRyzU=; b=bZbyszW0Q0DmxYzTLqlWXdBb6ujZ3VYDFp19GGyYbOkHPLSya3edZOnqjPc0aS4wWa 9Ai2v73l0tGi7ZXgFmK2D0oWqvTS5zN91LQaZSXb/4gyr6pJ58q4ZVd6CjDI2NYcesvt w33f9d/1Ga5Q+3EVttmRQFK2m1wz+RFXqY1dceEqFM/9+awAqAUXcTbmIVgSOtFXSfrl j3/GukP/5qbNCzNBMrlQYOsMQCZPdGgg45hkMB7/kkZc8mdMAio/EpPIATAI4i1lQG1g I4tSMurjHZRDSUMAe/EPhmS5GIk06fMuSP924/FW8iLqgAiXyr/vTPQ9HiumDSxsUv+L FwuQ== X-Gm-Message-State: AIkVDXLMNr6B8UentydJGItElTzFc9b3vIuqdLxjXPYUBQtq7dCiJWovBQauxtHIXp7H0bIOm2yf1/BtGdfVvw== X-Received: by 10.223.151.99 with SMTP id r90mr9075828wrb.183.1486072900011; Thu, 02 Feb 2017 14:01:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.145.133 with HTTP; Thu, 2 Feb 2017 14:01:39 -0800 (PST) In-Reply-To: References: From: Xin LI Date: Thu, 2 Feb 2017 14:01:39 -0800 Message-ID: Subject: Re: mlock and jail To: =?UTF-8?B?QnJ1bm8gTGF1esOp?= Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:01:42 -0000 On Thu, Feb 2, 2017 at 1:28 PM, Bruno Lauz=C3=A9 wrote= : > > > But a simple user with no rights can mlock (64kb by default) why a jail w= ould not be able? > No, I'm not, by any means, arguing against having jailed processes being able to mlock(), I'm just saying that we should have more fine grained control over it (a knob to allow system administrators to tweak it would be a good start). Cheers, > > From: Xin LI > Sent: Thursday, February 2, 2017 1:13 PM > To: Pavel Timofeev > Cc: Bruno Lauz=C3=A9; freebsd-current > Subject: Re: mlock and jail > > > > On Thu, Feb 2, 2017 at 7:54 AM, Pavel Timofeev wrote: >> 2017-02-02 4:31 GMT+03:00 Xin LI : >>> I like this idea. >>> >>> Note that potentially your patch would make it possible for a jailed >>> root to DoS the whole system by locking too much of pages in memory. >>> I think it would be sensible to provide a per-jail flag to enable >>> doing it, or better, have some finer grained control (e.g. per jail >>> quota of permitted locked pages). >>> >>> Why did the application want to lock pages in main memory, though? >> >> For example, this secret management tool >> https://www.vaultproject.io/docs/config/ wants to lock memory for >> security (surprise) reason. >> It's available as security/vault in our ports tree. > > No it's not surprise but overkill IMHO. Here is why: > > Locking memory does prevent swapping, but in a typical multi-user > system, if an attacker is already able to read swap (keep in mind that > disks are by default owned by root and can not be read in a typical > setup), then the administrator already have much bigger problem to > worry about, and the attacker would have much more powerful tools to > steal the secrets. > > Additionally, if one really cares about safety of swap, they should > have used encrypted swap in the first place. On FreeBSD, appending > '.eli' to the swap device in fstab (e.g. /dev/ada0p3 -> > /dev/ada0p3.eli) would automatically do one-time keyed swapping. > > Moreover, I don't think it's a good idea to use an application that > advocates locking all memory that it owns for "security" reasons: if > the application writer does not know which memory pages would contain > sensitive information, good chances that the application writer have > no idea what is privilege separation and the design they have created > could be fundamentally flawed. > > Cheers, > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " From owner-freebsd-current@freebsd.org Fri Feb 3 02:31:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBDA2CCDB27; Fri, 3 Feb 2017 02:31:59 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (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 8E1FF1B07; Fri, 3 Feb 2017 02:31:59 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yb0-x22d.google.com with SMTP id o65so2045961ybo.2; Thu, 02 Feb 2017 18:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dButyUbQ5iTvPrQO/TVCBj8PpIAxBy/Ic44tS/rHWbo=; b=JbexhR1vcawix1HvD9Rr+gmlorncrCHAsQJPWCQCGebMcvHLHEnWuv24bST8TP66Pr dRVCyyUTFnSyjNOMPY5FtOlpIySA0N4x1abQHKLKmXSWIu1vD9MMOuOZc1gUsKj6Knfz fqi31n/tVDL16mesu0kD0Otejx6hAaX5xA/qs1bkq5OK5qG5OuweZpvLfk4y0eeS9Ib3 m/0uaMeuWJ0ooEfZWEfCIvehwMYqlGiqkZwrt9JQWWv0yO1ISy3Wqd61qPHZ3W+1TJEN 2KpBr5luLixmTG7Ju26d8en1WIlq6hQTDK37A5Uc8kwii8oWTP6Su0cZsvodw7gNZqid nhEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dButyUbQ5iTvPrQO/TVCBj8PpIAxBy/Ic44tS/rHWbo=; b=OXcehSapoTSaSoYUNNa3py+UmZP8C+IX3cKVLPS7lVPvw+S9ni5Tsq8MwGXrVTra9V s8k3qflxQLh4q6AIayjGc14hG6T7msg/NDv4S/UbnyM2Jdpc7FXbA0ZRgtkkDM9TJgbN Ra0KwffdVFyRHvyot1GV1VZmxSurq7zOSFY+sHXE7JjUTW7acYqMyMMgjqsN7iP2cMYY 9Rauw1taa85Yetc1iQEKTcT8RDCTR/udFCPj3L4KYXiZIq8ou/satldcdr90fBVqfZc/ nJtebppGt1hl18iUCGSs2uh8g2nuESrahLUzzmCMtGRU8WmxWpinpTHkQM6KdQyk9SH6 kO+Q== X-Gm-Message-State: AIkVDXLzwkF0keeiaxseUK6JkdpRwsYIyZWdEUUJ9m/+AuLXKHZN0PgeOwFBDLz6eI9QM/oTqp1ge5W/SMrEUw== X-Received: by 10.37.248.2 with SMTP id u2mr4670497ybd.52.1486089118503; Thu, 02 Feb 2017 18:31:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.52.65 with HTTP; Thu, 2 Feb 2017 18:31:58 -0800 (PST) From: Ultima Date: Thu, 2 Feb 2017 21:31:58 -0500 Message-ID: Subject: zfs snapshot_limit is not respected To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 02:31:59 -0000 I recently moved some data on a box with limited space. I decided I should limit the snapshots so that space would not become an issue. I just check back a week later to find out the box is hitting the borderline. Doing I quick check I realized that the snapshot_limit is not being respected. # uname -a FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 10:59:10 EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/MYKERNEL amd64 # zfs create zroot/bhyve/test # zfs set snapshot_limit=0 zroot/bhyve/test # zfs snapshot zroot/bhyve/test@1 # zfs snapshot zroot/bhyve/test@2 # zfs snapshot zroot/bhyve/test@3 # zfs list -t snapshot | grep zroot/bhyve/test zroot/bhyve/test@1 0 - 88K - zroot/bhyve/test@2 0 - 88K - zroot/bhyve/test@3 0 - 88K - # zfs get all zroot/bhyve/test | grep snapshot zroot/bhyve/test usedbysnapshots 0 - zroot/bhyve/test snapshot_limit 0 local zroot/bhyve/test snapshot_count 3 local Also wanted to verify 0 was not being mistaken for none. # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk '{print $1}'`; do zfs destroy $snapshot ; done # zfs get all zroot/bhyve/test | grep snapshot zroot/bhyve/test usedbysnapshots 0 - zroot/bhyve/test snapshot_limit 0 local zroot/bhyve/test snapshot_count 0 local # zfs set snapshot_limit=1 zroot/bhyve/test # zfs snapshot zroot/bhyve/test@1 # zfs snapshot zroot/bhyve/test@2 # zfs snapshot zroot/bhyve/test@3 # zfs get all zroot/bhyve/test | grep snapshot zroot/bhyve/test usedbysnapshots 0 - zroot/bhyve/test snapshot_limit 1 local zroot/bhyve/test snapshot_count 3 local Also tested on head FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18 12:38:52 EST 2017 root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG amd64 From owner-freebsd-current@freebsd.org Fri Feb 3 08:24:38 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1711CCDF0C for ; Fri, 3 Feb 2017 08:24:38 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 69D0138E; Fri, 3 Feb 2017 08:24:38 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id c85so16601579wmi.1; Fri, 03 Feb 2017 00:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2umMVZ9+iSlefLvBRKcasTZuepgUiEhCxYPiiVRk9pQ=; b=qFw1U92ihhrD0j9s2iZzN6vFRpAL6htB93cXOJMTHbRRrRFoTNndu+iqRhaZMRVj3O 7tzpEs2Xh1g2nXSDN6hzpn1zii/uwY8oT7z8eyLrAttao3TkSKjKHgPhOmRVxK3YFmaR L0qZM7xfFz4iGlh1rmVhNB22QmR8CWNSJ+DNJJb/Y6jakTV3Emd3tJheSEom394JTsNe EoU8HDFUMGDX/UgmNfbCLE5v/CJM5sZ9rA/8mIenRmzwk8h/5gH2Q1/vVkPUomNpLLtl 3P00FmgvVMOTnIjpWTHhRT9ZCkSHwu30eq66mpKHAJ/7E0ZfLFzV4o7m8qlx+0rkD2I3 94Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2umMVZ9+iSlefLvBRKcasTZuepgUiEhCxYPiiVRk9pQ=; b=rBuoW+fN6or8TGQYdX6VsTgXa2L/RHPYiEl32uHFym/wbLUsi4r3ZtD5gI4X/1MuM0 ErH6m8PbRJjFsKBIrFQL+tMmy+8YCHQVcxIUbsvAUaOxPEElkz54Gd8hj/C9pNiHMWWH Bk5ta3V6TlJSpXp3mtOq8oUEYsAQSw+TQBg9wEplif6mN0JOV7+f3uVJlnzhTUFSZ1o9 M3Os8wdqPAqgrcw+qtQrU8LkI3/cpQOc1GnOvqKUrOG5vD3wWgXoJlCU1DsSHFV9/UDZ b7qPDhwM2Gs2A+3ObsDXl8kXbeP8/nwb/8QoGcTDaG+Ca1J2DKjl1stRnmAdzwsNMkiZ 0Kxw== X-Gm-Message-State: AMke39lQocQ6fH1CDH5qhGMQS3jn4pazLQnpaSWqgf211wW1fDu0wrFIkxiYTuBx41ibhe9rBOZxGXAuFXf6Sg== X-Received: by 10.28.111.78 with SMTP id k75mr250577wmc.71.1486110276683; Fri, 03 Feb 2017 00:24:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.24.6 with HTTP; Fri, 3 Feb 2017 00:24:35 -0800 (PST) From: Guy Yur Date: Fri, 3 Feb 2017 10:24:35 +0200 Message-ID: Subject: resolvconf Makefile RESTARTCMD sed after r312992 To: Pedro Giffuni , freebsd-current Content-Type: multipart/mixed; boundary=001a1147df4023b05505479c0385 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 08:24:38 -0000 --001a1147df4023b05505479c0385 Content-Type: text/plain; charset=UTF-8 Hi, In openresolv 3.9.0, the only RESTARTCMD pattern left is @RESTARTCMD@. The '@RESTARTCMD something@' pattern was dropped from pdns_recursor.in. r312992 removed RESTARTCMD_WITH_ARG for @RESTARTCMD something@ but reverted the sed to be '@RESTARTCMD \(.*\)@' and RESTARTCMD= to be the value of RESTARTCMD_WITH_ARG. After the change /sbin/resolvconf has 'RESTARTCMD=@RESTARTCMD@' again. Attaching patch to restore RESTARTCMD=, CMD1=, CMD2= and sed pattern to values before r312992. Thanks, Guy --001a1147df4023b05505479c0385 Content-Type: application/octet-stream; name="resolvconf_RESTARTCMD_sed.patch" Content-Disposition: attachment; filename="resolvconf_RESTARTCMD_sed.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_iypj4mg10 SW5kZXg6IHNiaW4vcmVzb2x2Y29uZi9NYWtlZmlsZQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzYmluL3Jlc29s dmNvbmYvTWFrZWZpbGUJKHJldmlzaW9uIDMxMzEzNykKKysrIHNiaW4vcmVzb2x2Y29uZi9NYWtl ZmlsZQkod29ya2luZyBjb3B5KQpAQCAtMjAsOSArMjAsOSBAQCBTQklORElSPQkvc2JpbgogCiAj IFdlIGRvbid0IGFzc3VtZSB0byByZXN0YXJ0IHRoZSBzZXJ2aWNlcyBpbiAvc2Jpbi4gIFNvLCB0 aG91Z2gKICMgb3VyIHNlcnZpY2UoOCkgaXMgaW4gL3Vzci9zYmluLCB3ZSBjYW4gdXNlIGl0LCBo ZXJlLgotQ01EMT0JCVwxIG9uZXN0YXR1cyA+L2Rldi9udWxsIDI+XCYxCi1DTUQyPQkJXDEgcmVz dGFydAotUkVTVEFSVENNRD0JL3Vzci9zYmluL3NlcnZpY2UgJHtDTUQxfSBcJlwmIC91c3Ivc2Jp bi9zZXJ2aWNlICR7Q01EMn0KK0NNRDE9CQlcXCQkMSBvbmVzdGF0dXMgPi9kZXYvbnVsbCAyPlwm MQorQ01EMj0JCVxcJCQxIHJlc3RhcnQKK1JFU1RBUlRDTUQ9CSIvdXNyL3NiaW4vc2VydmljZSAk e0NNRDF9IFwmXCYgL3Vzci9zYmluL3NlcnZpY2UgJHtDTUQyfSIKIAogLmZvciBmIGluICR7U0NS SVBUU30gJHtGSUxFU30gJHtNQU59CiAke2Z9Ogkke2Z9LmluCkBAIC0yOSw3ICsyOSw3IEBAICR7 Zn06CSR7Zn0uaW4KIAlzZWQJLWUgJ3M6QFNZU0NPTkZESVJAOiR7U1lTQ09ORkRJUn06ZycgXAog CQktZSAnczpATElCRVhFQ0RJUkA6JHtGSUxFU0RJUn06ZycgXAogCQktZSAnczpAVkFSRElSQDok e1ZBUkRJUn06ZycgXAotCQktZSAnczpAUkVTVEFSVENNRCBcKC4qXClAOiR7UkVTVEFSVENNRH06 ZycgXAorCQktZSAnczpAUkVTVEFSVENNREA6JHtSRVNUQVJUQ01EfTpnJyBcCiAJCS1lICdzOkBS Q0RJUkA6JHtSQ0RJUn06ZycgXAogCQktZSAnczpAU0JJTkRJUkA6JHtTQklORElSfTpnJyBcCiAJ CS1lICdzOiB2cG4gOiBuZ1swLTldKiY6ZycgXAo= --001a1147df4023b05505479c0385-- From owner-freebsd-current@freebsd.org Fri Feb 3 12:42:53 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2478CCD0D4; Fri, 3 Feb 2017 12:42:53 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 8E9EE16DE; Fri, 3 Feb 2017 12:42:53 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cZdCV-0004Kq-NV; Fri, 03 Feb 2017 12:42:51 +0000 Date: Fri, 3 Feb 2017 12:42:51 +0000 From: Gary Palmer To: Ultima Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: Re: zfs snapshot_limit is not respected Message-ID: <20170203124251.GA68015@in-addr.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 12:42:53 -0000 On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote: > I recently moved some data on a box with limited space. I decided I should > limit the snapshots so that space would not become an issue. I just check > back a week later to find out the box is hitting the borderline. Doing I > quick check I realized that the snapshot_limit is not being respected. > > # uname -a > FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 10:59:10 > EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/MYKERNEL > amd64 > > # zfs create zroot/bhyve/test > # zfs set snapshot_limit=0 zroot/bhyve/test > # zfs snapshot zroot/bhyve/test@1 > > > # zfs snapshot zroot/bhyve/test@2 > # zfs snapshot zroot/bhyve/test@3 > # zfs list -t snapshot | grep zroot/bhyve/test > zroot/bhyve/test@1 0 - > 88K - > zroot/bhyve/test@2 0 - > 88K - > zroot/bhyve/test@3 0 - > 88K - > # zfs get all zroot/bhyve/test | grep snapshot > zroot/bhyve/test usedbysnapshots 0 - > zroot/bhyve/test snapshot_limit 0 local > zroot/bhyve/test snapshot_count 3 local > > Also wanted to verify 0 was not being mistaken for none. > > # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk > '{print $1}'`; do zfs destroy $snapshot ; done > > # zfs get all zroot/bhyve/test | grep snapshot > zroot/bhyve/test usedbysnapshots 0 - > zroot/bhyve/test snapshot_limit 0 local > zroot/bhyve/test snapshot_count 0 local > > # zfs set snapshot_limit=1 zroot/bhyve/test > # zfs snapshot zroot/bhyve/test@1 > # zfs snapshot zroot/bhyve/test@2 > # zfs snapshot zroot/bhyve/test@3 > # zfs get all zroot/bhyve/test | grep snapshot > zroot/bhyve/test usedbysnapshots 0 - > zroot/bhyve/test snapshot_limit 1 local > zroot/bhyve/test snapshot_count 3 local > > > Also tested on head > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18 > 12:38:52 EST 2017 > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG > amd64 Hi, I suspect this line from the manpage is key: The limit is not enforced if the user is allowed to change the limit Regards, Gary From owner-freebsd-current@freebsd.org Fri Feb 3 15:27:49 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2221CCE701; Fri, 3 Feb 2017 15:27:49 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (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 8F80FC59; Fri, 3 Feb 2017 15:27:49 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yb0-x22c.google.com with SMTP id 123so6869657ybe.3; Fri, 03 Feb 2017 07:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=90z5R+cAE8kRp+53gjHy5SjNSxArbYP8OHsumqA/KhI=; b=kN/HAPFFp2mxF40sPpRcerux4+folvEhDEEJ+JKf6eE2TV7/W8MbG9S5ui5l6JvwlM wRawdPuksTlE3kHOh8FlK2RqaZn/UJjL0iHR0BaJRHwxUT7maWa/rHi2D2ZnBIKYlCf3 8DGg/wCXVfl/lnZpeiKO8gq2SMTM+6xYY1vgnWygPNG7omWxJdi/jsrcbTr4CV37XdF+ xcbVPXAjsSJvwmwgrpBtX1dKsoAkZ+b9fgsadZH+i3v8jksgHEt+5SlSeF/Ldj9/OMps uk2Oc5uYMFECkp7Z6yZg2hm55ytVZDxAKeTZfQUfreUE8bY2onzvpreKBuZeC/ubzFUi GRUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=90z5R+cAE8kRp+53gjHy5SjNSxArbYP8OHsumqA/KhI=; b=MEz5yiywi1GIDNQpmQ8OTVNyGtnZDz1RqUDOjoe0LiChF5SJJrglxeQbgMsdM8TEmd wsIiiRdDn6SeTtCGm9t10q6ZV9Htjjfz/TyD8+RjCOMrIgS+KpyHWi1Cvhj7zzSvziSq cjhmYbrbVjmCiROHI74KI3QcosVeB3ZLMPjqbzKYIB40wjdyGydkkX5bg8FWPI9jUZwx Il6kBBMUcdRZXBM5zDSslqYFGU9u4m5wbCVhzRYMaGM5YPvParbPDh2V5V2fWnhU8R3n diihIRL4KRN5ZDfeJA2PlIJNwWzXoZ3ndx0OxyEOlJkYxoXh2jYDsCOcmCg6jWQJHKZy hJDQ== X-Gm-Message-State: AIkVDXJKncecFJDMjmkV9241CdcxuTYc5V6h4lizevSjsCF+oYUhI7c6ig7km9Xwwv4dV9rJH8vApkZGOthrAA== X-Received: by 10.37.248.2 with SMTP id u2mr6440810ybd.52.1486135668573; Fri, 03 Feb 2017 07:27:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.52.65 with HTTP; Fri, 3 Feb 2017 07:27:48 -0800 (PST) In-Reply-To: <20170203124251.GA68015@in-addr.com> References: <20170203124251.GA68015@in-addr.com> From: Ultima Date: Fri, 3 Feb 2017 10:27:48 -0500 Message-ID: Subject: Re: zfs snapshot_limit is not respected To: Gary Palmer Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 15:27:50 -0000 Hey Gary, You are probably right. Do you know how to "lock" this property by chance? I'v read this exact line several times trying to understand the exact meaning. The "user is allowed to change the limit" I *think* is referring to the zfs allow command. The problem is that I checked the dataset and it is showing no permissions granted to a user. So I guess user in this case is also including the root user, but how does one lock the property from root? I keep going through the manpage looking for something I may have missed but keep coming up empty. Thanks for replying, Ultima On Fri, Feb 3, 2017 at 7:42 AM, Gary Palmer wrote: > On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote: > > I recently moved some data on a box with limited space. I decided I > should > > limit the snapshots so that space would not become an issue. I just check > > back a week later to find out the box is hitting the borderline. Doing I > > quick check I realized that the snapshot_limit is not being respected. > > > > # uname -a > > FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 > 10:59:10 > > EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/ > MYKERNEL > > amd64 > > > > # zfs create zroot/bhyve/test > > # zfs set snapshot_limit=0 zroot/bhyve/test > > # zfs snapshot zroot/bhyve/test@1 > > > > > > # zfs snapshot zroot/bhyve/test@2 > > # zfs snapshot zroot/bhyve/test@3 > > # zfs list -t snapshot | grep zroot/bhyve/test > > zroot/bhyve/test@1 0 - > > 88K - > > zroot/bhyve/test@2 0 - > > 88K - > > zroot/bhyve/test@3 0 - > > 88K - > > # zfs get all zroot/bhyve/test | grep snapshot > > zroot/bhyve/test usedbysnapshots 0 - > > zroot/bhyve/test snapshot_limit 0 local > > zroot/bhyve/test snapshot_count 3 local > > > > Also wanted to verify 0 was not being mistaken for none. > > > > # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk > > '{print $1}'`; do zfs destroy $snapshot ; done > > > > # zfs get all zroot/bhyve/test | grep snapshot > > zroot/bhyve/test usedbysnapshots 0 - > > zroot/bhyve/test snapshot_limit 0 local > > zroot/bhyve/test snapshot_count 0 local > > > > # zfs set snapshot_limit=1 zroot/bhyve/test > > # zfs snapshot zroot/bhyve/test@1 > > # zfs snapshot zroot/bhyve/test@2 > > # zfs snapshot zroot/bhyve/test@3 > > # zfs get all zroot/bhyve/test | grep snapshot > > zroot/bhyve/test usedbysnapshots 0 - > > zroot/bhyve/test snapshot_limit 1 local > > zroot/bhyve/test snapshot_count 3 local > > > > > > Also tested on head > > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18 > > 12:38:52 EST 2017 > > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG > > amd64 > > Hi, > > I suspect this line from the manpage is key: > > The limit is not enforced if the user is allowed to change the limit > > Regards, > > Gary > From owner-freebsd-current@freebsd.org Fri Feb 3 16:12:10 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A6E0CCF536; Fri, 3 Feb 2017 16:12:10 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from mail.in-addr.com (mail.in-addr.com [IPv6:2a01:4f8:191:61e8::2525:2525]) (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 DA64E8C7; Fri, 3 Feb 2017 16:12:09 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by mail.in-addr.com with local (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cZgT2-0003hV-22; Fri, 03 Feb 2017 16:12:08 +0000 Date: Fri, 3 Feb 2017 16:12:07 +0000 From: Gary Palmer To: Ultima Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: Re: zfs snapshot_limit is not respected Message-ID: <20170203161207.GB68015@in-addr.com> References: <20170203124251.GA68015@in-addr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on mail.in-addr.com); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:12:10 -0000 On Fri, Feb 03, 2017 at 10:27:48AM -0500, Ultima wrote: > Hey Gary, > > You are probably right. Do you know how to "lock" this property by chance? > I'v read this exact line several times trying to understand the exact > meaning. The "user is allowed to change the limit" I *think* is referring > to the zfs allow command. The problem is that I checked the dataset and it > is showing no permissions granted to a user. So I guess user in this case > is also including the root user, but how does one lock the property from > root? I keep going through the manpage looking for something I may have > missed but keep coming up empty. Hi, I suspect you can't lock root out, but you could allow a different user to create snapshots. If you use that user to create snapshots, they should be subject to the snapshot limit, assuming you don't let them change that property. Regards, Gary > Thanks for replying, > Ultima > > On Fri, Feb 3, 2017 at 7:42 AM, Gary Palmer wrote: > > > On Thu, Feb 02, 2017 at 09:31:58PM -0500, Ultima wrote: > > > I recently moved some data on a box with limited space. I decided I > > should > > > limit the snapshots so that space would not become an issue. I just check > > > back a week later to find out the box is hitting the borderline. Doing I > > > quick check I realized that the snapshot_limit is not being respected. > > > > > > # uname -a > > > FreeBSD R1 11.0-STABLE FreeBSD 11.0-STABLE #17 r312232: Sun Jan 15 > > 10:59:10 > > > EST 2017 root@S1:/usr/src/11-STABLE/obj/usr/src/11-STABLE/src/sys/ > > MYKERNEL > > > amd64 > > > > > > # zfs create zroot/bhyve/test > > > # zfs set snapshot_limit=0 zroot/bhyve/test > > > # zfs snapshot zroot/bhyve/test@1 > > > > > > > > > # zfs snapshot zroot/bhyve/test@2 > > > # zfs snapshot zroot/bhyve/test@3 > > > # zfs list -t snapshot | grep zroot/bhyve/test > > > zroot/bhyve/test@1 0 - > > > 88K - > > > zroot/bhyve/test@2 0 - > > > 88K - > > > zroot/bhyve/test@3 0 - > > > 88K - > > > # zfs get all zroot/bhyve/test | grep snapshot > > > zroot/bhyve/test usedbysnapshots 0 - > > > zroot/bhyve/test snapshot_limit 0 local > > > zroot/bhyve/test snapshot_count 3 local > > > > > > Also wanted to verify 0 was not being mistaken for none. > > > > > > # for snapshot in `zfs list -t snapshot | grep zroot/bhyve/test | awk > > > '{print $1}'`; do zfs destroy $snapshot ; done > > > > > > # zfs get all zroot/bhyve/test | grep snapshot > > > zroot/bhyve/test usedbysnapshots 0 - > > > zroot/bhyve/test snapshot_limit 0 local > > > zroot/bhyve/test snapshot_count 0 local > > > > > > # zfs set snapshot_limit=1 zroot/bhyve/test > > > # zfs snapshot zroot/bhyve/test@1 > > > # zfs snapshot zroot/bhyve/test@2 > > > # zfs snapshot zroot/bhyve/test@3 > > > # zfs get all zroot/bhyve/test | grep snapshot > > > zroot/bhyve/test usedbysnapshots 0 - > > > zroot/bhyve/test snapshot_limit 1 local > > > zroot/bhyve/test snapshot_count 3 local > > > > > > > > > Also tested on head > > > FreeBSD S1 12.0-CURRENT FreeBSD 12.0-CURRENT #26 r312388: Wed Jan 18 > > > 12:38:52 EST 2017 > > > root@S1:/usr/src/head/obj/usr/src/head/src/sys/MYKERNEL-NODEBUG > > > amd64 > > > > Hi, > > > > I suspect this line from the manpage is key: > > > > The limit is not enforced if the user is allowed to change the limit > > > > Regards, > > > > Gary > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Fri Feb 3 16:44:02 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84919CCE050; Fri, 3 Feb 2017 16:44:02 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::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 35655177B; Fri, 3 Feb 2017 16:44:02 +0000 (UTC) (envelope-from ultima1252@gmail.com) Received: by mail-yb0-x231.google.com with SMTP id w194so7664274ybe.0; Fri, 03 Feb 2017 08:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DSwEZUv9I7ly4VSc/iYaj5I+vRlU7Wvz5KkTTdiRjdg=; b=pHg+aUedD3UxK6K17pXg8f2p/Uv+DID12DY4TagUnfI9+a40B0z8b+E17K+PCTqin0 l+Hu0oqMTwxnftRS0nEDBQqTazOmbmxt9uUTODJMO09rjAi9Z2EnViEcUB8wd2KW1qQF 4DWueGjrMCIP1msYSFVDLlMTmTscYA9yIkpKJVhNhXrNIH+04UodIJQZwhNuahIeJsyK BfMPBFXn9Yvug029zLhnE6jysptop+OGqZi6ytW+p5BulXjP1eTvYLlnR+HuPYEWmydz likhWGGe5P0RCA5lAaHKqiP3VoV/IHZmyvTrZzdTkkSHah2GQnR/6UqB5g92W3KRkMXl z9nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DSwEZUv9I7ly4VSc/iYaj5I+vRlU7Wvz5KkTTdiRjdg=; b=Mol+9YYXydtn643+HbS7w3VHf7SJjJddNthiHwk3EVHelbk9uNx4WdoxyTHvtSJC0J ZD/twrBJ7uTkcyJv8abciuGhuR8hHFUnX/9znQA+6mvBVxhp9U3Y/f81TcPpC3G7zf+1 inEkGQijCarhv4AMB+wM88g2Lg0hAI+Ne0jJ5uBfvdSr8wK55N67yzx3CqulfJwvm044 cZrqxeOVaeZjCdMYBz6sulKgWaboVOH+aOhTnrSYkxsKqXqUClCzlOZYNsIYJre2kEyT PMzMVvNSL2DUUTqQYTYRM34fKMx/NK464tiJDidrtS1nT7s/kG5PPgSVNX7GDDdsHrxs VLgg== X-Gm-Message-State: AIkVDXKuo/GLw/VC5oZiZowefaQT4ZonC2CJwruT/c6ZdnjLpUNXYtR7wgep2HFu7voru55DEIGEwl1N27nAUg== X-Received: by 10.37.56.208 with SMTP id f199mr6592142yba.94.1486140241182; Fri, 03 Feb 2017 08:44:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.52.65 with HTTP; Fri, 3 Feb 2017 08:44:00 -0800 (PST) In-Reply-To: <20170203161207.GB68015@in-addr.com> References: <20170203124251.GA68015@in-addr.com> <20170203161207.GB68015@in-addr.com> From: Ultima Date: Fri, 3 Feb 2017 11:44:00 -0500 Message-ID: Subject: Re: zfs snapshot_limit is not respected To: Gary Palmer Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:44:02 -0000 Yes just tested this and it is how it works. Thanks for the explanation. Ultima From owner-freebsd-current@freebsd.org Fri Feb 3 17:45:28 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BF49CCFA22 for ; Fri, 3 Feb 2017 17:45:28 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm11-vm6.bullet.mail.ne1.yahoo.com (nm11-vm6.bullet.mail.ne1.yahoo.com [98.138.91.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50B4CB8A for ; Fri, 3 Feb 2017 17:45:27 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1486143740; bh=AA1QcLg3I8xrXc5bHJjjcswukLipMGKUKHErXAXx8BI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=jkR6mVRy4bv/VL7k/OoBmniG7hjD21ADJ0IKybe860OznXe1QRMn8fwDrYxxFp7xRLKM6oQz3DTITjZyMg2vgmW+W6y15DnwSe2HAPszQ4AVB0UeOYW4jG/Z2OJSpcECXRAI9YaSlZ6HOqjLnSnyTkMUZM62PyaMxlc28tWFjfy5bONIX6wVsRO/lwaaxgSJo8KST/owuYVCF4HWyetccfydKlGEVRbfME9JxyQEIu7st/ESs8Mt2vqVC7q6EX13R32P/zhCeyYDKuXWiALdV1HdmRl8+VseyWiatieEe3VhXjXPSoq6EOHIROjXf83yPfR3mQ3DuTNXgs1ZQcwgIg== Received: from [98.138.101.132] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 03 Feb 2017 17:42:20 -0000 Received: from [98.138.84.46] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 03 Feb 2017 17:42:20 -0000 Received: from [127.0.0.1] by smtp114.mail.ne1.yahoo.com with NNFMP; 03 Feb 2017 17:42:20 -0000 X-Yahoo-Newman-Id: 405895.57873.bm@smtp114.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: cjFnT4QVM1l4tUypNVC5t_rW8hfNSgn3twlyQ57_d7cjIpj XWTezA8OEXmGompRu.koIaFE4pks_pST0t76xJSdBNU1NVx.M4UQMq1k.rvm tAnZRfr793poMEb1yi.QKgnYZnqZn1nVrdN5c_PikNuIDpoCm1qxK0JRjF_q d3vmZWP1ds_W.Dg8rX4B70vWFjjhNeROuY7qgQcj3lz3j8Ugcs0giMfm1.G7 jn.RT5KHw7IuGqt4uNvv5WLWCmQBRvo1MDTmdDA7yysda.oVIPIRZNl.3iRF OQn2b97DC7342BhS3ltvPZ0hh4YXbqBvBv6XHS.Ky8zcYXuJ45xxC8mei_z3 Q.xqLrBlriwsnIYNJD2fqYVZhfabMYSYjT_tHLnLnGPYGcxAYOrc7HoRjIGk Gck1lXD85AHlZaB2SzwkVTgUGuhHoboVPgTIFiYRo8kR3o.HkVC8vahXu0d. Rb00Lur5mf4EZ7rNh3KJw9jsTn.bcznWByNmyzbRl9DqANQ0JjJuKj3FKi3i FU_Jh2uQmEnFfzHbb4RNzqPBDnCaGw1uJplamewB7GR91xvo- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: resolvconf Makefile RESTARTCMD sed after r312992 To: Guy Yur , freebsd-current References: From: Pedro Giffuni Message-ID: <546163e8-e62c-bf8e-3a2b-c26cc4b637b8@FreeBSD.org> Date: Fri, 3 Feb 2017 12:44:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:45:28 -0000 Committed as r313160. Thanks! Pedro. On 2/3/2017 3:24 AM, Guy Yur wrote: > Hi, > > In openresolv 3.9.0, the only RESTARTCMD pattern left is @RESTARTCMD@. > The '@RESTARTCMD something@' pattern was dropped from pdns_recursor.in. > > r312992 removed RESTARTCMD_WITH_ARG for @RESTARTCMD something@ but > reverted the sed to be '@RESTARTCMD \(.*\)@' and RESTARTCMD= to be > the value of RESTARTCMD_WITH_ARG. > > After the change /sbin/resolvconf has 'RESTARTCMD=@RESTARTCMD@' again. > > Attaching patch to restore RESTARTCMD=, CMD1=, CMD2= and sed pattern > to values before r312992. > > Thanks, > Guy From owner-freebsd-current@freebsd.org Sat Feb 4 06:43:40 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94128CD0CBE for ; Sat, 4 Feb 2017 06:43:40 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from heemeyer.club (heemeyer.club [108.61.204.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "heemeyer.club", Issuer "heemeyer.club" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 76D2712D0 for ; Sat, 4 Feb 2017 06:43:39 +0000 (UTC) (envelope-from dchagin@chd.heemeyer.club) Received: from chd.heemeyer.club (dchagin.static.corbina.ru [78.107.232.239]) by heemeyer.club (8.15.2/8.15.1) with ESMTPS id v146hTmE033243 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 4 Feb 2017 06:43:32 GMT (envelope-from dchagin@chd.heemeyer.club) X-Authentication-Warning: heemeyer.club: Host dchagin.static.corbina.ru [78.107.232.239] claimed to be chd.heemeyer.club Received: from chd.heemeyer.club (localhost [127.0.0.1]) by chd.heemeyer.club (8.15.2/8.15.1) with ESMTPS id v146hS1h002654 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 4 Feb 2017 09:43:28 +0300 (MSK) (envelope-from dchagin@chd.heemeyer.club) Received: (from dchagin@localhost) by chd.heemeyer.club (8.15.2/8.15.2/Submit) id v146hS78002653 for freebsd-current@freebsd.org; Sat, 4 Feb 2017 09:43:28 +0300 (MSK) (envelope-from dchagin) Date: Sat, 4 Feb 2017 09:43:28 +0300 From: Chagin Dmitry To: freebsd-current@freebsd.org Subject: arp panic Message-ID: <20170204064328.GA2641@chd.heemeyer.club> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 06:43:40 -0000 chd.heemeyer.club dumped core - see /var/crash/vmcore.8 Sat Feb 4 09:01:35 MSK 2017 FreeBSD chd.heemeyer.club 12.0-CURRENT FreeBSD 12.0-CURRENT #237 r313172+c19dc6ff09(lemul): Fri Feb 3 22:38:44 MSK 2017 root@chd.heemeyer.club:/home/rootobj/home/git/head/sys/YOY amd64 panic: GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD] Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. done. Unread portion of the kernel message buffer: Fatal trap 9: general protection fault while in kernel mode cpuid = 3; apic id = 03 instruction pointer = 0x20:0xffffffff807833ed stack pointer = 0x28:0xfffffe032db70430 frame pointer = 0x28:0xfffffe032db704f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock (0)) Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /usr/lib/debug//boot/kernel/drm2.ko.debug...done. done. Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/linprocfs.ko.debug...done. done. Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from /usr/lib/debug//boot/kernel/pseudofs.ko.debug...done. done. Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux_common.ko.debug...done. done. Reading symbols from /boot/kernel/procfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/procfs.ko.debug...done. done. Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /usr/lib/debug//boot/kernel/i915kms.ko.debug...done. done. doadump (textdump=766966752) at /home/git/head/sys/kern/kern_shutdown.c:318 318 dumptid = curthread->td_tid; (kgdb) #0 doadump (textdump=766966752) at /home/git/head/sys/kern/kern_shutdown.c:318 #1 0xffffffff803fbcc5 in db_fncall_generic (addr=-2139566720, rv=0xfffffe032db6fb90, nargs=0, args=0xfffffe032db6fba0) at /home/git/head/sys/ddb/db_command.c:581 #2 0xffffffff803fb284 in db_fncall (dummy1=-2185371386672, dummy2=false, dummy3=0, dummy4=0xfffffe032db6fcd0 "\360\374\266-\003\376\377\377") at /home/git/head/sys/ddb/db_command.c:629 #3 0xffffffff803fabee in db_command ( last_cmdp=0xffffffff81703940 , cmd_table=0x0, dopager=1) at /home/git/head/sys/ddb/db_command.c:453 #4 0xffffffff803fa789 in db_command_loop () at /home/git/head/sys/ddb/db_command.c:506 #5 0xffffffff803ff5da in db_trap (type=9, code=0) at /home/git/head/sys/ddb/db_main.c:248 #6 0xffffffff807f6b3f in kdb_trap (type=9, code=0, tf=0xfffffe032db70370) at /home/git/head/sys/kern/subr_kdb.c:654 #7 0xffffffff80ceb21c in trap_fatal (frame=0xfffffe032db70370, eva=0) at /home/git/head/sys/amd64/amd64/trap.c:819 #8 0xffffffff80cea651 in trap (frame=0xfffffe032db70370) at /home/git/head/sys/amd64/amd64/trap.c:553 #9 0xffffffff80cebd2a in trap_check (frame=0xfffffe032db70370) at /home/git/head/sys/amd64/amd64/trap.c:625 #10 #11 0xffffffff807833ed in _rw_wlock_cookie (c=0xdeadc0dedeadc2de, file=0xffffffff80ea3d10 "/home/git/head/sys/netinet/if_ether.c", line=287) at /home/git/head/sys/kern/kern_rwlock.c:295 #12 0xffffffff80a2c723 in arptimer (arg=0xfffff80007d67a00) at /home/git/head/sys/netinet/if_ether.c:287 #13 0xffffffff807b60bc in softclock_call_cc (c=0xfffff80007d67ab8, cc=0xffffffff81a31a00 , direct=0) at /home/git/head/sys/kern/kern_timeout.c:729 #14 0xffffffff807b68ec in softclock (arg=0xffffffff81a31a00 ) at /home/git/head/sys/kern/kern_timeout.c:867 #15 0xffffffff807350c8 in intr_event_execute_handlers (p=0xfffff80003df9000, ie=0xfffff80003deea00) at /home/git/head/sys/kern/kern_intr.c:1262 #16 0xffffffff80735e57 in ithread_execute_handlers (p=0xfffff80003df9000, ie=0xfffff80003deea00) at /home/git/head/sys/kern/kern_intr.c:1275 #17 0xffffffff80735c86 in ithread_loop (arg=0xfffff80003e30060) at /home/git/head/sys/kern/kern_intr.c:1356 #18 0xffffffff807306ee in fork_exit ( callout=0xffffffff80735b10 , arg=0xfffff80003e30060, frame=0xfffffe032db70ac0) at /home/git/head/sys/kern/kern_fork.c:1038 #19 (kgdb) (kgdb) up 12 #12 0xffffffff80a2c723 in arptimer (arg=0xfffff80007d67a00) at /home/git/head/sys/netinet/if_ether.c:287 287 IF_AFDATA_LOCK(ifp); (kgdb) p *(struct llentry *) arg $1 = {lle_next = {le_next = 0x0, le_prev = 0xfffff8000d5cf540}, r_l3addr = {addr4 = {s_addr = 0x101a8c0}, addr6 = { __u6_addr = {__u6_addr8 = "\300\250\001\001", '\000' , __u6_addr16 = {0xa8c0, 0x101, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0x101a8c0, 0x0, 0x0, 0x0}}}}, r_linkdata = "\220\357h\374&L|z\221\230\200F\b\000\000\000\000\000\000\000\000\000\000", r_hdrlen = 0xe, spare0 = "\000\000", r_flags = 0x1, r_skip_req = 0x1, lle_tbl = 0xfffff8000d5cf600, lle_head = 0xfffff8000d5cf540, lle_free = 0xffffffff80a3e160 , la_hold = 0x0, la_numheld = 0x0, la_expire = 0x4ea, la_flags = 0x1, la_asked = 0x0, la_preempt = 0x5, ln_state = 0x2, ln_router = 0x0, ln_ntick = 0x0, lle_remtime = 0x0, lle_hittime = 0x0, lle_refcnt = 0x1, ll_addr = 0xfffff80007d67a20 "\220\357h\374&L|z\221\230\200F\b", lle_chain = {le_next = 0x0, le_prev = 0x0}, lle_timer = {c_links = {le = {le_next = 0xfffff80007d8b448, le_prev = 0xffffffff81a31b18 }, sle = { sle_next = 0xfffff80007d8b448}, tqe = {tqe_next = 0xfffff80007d8b448, tqe_prev = 0xffffffff81a31b18 }}, c_time = 0x4ead51d7ecc, c_precision = 0xfffffed, c_arg = 0xfffff80007d67a00, c_func = 0xffffffff80a2bff0 , c_lock = 0x0, c_flags = 0x0, c_iflags = 0x90, c_cpu = 0x0}, lle_lock = {lock_object = {lo_name = 0xffffffff80e8699c "lle", lo_flags = 0x5630000, lo_data = 0x0, lo_witness = 0xfffffe0000afd700}, rw_lock = 0x1}, req_mtx = {lock_object = { lo_name = 0xffffffff80ea5888 "lle req", lo_flags = 0x1030000, lo_data = 0x0, lo_witness = 0xfffffe0000afd780}, mtx_lock = 0x4}} (kgdb) p *(*(struct llentry *) arg)->lle_tbl $2 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = 0xdeadc0de, llt_hsize = 0xdeadc0de, lle_head = 0xdeadc0dedeadc0de, llt_ifp = 0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de, llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry = 0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de, llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de, llt_match_prefix = 0xdeadc0dedeadc0de, llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry = 0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de, llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry = 0xdeadc0dedeadc0de, llt_free_tbl = 0xdeadc0dedeadc0de} From owner-freebsd-current@freebsd.org Sat Feb 4 08:24:35 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0715ECD08E3 for ; Sat, 4 Feb 2017 08:24:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 A90792A9; Sat, 4 Feb 2017 08:24:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 277B61FE025; Sat, 4 Feb 2017 09:23:39 +0100 (CET) Subject: Re: arp panic To: Chagin Dmitry , freebsd-current@freebsd.org References: <20170204064328.GA2641@chd.heemeyer.club> From: Hans Petter Selasky Message-ID: <85d72953-80be-cf99-c532-8e738389d97b@selasky.org> Date: Sat, 4 Feb 2017 09:23:46 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170204064328.GA2641@chd.heemeyer.club> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 08:24:35 -0000 On 02/04/17 07:43, Chagin Dmitry wrote: > > chd.heemeyer.club dumped core - see /var/crash/vmcore.8 > > Sat Feb 4 09:01:35 MSK 2017 > > FreeBSD chd.heemeyer.club 12.0-CURRENT FreeBSD 12.0-CURRENT #237 r313172+c19dc6ff09(lemul): Fri Feb 3 22:38:44 MSK 2017 root@chd.heemeyer.club:/home/rootobj/home/git/head/sys/YOY amd64 > > panic: > > GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD] > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-portbld-freebsd12.0". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done. > done. > > Unread portion of the kernel message buffer: > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 3; apic id = 03 > instruction pointer = 0x20:0xffffffff807833ed > stack pointer = 0x28:0xfffffe032db70430 > frame pointer = 0x28:0xfffffe032db704f0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 11 (swi4: clock (0)) > > Reading symbols from /boot/kernel/drm2.ko...Reading symbols from /usr/lib/debug//boot/kernel/drm2.ko.debug...done. > done. > Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/linprocfs.ko.debug...done. > done. > Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from /usr/lib/debug//boot/kernel/pseudofs.ko.debug...done. > done. > Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from /usr/lib/debug//boot/kernel/linux_common.ko.debug...done. > done. > Reading symbols from /boot/kernel/procfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/procfs.ko.debug...done. > done. > Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /usr/lib/debug//boot/kernel/i915kms.ko.debug...done. > done. > doadump (textdump=766966752) at /home/git/head/sys/kern/kern_shutdown.c:318 > 318 dumptid = curthread->td_tid; > (kgdb) #0 doadump (textdump=766966752) > at /home/git/head/sys/kern/kern_shutdown.c:318 > #1 0xffffffff803fbcc5 in db_fncall_generic (addr=-2139566720, > rv=0xfffffe032db6fb90, nargs=0, args=0xfffffe032db6fba0) > at /home/git/head/sys/ddb/db_command.c:581 > #2 0xffffffff803fb284 in db_fncall (dummy1=-2185371386672, dummy2=false, > dummy3=0, dummy4=0xfffffe032db6fcd0 "\360\374\266-\003\376\377\377") > at /home/git/head/sys/ddb/db_command.c:629 > #3 0xffffffff803fabee in db_command ( > last_cmdp=0xffffffff81703940 , cmd_table=0x0, dopager=1) > at /home/git/head/sys/ddb/db_command.c:453 > #4 0xffffffff803fa789 in db_command_loop () > at /home/git/head/sys/ddb/db_command.c:506 > #5 0xffffffff803ff5da in db_trap (type=9, code=0) > at /home/git/head/sys/ddb/db_main.c:248 > #6 0xffffffff807f6b3f in kdb_trap (type=9, code=0, tf=0xfffffe032db70370) > at /home/git/head/sys/kern/subr_kdb.c:654 > #7 0xffffffff80ceb21c in trap_fatal (frame=0xfffffe032db70370, eva=0) > at /home/git/head/sys/amd64/amd64/trap.c:819 > #8 0xffffffff80cea651 in trap (frame=0xfffffe032db70370) > at /home/git/head/sys/amd64/amd64/trap.c:553 > #9 0xffffffff80cebd2a in trap_check (frame=0xfffffe032db70370) > at /home/git/head/sys/amd64/amd64/trap.c:625 > #10 > #11 0xffffffff807833ed in _rw_wlock_cookie (c=0xdeadc0dedeadc2de, > file=0xffffffff80ea3d10 "/home/git/head/sys/netinet/if_ether.c", line=287) > at /home/git/head/sys/kern/kern_rwlock.c:295 > #12 0xffffffff80a2c723 in arptimer (arg=0xfffff80007d67a00) > at /home/git/head/sys/netinet/if_ether.c:287 > #13 0xffffffff807b60bc in softclock_call_cc (c=0xfffff80007d67ab8, > cc=0xffffffff81a31a00 , direct=0) > at /home/git/head/sys/kern/kern_timeout.c:729 > #14 0xffffffff807b68ec in softclock (arg=0xffffffff81a31a00 ) > at /home/git/head/sys/kern/kern_timeout.c:867 > #15 0xffffffff807350c8 in intr_event_execute_handlers (p=0xfffff80003df9000, > ie=0xfffff80003deea00) at /home/git/head/sys/kern/kern_intr.c:1262 > #16 0xffffffff80735e57 in ithread_execute_handlers (p=0xfffff80003df9000, > ie=0xfffff80003deea00) at /home/git/head/sys/kern/kern_intr.c:1275 > #17 0xffffffff80735c86 in ithread_loop (arg=0xfffff80003e30060) > at /home/git/head/sys/kern/kern_intr.c:1356 > #18 0xffffffff807306ee in fork_exit ( > callout=0xffffffff80735b10 , arg=0xfffff80003e30060, > frame=0xfffffe032db70ac0) at /home/git/head/sys/kern/kern_fork.c:1038 > #19 > (kgdb) > > (kgdb) up 12 > #12 0xffffffff80a2c723 in arptimer (arg=0xfffff80007d67a00) at /home/git/head/sys/netinet/if_ether.c:287 > 287 IF_AFDATA_LOCK(ifp); > > (kgdb) p *(struct llentry *) arg > $1 = {lle_next = {le_next = 0x0, le_prev = 0xfffff8000d5cf540}, r_l3addr = {addr4 = {s_addr = 0x101a8c0}, addr6 = { > __u6_addr = {__u6_addr8 = "\300\250\001\001", '\000' , __u6_addr16 = {0xa8c0, 0x101, 0x0, 0x0, > 0x0, 0x0, 0x0, 0x0}, __u6_addr32 = {0x101a8c0, 0x0, 0x0, 0x0}}}}, > r_linkdata = "\220\357h\374&L|z\221\230\200F\b\000\000\000\000\000\000\000\000\000\000", r_hdrlen = 0xe, > spare0 = "\000\000", r_flags = 0x1, r_skip_req = 0x1, lle_tbl = 0xfffff8000d5cf600, lle_head = 0xfffff8000d5cf540, > lle_free = 0xffffffff80a3e160 , la_hold = 0x0, la_numheld = 0x0, la_expire = 0x4ea, > la_flags = 0x1, la_asked = 0x0, la_preempt = 0x5, ln_state = 0x2, ln_router = 0x0, ln_ntick = 0x0, > lle_remtime = 0x0, lle_hittime = 0x0, lle_refcnt = 0x1, > ll_addr = 0xfffff80007d67a20 "\220\357h\374&L|z\221\230\200F\b", lle_chain = {le_next = 0x0, le_prev = 0x0}, > lle_timer = {c_links = {le = {le_next = 0xfffff80007d8b448, le_prev = 0xffffffff81a31b18 }, sle = { > sle_next = 0xfffff80007d8b448}, tqe = {tqe_next = 0xfffff80007d8b448, > tqe_prev = 0xffffffff81a31b18 }}, c_time = 0x4ead51d7ecc, c_precision = 0xfffffed, > c_arg = 0xfffff80007d67a00, c_func = 0xffffffff80a2bff0 , c_lock = 0x0, c_flags = 0x0, c_iflags = 0x90, > c_cpu = 0x0}, lle_lock = {lock_object = {lo_name = 0xffffffff80e8699c "lle", lo_flags = 0x5630000, lo_data = 0x0, > lo_witness = 0xfffffe0000afd700}, rw_lock = 0x1}, req_mtx = {lock_object = { > lo_name = 0xffffffff80ea5888 "lle req", lo_flags = 0x1030000, lo_data = 0x0, lo_witness = 0xfffffe0000afd780}, > mtx_lock = 0x4}} > > (kgdb) p *(*(struct llentry *) arg)->lle_tbl > $2 = {llt_link = {sle_next = 0xdeadc0dedeadc0de}, llt_af = 0xdeadc0de, llt_hsize = 0xdeadc0de, > lle_head = 0xdeadc0dedeadc0de, llt_ifp = 0xdeadc0dedeadc0de, llt_lookup = 0xdeadc0dedeadc0de, > llt_alloc_entry = 0xdeadc0dedeadc0de, llt_delete_entry = 0xdeadc0dedeadc0de, llt_prefix_free = 0xdeadc0dedeadc0de, > llt_dump_entry = 0xdeadc0dedeadc0de, llt_hash = 0xdeadc0dedeadc0de, llt_match_prefix = 0xdeadc0dedeadc0de, > llt_free_entry = 0xdeadc0dedeadc0de, llt_foreach_entry = 0xdeadc0dedeadc0de, llt_link_entry = 0xdeadc0dedeadc0de, > llt_unlink_entry = 0xdeadc0dedeadc0de, llt_fill_sa_entry = 0xdeadc0dedeadc0de, llt_free_tbl = 0xdeadc0dedeadc0de} There are some known issues described here: https://reviews.freebsd.org/D4605 --HPS