Date: Fri, 3 Apr 2015 17:31:37 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Emeric POUPON <emeric.poupon@stormshield.eu> Cc: Hans Petter Selasky <hps@selasky.org>, Mateusz Guzik <mjguzik@gmail.com>, src-committers@freebsd.org, Ian Lepore <ian@freebsd.org>, svn-src-all@freebsd.org, Gleb Smirnoff <glebius@FreeBSD.org>, svn-src-head@freebsd.org Subject: Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf Message-ID: <alpine.BSF.2.11.1504031728380.64391@fledge.watson.org> In-Reply-To: <206317407.27296349.1428068318117.JavaMail.zimbra@stormshield.eu> References: <551DA5EA.1080908@selasky.org> <6DF5FB51-8135-4144-BD3A-6E4127A23AA7@FreeBSD.org> <551E5C38.7070203@selasky.org> <78DD67BD-621C-451D-8E30-EC9BF396716F@FreeBSD.org> <551E6E72.8050208@selasky.org> <20150403112927.GQ64665@FreeBSD.org> <551E8A96.6030806@selasky.org> <551E906B.3010900@selasky.org> <206317407.27296349.1428068318117.JavaMail.zimbra@stormshield.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Apr 2015, Emeric POUPON wrote: > A good ip id random would be certainly better. But the current > implementation is far from being optimized: a lock is being held inside > arc4rand, and another one for protecting the ip_id internals. We already > have contention problems with the IV generated for ESP packets. The > randomized ip id, using this implementation, is my opinion not an acceptable > solution. Presumably, arc4random() should draw from per-CPU PRNGs to avoid contention, which would have positive scalability effects elsewhere in the stack as well. It is, of course, important that they be seeded independently in order to provide different pseudo-random number sequences! However, the point made earlier in the thread holds: I'm not convinced that our IP ID randomisation is suitable for use given conflation of the IP ID spaces. There's just too much chance of a collision if you are actually seeing a lot of fragmentation with multiple 2-tuple pairs. Robert > > Regards, > > Emeric > > > ----- Mail original ----- > De: "Hans Petter Selasky" <hps@selasky.org> > À: "Gleb Smirnoff" <glebius@FreeBSD.org> > Cc: "Mateusz Guzik" <mjguzik@gmail.com>, "Ian Lepore" <ian@freebsd.org>, svn-src-all@freebsd.org, src-committers@freebsd.org, "Robert N. M. Watson" <rwatson@FreeBSD.org>, svn-src-head@freebsd.org > Envoyé: Vendredi 3 Avril 2015 15:06:51 > Objet: Re: svn commit: r280971 - in head: contrib/ipfilter/tools share/man/man4 sys/contrib/ipfilter/netinet sys/netinet sys/netipsec sys/netpfil/pf > > On 04/03/15 14:41, Hans Petter Selasky wrote: >> On 04/03/15 13:29, Gleb Smirnoff wrote: >>> On Fri, Apr 03, 2015 at 12:41:54PM +0200, Hans Petter Selasky wrote: >>> H> "ip_do_randomid" is zero by default, and is not documented anywhere: >>> H> >>> H> grep -r ip_do_randomid share/ >>> >>> It is documented in inet(4). >>> >>> The actual sysctl knob doesn't match the kernel symbol name, which is >>> allowed in sysctl(9). >>> >> >> Hi, >> >> Will you mind if I rephrase that paragraph in the "inet.4" manual page >> from: >> >> "This closes a minor information leak which allows remote observers to >> determine the rate of packet generation on the machine by watching the >> counter." >> >> Into: >> >> "This prevents high-speed information exchange between internal and >> external observers using packet frequency modulation. An outside >> observer can ping the outside facing port at a fixed rate watching the >> counter. An inside observer can ping the inside facing port watching the >> same counter. Even though packets don't flow between the two ports, data >> can be exchanged by watching changes in the packet rate. It is believed >> that data can be exchanged in Kb/s range this way. Setting this sysctl >> also prevents remote and internal observers to determine the rate of >> packet generation on the machine by watching the counter." >> > > Hi, > > Maybe there will be some new applications after this discovery. No need > for uPnP any more. Could be nice to send text messages through > firewalls. Depends how many implement the IP ID counting the same way > like FreeBSD does ;-) > > --HPS > > _______________________________________________ > svn-src-all@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/svn-src-all > To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" > > From owner-svn-src-head@FreeBSD.ORG Fri Apr 3 16:37:53 2015 Return-Path: <owner-svn-src-head@FreeBSD.ORG> Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C90F842D; Fri, 3 Apr 2015 16:37:53 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C73D3F8; Fri, 3 Apr 2015 16:37:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id t33GbEjx082093; Fri, 3 Apr 2015 19:37:14 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Fri, 3 Apr 2015 19:37:14 +0300 (MSK) From: Dmitry Morozovsky <marck@rinet.ru> To: Alexander Motin <mav@freebsd.org> Subject: Re: svn commit: r281026 - in head/sys: cddl/contrib/opensolaris/uts/common/fs/zfs kern sys In-Reply-To: <201504031445.t33EjnJx099446@svn.freebsd.org> Message-ID: <alpine.BSF.2.00.1504031936290.81977@woozle.rinet.ru> References: <201504031445.t33EjnJx099446@svn.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Fri, 03 Apr 2015 19:37:14 +0300 (MSK) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Fri, 03 Apr 2015 16:37:53 -0000 Alexander, On Fri, 3 Apr 2015, Alexander Motin wrote: > Author: mav > Date: Fri Apr 3 14:45:48 2015 > New Revision: 281026 > URL: https://svnweb.freebsd.org/changeset/base/281026 > > Log: > Make ZFS ARC track both KVA usage and fragmentation. > > Even on Illumos, with its much larger KVA, ZFS ARC steps back if KVA usage > reaches certain threshold (3/4 on i386 or 16/17 otherwise). FreeBSD has > even less KVA, but had no such limit on archs with direct map as amd64. > As result, on machines with a lot of RAM, during load with very small user- > space memory pressure, such as `zfs send`, it was possible to reach state, > when there is enough both physical RAM and KVA (I've seen up to 25-30%), > but no continuous KVA range to allocate even single 128KB I/O request. > > Address this situation from two sides: > - restore KVA usage limitations in a way the most close to Illumos; > - introduce new requirement for KVA fragmentation, specifying that we > should have at least one sequential KVA range of zfs_max_recordsize bytes. > > Experiments show that first limitation done alone is not sufficient. On > machine with 64GB of RAM it is sometimes needed to drop up to half of ARC > size to get at leats one 1MB KVA chunk. Statically limiting ARC to half > of KVA/RAM is too strict, so second limitation makes it to work in cycles: > accumulate trash up to certain critical mass, do massive spring-cleaning, > and then start littering again. :) > > MFC after: 1 month Wow. Excellent dig, thank you. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1504031728380.64391>