From owner-freebsd-current@FreeBSD.ORG Sun Jul 27 07:40:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF23DA5E for ; Sun, 27 Jul 2014 07:40:55 +0000 (UTC) Received: from dnvrco-queue03.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9A90F2F3D for ; Sun, 27 Jul 2014 07:40:55 +0000 (UTC) Received: from dnvrco-oedge-vip.email.rr.com ([107.14.70.243]) by dnvrco-queue03.email.rr.com (InterMail vM.8.04.01.13 201-2343-100-167-20131028) with ESMTP id <20140727073943.OZST27390.dnvrco-queue03.email.rr.com@dnvrco-oedge-vip.email.rr.com> for ; Sun, 27 Jul 2014 07:39:43 +0000 Received: from [96.28.178.143] ([96.28.178.143:65523] helo=localhost) by dnvrco-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTP id 26/B6-32028-C19A4D35; Sun, 27 Jul 2014 07:24:13 +0000 Date: Sun, 27 Jul 2014 07:24:12 +0000 Message-ID: <26.B6.32028.C19A4D35@dnvrco-oedge01> From: "Thomas Mueller" To: freebsd-current@freebsd.org Subject: Re: Unreadable DVD in FreeBSD and NetBSD X-RR-Connecting-IP: 107.14.64.118:25 X-Authority-Analysis: v=2.1 cv=aL1+qNNm c=1 sm=1 tr=0 a=RKm8ZHSrUWUxlfG+7GhaOw==:117 a=RKm8ZHSrUWUxlfG+7GhaOw==:17 a=ayC55rCoAAAA:8 a=WI4hIimoLeMA:10 a=DvSzqBOGy98A:10 a=pedpZTtsAAAA:8 a=o6SvArihAAAA:8 a=_ctWjzdLAAAA:8 a=Vj233p0cBiRxn8SIIlwA:9 a=wV7um_r7rhMA:10 X-Cloudmark-Score: 0 Cc: avg@icyb.net.ua, freebsd-ports@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 07:40:55 -0000 > You need to install sysutils/udfclient. Your cd is in UDF format, that isn't > covered by standard mount_udf. -- > Regards, > Ruslan Let me also say, one of the MASTER_SITES listed in the Makefile is no good (NXDOMAIN): http://www.13thmonkey.org/udfclient/releases I just tried and failed, got error messages but still got fusefs-libs which could prove useful: cc -O2 -pipe -fno-strict-aliasing -I/usr/local/include -D_FILE_OFFSET_BITS=64 -DNEEDS_ISPRINT -DNO_INT_FMTIO -DNO_DIRENT_NAMLEN -DSCSI -DUSCSI_FREEBSD_CAM -DPACKAGE_NAME=\"udfclient\" -DPACKAGE_TARNAME=\"udfclient\" -DPACKAGE_VERSION=\"0.7.5\" -DPACKAGE_STRING=\"udfclient\ 0.7.5\" -DPACKAGE_BUGREPORT=\"reinoud@NetBSD.org\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_ENDIAN_H=1 -DHAVE_MACHINE_ENDIAN_H=1 -DHAVE_STRUCT_STAT_ST_ATIMESPEC=1 -DHAVE_STRUCT_STAT_ST_BIRTHTIMESPEC=1 -DHAVE_CAMLIB_H=1 -I. -c udfclientfs.c In file included from udfclientfs.c:58: In file included from ./udf.h:175: ./uio.h:69:53: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int uiomove(void *buf, size_t amount, struct uio *uio); ^ In file included from udfclientfs.c:58: ./udf.h:499:98: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int udf_read_file_part_uio(struct udf_node *udf_node, char *what, int cachehints, struct uio *data_uio); ^ ./udf.h:500:99: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int udf_write_file_part_uio(struct udf_node *udf_node, char *what, int cachehints, struct uio *data_uio); ^ ./udf.h:503:59: warning: declaration of 'struct uio' will not be visible outside of this function [-Wvisibility] extern int udf_readdir(struct udf_node *udf_node, struct uio *result_uio, int *eof_res /* int *cookies, int ncookies */); ^ udfclientfs.c:147:43: warning: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] error = udf_lookup_name_in_dir(dir_node, name, strlen(name), &udf_icbptr, fid, &found); ^~~~ ./udf.h:505:69: note: passing argument to parameter 'name' here extern int udf_lookup_name_in_dir(struct udf_node *dir_node, char *name, int namelen, struct long_ad *icb_loc, struct fileid_desc *fid, int *found); ^ udfclientfs.c:520:13: error: variable has incomplete type 'struct uio' struct uio file_uio; ^ udfclientfs.c:520:9: note: forward declaration of 'struct uio' struct uio file_uio; ^ udfclientfs.c:560:13: error: variable has incomplete type 'struct uio' struct uio file_uio; ^ udfclientfs.c:560:9: note: forward declaration of 'struct uio' struct uio file_uio; ^ udfclientfs.c:621:13: error: variable has incomplete type 'struct uio' struct uio dir_uio; ^ udfclientfs.c:621:9: note: forward declaration of 'struct uio' struct uio dir_uio; ^ 5 warnings and 3 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/ports/sysutils/udfclient/work11/UDFclient.0.7.5 *** Error code 1 Stop. make[1]: stopped in /usr/ports/sysutils/udfclient *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/udfclient ===>>> make failed for sysutils/udfclient ===>>> Aborting update ===>>> Killing background jobs Terminated ===>>> There are messages from installed ports to display, but first take a moment to review the error messages above. Then press Enter when ready to proceed. ===>>> pkg-message for pkg-1.3.0 If you are upgrading from the old package format, first run: # pkg2ng ===>>> pkg-message for fusefs-libs-2.9.3_2 Install the fuse kernel module to use this port. ===>>> Done displaying pkg-message files ===>>> The following actions were performed: Upgrade of pkg-1.2.7_3 to pkg-1.3.0 Installation of sysutils/fusefs-libs (fusefs-libs-2.9.3_2) ===>>> You can restart from the point of failure with this command line: portmaster sysutils/udfclient ===>>> Exiting I was successful in NetBSD installing misc/udfclient from pkgsrc, but it proved useless for reading the Seagate DVD. >From what I saw, it looks like even if I could successfully build sysutils/udfclient from FreeBSD ports, it would prove equally useless. Tom From owner-freebsd-current@FreeBSD.ORG Sun Jul 27 09:22:19 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 215AE125; Sun, 27 Jul 2014 09:22:19 +0000 (UTC) Received: from thetys.cloudzeeland.nl (webrz.xs4all.nl [83.161.133.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloudzeeland.nl", Issuer "PositiveSSL CA 2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A52F27A5; Sun, 27 Jul 2014 09:22:17 +0000 (UTC) Received: from thetys.cloudzeeland.nl (thetys.cloudzeeland.nl [10.10.10.31]) by thetys.cloudzeeland.nl (Postfix) with ESMTP id DF2001689C32; Sun, 27 Jul 2014 11:17:34 +0200 (CEST) Received: from [10.10.10.70] (daedalus.cloudzeeland.nl [10.10.10.70]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by thetys.cloudzeeland.nl (Postfix) with ESMTPSA id A6E811689B5F; Sun, 27 Jul 2014 11:17:34 +0200 (CEST) Message-ID: <53D4C450.6010001@webrz.net> Date: Sun, 27 Jul 2014 11:20:16 +0200 From: Jos Chrispijn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Kevin Oberman , Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP on thetys.cloudzeeland.nl X-Mailman-Approved-At: Sun, 27 Jul 2014 12:38:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "ports@FreeBSD.org" , FreeBSD Stable ML , "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 09:22:19 -0000 Just tried to update the port: ===>>> Creating a backup package for old version pkg-1.3.0 Creating package for pkg-1.3.0 Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 1 packages in the universe): Installed packages to be REMOVED: pkg-1.3.0 The operation will free 7 MB [1/1] Deleting pkg-1.3.0: 100% ===>>> Starting check for runtime dependencies ===>>> Gathering dependency list for ports-mgmt/pkg from ports ===>>> No dependencies for ports-mgmt/pkg ===> Installing for pkg-1.3.1 ===> Checking if ports-mgmt/pkg already installed Child process pid=82376 terminated abnormally: Segmentation fault: 11 *** [check-already-installed] Error code 245 Stop in /usr/ports/ports-mgmt/pkg. *** [/usr/ports/ports-mgmt/pkg/work/.install_done.pkg._usr_local] Error code 1 Stop in /usr/ports/ports-mgmt/pkg. ===>>> A backup package for pkg-1.3.0 should be located in /usr/ports/packages/portmaster-backup ===>>> Installation of pkg-1.3.1 (ports-mgmt/pkg) failed ===>>> Aborting update ===>>> Update for ports-mgmt/pkg failed ===>>> Aborting update Any suggestion to solve this? Perhaps I am doing something wrong here - pls advise. thanks, Jos Chrispijn Kevin Oberman: On Wed, Jul 23, 2014 at 7:42 AM, Baptiste Daroussin [1] wrote: Hi all, I'm very please to announce the release of pkg 1.3.0 This version is the result of almost 9 month of hard work Here are the statistics for the version: - 373 files changed, 66973 insertions(+), 38512 deletions(-) - 29 different contributors Please not that for the first time I'm not the main contributor, and I would like to particularly thanks Vsevold Stakhov for all the hard work he has done to allow us to get this release out. I would like also to give a special thanks to Andrej Zverev for the tons of hours spending on testing and cleaning the bug tracker! So much has happened that it is hard to summarize so I'll try to highlight the major points: - New solver, now pkg has a real SAT solver able to automatically handle conflicts and dynamically discover them. (yes pkg set -o is deprecated now) - pkg install now able to install local files as well and resolve their dependencies from the remote repositories - Lots of parts of the code has been sandboxed - Lots of rework to improve portability - Package installation process has been reworked to be safer and handle properly the schg flags - Important modification of the locking system for finer grain locks - Massive usage of libucl - Simplification of the API - Lots of improvements on the UI to provide a better user experience. - Lots of improvements in multi repository mode - pkg audit code has been moved into the library - pkg -o A=B that will overwrite configuration file from cli - The ui now support long options - The unicity of a package is not anymore origin - Tons of bug fixes - Tons of behaviours fixes - Way more! Thank you to all contributors: Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, Bryan Drewery, Dag-Erling Smørgrav, Dmitry Marakasov, Elvira Khabirova, Jamie Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, Matthew Seaman, Maximilian GaÃY, Michael Gehring, Michael Gmelin, Nicolas Szalay, Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, Vsevolod Stakhov, Xin Li, coctic Regards, Bapt on behalf of the pkg@ Really, really great news! Congrats to Bapt and all of the contributors, large and small, for doing the work to make this happen. The real, live, provable solver is something that was desperately needed. Thaqt is followed closely with multi-repository mode. All of the rest is great, too. I think one bullet was a bit mangled in French->English translation, though. What does "The unicity of a package is not anymore origin" mean? I have a couple of guesses, but I am not really sure. Ithink the best translations would be "The unicity of a package is no longer the origin", but I am unsure of "unicity". "Uniqueness"? That would make sense, but I am not quite sure that is what was meant. -- R. Kevin Oberman, Network Engineer, Retired E-mail: [2]rkoberman@gmail.com _______________________________________________ [3]freebsd-ports@freebsd.org mailing list [4]http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [5]"freebsd-ports-unsubscribe@freebsd.org" References 1. mailto:bapt@freebsd.org 2. mailto:rkoberman@gmail.com 3. mailto:freebsd-ports@freebsd.org 4. http://lists.freebsd.org/mailman/listinfo/freebsd-ports 5. mailto:freebsd-ports-unsubscribe@freebsd.org From owner-freebsd-current@FreeBSD.ORG Sun Jul 27 12:42:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 563EA1B3 for ; Sun, 27 Jul 2014 12:42:22 +0000 (UTC) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1EB5928D3 for ; Sun, 27 Jul 2014 12:42:21 +0000 (UTC) Received: by mail-oa0-f47.google.com with SMTP id g18so7546867oah.20 for ; Sun, 27 Jul 2014 05:42:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Ytm4U1+gw1sr+vtPADfKb2JBTuK0+8GgcetTCzbXXGA=; b=Eqxw+DyIDMH9M3wR9qHpJf3WEYtHHVVc2QPI7BKD9KQsYT56fQf7ALbB8MmmYMJPYg z3s7X9fbHuIKV8DGzCy431g2jua16S70+087Ap1UpASAx4LILv/A5oOV0rmbbr5Ajh0L WSF9R6yRz5pxQ0YSVX8aZMoY/FHqYHqpideHPr0lCB6LRG17WNybjScH0lKgjStRwA8R +rTuofdnlm5yuw9CfLN9ASTj9dldr+L3XjuMVY0hbgtxcy34hE+Restbx79Tx39j8GBx +1rWLl25U1v9P58VzdAlaTyppdt5bBEVUc1J/fUVq7OQOgEECLqb3bSqFQHma0vRGquq f5Yw== X-Gm-Message-State: ALoCoQmycpbwCXV+kbsUy1liGDRc3i6mk8V06bSHlobFfZHQI/MC7XB6nRMet+s5lx5Xst0EkWt2 MIME-Version: 1.0 X-Received: by 10.60.140.234 with SMTP id rj10mr38868327oeb.6.1406458316354; Sun, 27 Jul 2014 03:51:56 -0700 (PDT) Received: by 10.182.40.137 with HTTP; Sun, 27 Jul 2014 03:51:56 -0700 (PDT) X-Originating-IP: [2001:44b8:31b0:aa00:be5f:f4ff:fe4a:cae2] Date: Sun, 27 Jul 2014 20:51:56 +1000 Message-ID: Subject: portversion doesn't seem to know what's out of date From: Jason Birch To: "freebsd-current@freebsd.org" , "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 27 Jul 2014 12:42:22 -0000 I built FreeBSD for my Beaglebone Black a couple of weeks ago, and went to do an update just then. After updating /usr/ports, I ran `portversion | grep \<` to see a list of what could be updated. Knowing that this takes a bit longer and needing to run out the door, I also type `portupgrade -aF` afterwards, to fetch anything that might need upgrading. When I returned, I found that portversion seemed to think everything was up to date, but `portupgrade -aF` had found and downloaded upgrades to ruby, pkg, Net-SSLeay, gnutls, and emacs-nox11. Checking the verbose output of portversion, I saw that portversion seemed to think the out-of-date version was up to date with the port... root@beaglebone:/usr/home/jbirch # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... none found. Fetching snapshot tag from portsnap.FreeBSD.org... done. Fetching snapshot metadata... done. Updating from Thu Jul 10 04:42:24 UTC 2014 to Sun Jul 27 05:09:26 UTC 2014. .... Fetching 63 new ports or files... done. root@beaglebone:/usr/home/jbirch # portsnap update Removing old files and directories... done. Extracting new files: /usr/ports/CHANGES .... /usr/ports/editors/emacs-nox11/ .... /usr/ports/lang/ruby19/ .... /usr/ports/ports-mgmt/pkg/ .... /usr/ports/security/gnutls/ .... /usr/ports/security/p5-Net-SSLeay/ .... root@beaglebone:/usr/home/jbirch # portversion | grep \< [Reading data from pkg(8) ... - 63 packages found - done] root@beaglebone:/usr/home/jbirch # portupgrade -aF [Reading data from pkg(8) ... - 63 packages found - done] ---> Fetching the distfile(s) for 'ruby-1.9.3.547,1' (lang/ruby19) .... ---> Fetching the distfile(s) for 'pkg-1.3.1' (ports-mgmt/pkg) .... ---> Fetching the distfile(s) for 'p5-Net-SSLeay-1.65' (security/p5-Net-SSLeay) .... ---> Fetching the distfile(s) for 'gnutls-3.2.16_1' (security/gnutls) .... ---> Fetching the distfile(s) for 'emacs-nox11-24.3_11,3' (editors/emacs-nox11) .... root@beaglebone:/usr/home/jbirch # portversion -v [Reading data from pkg(8) ... - 63 packages found - done] .... emacs-nox11-24.3_10,3 = up-to-date with port .... gnutls-2.12.23_6 = up-to-date with port .... p5-Net-SSLeay-1.64 = up-to-date with port .... pkg-1.2.7_4 = up-to-date with port .... ruby-1.9.3.484_2,1 = up-to-date with port .... root@beaglebone:/usr/home/jbirch # uname -a FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r268309: Sun Jul 6 22:13:49 EST 2014 jbirch@267801:/usr/home/jbirch/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm I'm trying to update just pkg for the moment to see if that helps the situation, but it seems to be stuck in some sort of configure loop when building from ports. I'll leave it for the night, as each loop seems to compile something different. pkg check is offering no hints as to if anything is awry -- it just looks like portversion is looking at something completely different, or not looking at anything at all. Has anyone seen this behaviour before, or can point me forward? JB From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 09:41:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A6E484E for ; Mon, 28 Jul 2014 09:41:36 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 2C2BB2AAA for ; Mon, 28 Jul 2014 09:41:36 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway1.nyi.internal (Postfix) with ESMTP id 23EE22103B for ; Mon, 28 Jul 2014 05:41:28 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 28 Jul 2014 05:41:28 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=K+Z9WH0k3tO3WxquCh+To/ PoC8s=; b=qy2iNyjVFmnsq7CQwxhfGXc30ug4GrbcG1nPV5pgh4SB7uBJ22tDaK fXPesYv/PHk5ESAtrtlDlp+Hxj6pFfSCM8NuCVDDYyIVY120zODUvLJ8mWcoGPN0 wIUXlcs5gGt4xILNt68g7DC9AI/hwSUTud713Cs0eod8XK4H7Yaok= X-Sasl-enc: XeyBQ9Jwbre0aV7aTIw1TEQk5dYpqmW1o/PI8f+NfJg9 1406540487 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 31CF7C00003; Mon, 28 Jul 2014 05:41:26 -0400 (EDT) Message-ID: <53D61AC6.5030305@freebsd.org> Date: Mon, 28 Jul 2014 19:41:26 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Cy Schubert Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <201407261843.s6QIhcx4008597@slippy.cwsent.com> In-Reply-To: <201407261843.s6QIhcx4008597@slippy.cwsent.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 28 Jul 2014 09:41:36 -0000 On 27/07/2014 4:43 AM, Cy Schubert wrote: > In message <53D395E4.1070006@fastmail.net>, Darren Reed writes: >> On 24/07/2014 1:42 AM, Cy Schubert wrote: >>>>> But, lack of ipv6 fragment processing still causes ongoing pain. That'= >>>>> s our=20 >>>>> #1 wish list item for the cluster. >>> Taking this discussion slightly sideways but touching on this thread a >>> little, each of our packet filters will need nat66 support too. Pf doesn't >>> support it for sure. I've been told that ipfw may and I suspect ipfilter >>> doesn't as it was on Darren's todo list from 2009. >> ipfiler 5 handles fragments for ipv6. > Switching gears and leaving the discussion of ipv6 fragments to mention > nat66. A lot of people have been talking about nat66. I could be wrong but > I don't think it can handle nat66. I need to do some testing to verify > this. I remember reading on sourceforge that it was on your todo list. It > doesn't look like it was checked off as being completed. IPFilter 5 does IPv6 NAT. With the import of 5.1.2, map, rdr and rewrite rules will all work with IPv6 addresses. NAT66 is a specific implementation of IPv6 NAT behaviour. Cheers, Darren From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 13:53:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 630E79ED for ; Mon, 28 Jul 2014 13:53:56 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 2137D2BD2 for ; Mon, 28 Jul 2014 13:53:55 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XBlJX-002GGZ-Ff>; Mon, 28 Jul 2014 15:50:07 +0200 Received: from e179187250.adsl.alicedsl.de ([85.179.187.250] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XBlJX-000sV2-Df>; Mon, 28 Jul 2014 15:50:07 +0200 Date: Mon, 28 Jul 2014 15:50:02 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: local_unbound: since update sporadic hangs in connections Message-ID: <20140728155002.3d29e22c.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/VHm_L3QwLjsjc_1ZvD_/h1E"; protocol="application/pgp-signature" X-Originating-IP: 85.179.187.250 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 28 Jul 2014 13:53:56 -0000 --Sig_/VHm_L3QwLjsjc_1ZvD_/h1E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since local_unbound update and the suggested update procedure as requested = with TAG 20140719 the connection to the net hangs (DNS resolving). This is very ofte= n with the freebsd.org domain the case, while domestic domains rarely show this strang= e behaviour. The problem occurs on ALL CURRENT systems with updated unbound! Updates via svn also show those hangs (FBSD SVN server). This is nasty ... oh --Sig_/VHm_L3QwLjsjc_1ZvD_/h1E Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT1lUOAAoJEOgBcD7A/5N85voIAKFzp24iMgMF0B07TygcbR12 r64rnWPeg465aYdY9Lk+spd+URetEB6VMeLWWHPT9txYMaBvNnsQQ2m6ol6mGvLh 07jsl5508+ap61kKFXz41Dbm1qnVuwGQPjEuDcH8wLGLWD2o2g0wQTEtUoe+QGx3 MenOBPgYxoQy60UvnmU5to/eXgQeVUdl1Uol696qG9qg9jOUmg5hoftriPZgiXXX kJLVjRXi5WJNOdv8z0Y7w3yoXH1LuQjxsJ1T9xkPOMN24BXxfAdjXfxZ7aLRHe3i HdisXtUF9CJpv2jbelxQApx5bTEPl9m8Oj5pJ+T7aIIPx8s2X2t56xlspfKz2yY= =by6b -----END PGP SIGNATURE----- --Sig_/VHm_L3QwLjsjc_1ZvD_/h1E-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 15:02:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA6827A4; Mon, 28 Jul 2014 15:02:32 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 7794125CD; Mon, 28 Jul 2014 15:02:32 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XBmRZ-002cF1-OL>; Mon, 28 Jul 2014 17:02:29 +0200 Received: from e179187250.adsl.alicedsl.de ([85.179.187.250] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XBmRZ-0010Bw-MF>; Mon, 28 Jul 2014 17:02:29 +0200 Date: Mon, 28 Jul 2014 17:02:21 +0200 From: "O. Hartmann" To: FreeBSD Ports , FreeBSD CURRENT Subject: net/openldap24-server: lstat(/usr/ports/net/openldap24-server/work/stage/usr/local/libexec/openldap/smbk5pwd.so.0.0.0): Message-ID: <20140728170221.63fb0333.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Xt=9bCBYgf_gzm_wQz6BWWY"; protocol="application/pgp-signature" X-Originating-IP: 85.179.187.250 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 28 Jul 2014 15:02:32 -0000 --Sig_/Xt=9bCBYgf_gzm_wQz6BWWY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Updating of port net/openldap24-server fails grandios with the following er= ror: =3D=3D=3D> Installing for openldap-sasl-server-2.4.39_2 =3D=3D=3D> Registering installation for openldap-sasl-server-2.4.39_2 pkg-static: lstat(/usr/ports/net/openldap24-server/work/stage/usr/local/libexec/openlda= p/pw-sha2.so.0.0.0): No such file or directory pkg-static: lstat(/usr/ports/net/openldap24-server/work/stage/usr/local/libexec/openlda= p/smbk5pwd.so.0.0.0): No such file or directory *** Error code 74 Great. The OS is=20 FreeBSD 11.0-CURRENT #0 r269157: Sun Jul 27 22:57:48 CEST 2014=20 --Sig_/Xt=9bCBYgf_gzm_wQz6BWWY Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT1mYEAAoJEOgBcD7A/5N8YdcH/jJkftC7JYNEFIwaopWik4dG Nu11c6J2fhdv0tXxxVGABRtZFl3BK4FwdMdUgeD5frSd85ubK3wJWDrm8JIKtQt/ qFz22fw1Jykhd4pDtvNphINhWlT1tjWK6zarIX4cNqWB/tldUTE45htPN5CtcoJ8 8zr4xix05+NYtAIJ1XTaVD1aaRd8mNO2CoWIHJ4NLhi1QF5V9TGxpSC+ngDQElSf KqggcqQbK3prESGzTxae3z9WiD8LXCuXC9raYhc5jFRsh+EqywFK4g+ms/etRQN9 vx2We4jMDogojqfPPFXWyIi4XKVQHFODgIRyXEP6zZANEignnm+L8Ozb8pn9rfI= =Mr1S -----END PGP SIGNATURE----- --Sig_/Xt=9bCBYgf_gzm_wQz6BWWY-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 17:19:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67C1C62E for ; Mon, 28 Jul 2014 17:19:55 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DF7E26B0 for ; Mon, 28 Jul 2014 17:19:55 +0000 (UTC) Received: from [10.38.65.170] (mobile-166-137-176-025.mycingular.net [166.137.176.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: peter) by smtp2.wemm.org (Postfix) with ESMTPSA id 45815705; Mon, 28 Jul 2014 10:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1406567994; bh=nJgTceY+eTpUp8YSe74N5ek5QINKxWZK3fmPdXEotI8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=e399XzhP0EOASP+MBHbJwHHndkxt5XRw+qqwROAknRee2+IAOJaGLTiYa3+rDnCXV On/pC5Wtkp2rOZn5E1dY3nnGt65TA44hXFTuvJ0CR6Xm5N7/MHEWrvbeSgay8Kck6H YOr0vEZcSdgLNWXyM9nNGlkZJf8czKJyJdp4DIwU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: local_unbound: since update sporadic hangs in connections From: Peter Wemm X-Mailer: iPhone Mail (12A4331d) In-Reply-To: <20140728155002.3d29e22c.ohartman@zedat.fu-berlin.de> Date: Mon, 28 Jul 2014 10:19:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140728155002.3d29e22c.ohartman@zedat.fu-berlin.de> To: "O. Hartmann" Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 28 Jul 2014 17:19:55 -0000 Are you using pf and IPv6 by any chance? Since you mentioned the FreeBSD.or= g domain, DNSSEC and IPv6 triggers fragments. Just a thought.=20 -- Peter Wemm. peter@wemm.org > On 28 Jul 2014, at 6:50 am, O. Hartmann wrot= e: >=20 >=20 > Since local_unbound update and the suggested update procedure as requested= with TAG > 20140719 the connection to the net hangs (DNS resolving). This is very oft= en with the > freebsd.org domain the case, while domestic domains rarely show this stran= ge behaviour. >=20 > The problem occurs on ALL CURRENT systems with updated unbound! >=20 > Updates via svn also show those hangs (FBSD SVN server). >=20 > This is nasty ... >=20 > oh From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 18:07:41 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB18FA6C for ; Mon, 28 Jul 2014 18:07:41 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 86F2E2CEC for ; Mon, 28 Jul 2014 18:07:41 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XBpKk-003O2g-Qg>; Mon, 28 Jul 2014 20:07:38 +0200 Received: from e179187250.adsl.alicedsl.de ([85.179.187.250] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XBpKk-001KNw-OT>; Mon, 28 Jul 2014 20:07:38 +0200 Date: Mon, 28 Jul 2014 20:07:32 +0200 From: "O. Hartmann" To: Peter Wemm Subject: Re: local_unbound: since update sporadic hangs in connections Message-ID: <20140728200732.5877f9f3.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140728155002.3d29e22c.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/s9VqQhbG7o8kH5wFW1yspXz"; protocol="application/pgp-signature" X-Originating-IP: 85.179.187.250 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 28 Jul 2014 18:07:41 -0000 --Sig_/s9VqQhbG7o8kH5wFW1yspXz Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 28 Jul 2014 10:19:50 -0700 Peter Wemm schrieb: > Are you using pf and IPv6 by any chance? Since you mentioned the FreeBSD= .org domain, > DNSSEC and IPv6 triggers fragments. Just a thought.=20 >=20 > -- > Peter Wemm. peter@wemm.org >=20 >=20 > > On 28 Jul 2014, at 6:50 am, O. Hartmann w= rote: > >=20 > >=20 > > Since local_unbound update and the suggested update procedure as reques= ted with TAG > > 20140719 the connection to the net hangs (DNS resolving). This is very = often with the > > freebsd.org domain the case, while domestic domains rarely show this st= range > > behaviour. > >=20 > > The problem occurs on ALL CURRENT systems with updated unbound! > >=20 > > Updates via svn also show those hangs (FBSD SVN server). > >=20 > > This is nasty ... > >=20 > > oh The gateway uses pf, IPv6 is not used, but configured. The gateway is CURRE= NT, as well as the boxes inside my LAN (they use ipfw2, also IPv6 not used, but configured= and a capable kernel). --Sig_/s9VqQhbG7o8kH5wFW1yspXz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT1pFqAAoJEOgBcD7A/5N8fF8IAJqXmS4gUJ7KWFUPFzUap2eQ ftPJsKLZJz013tEE4uI4pEnlb5DBunfaFnR6TIyhYAzG4sG0A09SGgoPc0HUNM58 TDGQfHKBtJ5qKyvV3NpbQCknhGMuQDVttU2hecRCY4+z6mKtOBGTP7l0KPO5JyZC C2ooaB7quytbIglInceGa5teJGyZmemQX1XS/DVObbvGbpfciGkDAyQSFUCGfzAj QcuVp7jHy4Jzqj+RjZ1nV7b3SMAr6Fj3I/+ZBE8kA2GOaSMsec9ZVC1OFhaR77sK ZW9g9+RPOsX9vX4KmVTNcauMT/yr665mK0+wli/OoepDxTgUFDjVV6qyH/233BA= =fS+Z -----END PGP SIGNATURE----- --Sig_/s9VqQhbG7o8kH5wFW1yspXz-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 22:07:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C8A0520; Mon, 28 Jul 2014 22:07:33 +0000 (UTC) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3153A298B; Mon, 28 Jul 2014 22:07:33 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id rl12so7459677iec.38 for ; Mon, 28 Jul 2014 15:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RmMC/xrbCH/TCy2b3XOznXw8yBXQIG3dlMItsqI2GDw=; b=WmDyawSN1vt7SE1ICCLRMzzWOCpWcP1uW53H6zkyNDoLo8/W239qRGw5M7qGlYhm99 TG8HJmMDBVyn/2tprfpdBg3BtwmpNJZqkZWuhd/1XCI7IBlJ9U1aXReCvAqzvK4NApOH ShP/Luf9fiSTWb7i0WFuPEW1AhxZZATPlLEnhrxTMKeMgCYJRJEkwtuumbX1CxpOzFUh nasVt+jZ6xRIUnrTqcYybjtvYgyXheccMI3YU8VEu0mHg9luDaAaZ2BWP0Sh9jBFYjV3 XoVLroRqwAmKyjyIZb1OC4QDTUGe1kQOBE0MbKgln9esklOZvAH/JKe4XO0ToBzXOFbT ugNg== MIME-Version: 1.0 X-Received: by 10.50.221.104 with SMTP id qd8mr36523473igc.35.1406585252496; Mon, 28 Jul 2014 15:07:32 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.163.148 with HTTP; Mon, 28 Jul 2014 15:07:32 -0700 (PDT) In-Reply-To: <53D61AC6.5030305@freebsd.org> References: <201407261843.s6QIhcx4008597@slippy.cwsent.com> <53D61AC6.5030305@freebsd.org> Date: Mon, 28 Jul 2014 15:07:32 -0700 X-Google-Sender-Auth: oYRP-ezuDGwO9fqCIWnvABmKVZY Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Kevin Oberman To: Darren Reed Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 28 Jul 2014 22:07:33 -0000 On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed wrote: > On 27/07/2014 4:43 AM, Cy Schubert wrote: > > In message <53D395E4.1070006@fastmail.net>, Darren Reed writes: > >> On 24/07/2014 1:42 AM, Cy Schubert wrote: > >>>>> But, lack of ipv6 fragment processing still causes ongoing pain. > That'= > >>>>> s our=20 > >>>>> #1 wish list item for the cluster. > >>> Taking this discussion slightly sideways but touching on this thread a > >>> little, each of our packet filters will need nat66 support too. Pf > doesn't > >>> support it for sure. I've been told that ipfw may and I suspect > ipfilter > >>> doesn't as it was on Darren's todo list from 2009. > >> ipfiler 5 handles fragments for ipv6. > > Switching gears and leaving the discussion of ipv6 fragments to mention > > nat66. A lot of people have been talking about nat66. I could be wrong > but > > I don't think it can handle nat66. I need to do some testing to verify > > this. I remember reading on sourceforge that it was on your todo list. It > > doesn't look like it was checked off as being completed. > > IPFilter 5 does IPv6 NAT. > > With the import of 5.1.2, map, rdr and rewrite rules will all work with > IPv6 addresses. > > NAT66 is a specific implementation of IPv6 NAT behaviour. > > Cheers, > Darren > And all IPv6 NAT is evil and should be cast into (demonic residence of your choosing) on sight! NAT on IPv6 serves no useful purpose at all. It only serves to complicate things and make clueless security officers happy. It adds zero security. It is a great example of people who assume that NAT is a security feature in IPv4 (it's not) so it should also be in IPv6. The problem is that this meme is so pervasive that even when people understand that it is bad, they still insist on it because there will be an unchecked box on the security checklist for "All systems not pubic servers are in RFC1918 space? -- YES NO". The checklist item should be (usually) "All systems behind a stateful firewall with an appropriate rule set? -- YES NO" as it is a stateful firewall (which is mandatory for NAT that provides all of the security. I say "usually" because the major research lab where I worked ran without a firewall (and probably still does) and little, if any, NAT. It was tested regularly by red teams hired by the feds and they never were able to penetrate anything due to a very aggressive IDS/IPS system, but most people and companies should NOT go this route. I have IPv6 at home (Comcast) and my router runs a stateful firewall with a rule set functionally the same as that used for IPv4 and that provides the protection needed. So putting support for NAT66 or any IPv6 NAT into a firewall is just making things worse. Please don't do it! -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Mon Jul 28 23:22:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5D3C970 for ; Mon, 28 Jul 2014 23:22:00 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB0823F1 for ; Mon, 28 Jul 2014 23:22:00 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hMcVG4Yn1zB7; Tue, 29 Jul 2014 01:21:58 +0200 (CEST) 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=jakla2; t=1406589714; x=1409181715; bh=I0I gQemrj96+WcDG2XjxhzqQGsHtKOrmTHCRvj4GKPA=; b=JFHMqCtGBSdRLjRDnhW v7Yj/kJctjQk15uY8uvtU+zlMcceLilEiEiAC6ST6eEuMhZmzO0j16qntkPyNJcw +MMl89edoKoDZ9ndFL6h0BvJkeLKOPS5M7pb/SWd9D0TaedruC5nwy9RarxrXg/p Y3vnM/zv7ZMlS5JXxweoAhOs= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id fzkHIgLwAlpO; Tue, 29 Jul 2014 01:21:54 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Tue, 29 Jul 2014 01:21:53 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hMcV941KVzpf; Tue, 29 Jul 2014 01:21:53 +0200 (CEST) Received: from sleepy.ijs.si ([2001:1470:ff80:e001::1:1]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 29 Jul 2014 01:21:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Jul 2014 01:21:53 +0200 From: Mark Martinec To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD =?UTF-8?Q?=3F=20-=20does?= =?UTF-8?Q?=20it=20have=20one=20=3F?= Organization: J. Stefan Institute In-Reply-To: References: <201407261843.s6QIhcx4008597@slippy.cwsent.com> <53D61AC6.5030305@freebsd.org> Message-ID: <331930d6178ebbed522e9eddff0196fc@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 Cc: Kevin Oberman X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 28 Jul 2014 23:22:01 -0000 > On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed =20 > wrote: >> [...] >> IPFilter 5 does IPv6 NAT. >>=20 >> With the import of 5.1.2, map, rdr and rewrite rules will all work=20 >> with >> IPv6 addresses. >>=20 >> NAT66 is a specific implementation of IPv6 NAT behaviour. 2014-07-29 00:07 Kevin Oberman wrote: > And all IPv6 NAT is evil and should be cast into (demonic residence of=20 > your > choosing) on sight! >=20 > NAT on IPv6 serves no useful purpose at all. It only serves to=20 > complicate > things and make clueless security officers happy. It adds zero=20 > security. It > is a great example of people who assume that NAT is a security feature=20 > in > IPv4 (it's not) so it should also be in IPv6. >=20 > The problem is that this meme is so pervasive that even when people > understand that it is bad, they still insist on it because there will=20 > be an > unchecked box on the security checklist for "All systems not pubic=20 > servers > are in RFC1918 space? -- YES NO". The checklist item should be=20 > (usually) > "All systems behind a stateful firewall with an appropriate rule set?=20 > -- > YES NO" as it is a stateful firewall (which is mandatory for NAT that > provides all of the security. >=20 > I say "usually" because the major research lab where I worked ran=20 > without a > firewall (and probably still does) and little, if any, NAT. It was=20 > tested > regularly by red teams hired by the feds and they never were able to > penetrate anything due to a very aggressive IDS/IPS system, but most=20 > people > and companies should NOT go this route. I have IPv6 at home (Comcast)=20 > and > my router runs a stateful firewall with a rule set functionally the=20 > same as > that used for IPv4 and that provides the protection needed. >=20 > So putting support for NAT66 or any IPv6 NAT into a firewall is just=20 > making > things worse. Please don't do it! > -- > R. Kevin Oberman, Network Engineer, Retired > E-mail: rkoberman@gmail.com You are missing the point, we are talking about NAT64 (IPv6-only=20 datacenter's path to a legacy world), and NPT66 (prefix transalation). I doubt anyone=20 had a traditional NAT in mind. Consider a small site with uplinks to two service providers: it can use=20 ULA internally and translate prefix on each uplink. Please see these short blogs: - To ULA or not to ULA, That=E2=80=99s the Question =20 http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.html - I Say ULA, You Hear NAT http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html - PA, PI or ULA IPv6 Address Space? It depends =20 http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html - Source IPv6 Address Selection Saves the Day =20 http://blog.ipspace.net/2014/01/source-ipv6-address-selection-saves-day.htm= l Mark From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 01:13:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 531D5D26 for ; Tue, 29 Jul 2014 01:13:20 +0000 (UTC) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DA542D7E for ; Tue, 29 Jul 2014 01:13:20 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id rp18so7770550iec.19 for ; Mon, 28 Jul 2014 18:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=O11RSaScVn5XjUjqMkPJ4zNiUf0SpsxW/NoCGYwfxlk=; b=WIrrasCeXyHXBw5ytHS39pxlz11oroVxjvpajtPmms4V42b5Leg7d+6rGfofMTUvD/ slmsUXsBGc7UDrbebkiXpM2hD3CGeewaprzIcs96HJVkDiBPkzg7P5WYZfXzQ+VAaniN AQBFvGhgILkm3wah7X/7DaK4CtgxUuz7NR+7VMewlv8NQ20MB2kI86o0f6jHxcEeSpyo +8sFW5NGGw6YQ5NRL3qb1LQrysBlswKSSJA0fiADKTYFHridyKTAzMNHLAA5H2aZfvXO fpPu6SB7HMHNXXB7DzrXVwJqyq3B6Mr1DGk4GQWFm6Xbds16f1fiydpChbqzR3rCISoY cTGw== MIME-Version: 1.0 X-Received: by 10.50.79.169 with SMTP id k9mr37835358igx.0.1406596399439; Mon, 28 Jul 2014 18:13:19 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.163.148 with HTTP; Mon, 28 Jul 2014 18:13:19 -0700 (PDT) In-Reply-To: <331930d6178ebbed522e9eddff0196fc@mailbox.ijs.si> References: <201407261843.s6QIhcx4008597@slippy.cwsent.com> <53D61AC6.5030305@freebsd.org> <331930d6178ebbed522e9eddff0196fc@mailbox.ijs.si> Date: Mon, 28 Jul 2014 18:13:19 -0700 X-Google-Sender-Auth: TW-wMqEeg-eKna1ofzQWeVxnYfo Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Kevin Oberman To: Mark Martinec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 01:13:20 -0000 On Mon, Jul 28, 2014 at 4:21 PM, Mark Martinec wrote: > On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed wrote: >> >>> [...] >>> >>> IPFilter 5 does IPv6 NAT. >>> >>> With the import of 5.1.2, map, rdr and rewrite rules will all work with >>> IPv6 addresses. >>> >>> NAT66 is a specific implementation of IPv6 NAT behaviour. >>> >> > 2014-07-29 00:07 Kevin Oberman wrote: > >> And all IPv6 NAT is evil and should be cast into (demonic residence of >> your >> choosing) on sight! >> >> NAT on IPv6 serves no useful purpose at all. It only serves to complicat= e >> things and make clueless security officers happy. It adds zero security. >> It >> is a great example of people who assume that NAT is a security feature i= n >> IPv4 (it's not) so it should also be in IPv6. >> >> The problem is that this meme is so pervasive that even when people >> understand that it is bad, they still insist on it because there will be >> an >> unchecked box on the security checklist for "All systems not pubic serve= rs >> are in RFC1918 space? -- YES NO". The checklist item should be (usuall= y) >> "All systems behind a stateful firewall with an appropriate rule set? -- >> YES NO" as it is a stateful firewall (which is mandatory for NAT that >> provides all of the security. >> >> I say "usually" because the major research lab where I worked ran withou= t >> a >> firewall (and probably still does) and little, if any, NAT. It was teste= d >> regularly by red teams hired by the feds and they never were able to >> penetrate anything due to a very aggressive IDS/IPS system, but most >> people >> and companies should NOT go this route. I have IPv6 at home (Comcast) an= d >> my router runs a stateful firewall with a rule set functionally the same >> as >> that used for IPv4 and that provides the protection needed. >> >> So putting support for NAT66 or any IPv6 NAT into a firewall is just >> making >> things worse. Please don't do it! >> -- >> R. Kevin Oberman, Network Engineer, Retired >> E-mail: rkoberman@gmail.com >> > > You are missing the point, we are talking about NAT64 (IPv6-only > datacenter's > path to a legacy world), and NPT66 (prefix transalation). I doubt anyone > had > a traditional NAT in mind. > > Consider a small site with uplinks to two service providers: it can use U= LA > internally and translate prefix on each uplink. > > Please see these short blogs: > > - To ULA or not to ULA, That=E2=80=99s the Question > http://blog.ipspace.net/2013/09/to-ula-or-not-to-ula-thats-question.htm= l > > - I Say ULA, You Hear NAT > http://blog.ipspace.net/2014/01/i-say-ula-you-hear-nat.html > > - PA, PI or ULA IPv6 Address Space? It depends > http://blog.ipspace.net/2014/01/pa-pi-or-ula-ipv6-address-space-it.html > > - Source IPv6 Address Selection Saves the Day > http://blog.ipspace.net/2014/01/source-ipv6-address- > selection-saves-day.html > > > Mark > Mark, No, all of the messages in the thread are specific about NAT66, not NPT66. NPT66 may have real value. I hate it, but it may well be better than alternatives. It addresses an issue I have had with many of the IPv6 purists. I do think some of the arguments for it are over-stated. Getting a /48 is trivial, but getting it routed is not, so there is a real issue, but it remains unclear how bit the issue really is. For most users, multi-homing is fine, but not for servers. But smaller companies often farm out their servers, so it's not an issue for them. The one really significant issue I accept as real is the expansion of the routing tables. While the IPv6 table is still fairly small (~17k) , it is growing and has the potential to exceed the size of the IPv4 table (>500K) which continues to grow due to deaggregation. For those not dealing with backbone BGP, the issues include handling large numbers of prefixes and the stability of routing tables (both RIBs and FIBs) with all of the churn . Since I have retired, I have not been involved in IPv6 implementation or technical discussion, but I started dealing with it back in the 1990s and, until I retired in 2011 I had the first computer (a DEC Alpha) that had an ARIN assigned IPv6 address sitting under my desk, hershey.es.net. (No, it was no longer in use.) I also opposed ULA. While I understood the arguments in its favor, I have still do not agree with them. I think ULA is simply a bad idea, but it is there and we will have to deal with it... forever. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 07:32:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CF5F9B9; Tue, 29 Jul 2014 07:32:24 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF475227B; Tue, 29 Jul 2014 07:32:23 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id ADDB5153A51; Tue, 29 Jul 2014 09:32:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ7v8KRmmdwK; Tue, 29 Jul 2014 09:32:08 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:e9f0:504a:6a3a:c776] (unknown [IPv6:2001:4cb8:3:1:e9f0:504a:6a3a:c776]) by smtp.digiware.nl (Postfix) with ESMTP id CC2801534C0; Tue, 29 Jul 2014 09:32:08 +0200 (CEST) Message-ID: <53D74DEC.3020104@digiware.nl> Date: Tue, 29 Jul 2014 09:31:56 +0200 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kevin Oberman , Darren Reed Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <201407261843.s6QIhcx4008597@slippy.cwsent.com> <53D61AC6.5030305@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 07:32:24 -0000 On 2014-07-29 0:07, Kevin Oberman wrote: > And all IPv6 NAT is evil and should be cast into (demonic residence of your > choosing) on sight! > > NAT on IPv6 serves no useful purpose at all. It only serves to complicate > things and make clueless security officers happy. It adds zero security. It > is a great example of people who assume that NAT is a security feature in > IPv4 (it's not) so it should also be in IPv6. ...... > So putting support for NAT66 or any IPv6 NAT into a firewall is just > making things worse. Please don't do it! Well said.... I'm actually rather relieved that natd can/should go away. Stops giving me migraines with all those special protocl cases that don't like to be natted.. Which of course started as early as FTP. --WjW From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 09:42:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 692E9F7F for ; Tue, 29 Jul 2014 09:42:24 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 3845922A9 for ; Tue, 29 Jul 2014 09:42:24 +0000 (UTC) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway1.nyi.internal (Postfix) with ESMTP id CFD2922FAE for ; Tue, 29 Jul 2014 05:42:13 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 29 Jul 2014 05:42:13 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=jd/yza6T0q0gblG3RTNaJB ynTM0=; b=V3ruOf6wNWF0eYFFblrHnJIzQwFoMOtxXMJsqAQhB7Mgs5M+KF7joP 5ErNjfpOpmXvwlNVhFvJqgU8MEZA7Z1G6rip11TzG2POBx5alyFpW4y5r1yciSC4 f0Fs5WX4/WPKg61u2oOGWrEyr7TMc4qbnpF79g0QNSTqVnAwJN/lc= X-Sasl-enc: QBcO9t13WH41ZC1RIlp3cDfDeK0ynR8aIRAx29QRRamt 1406626933 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 91CC2C0000C; Tue, 29 Jul 2014 05:42:12 -0400 (EDT) Message-ID: <53D76C73.4010201@freebsd.org> Date: Tue, 29 Jul 2014 19:42:11 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <201407261843.s6QIhcx4008597@slippy.cwsent.com> <53D61AC6.5030305@freebsd.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 09:42:24 -0000 On 29/07/2014 8:07 AM, Kevin Oberman wrote: ... > And all IPv6 NAT is evil and should be cast into (demonic residence > of your choosing) on sight! For the most part, I agree with you but the problem is "checkbox" comparisons. That IPv6 shouldn't be NAT'd is why I didn't implement it for such a long time. However given the problem that EIDs pose for privacy, I'm of the opinion that maybe NAT66 does have a place but not in the way that the NAT66 RFC prescribes. Darren From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 10:18:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5A6C0A07; Tue, 29 Jul 2014 10:18:26 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2A192682; Tue, 29 Jul 2014 10:18:24 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6TAI7u3030249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jul 2014 14:18:07 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6TAI67U030248; Tue, 29 Jul 2014 14:18:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Jul 2014 14:18:06 +0400 From: Gleb Smirnoff To: Darren Pilgrim Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140729101806.GB89995@FreeBSD.org> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CB4736.90809@bluerosetech.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Kristian K. Nielsen" , Franco Fichtner , freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 10:18:26 -0000 Darren, On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote: D> Never mistake silence for consent. D> D> The vast majority of people don't know pf is outdated and broken on D> FreeBSD because they don't know what they're missing and likely aren't D> using IPv6 yet. The moment you turn on IPv6 and restart a validating D> unbound, you run full-speed into pf's broken behaviour. Make an D> EDNS0-enabled query for a signed zone and you'll get a fragmented UDP D> packet that will never make it through unless you tell pf to allow all D> fragments unconditionally. They'll simply think something is wrong with D> unbound, turn off EDNS0 and/or validation, hurt peformance and/or D> security in the process, and never realize their firewall is doing D> literally the worst possible thing it could do. D> D> All because over half a decade ago some folks got all butthurt over a D> config file format change. Do I understand you right, that you propose a tens thousands lines of untrivial code bulk update in order to fix a particular bug, that can be nailed down separately? Do you also say that breaking configuration files for a large number of people is okay if the update is expected to fix a bug unrelated to configuration? For me sounds like hunting a sparrow with a cannon. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 10:35:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22A5ED5; Tue, 29 Jul 2014 10:35:16 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 950092827; Tue, 29 Jul 2014 10:35:15 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6TAZD43030594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jul 2014 14:35:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6TAZDiR030593; Tue, 29 Jul 2014 14:35:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Jul 2014 14:35:13 +0400 From: Gleb Smirnoff To: "Mike." Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140729103512.GC89995@FreeBSD.org> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> <201407201230590265.00B479C4@smtp.24cl.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407201230590265.00B479C4@smtp.24cl.home> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 10:35:16 -0000 On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: M> |> imho, the root problem here is that an effort to implement a M> single M> |> feature improvement (multi-threading) has caused the FreeBSD M> version M> |> of pf to apparently reach a near-unmaintainable position in the M> |> FreeBSD community because improvements from OpenBSD can no longer M> be M> |> ported over easily. FreeBSD's pf has been put in a virtual M> |> isolation chamber due to the multi-threaded enhancement. M> |> M> |> Was it worth it? M> | M> |Yes. This happened *three times* in BSD land now. How much more M> |proof does it take to make that clear? M> |[snip] M> M> In this instance, more proof would consist of pf development not M> wallowing in inactivity. M> M> imo, tactical changes were implemented in pf without the strategic M> negative consequences affecting the decision process guiding the M> implementation of those tactical features. And that's backwards. M> Strategies direct tactics, not vice versa. I would strongly disagree with you. I would claim that directions I've put in pf in 2012 are strategically correct, while previous life of pf in FreeBSD was not. History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already outdated. It isn't possible otherwise. While Max spent time on porting some stable version, the OpenBSD moved forward. It was later updated again by Max, and again right after update it was outdated. I mean that people who a) believe that OpenBSD pf is the one true b) eager for bleeding edge version, these people simply cannot be satisfied. A porter needs to take latest stable version from OpenBSD and spend some time working on it. So, pf in FreeBSD was always "outdated", even before my SMP work on it. Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. In 2004 we've got 10 years of diverging developement between FreeBSD and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in 9.x is again outdated and introduces a number of bugs that were not present in 8.x (regressions). Most regressions didn't came from OpenBSD, but were artifacts of porting. Also, the number of #ifdefs in code became so unbearable that no one would want to go through code fixing bugs. In 2012 for me it was obvious that following this route is strategically incorrect. You are never "up to date". You need more efforts to port pf, and you yield in a port of worse and worse quality over time. So, in 2012 I put a lot of efforts to not only bring pf out of a single mutex, but also make it more native to FreeBSD. You can read this through commit logs. The net result is that we got our own pf, that can be maintained further. Unfortunately, still no person is seen on horizon who can take maintainership. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 10:42:00 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19162584; Tue, 29 Jul 2014 10:42:00 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 22D0C28E7; Tue, 29 Jul 2014 10:41:58 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6TAfunN031704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jul 2014 14:41:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6TAfu1D031703; Tue, 29 Jul 2014 14:41:56 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Jul 2014 14:41:56 +0400 From: Gleb Smirnoff To: current@FreeBSD.org Subject: Re: [CFT/CFR] machine independent sf_bufs Message-ID: <20140729104156.GD89995@FreeBSD.org> References: <20140719062725.GB85917@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140719062725.GB85917@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: kib@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 10:42:00 -0000 Hi! Sorry for top quoting, this is to annoy you :) I got zero replies on the below email during a week. I'd really appreciate testing on different platforms. Any takers? On Sat, Jul 19, 2014 at 10:27:25AM +0400, Gleb Smirnoff wrote: T> Hi! T> T> we've got a lot of common code in sys/*/*/vm_machdep.c wrt the T> sf_buf allocation. I have gathered it into kern/subr_sfbuf.c. T> T> o No MD code left in sys/*/*/vm_machdep.c. T> o The arches that have physical map have their implementation in T> machine/sf_buf.h T> o The arches that needs sf_bufs use subr_sfbuf.c, optionally having T> some stuff in machine/sf_buf.h T> T> I can test only i386. I'd be grateful for testing: T> T> arm T> mips T> mips64 T> sparc64 T> powerpc T> i386 XEN T> T> The test is a simple use of any applcation or test that uses sendfile(2). T> The box shouldn't crash :) of course, and after end of a test there T> should be no evidence of sf_buf leak (observed via netstat -m). T> T> -- T> Totus tuus, Glebius. T> Index: sys/amd64/include/sf_buf.h T> =================================================================== T> --- sys/amd64/include/sf_buf.h (revision 268750) T> +++ sys/amd64/include/sf_buf.h (working copy) T> @@ -29,10 +29,6 @@ T> #ifndef _MACHINE_SF_BUF_H_ T> #define _MACHINE_SF_BUF_H_ T> T> -#include T> -#include T> -#include T> - T> /* T> * On this machine, the only purpose for which sf_buf is used is to implement T> * an opaque pointer required by the machine-independent parts of the kernel. T> @@ -39,21 +35,7 @@ T> * That pointer references the vm_page that is "mapped" by the sf_buf. The T> * actual mapping is provided by the direct virtual-to-physical mapping. T> */ T> -struct sf_buf; T> - T> -static inline struct sf_buf * T> -sf_buf_alloc(struct vm_page *m, int pri) T> -{ T> - T> - return ((struct sf_buf *)m); T> -} T> - T> -static inline void T> -sf_buf_free(struct sf_buf *sf) T> -{ T> -} T> - T> -static __inline vm_offset_t T> +static inline vm_offset_t T> sf_buf_kva(struct sf_buf *sf) T> { T> T> @@ -60,11 +42,10 @@ sf_buf_kva(struct sf_buf *sf) T> return (PHYS_TO_DMAP(VM_PAGE_TO_PHYS((vm_page_t)sf))); T> } T> T> -static __inline vm_page_t T> +static inline vm_page_t T> sf_buf_page(struct sf_buf *sf) T> { T> T> return ((vm_page_t)sf); T> } T> - T> #endif /* !_MACHINE_SF_BUF_H_ */ T> Index: sys/arm/arm/vm_machdep.c T> =================================================================== T> --- sys/arm/arm/vm_machdep.c (revision 268750) T> +++ sys/arm/arm/vm_machdep.c (working copy) T> @@ -50,7 +50,6 @@ __FBSDID("$FreeBSD$"); T> #include T> #include T> #include T> -#include T> #include T> #include T> #include T> @@ -83,43 +82,7 @@ __FBSDID("$FreeBSD$"); T> CTASSERT(sizeof(struct switchframe) == 24); T> CTASSERT(sizeof(struct trapframe) == 80); T> T> -#ifndef NSFBUFS T> -#define NSFBUFS (512 + maxusers * 16) T> -#endif T> - T> -static int nsfbufs; T> -static int nsfbufspeak; T> -static int nsfbufsused; T> - T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0, T> - "Maximum number of sendfile(2) sf_bufs available"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0, T> - "Number of sendfile(2) sf_bufs at peak usage"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0, T> - "Number of sendfile(2) sf_bufs in use"); T> - T> -static void sf_buf_init(void *arg); T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); T> - T> -LIST_HEAD(sf_head, sf_buf); T> - T> /* T> - * A hash table of active sendfile(2) buffers T> - */ T> -static struct sf_head *sf_buf_active; T> -static u_long sf_buf_hashmask; T> - T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) T> - T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; T> -static u_int sf_buf_alloc_want; T> - T> -/* T> - * A lock used to synchronize access to the hash table and free list T> - */ T> -static struct mtx sf_buf_lock; T> - T> -/* T> * Finish a fork operation, with process p2 nearly set up. T> * Copy and update the pcb, set up the stack so that the child T> * ready to run and return to user mode. T> @@ -184,107 +147,7 @@ cpu_thread_swapout(struct thread *td) T> { T> } T> T> -/* T> - * Detatch mapped page and release resources back to the system. T> - */ T> void T> -sf_buf_free(struct sf_buf *sf) T> -{ T> - T> - mtx_lock(&sf_buf_lock); T> - sf->ref_count--; T> - if (sf->ref_count == 0) { T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); T> - nsfbufsused--; T> - pmap_kremove(sf->kva); T> - sf->m = NULL; T> - LIST_REMOVE(sf, list_entry); T> - if (sf_buf_alloc_want > 0) T> - wakeup(&sf_buf_freelist); T> - } T> - mtx_unlock(&sf_buf_lock); T> -} T> - T> -/* T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you prefer. :-)) T> - */ T> -static void T> -sf_buf_init(void *arg) T> -{ T> - struct sf_buf *sf_bufs; T> - vm_offset_t sf_base; T> - int i; T> - T> - nsfbufs = NSFBUFS; T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); T> - T> - sf_buf_active = hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); T> - TAILQ_INIT(&sf_buf_freelist); T> - sf_base = kva_alloc(nsfbufs * PAGE_SIZE); T> - sf_bufs = malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, T> - M_NOWAIT | M_ZERO); T> - for (i = 0; i < nsfbufs; i++) { T> - sf_bufs[i].kva = sf_base + i * PAGE_SIZE; T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], free_entry); T> - } T> - sf_buf_alloc_want = 0; T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); T> -} T> - T> -/* T> - * Get an sf_buf from the freelist. Will block if none are available. T> - */ T> -struct sf_buf * T> -sf_buf_alloc(struct vm_page *m, int flags) T> -{ T> - struct sf_head *hash_list; T> - struct sf_buf *sf; T> - int error; T> - T> - hash_list = &sf_buf_active[SF_BUF_HASH(m)]; T> - mtx_lock(&sf_buf_lock); T> - LIST_FOREACH(sf, hash_list, list_entry) { T> - if (sf->m == m) { T> - sf->ref_count++; T> - if (sf->ref_count == 1) { T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - } T> - goto done; T> - } T> - } T> - while ((sf = TAILQ_FIRST(&sf_buf_freelist)) == NULL) { T> - if (flags & SFB_NOWAIT) T> - goto done; T> - sf_buf_alloc_want++; T> - SFSTAT_INC(sf_allocwait); T> - error = msleep(&sf_buf_freelist, &sf_buf_lock, T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", 0); T> - sf_buf_alloc_want--; T> - T> - T> - /* T> - * If we got a signal, don't risk going back to sleep. T> - */ T> - if (error) T> - goto done; T> - } T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> - if (sf->m != NULL) T> - LIST_REMOVE(sf, list_entry); T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); T> - sf->ref_count = 1; T> - sf->m = m; T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - pmap_kenter(sf->kva, VM_PAGE_TO_PHYS(sf->m)); T> -done: T> - mtx_unlock(&sf_buf_lock); T> - return (sf); T> -} T> - T> -void T> cpu_set_syscall_retval(struct thread *td, int error) T> { T> struct trapframe *frame; T> Index: sys/arm/include/sf_buf.h T> =================================================================== T> --- sys/arm/include/sf_buf.h (revision 268750) T> +++ sys/arm/include/sf_buf.h (working copy) T> @@ -29,33 +29,18 @@ T> #ifndef _MACHINE_SF_BUF_H_ T> #define _MACHINE_SF_BUF_H_ T> T> -#include T> - T> -struct vm_page; T> - T> -struct sf_buf { T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ T> - struct vm_page *m; /* currently mapped page */ T> - vm_offset_t kva; /* va of mapping */ T> - int ref_count; /* usage of this mapping */ T> -}; T> - T> -static __inline vm_offset_t T> -sf_buf_kva(struct sf_buf *sf) T> +static inline void T> +sf_buf_map(struct sf_buf *sf, int flags) T> { T> T> - return (sf->kva); T> + pmap_kenter(sf->kva, VM_PAGE_TO_PHYS(sf->m)); T> } T> T> -static __inline struct vm_page * T> -sf_buf_page(struct sf_buf *sf) T> +static inline int T> +sf_buf_unmap(struct sf_buf *sf) T> { T> T> - return (sf->m); T> + pmap_kremove(sf->kva); T> + return (1); T> } T> - T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); T> -void sf_buf_free(struct sf_buf *sf); T> - T> #endif /* !_MACHINE_SF_BUF_H_ */ T> Index: sys/arm/include/vmparam.h T> =================================================================== T> --- sys/arm/include/vmparam.h (revision 268750) T> +++ sys/arm/include/vmparam.h (working copy) T> @@ -170,4 +170,7 @@ extern vm_offset_t vm_max_kernel_address; T> #define VM_MAX_AUTOTUNE_MAXUSERS 384 T> #endif T> T> +#define SFBUF T> +#define SFBUF_MAP T> + T> #endif /* _MACHINE_VMPARAM_H_ */ T> Index: sys/conf/files.arm T> =================================================================== T> --- sys/conf/files.arm (revision 268750) T> +++ sys/conf/files.arm (working copy) T> @@ -77,6 +77,7 @@ font.h optional sc \ T> clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16 ${SC_DFLT_FONT}-8x8" T> kern/subr_busdma_bufalloc.c standard T> kern/subr_dummy_vdso_tc.c standard T> +kern/subr_sfbuf.c standard T> libkern/arm/aeabi_unwind.c standard T> libkern/arm/divsi3.S standard T> libkern/arm/ffs.S standard T> Index: sys/conf/files.i386 T> =================================================================== T> --- sys/conf/files.i386 (revision 268750) T> +++ sys/conf/files.i386 (working copy) T> @@ -520,6 +520,7 @@ isa/vga_isa.c optional vga T> kern/kern_clocksource.c standard T> kern/imgact_aout.c optional compat_aout T> kern/imgact_gzip.c optional gzip T> +kern/subr_sfbuf.c standard T> libkern/divdi3.c standard T> libkern/flsll.c standard T> libkern/memmove.c standard T> Index: sys/conf/files.mips T> =================================================================== T> --- sys/conf/files.mips (revision 268750) T> +++ sys/conf/files.mips (working copy) T> @@ -51,6 +51,7 @@ mips/mips/vm_machdep.c standard T> kern/kern_clocksource.c standard T> kern/link_elf_obj.c standard T> kern/subr_dummy_vdso_tc.c standard T> +kern/subr_sfbuf.c optional mips | mipsel | mipsn32 T> T> # gcc/clang runtime T> libkern/ffsl.c standard T> Index: sys/conf/files.pc98 T> =================================================================== T> --- sys/conf/files.pc98 (revision 268750) T> +++ sys/conf/files.pc98 (working copy) T> @@ -205,6 +205,7 @@ i386/svr4/svr4_machdep.c optional compat_svr4 T> kern/kern_clocksource.c standard T> kern/imgact_aout.c optional compat_aout T> kern/imgact_gzip.c optional gzip T> +kern/subr_sfbuf.c standard T> libkern/divdi3.c standard T> libkern/flsll.c standard T> libkern/memmove.c standard T> Index: sys/conf/files.powerpc T> =================================================================== T> --- sys/conf/files.powerpc (revision 268750) T> +++ sys/conf/files.powerpc (working copy) T> @@ -71,6 +71,7 @@ dev/vt/hw/ofwfb/ofwfb.c optional vt aim T> kern/kern_clocksource.c standard T> kern/subr_dummy_vdso_tc.c standard T> kern/syscalls.c optional ktr T> +kern/subr_sfbuf.c standard T> libkern/ashldi3.c optional powerpc T> libkern/ashrdi3.c optional powerpc T> libkern/bcmp.c standard T> Index: sys/conf/files.sparc64 T> =================================================================== T> --- sys/conf/files.sparc64 (revision 268750) T> +++ sys/conf/files.sparc64 (working copy) T> @@ -63,6 +63,7 @@ dev/uart/uart_kbd_sun.c optional uart sc | vt T> kern/kern_clocksource.c standard T> kern/subr_dummy_vdso_tc.c standard T> kern/syscalls.c optional ktr T> +kern/subr_sfbuf.c standard T> libkern/ffs.c standard T> libkern/ffsl.c standard T> libkern/fls.c standard T> Index: sys/i386/i386/vm_machdep.c T> =================================================================== T> --- sys/i386/i386/vm_machdep.c (revision 268750) T> +++ sys/i386/i386/vm_machdep.c (working copy) T> @@ -118,38 +118,6 @@ static u_int cpu_reset_proxyid; T> static volatile u_int cpu_reset_proxy_active; T> #endif T> T> -static int nsfbufs; T> -static int nsfbufspeak; T> -static int nsfbufsused; T> - T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0, T> - "Maximum number of sendfile(2) sf_bufs available"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0, T> - "Number of sendfile(2) sf_bufs at peak usage"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0, T> - "Number of sendfile(2) sf_bufs in use"); T> - T> -static void sf_buf_init(void *arg); T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); T> - T> -LIST_HEAD(sf_head, sf_buf); T> - T> -/* T> - * A hash table of active sendfile(2) buffers T> - */ T> -static struct sf_head *sf_buf_active; T> -static u_long sf_buf_hashmask; T> - T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) T> - T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; T> -static u_int sf_buf_alloc_want; T> - T> -/* T> - * A lock used to synchronize access to the hash table and free list T> - */ T> -static struct mtx sf_buf_lock; T> - T> extern int _ucodesel, _udatasel; T> T> /* T> @@ -750,122 +718,13 @@ cpu_reset_real() T> } T> T> /* T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you prefer. :-)) T> - */ T> -static void T> -sf_buf_init(void *arg) T> -{ T> - struct sf_buf *sf_bufs; T> - vm_offset_t sf_base; T> - int i; T> - T> - nsfbufs = NSFBUFS; T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); T> - T> - sf_buf_active = hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); T> - TAILQ_INIT(&sf_buf_freelist); T> - sf_base = kva_alloc(nsfbufs * PAGE_SIZE); T> - sf_bufs = malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, T> - M_NOWAIT | M_ZERO); T> - for (i = 0; i < nsfbufs; i++) { T> - sf_bufs[i].kva = sf_base + i * PAGE_SIZE; T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], free_entry); T> - } T> - sf_buf_alloc_want = 0; T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); T> -} T> - T> -/* T> - * Invalidate the cache lines that may belong to the page, if T> - * (possibly old) mapping of the page by sf buffer exists. Returns T> - * TRUE when mapping was found and cache invalidated. T> - */ T> -boolean_t T> -sf_buf_invalidate_cache(vm_page_t m) T> -{ T> - struct sf_head *hash_list; T> - struct sf_buf *sf; T> - boolean_t ret; T> - T> - hash_list = &sf_buf_active[SF_BUF_HASH(m)]; T> - ret = FALSE; T> - mtx_lock(&sf_buf_lock); T> - LIST_FOREACH(sf, hash_list, list_entry) { T> - if (sf->m == m) { T> - /* T> - * Use pmap_qenter to update the pte for T> - * existing mapping, in particular, the PAT T> - * settings are recalculated. T> - */ T> - pmap_qenter(sf->kva, &m, 1); T> - pmap_invalidate_cache_range(sf->kva, sf->kva + T> - PAGE_SIZE); T> - ret = TRUE; T> - break; T> - } T> - } T> - mtx_unlock(&sf_buf_lock); T> - return (ret); T> -} T> - T> -/* T> * Get an sf_buf from the freelist. May block if none are available. T> */ T> -struct sf_buf * T> -sf_buf_alloc(struct vm_page *m, int flags) T> +void T> +sf_buf_map(struct sf_buf *sf, int flags) T> { T> pt_entry_t opte, *ptep; T> - struct sf_head *hash_list; T> - struct sf_buf *sf; T> -#ifdef SMP T> - cpuset_t other_cpus; T> - u_int cpuid; T> -#endif T> - int error; T> T> - KASSERT(curthread->td_pinned > 0 || (flags & SFB_CPUPRIVATE) == 0, T> - ("sf_buf_alloc(SFB_CPUPRIVATE): curthread not pinned")); T> - hash_list = &sf_buf_active[SF_BUF_HASH(m)]; T> - mtx_lock(&sf_buf_lock); T> - LIST_FOREACH(sf, hash_list, list_entry) { T> - if (sf->m == m) { T> - sf->ref_count++; T> - if (sf->ref_count == 1) { T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - } T> -#ifdef SMP T> - goto shootdown; T> -#else T> - goto done; T> -#endif T> - } T> - } T> - while ((sf = TAILQ_FIRST(&sf_buf_freelist)) == NULL) { T> - if (flags & SFB_NOWAIT) T> - goto done; T> - sf_buf_alloc_want++; T> - SFSTAT_INC(sf_allocwait); T> - error = msleep(&sf_buf_freelist, &sf_buf_lock, T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", 0); T> - sf_buf_alloc_want--; T> - T> - /* T> - * If we got a signal, don't risk going back to sleep. T> - */ T> - if (error) T> - goto done; T> - } T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> - if (sf->m != NULL) T> - LIST_REMOVE(sf, list_entry); T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); T> - sf->ref_count = 1; T> - sf->m = m; T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - T> /* T> * Update the sf_buf's virtual-to-physical mapping, flushing the T> * virtual address from the TLB. Since the reference count for T> @@ -876,11 +735,11 @@ cpu_reset_real() T> ptep = vtopte(sf->kva); T> opte = *ptep; T> #ifdef XEN T> - PT_SET_MA(sf->kva, xpmap_ptom(VM_PAGE_TO_PHYS(m)) | pgeflag T> - | PG_RW | PG_V | pmap_cache_bits(m->md.pat_mode, 0)); T> + PT_SET_MA(sf->kva, xpmap_ptom(VM_PAGE_TO_PHYS(sf->m)) | pgeflag T> + | PG_RW | PG_V | pmap_cache_bits(sf->m->md.pat_mode, 0)); T> #else T> - *ptep = VM_PAGE_TO_PHYS(m) | pgeflag | PG_RW | PG_V | T> - pmap_cache_bits(m->md.pat_mode, 0); T> + *ptep = VM_PAGE_TO_PHYS(sf->m) | pgeflag | PG_RW | PG_V | T> + pmap_cache_bits(sf->m->md.pat_mode, 0); T> #endif T> T> /* T> @@ -892,7 +751,21 @@ cpu_reset_real() T> #ifdef SMP T> if ((opte & (PG_V | PG_A)) == (PG_V | PG_A)) T> CPU_ZERO(&sf->cpumask); T> -shootdown: T> + T> + sf_buf_shootdown(sf, flags); T> +#else T> + if ((opte & (PG_V | PG_A)) == (PG_V | PG_A)) T> + pmap_invalidate_page(kernel_pmap, sf->kva); T> +#endif T> +} T> + T> +#ifdef SMP T> +void T> +sf_buf_shootdown(struct sf_buf *sf, int flags) T> +{ T> + cpuset_t other_cpus; T> + u_int cpuid; T> + T> sched_pin(); T> cpuid = PCPU_GET(cpuid); T> if (!CPU_ISSET(cpuid, &sf->cpumask)) { T> @@ -909,42 +782,50 @@ cpu_reset_real() T> } T> } T> sched_unpin(); T> +} T> +#endif T> + T> +/* T> + * MD part of sf_buf_free(). T> + */ T> +int T> +sf_buf_unmap(struct sf_buf *sf) T> +{ T> +#ifdef XEN T> + /* T> + * Xen doesn't like having dangling R/W mappings T> + */ T> + pmap_qremove(sf->kva, 1); T> + return (1); T> #else T> - if ((opte & (PG_V | PG_A)) == (PG_V | PG_A)) T> - pmap_invalidate_page(kernel_pmap, sf->kva); T> + return (0); T> #endif T> -done: T> - mtx_unlock(&sf_buf_lock); T> - return (sf); T> } T> T> +static void T> +sf_buf_invalidate(struct sf_buf *sf) T> +{ T> + vm_page_t m = sf->m; T> + T> + /* T> + * Use pmap_qenter to update the pte for T> + * existing mapping, in particular, the PAT T> + * settings are recalculated. T> + */ T> + pmap_qenter(sf->kva, &m, 1); T> + pmap_invalidate_cache_range(sf->kva, sf->kva + PAGE_SIZE); T> +} T> + T> /* T> - * Remove a reference from the given sf_buf, adding it to the free T> - * list when its reference count reaches zero. A freed sf_buf still, T> - * however, retains its virtual-to-physical mapping until it is T> - * recycled or reactivated by sf_buf_alloc(9). T> + * Invalidate the cache lines that may belong to the page, if T> + * (possibly old) mapping of the page by sf buffer exists. Returns T> + * TRUE when mapping was found and cache invalidated. T> */ T> -void T> -sf_buf_free(struct sf_buf *sf) T> +boolean_t T> +sf_buf_invalidate_cache(vm_page_t m) T> { T> T> - mtx_lock(&sf_buf_lock); T> - sf->ref_count--; T> - if (sf->ref_count == 0) { T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); T> - nsfbufsused--; T> -#ifdef XEN T> -/* T> - * Xen doesn't like having dangling R/W mappings T> - */ T> - pmap_qremove(sf->kva, 1); T> - sf->m = NULL; T> - LIST_REMOVE(sf, list_entry); T> -#endif T> - if (sf_buf_alloc_want > 0) T> - wakeup(&sf_buf_freelist); T> - } T> - mtx_unlock(&sf_buf_lock); T> + return (sf_buf_process_page(m, sf_buf_invalidate)); T> } T> T> /* T> Index: sys/i386/include/sf_buf.h T> =================================================================== T> --- sys/i386/include/sf_buf.h (revision 268750) T> +++ sys/i386/include/sf_buf.h (working copy) T> @@ -1,5 +1,5 @@ T> /*- T> - * Copyright (c) 2003, 2005 Alan L. Cox T> + * Copyright (c) 2014 Gleb Smirnoff T> * All rights reserved. T> * T> * Redistribution and use in source and binary forms, with or without T> @@ -29,39 +29,8 @@ T> #ifndef _MACHINE_SF_BUF_H_ T> #define _MACHINE_SF_BUF_H_ T> T> -#include T> -#include T> +void sf_buf_map(struct sf_buf *, int); T> +int sf_buf_unmap(struct sf_buf *); T> +boolean_t sf_buf_invalidate_cache(vm_page_t); T> T> -struct vm_page; T> - T> -struct sf_buf { T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ T> - struct vm_page *m; /* currently mapped page */ T> - vm_offset_t kva; /* va of mapping */ T> - int ref_count; /* usage of this mapping */ T> -#ifdef SMP T> - cpuset_t cpumask; /* cpus on which mapping is valid */ T> -#endif T> -}; T> - T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); T> -void sf_buf_free(struct sf_buf *sf); T> - T> -static __inline vm_offset_t T> -sf_buf_kva(struct sf_buf *sf) T> -{ T> - T> - return (sf->kva); T> -} T> - T> -static __inline struct vm_page * T> -sf_buf_page(struct sf_buf *sf) T> -{ T> - T> - return (sf->m); T> -} T> - T> -boolean_t sf_buf_invalidate_cache(vm_page_t m); T> - T> #endif /* !_MACHINE_SF_BUF_H_ */ T> Index: sys/i386/include/vmparam.h T> =================================================================== T> --- sys/i386/include/vmparam.h (revision 268750) T> +++ sys/i386/include/vmparam.h (working copy) T> @@ -198,4 +198,9 @@ T> #define VM_MAX_AUTOTUNE_MAXUSERS 384 T> #endif T> T> +#define SFBUF T> +#define SFBUF_MAP T> +#define SFBUF_CPUSET T> +#define SFBUF_PROCESS_PAGE T> + T> #endif /* _MACHINE_VMPARAM_H_ */ T> Index: sys/kern/subr_sfbuf.c T> =================================================================== T> --- sys/kern/subr_sfbuf.c (revision 0) T> +++ sys/kern/subr_sfbuf.c (working copy) T> @@ -0,0 +1,226 @@ T> +/*- T> + * Copyright (c) 2014 Gleb Smirnoff T> + * Copyright (c) 2003, 2005 Alan L. Cox T> + * All rights reserved. T> + * T> + * Redistribution and use in source and binary forms, with or without T> + * modification, are permitted provided that the following conditions T> + * are met: T> + * 1. Redistributions of source code must retain the above copyright T> + * notice, this list of conditions and the following disclaimer. T> + * 2. Redistributions in binary form must reproduce the above copyright T> + * notice, this list of conditions and the following disclaimer in the T> + * documentation and/or other materials provided with the distribution. T> + * T> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND T> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE T> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE T> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE T> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL T> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS T> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) T> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT T> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY T> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF T> + * SUCH DAMAGE. T> + */ T> + T> +#include T> +__FBSDID("$FreeBSD$"); T> + T> +#include T> +#include T> +#include T> +#include T> +#include T> +#include T> +#include T> +#include T> + T> +#include T> +#include T> +#include T> + T> +#ifndef NSFBUFS T> +#define NSFBUFS (512 + maxusers * 16) T> +#endif T> + T> +static int nsfbufs; T> +static int nsfbufspeak; T> +static int nsfbufsused; T> + T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0, T> + "Maximum number of sendfile(2) sf_bufs available"); T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0, T> + "Number of sendfile(2) sf_bufs at peak usage"); T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0, T> + "Number of sendfile(2) sf_bufs in use"); T> + T> +static void sf_buf_init(void *arg); T> +SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); T> + T> +LIST_HEAD(sf_head, sf_buf); T> + T> +/* T> + * A hash table of active sendfile(2) buffers T> + */ T> +static struct sf_head *sf_buf_active; T> +static u_long sf_buf_hashmask; T> + T> +#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) T> + T> +static TAILQ_HEAD(, sf_buf) sf_buf_freelist; T> +static u_int sf_buf_alloc_want; T> + T> +/* T> + * A lock used to synchronize access to the hash table and free list T> + */ T> +static struct mtx sf_buf_lock; T> + T> +/* T> + * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you prefer. :-)) T> + */ T> +static void T> +sf_buf_init(void *arg) T> +{ T> + struct sf_buf *sf_bufs; T> + vm_offset_t sf_base; T> + int i; T> + T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP T> + if (SFBUF_OPTIONAL_DIRECT_MAP) T> + return; T> +#endif T> + T> + nsfbufs = NSFBUFS; T> + TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); T> + T> + sf_buf_active = hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); T> + TAILQ_INIT(&sf_buf_freelist); T> + sf_base = kva_alloc(nsfbufs * PAGE_SIZE); T> + sf_bufs = malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, T> + M_NOWAIT | M_ZERO); T> + KASSERT(sf_bufs, ("%s: malloc failure", __func__)); T> + for (i = 0; i < nsfbufs; i++) { T> + sf_bufs[i].kva = sf_base + i * PAGE_SIZE; T> + TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], free_entry); T> + } T> + sf_buf_alloc_want = 0; T> + mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); T> +} T> + T> +/* T> + * Get an sf_buf from the freelist. May block if none are available. T> + */ T> +struct sf_buf * T> +sf_buf_alloc(struct vm_page *m, int flags) T> +{ T> + struct sf_head *hash_list; T> + struct sf_buf *sf; T> + int error; T> + T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP T> + if (SFBUF_OPTIONAL_DIRECT_MAP) T> + return ((struct sf_buf *)m); T> +#endif T> + T> + KASSERT(curthread->td_pinned > 0 || (flags & SFB_CPUPRIVATE) == 0, T> + ("sf_buf_alloc(SFB_CPUPRIVATE): curthread not pinned")); T> + hash_list = &sf_buf_active[SF_BUF_HASH(m)]; T> + mtx_lock(&sf_buf_lock); T> + LIST_FOREACH(sf, hash_list, list_entry) { T> + if (sf->m == m) { T> + sf->ref_count++; T> + if (sf->ref_count == 1) { T> + TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> + nsfbufsused++; T> + nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> + } T> +#if defined(SMP) && defined(SFBUF_CPUSET) T> + sf_buf_shootdown(sf, flags); T> +#endif T> + goto done; T> + } T> + } T> + while ((sf = TAILQ_FIRST(&sf_buf_freelist)) == NULL) { T> + if (flags & SFB_NOWAIT) T> + goto done; T> + sf_buf_alloc_want++; T> + SFSTAT_INC(sf_allocwait); T> + error = msleep(&sf_buf_freelist, &sf_buf_lock, T> + (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", 0); T> + sf_buf_alloc_want--; T> + T> + /* T> + * If we got a signal, don't risk going back to sleep. T> + */ T> + if (error) T> + goto done; T> + } T> + TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> + if (sf->m != NULL) T> + LIST_REMOVE(sf, list_entry); T> + LIST_INSERT_HEAD(hash_list, sf, list_entry); T> + sf->ref_count = 1; T> + sf->m = m; T> + nsfbufsused++; T> + nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> + sf_buf_map(sf, flags); T> +done: T> + mtx_unlock(&sf_buf_lock); T> + return (sf); T> +} T> + T> +/* T> + * Remove a reference from the given sf_buf, adding it to the free T> + * list when its reference count reaches zero. A freed sf_buf still, T> + * however, retains its virtual-to-physical mapping until it is T> + * recycled or reactivated by sf_buf_alloc(9). T> + */ T> +void T> +sf_buf_free(struct sf_buf *sf) T> +{ T> + T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP T> + if (SFBUF_OPTIONAL_DIRECT_MAP) T> + return; T> +#endif T> + T> + mtx_lock(&sf_buf_lock); T> + sf->ref_count--; T> + if (sf->ref_count == 0) { T> + TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); T> + nsfbufsused--; T> + if (sf_buf_unmap(sf)) { T> + sf->m = NULL; T> + LIST_REMOVE(sf, list_entry); T> + } T> + if (sf_buf_alloc_want > 0) T> + wakeup(&sf_buf_freelist); T> + } T> + mtx_unlock(&sf_buf_lock); T> +} T> + T> +#ifdef SFBUF_PROCESS_PAGE T> +/* T> + * Run callback function on sf_buf that holds a certain page. T> + */ T> +boolean_t T> +sf_buf_process_page(vm_page_t m, void (*cb)(struct sf_buf *)) T> +{ T> + struct sf_head *hash_list; T> + struct sf_buf *sf; T> + T> + hash_list = &sf_buf_active[SF_BUF_HASH(m)]; T> + mtx_lock(&sf_buf_lock); T> + LIST_FOREACH(sf, hash_list, list_entry) { T> + if (sf->m == m) { T> + cb(sf); T> + mtx_unlock(&sf_buf_lock); T> + return (TRUE); T> + } T> + } T> + mtx_unlock(&sf_buf_lock); T> + return (FALSE); T> +} T> +#endif /* SFBUF_PROCESS_PAGE */ T> T> Property changes on: sys/kern/subr_sfbuf.c T> ___________________________________________________________________ T> Added: svn:mime-type T> ## -0,0 +1 ## T> +text/plain T> \ No newline at end of property T> Added: svn:keywords T> ## -0,0 +1 ## T> +FreeBSD=%H T> \ No newline at end of property T> Added: svn:eol-style T> ## -0,0 +1 ## T> +native T> \ No newline at end of property T> Index: sys/mips/include/sf_buf.h T> =================================================================== T> --- sys/mips/include/sf_buf.h (revision 268750) T> +++ sys/mips/include/sf_buf.h (working copy) T> @@ -29,31 +29,9 @@ T> #ifndef _MACHINE_SF_BUF_H_ T> #define _MACHINE_SF_BUF_H_ T> T> -#ifdef __mips_n64 T> -#include T> -#include T> -#include T> -#else T> -#include T> -#endif T> +#ifdef __mips_n64 /* In 64 bit the whole memory is directly mapped */ T> T> -#ifdef __mips_n64 T> -/* In 64 bit the whole memory is directly mapped */ T> -struct sf_buf; T> - T> -static inline struct sf_buf * T> -sf_buf_alloc(struct vm_page *m, int pri) T> -{ T> - T> - return ((struct sf_buf *)m); T> -} T> - T> -static inline void T> -sf_buf_free(struct sf_buf *sf) T> -{ T> -} T> - T> -static __inline vm_offset_t T> +static inline vm_offset_t T> sf_buf_kva(struct sf_buf *sf) T> { T> vm_page_t m; T> @@ -62,7 +40,7 @@ sf_buf_kva(struct sf_buf *sf) T> return (MIPS_PHYS_TO_DIRECT(VM_PAGE_TO_PHYS(m))); T> } T> T> -static __inline struct vm_page * T> +static inline struct vm_page * T> sf_buf_page(struct sf_buf *sf) T> { T> T> @@ -69,31 +47,5 @@ sf_buf_page(struct sf_buf *sf) T> return ((vm_page_t)sf); T> } T> T> -#else /* ! __mips_n64 */ T> -struct vm_page; T> - T> -struct sf_buf { T> - SLIST_ENTRY(sf_buf) free_list; /* list of free buffer slots */ T> - struct vm_page *m; /* currently mapped page */ T> - vm_offset_t kva; /* va of mapping */ T> -}; T> - T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); T> -void sf_buf_free(struct sf_buf *sf); T> - T> -static __inline vm_offset_t T> -sf_buf_kva(struct sf_buf *sf) T> -{ T> - T> - return (sf->kva); T> -} T> - T> -static __inline struct vm_page * T> -sf_buf_page(struct sf_buf *sf) T> -{ T> - T> - return (sf->m); T> -} T> #endif /* __mips_n64 */ T> - T> #endif /* !_MACHINE_SF_BUF_H_ */ T> Index: sys/mips/include/vmparam.h T> =================================================================== T> --- sys/mips/include/vmparam.h (revision 268750) T> +++ sys/mips/include/vmparam.h (working copy) T> @@ -187,4 +187,8 @@ T> T> #define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ T> T> +#ifndef __mips_n64 T> +#define SFBUF T> +#endif T> + T> #endif /* !_MACHINE_VMPARAM_H_ */ T> Index: sys/mips/mips/vm_machdep.c T> =================================================================== T> --- sys/mips/mips/vm_machdep.c (revision 268750) T> +++ sys/mips/mips/vm_machdep.c (working copy) T> @@ -76,9 +76,6 @@ __FBSDID("$FreeBSD$"); T> T> #include T> #include T> -#ifndef __mips_n64 T> -#include T> -#endif T> T> /* Duplicated from asm.h */ T> #if defined(__mips_o32) T> @@ -92,39 +89,7 @@ __FBSDID("$FreeBSD$"); T> #define CALLFRAME_SIZ (SZREG * 4) T> #endif T> T> -#ifndef __mips_n64 T> - T> -#ifndef NSFBUFS T> -#define NSFBUFS (512 + maxusers * 16) T> -#endif T> - T> -static int nsfbufs; T> -static int nsfbufspeak; T> -static int nsfbufsused; T> - T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0, T> - "Maximum number of sendfile(2) sf_bufs available"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0, T> - "Number of sendfile(2) sf_bufs at peak usage"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0, T> - "Number of sendfile(2) sf_bufs in use"); T> - T> -static void sf_buf_init(void *arg); T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); T> - T> /* T> - * Expanded sf_freelist head. Really an SLIST_HEAD() in disguise, with the T> - * sf_freelist head with the sf_lock mutex. T> - */ T> -static struct { T> - SLIST_HEAD(, sf_buf) sf_head; T> - struct mtx sf_lock; T> -} sf_freelist; T> - T> -static u_int sf_buf_alloc_want; T> -#endif /* !__mips_n64 */ T> - T> -/* T> * Finish a fork operation, with process p2 nearly set up. T> * Copy and update the pcb, set up the stack so that the child T> * ready to run and return to user mode. T> @@ -513,84 +478,6 @@ cpu_set_upcall_kse(struct thread *td, void (*entry T> #define ZIDLE_HI(v) ((v) * 4 / 5) T> T> /* T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you prefer. :-)) T> - */ T> -#ifndef __mips_n64 T> -static void T> -sf_buf_init(void *arg) T> -{ T> - struct sf_buf *sf_bufs; T> - vm_offset_t sf_base; T> - int i; T> - T> - nsfbufs = NSFBUFS; T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); T> - T> - mtx_init(&sf_freelist.sf_lock, "sf_bufs list lock", NULL, MTX_DEF); T> - SLIST_INIT(&sf_freelist.sf_head); T> - sf_base = kva_alloc(nsfbufs * PAGE_SIZE); T> - sf_bufs = malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, T> - M_NOWAIT | M_ZERO); T> - for (i = 0; i < nsfbufs; i++) { T> - sf_bufs[i].kva = sf_base + i * PAGE_SIZE; T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, &sf_bufs[i], free_list); T> - } T> - sf_buf_alloc_want = 0; T> -} T> - T> -/* T> - * Get an sf_buf from the freelist. Will block if none are available. T> - */ T> -struct sf_buf * T> -sf_buf_alloc(struct vm_page *m, int flags) T> -{ T> - struct sf_buf *sf; T> - int error; T> - T> - mtx_lock(&sf_freelist.sf_lock); T> - while ((sf = SLIST_FIRST(&sf_freelist.sf_head)) == NULL) { T> - if (flags & SFB_NOWAIT) T> - break; T> - sf_buf_alloc_want++; T> - SFSTAT_INC(sf_allocwait); T> - error = msleep(&sf_freelist, &sf_freelist.sf_lock, T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", 0); T> - sf_buf_alloc_want--; T> - T> - /* T> - * If we got a signal, don't risk going back to sleep. T> - */ T> - if (error) T> - break; T> - } T> - if (sf != NULL) { T> - SLIST_REMOVE_HEAD(&sf_freelist.sf_head, free_list); T> - sf->m = m; T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - pmap_qenter(sf->kva, &sf->m, 1); T> - } T> - mtx_unlock(&sf_freelist.sf_lock); T> - return (sf); T> -} T> - T> -/* T> - * Release resources back to the system. T> - */ T> -void T> -sf_buf_free(struct sf_buf *sf) T> -{ T> - pmap_qremove(sf->kva, 1); T> - mtx_lock(&sf_freelist.sf_lock); T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, sf, free_list); T> - nsfbufsused--; T> - if (sf_buf_alloc_want > 0) T> - wakeup(&sf_freelist); T> - mtx_unlock(&sf_freelist.sf_lock); T> -} T> -#endif /* !__mips_n64 */ T> - T> -/* T> * Software interrupt handler for queued VM system processing. T> */ T> void T> Index: sys/powerpc/include/sf_buf.h T> =================================================================== T> --- sys/powerpc/include/sf_buf.h (revision 268750) T> +++ sys/powerpc/include/sf_buf.h (working copy) T> @@ -1,80 +0,0 @@ T> -/*- T> - * Copyright (c) 2003 Alan L. Cox T> - * All rights reserved. T> - * T> - * Redistribution and use in source and binary forms, with or without T> - * modification, are permitted provided that the following conditions T> - * are met: T> - * 1. Redistributions of source code must retain the above copyright T> - * notice, this list of conditions and the following disclaimer. T> - * 2. Redistributions in binary form must reproduce the above copyright T> - * notice, this list of conditions and the following disclaimer in the T> - * documentation and/or other materials provided with the distribution. T> - * T> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND T> - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE T> - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE T> - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE T> - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL T> - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS T> - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) T> - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT T> - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY T> - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF T> - * SUCH DAMAGE. T> - * T> - * $FreeBSD$ T> - */ T> - T> -#ifndef _MACHINE_SF_BUF_H_ T> -#define _MACHINE_SF_BUF_H_ T> - T> -#include T> -#include T> -#include T> -#include T> -#include T> - T> -struct vm_page; T> - T> -struct sf_buf { T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ T> - struct vm_page *m; /* currently mapped page */ T> - vm_offset_t kva; /* va of mapping */ T> - int ref_count; /* usage of this mapping */ T> -}; T> - T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); T> -void sf_buf_free(struct sf_buf *sf); T> - T> -/* T> - * On 32-bit OEA, the only purpose for which sf_buf is used is to implement T> - * an opaque pointer required by the machine-independent parts of the kernel. T> - * That pointer references the vm_page that is "mapped" by the sf_buf. The T> - * actual mapping is provided by the direct virtual-to-physical mapping. T> - * T> - * On OEA64 and Book-E, we need to do something a little more complicated. Use T> - * the runtime-detected hw_direct_map to pick between the two cases. Our T> - * friends in vm_machdep.c will do the same to ensure nothing gets confused. T> - */ T> - T> -static __inline vm_offset_t T> -sf_buf_kva(struct sf_buf *sf) T> -{ T> - if (hw_direct_map) T> - return (VM_PAGE_TO_PHYS((vm_page_t)sf)); T> - T> - return (sf->kva); T> -} T> - T> -static __inline struct vm_page * T> -sf_buf_page(struct sf_buf *sf) T> -{ T> - if (hw_direct_map) T> - return ((vm_page_t)sf); T> - T> - return (sf->m); T> -} T> - T> -#endif /* !_MACHINE_SF_BUF_H_ */ T> Index: sys/powerpc/include/vmparam.h T> =================================================================== T> --- sys/powerpc/include/vmparam.h (revision 268750) T> +++ sys/powerpc/include/vmparam.h (working copy) T> @@ -197,4 +197,18 @@ struct pmap_physseg { T> T> #define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ T> T> +/* T> + * On 32-bit OEA, the only purpose for which sf_buf is used is to implement T> + * an opaque pointer required by the machine-independent parts of the kernel. T> + * That pointer references the vm_page that is "mapped" by the sf_buf. The T> + * actual mapping is provided by the direct virtual-to-physical mapping. T> + * T> + * On OEA64 and Book-E, we need to do something a little more complicated. Use T> + * the runtime-detected hw_direct_map to pick between the two cases. Our T> + * friends in vm_machdep.c will do the same to ensure nothing gets confused. T> + */ T> +#define SFBUF T> +#define SFBUF_NOMD T> +#define SFBUF_OPTIONAL_DIRECT_MAP hw_direct_map T> + T> #endif /* _MACHINE_VMPARAM_H_ */ T> Index: sys/powerpc/powerpc/vm_machdep.c T> =================================================================== T> --- sys/powerpc/powerpc/vm_machdep.c (revision 268750) T> +++ sys/powerpc/powerpc/vm_machdep.c (working copy) T> @@ -80,7 +80,6 @@ T> #include T> #include T> #include T> -#include T> #include T> #include T> #include T> @@ -100,47 +99,6 @@ T> #include T> #include T> T> -/* T> - * On systems without a direct mapped region (e.g. PPC64), T> - * we use the same code as the Book E implementation. Since T> - * we need to have runtime detection of this, define some machinery T> - * for sf_bufs in this case, and ignore it on systems with direct maps. T> - */ T> - T> -#ifndef NSFBUFS T> -#define NSFBUFS (512 + maxusers * 16) T> -#endif T> - T> -static int nsfbufs; T> -static int nsfbufspeak; T> -static int nsfbufsused; T> - T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0, T> - "Maximum number of sendfile(2) sf_bufs available"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0, T> - "Number of sendfile(2) sf_bufs at peak usage"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0, T> - "Number of sendfile(2) sf_bufs in use"); T> - T> -static void sf_buf_init(void *arg); T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); T> - T> -LIST_HEAD(sf_head, sf_buf); T> - T> -/* A hash table of active sendfile(2) buffers */ T> -static struct sf_head *sf_buf_active; T> -static u_long sf_buf_hashmask; T> - T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) T> - T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; T> -static u_int sf_buf_alloc_want; T> - T> -/* T> - * A lock used to synchronize access to the hash table and free list T> - */ T> -static struct mtx sf_buf_lock; T> - T> #ifdef __powerpc64__ T> extern uintptr_t tocbase; T> #endif T> @@ -245,124 +203,6 @@ cpu_exit(struct thread *td) T> } T> T> /* T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you prefer. :-)) T> - */ T> -static void T> -sf_buf_init(void *arg) T> -{ T> - struct sf_buf *sf_bufs; T> - vm_offset_t sf_base; T> - int i; T> - T> - /* Don't bother on systems with a direct map */ T> - if (hw_direct_map) T> - return; T> - T> - nsfbufs = NSFBUFS; T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); T> - T> - sf_buf_active = hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); T> - TAILQ_INIT(&sf_buf_freelist); T> - sf_base = kva_alloc(nsfbufs * PAGE_SIZE); T> - sf_bufs = malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, T> - M_NOWAIT | M_ZERO); T> - T> - for (i = 0; i < nsfbufs; i++) { T> - sf_bufs[i].kva = sf_base + i * PAGE_SIZE; T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], free_entry); T> - } T> - sf_buf_alloc_want = 0; T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); T> -} T> - T> -/* T> - * Get an sf_buf from the freelist. Will block if none are available. T> - */ T> -struct sf_buf * T> -sf_buf_alloc(struct vm_page *m, int flags) T> -{ T> - struct sf_head *hash_list; T> - struct sf_buf *sf; T> - int error; T> - T> - if (hw_direct_map) { T> - /* Shortcut the direct mapped case */ T> - return ((struct sf_buf *)m); T> - } T> - T> - hash_list = &sf_buf_active[SF_BUF_HASH(m)]; T> - mtx_lock(&sf_buf_lock); T> - LIST_FOREACH(sf, hash_list, list_entry) { T> - if (sf->m == m) { T> - sf->ref_count++; T> - if (sf->ref_count == 1) { T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - } T> - goto done; T> - } T> - } T> - T> - while ((sf = TAILQ_FIRST(&sf_buf_freelist)) == NULL) { T> - if (flags & SFB_NOWAIT) T> - goto done; T> - T> - sf_buf_alloc_want++; T> - SFSTAT_INC(sf_allocwait); T> - error = msleep(&sf_buf_freelist, &sf_buf_lock, T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", 0); T> - sf_buf_alloc_want--; T> - T> - /* T> - * If we got a signal, don't risk going back to sleep. T> - */ T> - if (error) T> - goto done; T> - } T> - T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); T> - if (sf->m != NULL) T> - LIST_REMOVE(sf, list_entry); T> - T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); T> - sf->ref_count = 1; T> - sf->m = m; T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - pmap_qenter(sf->kva, &sf->m, 1); T> -done: T> - mtx_unlock(&sf_buf_lock); T> - return (sf); T> -} T> - T> -/* T> - * Detach mapped page and release resources back to the system. T> - * T> - * Remove a reference from the given sf_buf, adding it to the free T> - * list when its reference count reaches zero. A freed sf_buf still, T> - * however, retains its virtual-to-physical mapping until it is T> - * recycled or reactivated by sf_buf_alloc(9). T> - */ T> -void T> -sf_buf_free(struct sf_buf *sf) T> -{ T> - if (hw_direct_map) T> - return; T> - T> - mtx_lock(&sf_buf_lock); T> - sf->ref_count--; T> - if (sf->ref_count == 0) { T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); T> - nsfbufsused--; T> - T> - if (sf_buf_alloc_want > 0) T> - wakeup(&sf_buf_freelist); T> - } T> - mtx_unlock(&sf_buf_lock); T> -} T> - T> -/* T> * Software interrupt handler for queued VM system processing. T> */ T> void T> Index: sys/sparc64/include/sf_buf.h T> =================================================================== T> --- sys/sparc64/include/sf_buf.h (revision 268750) T> +++ sys/sparc64/include/sf_buf.h (working copy) T> @@ -1,59 +0,0 @@ T> -/*- T> - * Copyright (c) 2003 Alan L. Cox T> - * All rights reserved. T> - * T> - * Redistribution and use in source and binary forms, with or without T> - * modification, are permitted provided that the following conditions T> - * are met: T> - * 1. Redistributions of source code must retain the above copyright T> - * notice, this list of conditions and the following disclaimer. T> - * 2. Redistributions in binary form must reproduce the above copyright T> - * notice, this list of conditions and the following disclaimer in the T> - * documentation and/or other materials provided with the distribution. T> - * T> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND T> - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE T> - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE T> - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE T> - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL T> - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS T> - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) T> - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT T> - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY T> - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF T> - * SUCH DAMAGE. T> - * T> - * $FreeBSD$ T> - */ T> - T> -#ifndef _MACHINE_SF_BUF_H_ T> -#define _MACHINE_SF_BUF_H_ T> - T> -#include T> - T> -struct vm_page; T> - T> -struct sf_buf { T> - SLIST_ENTRY(sf_buf) free_list; /* list of free buffer slots */ T> - struct vm_page *m; /* currently mapped page */ T> - vm_offset_t kva; /* va of mapping */ T> -}; T> - T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); T> -void sf_buf_free(struct sf_buf *sf); T> - T> -static __inline vm_offset_t T> -sf_buf_kva(struct sf_buf *sf) T> -{ T> - T> - return (sf->kva); T> -} T> - T> -static __inline struct vm_page * T> -sf_buf_page(struct sf_buf *sf) T> -{ T> - T> - return (sf->m); T> -} T> - T> -#endif /* !_MACHINE_SF_BUF_H_ */ T> Index: sys/sparc64/include/vmparam.h T> =================================================================== T> --- sys/sparc64/include/vmparam.h (revision 268750) T> +++ sys/sparc64/include/vmparam.h (working copy) T> @@ -239,4 +239,7 @@ extern vm_offset_t vm_max_kernel_address; T> */ T> #define ZERO_REGION_SIZE PAGE_SIZE T> T> +#define SFBUF T> +#define SFBUF_NOMD T> + T> #endif /* !_MACHINE_VMPARAM_H_ */ T> Index: sys/sparc64/sparc64/vm_machdep.c T> =================================================================== T> --- sys/sparc64/sparc64/vm_machdep.c (revision 268750) T> +++ sys/sparc64/sparc64/vm_machdep.c (working copy) T> @@ -53,7 +53,6 @@ __FBSDID("$FreeBSD$"); T> #include T> #include T> #include T> -#include T> #include T> #include T> #include T> @@ -84,35 +83,6 @@ __FBSDID("$FreeBSD$"); T> #include T> #include T> T> -#ifndef NSFBUFS T> -#define NSFBUFS (512 + maxusers * 16) T> -#endif T> - T> -static int nsfbufs; T> -static int nsfbufspeak; T> -static int nsfbufsused; T> - T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, 0, T> - "Maximum number of sendfile(2) sf_bufs available"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, &nsfbufspeak, 0, T> - "Number of sendfile(2) sf_bufs at peak usage"); T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, &nsfbufsused, 0, T> - "Number of sendfile(2) sf_bufs in use"); T> - T> -static void sf_buf_init(void *arg); T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); T> - T> -/* T> - * Expanded sf_freelist head. Really an SLIST_HEAD() in disguise, with the T> - * sf_freelist head with the sf_lock mutex. T> - */ T> -static struct { T> - SLIST_HEAD(, sf_buf) sf_head; T> - struct mtx sf_lock; T> -} sf_freelist; T> - T> -static u_int sf_buf_alloc_want; T> - T> PMAP_STATS_VAR(uma_nsmall_alloc); T> PMAP_STATS_VAR(uma_nsmall_alloc_oc); T> PMAP_STATS_VAR(uma_nsmall_free); T> @@ -417,84 +387,7 @@ is_physical_memory(vm_paddr_t addr) T> return (0); T> } T> T> -/* T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you prefer. :-)) T> - */ T> -static void T> -sf_buf_init(void *arg) T> -{ T> - struct sf_buf *sf_bufs; T> - vm_offset_t sf_base; T> - int i; T> - T> - nsfbufs = NSFBUFS; T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); T> - T> - mtx_init(&sf_freelist.sf_lock, "sf_bufs list lock", NULL, MTX_DEF); T> - SLIST_INIT(&sf_freelist.sf_head); T> - sf_base = kva_alloc(nsfbufs * PAGE_SIZE); T> - sf_bufs = malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, T> - M_NOWAIT | M_ZERO); T> - for (i = 0; i < nsfbufs; i++) { T> - sf_bufs[i].kva = sf_base + i * PAGE_SIZE; T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, &sf_bufs[i], free_list); T> - } T> - sf_buf_alloc_want = 0; T> -} T> - T> -/* T> - * Get an sf_buf from the freelist. Will block if none are available. T> - */ T> -struct sf_buf * T> -sf_buf_alloc(struct vm_page *m, int flags) T> -{ T> - struct sf_buf *sf; T> - int error; T> - T> - mtx_lock(&sf_freelist.sf_lock); T> - while ((sf = SLIST_FIRST(&sf_freelist.sf_head)) == NULL) { T> - if (flags & SFB_NOWAIT) T> - break; T> - sf_buf_alloc_want++; T> - SFSTAT_INC(sf_allocwait); T> - error = msleep(&sf_freelist, &sf_freelist.sf_lock, T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", 0); T> - sf_buf_alloc_want--; T> - T> - /* T> - * If we got a signal, don't risk going back to sleep. T> - */ T> - if (error) T> - break; T> - } T> - if (sf != NULL) { T> - SLIST_REMOVE_HEAD(&sf_freelist.sf_head, free_list); T> - sf->m = m; T> - nsfbufsused++; T> - nsfbufspeak = imax(nsfbufspeak, nsfbufsused); T> - pmap_qenter(sf->kva, &sf->m, 1); T> - } T> - mtx_unlock(&sf_freelist.sf_lock); T> - return (sf); T> -} T> - T> -/* T> - * Release resources back to the system. T> - */ T> void T> -sf_buf_free(struct sf_buf *sf) T> -{ T> - T> - pmap_qremove(sf->kva, 1); T> - mtx_lock(&sf_freelist.sf_lock); T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, sf, free_list); T> - nsfbufsused--; T> - if (sf_buf_alloc_want > 0) T> - wakeup(&sf_freelist); T> - mtx_unlock(&sf_freelist.sf_lock); T> -} T> - T> -void T> swi_vm(void *v) T> { T> T> Index: sys/sys/sf_buf.h T> =================================================================== T> --- sys/sys/sf_buf.h (revision 268750) T> +++ sys/sys/sf_buf.h (working copy) T> @@ -29,6 +29,114 @@ T> #ifndef _SYS_SF_BUF_H_ T> #define _SYS_SF_BUF_H_ T> T> +struct sfstat { /* sendfile statistics */ T> + uint64_t sf_iocnt; /* times sendfile had to do disk I/O */ T> + uint64_t sf_allocfail; /* times sfbuf allocation failed */ T> + uint64_t sf_allocwait; /* times sfbuf allocation had to wait */ T> +}; T> + T> +#ifdef _KERNEL T> +#include T> +#include T> +#include T> +#include T> +#include T> +#include T> + T> +#ifdef SFBUF T> +#if defined(SMP) && defined(SFBUF_CPUSET) T> +#include T> +#endif T> +#include T> + T> +struct sf_buf { T> + LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ T> + TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ T> + vm_page_t m; /* currently mapped page */ T> + vm_offset_t kva; /* va of mapping */ T> + int ref_count; /* usage of this mapping */ T> +#if defined(SMP) && defined(SFBUF_CPUSET) T> + cpuset_t cpumask; /* where mapping is valid */ T> +#endif T> +}; T> +#else /* ! SFBUF */ T> +struct sf_buf; T> +#endif /* SFBUF */ T> + T> +#ifndef SFBUF_NOMD T> +#include T> +#endif T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP T> +#include T> +#endif T> + T> +#ifdef SFBUF T> +struct sf_buf *sf_buf_alloc(struct vm_page *, int); T> +void sf_buf_free(struct sf_buf *); T> + T> +static inline vm_offset_t T> +sf_buf_kva(struct sf_buf *sf) T> +{ T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP T> + if (SFBUF_OPTIONAL_DIRECT_MAP) T> + return (VM_PAGE_TO_PHYS((vm_page_t)sf)); T> +#endif T> + T> + return (sf->kva); T> +} T> + T> +static inline vm_page_t T> +sf_buf_page(struct sf_buf *sf) T> +{ T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP T> + if (SFBUF_OPTIONAL_DIRECT_MAP) T> + return ((vm_page_t)sf); T> +#endif T> + T> + return (sf->m); T> +} T> + T> +#ifndef SFBUF_MAP T> +#include T> + T> +static inline void T> +sf_buf_map(struct sf_buf *sf, int flags) T> +{ T> + T> + pmap_qenter(sf->kva, &sf->m, 1); T> +} T> + T> +static inline int T> +sf_buf_unmap(struct sf_buf *sf) T> +{ T> + T> + return (0); T> +} T> +#endif /* SFBUF_MAP */ T> + T> +#if defined(SMP) && defined(SFBUF_CPUSET) T> +void sf_buf_shootdown(struct sf_buf *, int); T> +#endif T> + T> +#ifdef SFBUF_PROCESS_PAGE T> +boolean_t sf_buf_process_page(vm_page_t, void (*)(struct sf_buf *)); T> +#endif T> + T> +#else /* ! SFBUF */ T> + T> +static inline struct sf_buf * T> +sf_buf_alloc(struct vm_page *m, int pri) T> +{ T> + T> + return ((struct sf_buf *)m); T> +} T> + T> +static inline void T> +sf_buf_free(struct sf_buf *sf) T> +{ T> +} T> +#endif /* SFBUF */ T> + T> /* T> * Options to sf_buf_alloc() are specified through its flags argument. This T> * argument's value should be the result of a bitwise or'ing of one or more T> @@ -40,19 +148,6 @@ T> #define SFB_DEFAULT 0 T> #define SFB_NOWAIT 4 /* Return NULL if all bufs are used. */ T> T> -struct vm_page; T> - T> -struct sfstat { /* sendfile statistics */ T> - uint64_t sf_iocnt; /* times sendfile had to do disk I/O */ T> - uint64_t sf_allocfail; /* times sfbuf allocation failed */ T> - uint64_t sf_allocwait; /* times sfbuf allocation had to wait */ T> -}; T> - T> -#ifdef _KERNEL T> -#include T> -#include T> -#include T> - T> extern counter_u64_t sfstat[sizeof(struct sfstat) / sizeof(uint64_t)]; T> #define SFSTAT_ADD(name, val) \ T> counter_u64_add(sfstat[offsetof(struct sfstat, name) / sizeof(uint64_t)],\ T> _______________________________________________ T> freebsd-current@freebsd.org mailing list T> http://lists.freebsd.org/mailman/listinfo/freebsd-current T> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 10:56:16 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CAF6E92A for ; Tue, 29 Jul 2014 10:56:16 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 87D7129F4 for ; Tue, 29 Jul 2014 10:56:15 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1XC54n-002XKZ-Ju>; Tue, 29 Jul 2014 12:56:13 +0200 Received: from g226176092.adsl.alicedsl.de ([92.226.176.92] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1XC54n-002bIh-Hk>; Tue, 29 Jul 2014 12:56:13 +0200 Date: Tue, 29 Jul 2014 12:56:08 +0200 From: "O. Hartmann" To: Peter Wemm Subject: Re: local_unbound: since update sporadic hangs in connections Message-ID: <20140729125608.2d3a10a2.ohartman@zedat.fu-berlin.de> In-Reply-To: References: <20140728155002.3d29e22c.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/=..+ZpnMg=ByYVtwtCMS5xT"; protocol="application/pgp-signature" X-Originating-IP: 92.226.176.92 X-ZEDAT-Hint: A Cc: FreeBSD CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 10:56:16 -0000 --Sig_/=..+ZpnMg=ByYVtwtCMS5xT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Mon, 28 Jul 2014 10:19:50 -0700 Peter Wemm schrieb: > Are you using pf and IPv6 by any chance? Since you mentioned the FreeBSD= .org domain, > DNSSEC and IPv6 triggers fragments. Just a thought.=20 >=20 > -- > Peter Wemm. peter@wemm.org >=20 >=20 > > On 28 Jul 2014, at 6:50 am, O. Hartmann w= rote: > >=20 > >=20 > > Since local_unbound update and the suggested update procedure as reques= ted with TAG > > 20140719 the connection to the net hangs (DNS resolving). This is very = often with the > > freebsd.org domain the case, while domestic domains rarely show this st= range > > behaviour. > >=20 > > The problem occurs on ALL CURRENT systems with updated unbound! > >=20 > > Updates via svn also show those hangs (FBSD SVN server). > >=20 > > This is nasty ... > >=20 > > oh At the moment, it is a pain in the ass connecting to the net (not even Free= BSD related sites). The connect seems sporadic, then many times I get timeouts. What is this cuased by? What is the solution? --Sig_/=..+ZpnMg=ByYVtwtCMS5xT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT133NAAoJEOgBcD7A/5N8JD4IALyGars0aSaKfU3rawx48aFm Kr9eTmElUvHmNbQrO61CzxE23N/3n5VRe/pBtijIzcV5VGVtiPi6oy/mFcfgYV0F qbYVJTtKpvVvLnImyca4TAJbMn0ajUpLCGRIKjRx0RHwuhfWqYURhxW1bbagLc9w 4myA7pnWflbUOTKipc7WwWtyRSSqaihO1lc0Pkbt73QCgL72skbA4prrZ5I3J0Sv eDpeaKYXc7AWS2CEPC+G0WgPLY484wR60fpbstGefKx4QDTy93BvTLrSibJ85du/ delcwIdWz6xrgSDFagaWbEX9Ukn9sbTJN2w8KKIe24JxkVjK08icvSHaYD5kW4U= =Vokr -----END PGP SIGNATURE----- --Sig_/=..+ZpnMg=ByYVtwtCMS5xT-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 11:05:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2E97B9B for ; Tue, 29 Jul 2014 11:05:15 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EC4A2AEC for ; Tue, 29 Jul 2014 11:05:14 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6TB5CSg032204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 29 Jul 2014 15:05:12 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6TB5Cog032203 for freebsd-current@freebsd.org; Tue, 29 Jul 2014 15:05:12 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Jul 2014 15:05:12 +0400 From: Gleb Smirnoff To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140729110512.GE89995@FreeBSD.org> References: <53C706C9.6090506@com.jkkn.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53C706C9.6090506@com.jkkn.dk> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 11:05:15 -0000 Replying to the top of the thread, but the text is actually reply to those people in the thread, who eager for import of new pf from OpenBSD. So, I claim that there is a vast and silent majority of people who simply use pf and do not want the hassle with broken pf.conf. I also claim that there is number of people who utilize pf at larger installations and they were very glad to see pf to scale on multiple CPUs and at least not to freeze the entire traffic for seconds during expiry run. And you claim that there is another large number of people, who want to run newest pf from OpenBSD on FreeBSD, and they do not care about syntax change problems. Unfortunately, we cannot compare our large numbers. Well, you can tell that your number is at least four times bigger than mine, but you will not provide details on how can we check that. :) What can we do in this situation? Thanks to the pfil(9) framework, we can have as much firewalls as we want. You can import new pf keeping the current version intact. There could be some minor problems on decision how to manage two different pfctls, and other utilities, but these are solvable. Let me restate. The FreeBSD version of pf IS NOT on your way of putting OpenBSD version of pf to FreeBSD. What IS your main obstacle in this task is the porting process itself. Try it. Fork FreeBSD in git, mercurial, or simply checkout subversion working directory, then: # cd sys/netpfil # mkdir openbsd-pf # cd openbsd-pf And start working. When you got a buildable and working version[*], post call for testing email to current@ and pf@. After several rounds of testing you will end up with something working. And if we see that the demand for second pf in FreeBSD is real, and you are willing to take maintainership of it, you will be welcome as committer and second pf will be welcome to the tree[**]. Any takers? === [*] Spoiler: usually by that time both FreeBSD tree and pf taken from OpenBSD would diverge and you would need to sync up :) [**] This is my personal opinion, not an official project statement, neither a core team member statement. I expect that there would be resistance against yet-another-packet-filter, that you would need to deal with. But if you got a working code, and you got a userbase of the code, then you have chances to overcome the resistance. And please don't start bikeshedding right now with no code at hand. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 11:23:10 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0E351D3 for ; Tue, 29 Jul 2014 11:23:10 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B1682D28 for ; Tue, 29 Jul 2014 11:23:08 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6TBN6vf032475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 29 Jul 2014 15:23:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6TBN6kn032474 for freebsd-current@freebsd.org; Tue, 29 Jul 2014 15:23:06 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Jul 2014 15:23:06 +0400 From: Gleb Smirnoff To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140729112306.GF89995@FreeBSD.org> References: <53C706C9.6090506@com.jkkn.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53C706C9.6090506@com.jkkn.dk> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 11:23:10 -0000 Yet another top reply to everyone. If anyone is interested in maintaining our FreeBSD version of pf and taking strategically right (my opinion!) steps in its life, here is a short TODO list: 1) Make Peter and FreeBSD cluster happy. Work on the IPv6 fragments handling. IMHO, the right way would be understanding the problem in its depth and writing code yourself taking ideas or code snippets from OpenBSD. Do not try blindly to replay all their commits over our tree. 2) Do massive API/ABI cleanup. I had started the process, but did less than 10% of it. We need to stop sharing structures between pf internals and ioctls. All kernel structures should live in pfvar.h, and all API in pf.h. The userland utilities should forget pfvar.h. This is huge task. No performance benefit, no new shiny features. But this is strategically correct, if we want a good support of pf in stable branches. Right now we can't merge any feature back due to breaking ABI. Even fixing bugs usually would require ABI breakage. Also, after completing the cleanup and header split further development would become easier. 3) Right now the hot point of contention is the pf_rules_rwlock. It is reader-vs-reader contention on the cache line. Eliminating it would bring a good performance gain on SMP. This would probably require an RCU-like management of rules. Fortunately, the rules in pf a changed in "one commit", unlike in ipfw rule by rule. 4) Convert all counters in pf to counter(9). That would be next point of contention once 3) is done. *) Cherry pick any feature you need from OpenBSD. This requires understanding code. Replaying commits won't work. P.S. I'm sorry for saying what should be done without doing that myself. I've spent quite a lot of time on pf, I was promised funding for that and later deceived. Real life changes like new job, children, etc. shifted my focus away from pf and I simply can't dedicate the amount of time to pf that I used before. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 11:37:26 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 194BB4F7; Tue, 29 Jul 2014 11:37:26 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE6582FA4; Tue, 29 Jul 2014 11:37:24 +0000 (UTC) Received: from [192.168.1.200] (p548188AB.dip0.t-ipconnect.de [84.129.136.171]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6DE581C0E97AF; Tue, 29 Jul 2014 13:37:19 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT/CFR] machine independent sf_bufs From: Michael Tuexen In-Reply-To: <20140729104156.GD89995@FreeBSD.org> Date: Tue, 29 Jul 2014 13:37:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <718A7102-5908-49AC-98C6-0BA4D1E5AE18@freebsd.org> References: <20140719062725.GB85917@FreeBSD.org> <20140729104156.GD89995@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1878.6) Cc: kib@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 11:37:26 -0000 On 29 Jul 2014, at 12:41, Gleb Smirnoff wrote: > Hi! >=20 > Sorry for top quoting, this is to annoy you :) I got zero > replies on the below email during a week. I'd really appreciate > testing on different platforms. Any takers? I can try to test it on a raspberry pi, building a patched kernel right now. Best regards Michael >=20 > On Sat, Jul 19, 2014 at 10:27:25AM +0400, Gleb Smirnoff wrote: > T> Hi! > T>=20 > T> we've got a lot of common code in sys/*/*/vm_machdep.c wrt the > T> sf_buf allocation. I have gathered it into kern/subr_sfbuf.c. > T>=20 > T> o No MD code left in sys/*/*/vm_machdep.c. > T> o The arches that have physical map have their implementation in > T> machine/sf_buf.h > T> o The arches that needs sf_bufs use subr_sfbuf.c, optionally having > T> some stuff in machine/sf_buf.h > T>=20 > T> I can test only i386. I'd be grateful for testing: > T>=20 > T> arm > T> mips > T> mips64 > T> sparc64 > T> powerpc > T> i386 XEN > T>=20 > T> The test is a simple use of any applcation or test that uses = sendfile(2). > T> The box shouldn't crash :) of course, and after end of a test there > T> should be no evidence of sf_buf leak (observed via netstat -m). > T>=20 > T> --=20 > T> Totus tuus, Glebius. >=20 > T> Index: sys/amd64/include/sf_buf.h > T> =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 > T> --- sys/amd64/include/sf_buf.h (revision 268750) > T> +++ sys/amd64/include/sf_buf.h (working copy) > T> @@ -29,10 +29,6 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#include > T> -#include > T> -#include > T> - > T> /* > T> * On this machine, the only purpose for which sf_buf is used is = to implement > T> * an opaque pointer required by the machine-independent parts of = the kernel. > T> @@ -39,21 +35,7 @@ > T> * That pointer references the vm_page that is "mapped" by the = sf_buf. The > T> * actual mapping is provided by the direct virtual-to-physical = mapping. =20 > T> */ > T> -struct sf_buf; > T> - > T> -static inline struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int pri) > T> -{ > T> - > T> - return ((struct sf_buf *)m); > T> -} > T> - > T> -static inline void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> -} > T> - > T> -static __inline vm_offset_t > T> +static inline vm_offset_t > T> sf_buf_kva(struct sf_buf *sf) > T> { > T> =20 > T> @@ -60,11 +42,10 @@ sf_buf_kva(struct sf_buf *sf) > T> return (PHYS_TO_DMAP(VM_PAGE_TO_PHYS((vm_page_t)sf))); > T> } > T> =20 > T> -static __inline vm_page_t > T> +static inline vm_page_t > T> sf_buf_page(struct sf_buf *sf) > T> { > T> =20 > T> return ((vm_page_t)sf); > T> } > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/arm/arm/vm_machdep.c > T> =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 > T> --- sys/arm/arm/vm_machdep.c (revision 268750) > T> +++ sys/arm/arm/vm_machdep.c (working copy) > T> @@ -50,7 +50,6 @@ __FBSDID("$FreeBSD$"); > T> #include > T> #include > T> #include > T> -#include > T> #include > T> #include > T> #include > T> @@ -83,43 +82,7 @@ __FBSDID("$FreeBSD$"); > T> CTASSERT(sizeof(struct switchframe) =3D=3D 24); > T> CTASSERT(sizeof(struct trapframe) =3D=3D 80); > T> =20 > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> -LIST_HEAD(sf_head, sf_buf); > T> - > T> /* > T> - * A hash table of active sendfile(2) buffers > T> - */ > T> -static struct sf_head *sf_buf_active; > T> -static u_long sf_buf_hashmask; > T> - > T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) > T> - > T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> -static u_int sf_buf_alloc_want; > T> - > T> -/* > T> - * A lock used to synchronize access to the hash table and free = list > T> - */ > T> -static struct mtx sf_buf_lock; > T> - > T> -/* > T> * Finish a fork operation, with process p2 nearly set up. > T> * Copy and update the pcb, set up the stack so that the child > T> * ready to run and return to user mode. > T> @@ -184,107 +147,7 @@ cpu_thread_swapout(struct thread *td) > T> { > T> } > T> =20 > T> -/* > T> - * Detatch mapped page and release resources back to the system. > T> - */ > T> void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - > T> - mtx_lock(&sf_buf_lock); > T> - sf->ref_count--; > T> - if (sf->ref_count =3D=3D 0) { > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> - nsfbufsused--; > T> - pmap_kremove(sf->kva); > T> - sf->m =3D NULL; > T> - LIST_REMOVE(sf, list_entry); > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_buf_freelist); > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> -} > T> - > T> -/* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - =09 > T> - sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> - TAILQ_INIT(&sf_buf_freelist); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - sf->ref_count++; > T> - if (sf->ref_count =3D=3D 1) { > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> - } > T> - goto done; > T> - } > T> - } > T> - while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - goto done; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> -=09 > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - goto done; > T> - } > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> - if (sf->m !=3D NULL) > T> - LIST_REMOVE(sf, list_entry); > T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> - sf->ref_count =3D 1; > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_kenter(sf->kva, VM_PAGE_TO_PHYS(sf->m)); > T> -done: > T> - mtx_unlock(&sf_buf_lock); > T> - return (sf); > T> -} > T> - > T> -void > T> cpu_set_syscall_retval(struct thread *td, int error) > T> { > T> struct trapframe *frame; > T> Index: sys/arm/include/sf_buf.h > T> =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 > T> --- sys/arm/include/sf_buf.h (revision 268750) > T> +++ sys/arm/include/sf_buf.h (working copy) > T> @@ -29,33 +29,18 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#include > T> - > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> - int ref_count; /* usage of this mapping */ > T> -}; > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> +static inline void > T> +sf_buf_map(struct sf_buf *sf, int flags) > T> { > T> =20 > T> - return (sf->kva); > T> + pmap_kenter(sf->kva, VM_PAGE_TO_PHYS(sf->m)); > T> } > T> =20 > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> +static inline int > T> +sf_buf_unmap(struct sf_buf *sf) > T> { > T> =20 > T> - return (sf->m); > T> + pmap_kremove(sf->kva); > T> + return (1); > T> } > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/arm/include/vmparam.h > T> =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 > T> --- sys/arm/include/vmparam.h (revision 268750) > T> +++ sys/arm/include/vmparam.h (working copy) > T> @@ -170,4 +170,7 @@ extern vm_offset_t vm_max_kernel_address; > T> #define VM_MAX_AUTOTUNE_MAXUSERS 384 > T> #endif > T> =20 > T> +#define SFBUF > T> +#define SFBUF_MAP > T> + > T> #endif /* _MACHINE_VMPARAM_H_ */ > T> Index: sys/conf/files.arm > T> =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 > T> --- sys/conf/files.arm (revision 268750) > T> +++ sys/conf/files.arm (working copy) > T> @@ -77,6 +77,7 @@ font.h optional = sc \ > T> clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16 = ${SC_DFLT_FONT}-8x8" > T> kern/subr_busdma_bufalloc.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> +kern/subr_sfbuf.c standard > T> libkern/arm/aeabi_unwind.c standard > T> libkern/arm/divsi3.S standard > T> libkern/arm/ffs.S standard > T> Index: sys/conf/files.i386 > T> =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 > T> --- sys/conf/files.i386 (revision 268750) > T> +++ sys/conf/files.i386 (working copy) > T> @@ -520,6 +520,7 @@ isa/vga_isa.c optional vga > T> kern/kern_clocksource.c standard > T> kern/imgact_aout.c optional compat_aout > T> kern/imgact_gzip.c optional gzip > T> +kern/subr_sfbuf.c standard > T> libkern/divdi3.c standard > T> libkern/flsll.c standard > T> libkern/memmove.c standard > T> Index: sys/conf/files.mips > T> =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 > T> --- sys/conf/files.mips (revision 268750) > T> +++ sys/conf/files.mips (working copy) > T> @@ -51,6 +51,7 @@ mips/mips/vm_machdep.c standard > T> kern/kern_clocksource.c standard > T> kern/link_elf_obj.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> +kern/subr_sfbuf.c optional mips | mipsel | = mipsn32 > T> =20 > T> # gcc/clang runtime > T> libkern/ffsl.c standard > T> Index: sys/conf/files.pc98 > T> =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 > T> --- sys/conf/files.pc98 (revision 268750) > T> +++ sys/conf/files.pc98 (working copy) > T> @@ -205,6 +205,7 @@ i386/svr4/svr4_machdep.c optional = compat_svr4 > T> kern/kern_clocksource.c standard > T> kern/imgact_aout.c optional compat_aout > T> kern/imgact_gzip.c optional gzip > T> +kern/subr_sfbuf.c standard > T> libkern/divdi3.c standard > T> libkern/flsll.c standard > T> libkern/memmove.c standard > T> Index: sys/conf/files.powerpc > T> =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 > T> --- sys/conf/files.powerpc (revision 268750) > T> +++ sys/conf/files.powerpc (working copy) > T> @@ -71,6 +71,7 @@ dev/vt/hw/ofwfb/ofwfb.c optional = vt aim > T> kern/kern_clocksource.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> kern/syscalls.c optional ktr > T> +kern/subr_sfbuf.c standard > T> libkern/ashldi3.c optional powerpc > T> libkern/ashrdi3.c optional powerpc > T> libkern/bcmp.c standard > T> Index: sys/conf/files.sparc64 > T> =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 > T> --- sys/conf/files.sparc64 (revision 268750) > T> +++ sys/conf/files.sparc64 (working copy) > T> @@ -63,6 +63,7 @@ dev/uart/uart_kbd_sun.c optional = uart sc | vt > T> kern/kern_clocksource.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> kern/syscalls.c optional ktr > T> +kern/subr_sfbuf.c standard > T> libkern/ffs.c standard > T> libkern/ffsl.c standard > T> libkern/fls.c standard > T> Index: sys/i386/i386/vm_machdep.c > T> =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 > T> --- sys/i386/i386/vm_machdep.c (revision 268750) > T> +++ sys/i386/i386/vm_machdep.c (working copy) > T> @@ -118,38 +118,6 @@ static u_int cpu_reset_proxyid; > T> static volatile u_int cpu_reset_proxy_active; > T> #endif > T> =20 > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> -LIST_HEAD(sf_head, sf_buf); > T> - > T> -/* > T> - * A hash table of active sendfile(2) buffers > T> - */ > T> -static struct sf_head *sf_buf_active; > T> -static u_long sf_buf_hashmask; > T> - > T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & = sf_buf_hashmask) > T> - > T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> -static u_int sf_buf_alloc_want; > T> - > T> -/* > T> - * A lock used to synchronize access to the hash table and free = list > T> - */ > T> -static struct mtx sf_buf_lock; > T> - > T> extern int _ucodesel, _udatasel; > T> =20 > T> /* > T> @@ -750,122 +718,13 @@ cpu_reset_real() > T> } > T> =20 > T> /* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> - TAILQ_INIT(&sf_buf_freelist); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> -} > T> - > T> -/* > T> - * Invalidate the cache lines that may belong to the page, if > T> - * (possibly old) mapping of the page by sf buffer exists. = Returns > T> - * TRUE when mapping was found and cache invalidated. > T> - */ > T> -boolean_t > T> -sf_buf_invalidate_cache(vm_page_t m) > T> -{ > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> - boolean_t ret; > T> - > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - ret =3D FALSE; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - /* > T> - * Use pmap_qenter to update the pte for > T> - * existing mapping, in particular, the PAT > T> - * settings are recalculated. > T> - */ > T> - pmap_qenter(sf->kva, &m, 1); > T> - pmap_invalidate_cache_range(sf->kva, sf->kva + > T> - PAGE_SIZE); > T> - ret =3D TRUE; > T> - break; > T> - } > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> - return (ret); > T> -} > T> - > T> -/* > T> * Get an sf_buf from the freelist. May block if none are = available. > T> */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> +void > T> +sf_buf_map(struct sf_buf *sf, int flags) > T> { > T> pt_entry_t opte, *ptep; > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> -#ifdef SMP > T> - cpuset_t other_cpus; > T> - u_int cpuid; > T> -#endif > T> - int error; > T> =20 > T> - KASSERT(curthread->td_pinned > 0 || (flags & SFB_CPUPRIVATE) =3D=3D= 0, > T> - ("sf_buf_alloc(SFB_CPUPRIVATE): curthread not pinned")); > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - sf->ref_count++; > T> - if (sf->ref_count =3D=3D 1) { > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> - } > T> -#ifdef SMP > T> - goto shootdown;=09 > T> -#else > T> - goto done; > T> -#endif > T> - } > T> - } > T> - while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - goto done; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep.=20= > T> - */ > T> - if (error) > T> - goto done; > T> - } > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> - if (sf->m !=3D NULL) > T> - LIST_REMOVE(sf, list_entry); > T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> - sf->ref_count =3D 1; > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - > T> /* > T> * Update the sf_buf's virtual-to-physical mapping, flushing the > T> * virtual address from the TLB. Since the reference count for=20= > T> @@ -876,11 +735,11 @@ cpu_reset_real() > T> ptep =3D vtopte(sf->kva); > T> opte =3D *ptep; > T> #ifdef XEN > T> - PT_SET_MA(sf->kva, xpmap_ptom(VM_PAGE_TO_PHYS(m)) | pgeflag > T> - | PG_RW | PG_V | pmap_cache_bits(m->md.pat_mode, 0)); > T> + PT_SET_MA(sf->kva, xpmap_ptom(VM_PAGE_TO_PHYS(sf->m)) | = pgeflag > T> + | PG_RW | PG_V | pmap_cache_bits(sf->m->md.pat_mode, 0)); > T> #else > T> - *ptep =3D VM_PAGE_TO_PHYS(m) | pgeflag | PG_RW | PG_V | > T> - pmap_cache_bits(m->md.pat_mode, 0); > T> + *ptep =3D VM_PAGE_TO_PHYS(sf->m) | pgeflag | PG_RW | PG_V | > T> + pmap_cache_bits(sf->m->md.pat_mode, 0); > T> #endif > T> =20 > T> /* > T> @@ -892,7 +751,21 @@ cpu_reset_real() > T> #ifdef SMP > T> if ((opte & (PG_V | PG_A)) =3D=3D (PG_V | PG_A)) > T> CPU_ZERO(&sf->cpumask); > T> -shootdown: > T> + > T> + sf_buf_shootdown(sf, flags); > T> +#else > T> + if ((opte & (PG_V | PG_A)) =3D=3D (PG_V | PG_A)) > T> + pmap_invalidate_page(kernel_pmap, sf->kva); > T> +#endif > T> +} > T> + > T> +#ifdef SMP > T> +void > T> +sf_buf_shootdown(struct sf_buf *sf, int flags) > T> +{ > T> + cpuset_t other_cpus; > T> + u_int cpuid; > T> + > T> sched_pin(); > T> cpuid =3D PCPU_GET(cpuid); > T> if (!CPU_ISSET(cpuid, &sf->cpumask)) { > T> @@ -909,42 +782,50 @@ cpu_reset_real() > T> } > T> } > T> sched_unpin(); > T> +} > T> +#endif > T> + > T> +/* > T> + * MD part of sf_buf_free(). > T> + */ > T> +int > T> +sf_buf_unmap(struct sf_buf *sf) > T> +{ > T> +#ifdef XEN > T> + /* > T> + * Xen doesn't like having dangling R/W mappings > T> + */ > T> + pmap_qremove(sf->kva, 1); > T> + return (1); > T> #else > T> - if ((opte & (PG_V | PG_A)) =3D=3D (PG_V | PG_A)) > T> - pmap_invalidate_page(kernel_pmap, sf->kva); > T> + return (0); > T> #endif > T> -done: > T> - mtx_unlock(&sf_buf_lock); > T> - return (sf); > T> } > T> =20 > T> +static void > T> +sf_buf_invalidate(struct sf_buf *sf) > T> +{ > T> + vm_page_t m =3D sf->m; > T> + > T> + /* > T> + * Use pmap_qenter to update the pte for > T> + * existing mapping, in particular, the PAT > T> + * settings are recalculated. > T> + */ > T> + pmap_qenter(sf->kva, &m, 1); > T> + pmap_invalidate_cache_range(sf->kva, sf->kva + PAGE_SIZE); > T> +} > T> + > T> /* > T> - * Remove a reference from the given sf_buf, adding it to the free > T> - * list when its reference count reaches zero. A freed sf_buf = still, > T> - * however, retains its virtual-to-physical mapping until it is > T> - * recycled or reactivated by sf_buf_alloc(9). > T> + * Invalidate the cache lines that may belong to the page, if > T> + * (possibly old) mapping of the page by sf buffer exists. = Returns > T> + * TRUE when mapping was found and cache invalidated. > T> */ > T> -void > T> -sf_buf_free(struct sf_buf *sf) > T> +boolean_t > T> +sf_buf_invalidate_cache(vm_page_t m) > T> { > T> =20 > T> - mtx_lock(&sf_buf_lock); > T> - sf->ref_count--; > T> - if (sf->ref_count =3D=3D 0) { > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> - nsfbufsused--; > T> -#ifdef XEN > T> -/* > T> - * Xen doesn't like having dangling R/W mappings > T> - */ > T> - pmap_qremove(sf->kva, 1); > T> - sf->m =3D NULL; > T> - LIST_REMOVE(sf, list_entry); > T> -#endif > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_buf_freelist); > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> + return (sf_buf_process_page(m, sf_buf_invalidate)); > T> } > T> =20 > T> /* > T> Index: sys/i386/include/sf_buf.h > T> =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 > T> --- sys/i386/include/sf_buf.h (revision 268750) > T> +++ sys/i386/include/sf_buf.h (working copy) > T> @@ -1,5 +1,5 @@ > T> /*- > T> - * Copyright (c) 2003, 2005 Alan L. Cox > T> + * Copyright (c) 2014 Gleb Smirnoff > T> * All rights reserved. > T> * > T> * Redistribution and use in source and binary forms, with or = without > T> @@ -29,39 +29,8 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#include > T> -#include > T> +void sf_buf_map(struct sf_buf *, int); > T> +int sf_buf_unmap(struct sf_buf *); > T> +boolean_t sf_buf_invalidate_cache(vm_page_t); > T> =20 > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> - int ref_count; /* usage of this mapping */ > T> -#ifdef SMP > T> - cpuset_t cpumask; /* cpus on which mapping is = valid */ > T> -#endif > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->m); > T> -} > T> - > T> -boolean_t sf_buf_invalidate_cache(vm_page_t m); > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/i386/include/vmparam.h > T> =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 > T> --- sys/i386/include/vmparam.h (revision 268750) > T> +++ sys/i386/include/vmparam.h (working copy) > T> @@ -198,4 +198,9 @@ > T> #define VM_MAX_AUTOTUNE_MAXUSERS 384 > T> #endif > T> =20 > T> +#define SFBUF > T> +#define SFBUF_MAP > T> +#define SFBUF_CPUSET > T> +#define SFBUF_PROCESS_PAGE > T> + > T> #endif /* _MACHINE_VMPARAM_H_ */ > T> Index: sys/kern/subr_sfbuf.c > T> =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 > T> --- sys/kern/subr_sfbuf.c (revision 0) > T> +++ sys/kern/subr_sfbuf.c (working copy) > T> @@ -0,0 +1,226 @@ > T> +/*- > T> + * Copyright (c) 2014 Gleb Smirnoff > T> + * Copyright (c) 2003, 2005 Alan L. Cox > T> + * All rights reserved. > T> + * > T> + * Redistribution and use in source and binary forms, with or = without > T> + * modification, are permitted provided that the following = conditions > T> + * are met: > T> + * 1. Redistributions of source code must retain the above = copyright > T> + * notice, this list of conditions and the following = disclaimer. > T> + * 2. Redistributions in binary form must reproduce the above = copyright > T> + * notice, this list of conditions and the following disclaimer = in the > T> + * documentation and/or other materials provided with the = distribution. > T> + * > T> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS = IS'' AND > T> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED = TO, THE > T> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A = PARTICULAR PURPOSE > T> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS = BE LIABLE > T> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > T> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF = SUBSTITUTE GOODS > T> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > T> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN = CONTRACT, STRICT > T> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING = IN ANY WAY > T> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE = POSSIBILITY OF > T> + * SUCH DAMAGE. > T> + */ > T> + > T> +#include > T> +__FBSDID("$FreeBSD$"); > T> + > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> + > T> +#include > T> +#include > T> +#include > T> + > T> +#ifndef NSFBUFS > T> +#define NSFBUFS (512 + maxusers * 16) > T> +#endif > T> + > T> +static int nsfbufs; > T> +static int nsfbufspeak; > T> +static int nsfbufsused; > T> + > T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> + "Maximum number of sendfile(2) sf_bufs available"); > T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> + "Number of sendfile(2) sf_bufs at peak usage"); > T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> + "Number of sendfile(2) sf_bufs in use"); > T> + > T> +static void sf_buf_init(void *arg); > T> +SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> + > T> +LIST_HEAD(sf_head, sf_buf); > T> + > T> +/* > T> + * A hash table of active sendfile(2) buffers > T> + */ > T> +static struct sf_head *sf_buf_active; > T> +static u_long sf_buf_hashmask; > T> + > T> +#define SF_BUF_HASH(m) (((m) - vm_page_array) & = sf_buf_hashmask) > T> + > T> +static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> +static u_int sf_buf_alloc_want; > T> + > T> +/* > T> + * A lock used to synchronize access to the hash table and free = list > T> + */ > T> +static struct mtx sf_buf_lock; > T> + > T> +/* > T> + * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> + */ > T> +static void > T> +sf_buf_init(void *arg) > T> +{ > T> + struct sf_buf *sf_bufs; > T> + vm_offset_t sf_base; > T> + int i; > T> + > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return; > T> +#endif > T> + > T> + nsfbufs =3D NSFBUFS; > T> + TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> + > T> + sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> + TAILQ_INIT(&sf_buf_freelist); > T> + sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> + sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> + M_NOWAIT | M_ZERO); > T> + KASSERT(sf_bufs, ("%s: malloc failure", __func__)); > T> + for (i =3D 0; i < nsfbufs; i++) { > T> + sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> + TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> + } > T> + sf_buf_alloc_want =3D 0; > T> + mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> +} > T> + > T> +/* > T> + * Get an sf_buf from the freelist. May block if none are = available. > T> + */ > T> +struct sf_buf * > T> +sf_buf_alloc(struct vm_page *m, int flags) > T> +{ > T> + struct sf_head *hash_list; > T> + struct sf_buf *sf; > T> + int error; > T> + > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return ((struct sf_buf *)m); > T> +#endif > T> + > T> + KASSERT(curthread->td_pinned > 0 || (flags & SFB_CPUPRIVATE) =3D=3D= 0, > T> + ("sf_buf_alloc(SFB_CPUPRIVATE): curthread not pinned")); > T> + hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> + mtx_lock(&sf_buf_lock); > T> + LIST_FOREACH(sf, hash_list, list_entry) { > T> + if (sf->m =3D=3D m) { > T> + sf->ref_count++; > T> + if (sf->ref_count =3D=3D 1) { > T> + TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> + nsfbufsused++; > T> + nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> + } > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> + sf_buf_shootdown(sf, flags); > T> +#endif > T> + goto done; > T> + } > T> + } > T> + while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> + if (flags & SFB_NOWAIT) > T> + goto done; > T> + sf_buf_alloc_want++; > T> + SFSTAT_INC(sf_allocwait); > T> + error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> + (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> + sf_buf_alloc_want--; > T> + > T> + /* > T> + * If we got a signal, don't risk going back to sleep.=20= > T> + */ > T> + if (error) > T> + goto done; > T> + } > T> + TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> + if (sf->m !=3D NULL) > T> + LIST_REMOVE(sf, list_entry); > T> + LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> + sf->ref_count =3D 1; > T> + sf->m =3D m; > T> + nsfbufsused++; > T> + nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> + sf_buf_map(sf, flags); > T> +done: > T> + mtx_unlock(&sf_buf_lock); > T> + return (sf); > T> +} > T> + > T> +/* > T> + * Remove a reference from the given sf_buf, adding it to the free > T> + * list when its reference count reaches zero. A freed sf_buf = still, > T> + * however, retains its virtual-to-physical mapping until it is > T> + * recycled or reactivated by sf_buf_alloc(9). > T> + */ > T> +void > T> +sf_buf_free(struct sf_buf *sf) > T> +{ > T> + > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return; > T> +#endif > T> + > T> + mtx_lock(&sf_buf_lock); > T> + sf->ref_count--; > T> + if (sf->ref_count =3D=3D 0) { > T> + TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> + nsfbufsused--; > T> + if (sf_buf_unmap(sf)) { > T> + sf->m =3D NULL; > T> + LIST_REMOVE(sf, list_entry); > T> + } > T> + if (sf_buf_alloc_want > 0) > T> + wakeup(&sf_buf_freelist); > T> + } > T> + mtx_unlock(&sf_buf_lock); > T> +} > T> + > T> +#ifdef SFBUF_PROCESS_PAGE > T> +/* > T> + * Run callback function on sf_buf that holds a certain page. > T> + */ > T> +boolean_t > T> +sf_buf_process_page(vm_page_t m, void (*cb)(struct sf_buf *)) > T> +{ > T> + struct sf_head *hash_list; > T> + struct sf_buf *sf; > T> + > T> + hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> + mtx_lock(&sf_buf_lock); > T> + LIST_FOREACH(sf, hash_list, list_entry) { > T> + if (sf->m =3D=3D m) { > T> + cb(sf); > T> + mtx_unlock(&sf_buf_lock); > T> + return (TRUE); > T> + } > T> + } > T> + mtx_unlock(&sf_buf_lock); > T> + return (FALSE); > T> +} > T> +#endif /* SFBUF_PROCESS_PAGE */ > T>=20 > T> Property changes on: sys/kern/subr_sfbuf.c > T> ___________________________________________________________________ > T> Added: svn:mime-type > T> ## -0,0 +1 ## > T> +text/plain > T> \ No newline at end of property > T> Added: svn:keywords > T> ## -0,0 +1 ## > T> +FreeBSD=3D%H > T> \ No newline at end of property > T> Added: svn:eol-style > T> ## -0,0 +1 ## > T> +native > T> \ No newline at end of property > T> Index: sys/mips/include/sf_buf.h > T> =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 > T> --- sys/mips/include/sf_buf.h (revision 268750) > T> +++ sys/mips/include/sf_buf.h (working copy) > T> @@ -29,31 +29,9 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#ifdef __mips_n64 > T> -#include > T> -#include > T> -#include > T> -#else > T> -#include > T> -#endif > T> +#ifdef __mips_n64 /* In 64 bit the whole memory is directly mapped = */ > T> =20 > T> -#ifdef __mips_n64 > T> -/* In 64 bit the whole memory is directly mapped */ > T> -struct sf_buf; > T> - > T> -static inline struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int pri) > T> -{ > T> - > T> - return ((struct sf_buf *)m); > T> -} > T> - > T> -static inline void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> -} > T> - > T> -static __inline vm_offset_t > T> +static inline vm_offset_t > T> sf_buf_kva(struct sf_buf *sf) > T> { > T> vm_page_t m; > T> @@ -62,7 +40,7 @@ sf_buf_kva(struct sf_buf *sf) > T> return (MIPS_PHYS_TO_DIRECT(VM_PAGE_TO_PHYS(m))); > T> } > T> =20 > T> -static __inline struct vm_page * > T> +static inline struct vm_page * > T> sf_buf_page(struct sf_buf *sf) > T> { > T> =20 > T> @@ -69,31 +47,5 @@ sf_buf_page(struct sf_buf *sf) > T> return ((vm_page_t)sf); > T> } > T> =20 > T> -#else /* ! __mips_n64 */ > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - SLIST_ENTRY(sf_buf) free_list; /* list of free buffer slots */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->m); > T> -} > T> #endif /* __mips_n64 */ > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/mips/include/vmparam.h > T> =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 > T> --- sys/mips/include/vmparam.h (revision 268750) > T> +++ sys/mips/include/vmparam.h (working copy) > T> @@ -187,4 +187,8 @@ > T> =20 > T> #define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ > T> =20 > T> +#ifndef __mips_n64 > T> +#define SFBUF > T> +#endif > T> + > T> #endif /* !_MACHINE_VMPARAM_H_ */ > T> Index: sys/mips/mips/vm_machdep.c > T> =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 > T> --- sys/mips/mips/vm_machdep.c (revision 268750) > T> +++ sys/mips/mips/vm_machdep.c (working copy) > T> @@ -76,9 +76,6 @@ __FBSDID("$FreeBSD$"); > T> =20 > T> #include > T> #include > T> -#ifndef __mips_n64 > T> -#include > T> -#endif > T> =20 > T> /* Duplicated from asm.h */ > T> #if defined(__mips_o32) > T> @@ -92,39 +89,7 @@ __FBSDID("$FreeBSD$"); > T> #define CALLFRAME_SIZ (SZREG * 4) > T> #endif > T> =20 > T> -#ifndef __mips_n64 > T> - > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> /* > T> - * Expanded sf_freelist head. Really an SLIST_HEAD() in disguise, = with the > T> - * sf_freelist head with the sf_lock mutex. > T> - */ > T> -static struct { > T> - SLIST_HEAD(, sf_buf) sf_head; > T> - struct mtx sf_lock; > T> -} sf_freelist; > T> - > T> -static u_int sf_buf_alloc_want; > T> -#endif /* !__mips_n64 */ > T> - > T> -/* > T> * Finish a fork operation, with process p2 nearly set up. > T> * Copy and update the pcb, set up the stack so that the child > T> * ready to run and return to user mode. > T> @@ -513,84 +478,6 @@ cpu_set_upcall_kse(struct thread *td, void = (*entry > T> #define ZIDLE_HI(v) ((v) * 4 / 5) > T> =20 > T> /* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -#ifndef __mips_n64 > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - mtx_init(&sf_freelist.sf_lock, "sf_bufs list lock", NULL, = MTX_DEF); > T> - SLIST_INIT(&sf_freelist.sf_head); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, &sf_bufs[i], = free_list); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - mtx_lock(&sf_freelist.sf_lock); > T> - while ((sf =3D SLIST_FIRST(&sf_freelist.sf_head)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - break; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_freelist, &sf_freelist.sf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - break; > T> - } > T> - if (sf !=3D NULL) { > T> - SLIST_REMOVE_HEAD(&sf_freelist.sf_head, free_list); > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_qenter(sf->kva, &sf->m, 1); > T> - } > T> - mtx_unlock(&sf_freelist.sf_lock); > T> - return (sf); > T> -} > T> - > T> -/* > T> - * Release resources back to the system. > T> - */ > T> -void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - pmap_qremove(sf->kva, 1); > T> - mtx_lock(&sf_freelist.sf_lock); > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, sf, free_list); > T> - nsfbufsused--; > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_freelist); > T> - mtx_unlock(&sf_freelist.sf_lock); > T> -} > T> -#endif /* !__mips_n64 */ > T> - > T> -/* > T> * Software interrupt handler for queued VM system processing. > T> */ > T> void > T> Index: sys/powerpc/include/sf_buf.h > T> =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 > T> --- sys/powerpc/include/sf_buf.h (revision 268750) > T> +++ sys/powerpc/include/sf_buf.h (working copy) > T> @@ -1,80 +0,0 @@ > T> -/*- > T> - * Copyright (c) 2003 Alan L. Cox > T> - * All rights reserved. > T> - * > T> - * Redistribution and use in source and binary forms, with or = without > T> - * modification, are permitted provided that the following = conditions > T> - * are met: > T> - * 1. Redistributions of source code must retain the above = copyright > T> - * notice, this list of conditions and the following = disclaimer. > T> - * 2. Redistributions in binary form must reproduce the above = copyright > T> - * notice, this list of conditions and the following disclaimer = in the > T> - * documentation and/or other materials provided with the = distribution. > T> - * > T> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS = IS'' AND > T> - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED = TO, THE > T> - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A = PARTICULAR PURPOSE > T> - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS = BE LIABLE > T> - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > T> - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF = SUBSTITUTE GOODS > T> - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > T> - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN = CONTRACT, STRICT > T> - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING = IN ANY WAY > T> - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE = POSSIBILITY OF > T> - * SUCH DAMAGE. > T> - * > T> - * $FreeBSD$ > T> - */ > T> - > T> -#ifndef _MACHINE_SF_BUF_H_ > T> -#define _MACHINE_SF_BUF_H_ > T> - > T> -#include > T> -#include > T> -#include > T> -#include > T> -#include > T> - > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> - int ref_count; /* usage of this mapping */ > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -/* > T> - * On 32-bit OEA, the only purpose for which sf_buf is used is to = implement > T> - * an opaque pointer required by the machine-independent parts of = the kernel. > T> - * That pointer references the vm_page that is "mapped" by the = sf_buf. The > T> - * actual mapping is provided by the direct virtual-to-physical = mapping. =20 > T> - * > T> - * On OEA64 and Book-E, we need to do something a little more = complicated. Use > T> - * the runtime-detected hw_direct_map to pick between the two = cases. Our > T> - * friends in vm_machdep.c will do the same to ensure nothing gets = confused. > T> - */ > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - if (hw_direct_map) > T> - return (VM_PAGE_TO_PHYS((vm_page_t)sf)); > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - if (hw_direct_map) > T> - return ((vm_page_t)sf); > T> - > T> - return (sf->m); > T> -} > T> - > T> -#endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/powerpc/include/vmparam.h > T> =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 > T> --- sys/powerpc/include/vmparam.h (revision 268750) > T> +++ sys/powerpc/include/vmparam.h (working copy) > T> @@ -197,4 +197,18 @@ struct pmap_physseg { > T> =20 > T> #define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ > T> =20 > T> +/* > T> + * On 32-bit OEA, the only purpose for which sf_buf is used is to = implement > T> + * an opaque pointer required by the machine-independent parts of = the kernel. > T> + * That pointer references the vm_page that is "mapped" by the = sf_buf. The > T> + * actual mapping is provided by the direct virtual-to-physical = mapping. > T> + * > T> + * On OEA64 and Book-E, we need to do something a little more = complicated. Use > T> + * the runtime-detected hw_direct_map to pick between the two = cases. Our > T> + * friends in vm_machdep.c will do the same to ensure nothing gets = confused. > T> + */ > T> +#define SFBUF > T> +#define SFBUF_NOMD > T> +#define SFBUF_OPTIONAL_DIRECT_MAP hw_direct_map > T> +=20 > T> #endif /* _MACHINE_VMPARAM_H_ */ > T> Index: sys/powerpc/powerpc/vm_machdep.c > T> =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 > T> --- sys/powerpc/powerpc/vm_machdep.c (revision 268750) > T> +++ sys/powerpc/powerpc/vm_machdep.c (working copy) > T> @@ -80,7 +80,6 @@ > T> #include > T> #include > T> #include > T> -#include > T> #include > T> #include > T> #include > T> @@ -100,47 +99,6 @@ > T> #include > T> #include > T> =20 > T> -/* > T> - * On systems without a direct mapped region (e.g. PPC64), > T> - * we use the same code as the Book E implementation. Since > T> - * we need to have runtime detection of this, define some = machinery > T> - * for sf_bufs in this case, and ignore it on systems with direct = maps. > T> - */ > T> - > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> -=20 > T> -LIST_HEAD(sf_head, sf_buf); > T> -=20 > T> -/* A hash table of active sendfile(2) buffers */ > T> -static struct sf_head *sf_buf_active; > T> -static u_long sf_buf_hashmask; > T> - > T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) > T> - > T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> -static u_int sf_buf_alloc_want; > T> - > T> -/* > T> - * A lock used to synchronize access to the hash table and free = list > T> - */ > T> -static struct mtx sf_buf_lock; > T> - > T> #ifdef __powerpc64__ > T> extern uintptr_t tocbase; > T> #endif > T> @@ -245,124 +203,6 @@ cpu_exit(struct thread *td) > T> } > T> =20 > T> /* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - /* Don't bother on systems with a direct map */ > T> - if (hw_direct_map) > T> - return; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> - TAILQ_INIT(&sf_buf_freelist); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - if (hw_direct_map) { > T> - /* Shortcut the direct mapped case */ > T> - return ((struct sf_buf *)m); > T> - } > T> - > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - sf->ref_count++; > T> - if (sf->ref_count =3D=3D 1) { > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> - } > T> - goto done; > T> - } > T> - } > T> - > T> - while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - goto done; > T> - > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - goto done; > T> - } > T> - > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> - if (sf->m !=3D NULL) > T> - LIST_REMOVE(sf, list_entry); > T> - > T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> - sf->ref_count =3D 1; > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_qenter(sf->kva, &sf->m, 1); > T> -done: > T> - mtx_unlock(&sf_buf_lock); > T> - return (sf); > T> -} > T> - > T> -/* > T> - * Detach mapped page and release resources back to the system. > T> - * > T> - * Remove a reference from the given sf_buf, adding it to the free > T> - * list when its reference count reaches zero. A freed sf_buf = still, > T> - * however, retains its virtual-to-physical mapping until it is > T> - * recycled or reactivated by sf_buf_alloc(9). > T> - */ > T> -void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - if (hw_direct_map) > T> - return; > T> - > T> - mtx_lock(&sf_buf_lock); > T> - sf->ref_count--; > T> - if (sf->ref_count =3D=3D 0) { > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> - nsfbufsused--; > T> - > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_buf_freelist); > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> -} > T> - > T> -/* > T> * Software interrupt handler for queued VM system processing. > T> */ > T> void > T> Index: sys/sparc64/include/sf_buf.h > T> =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 > T> --- sys/sparc64/include/sf_buf.h (revision 268750) > T> +++ sys/sparc64/include/sf_buf.h (working copy) > T> @@ -1,59 +0,0 @@ > T> -/*- > T> - * Copyright (c) 2003 Alan L. Cox > T> - * All rights reserved. > T> - * > T> - * Redistribution and use in source and binary forms, with or = without > T> - * modification, are permitted provided that the following = conditions > T> - * are met: > T> - * 1. Redistributions of source code must retain the above = copyright > T> - * notice, this list of conditions and the following = disclaimer. > T> - * 2. Redistributions in binary form must reproduce the above = copyright > T> - * notice, this list of conditions and the following disclaimer = in the > T> - * documentation and/or other materials provided with the = distribution. > T> - * > T> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS = IS'' AND > T> - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED = TO, THE > T> - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A = PARTICULAR PURPOSE > T> - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS = BE LIABLE > T> - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > T> - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF = SUBSTITUTE GOODS > T> - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > T> - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN = CONTRACT, STRICT > T> - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING = IN ANY WAY > T> - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE = POSSIBILITY OF > T> - * SUCH DAMAGE. > T> - * > T> - * $FreeBSD$ > T> - */ > T> - > T> -#ifndef _MACHINE_SF_BUF_H_ > T> -#define _MACHINE_SF_BUF_H_ > T> - > T> -#include > T> - > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - SLIST_ENTRY(sf_buf) free_list; /* list of free buffer slots */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->m); > T> -} > T> - > T> -#endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/sparc64/include/vmparam.h > T> =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 > T> --- sys/sparc64/include/vmparam.h (revision 268750) > T> +++ sys/sparc64/include/vmparam.h (working copy) > T> @@ -239,4 +239,7 @@ extern vm_offset_t vm_max_kernel_address; > T> */ > T> #define ZERO_REGION_SIZE PAGE_SIZE > T> =20 > T> +#define SFBUF > T> +#define SFBUF_NOMD > T> + > T> #endif /* !_MACHINE_VMPARAM_H_ */ > T> Index: sys/sparc64/sparc64/vm_machdep.c > T> =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 > T> --- sys/sparc64/sparc64/vm_machdep.c (revision 268750) > T> +++ sys/sparc64/sparc64/vm_machdep.c (working copy) > T> @@ -53,7 +53,6 @@ __FBSDID("$FreeBSD$"); > T> #include > T> #include > T> #include > T> -#include > T> #include > T> #include > T> #include > T> @@ -84,35 +83,6 @@ __FBSDID("$FreeBSD$"); > T> #include > T> #include > T> =20 > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> -/* > T> - * Expanded sf_freelist head. Really an SLIST_HEAD() in disguise, = with the > T> - * sf_freelist head with the sf_lock mutex. > T> - */ > T> -static struct { > T> - SLIST_HEAD(, sf_buf) sf_head; > T> - struct mtx sf_lock; > T> -} sf_freelist; > T> - > T> -static u_int sf_buf_alloc_want; > T> - > T> PMAP_STATS_VAR(uma_nsmall_alloc); > T> PMAP_STATS_VAR(uma_nsmall_alloc_oc); > T> PMAP_STATS_VAR(uma_nsmall_free); > T> @@ -417,84 +387,7 @@ is_physical_memory(vm_paddr_t addr) > T> return (0); > T> } > T> =20 > T> -/* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - mtx_init(&sf_freelist.sf_lock, "sf_bufs list lock", NULL, = MTX_DEF); > T> - SLIST_INIT(&sf_freelist.sf_head); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, &sf_bufs[i], = free_list); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - mtx_lock(&sf_freelist.sf_lock); > T> - while ((sf =3D SLIST_FIRST(&sf_freelist.sf_head)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - break; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_freelist, &sf_freelist.sf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - break; > T> - } > T> - if (sf !=3D NULL) { > T> - SLIST_REMOVE_HEAD(&sf_freelist.sf_head, free_list); > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_qenter(sf->kva, &sf->m, 1); > T> - } > T> - mtx_unlock(&sf_freelist.sf_lock); > T> - return (sf); > T> -} > T> - > T> -/* > T> - * Release resources back to the system. > T> - */ > T> void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - > T> - pmap_qremove(sf->kva, 1); > T> - mtx_lock(&sf_freelist.sf_lock); > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, sf, free_list); > T> - nsfbufsused--; > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_freelist); > T> - mtx_unlock(&sf_freelist.sf_lock); > T> -} > T> - > T> -void > T> swi_vm(void *v) > T> { > T> =20 > T> Index: sys/sys/sf_buf.h > T> =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 > T> --- sys/sys/sf_buf.h (revision 268750) > T> +++ sys/sys/sf_buf.h (working copy) > T> @@ -29,6 +29,114 @@ > T> #ifndef _SYS_SF_BUF_H_ > T> #define _SYS_SF_BUF_H_ > T> =20 > T> +struct sfstat { /* sendfile statistics = */ > T> + uint64_t sf_iocnt; /* times sendfile had to do disk = I/O */ > T> + uint64_t sf_allocfail; /* times sfbuf allocation failed = */ > T> + uint64_t sf_allocwait; /* times sfbuf allocation had to = wait */ > T> +}; > T> + > T> +#ifdef _KERNEL > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> + > T> +#ifdef SFBUF > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> +#include > T> +#endif > T> +#include > T> + > T> +struct sf_buf { > T> + LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> + TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> + vm_page_t m; /* currently mapped page = */ > T> + vm_offset_t kva; /* va of mapping */ > T> + int ref_count; /* usage of this mapping = */ > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> + cpuset_t cpumask; /* where mapping is = valid */ > T> +#endif > T> +}; > T> +#else /* ! SFBUF */ > T> +struct sf_buf; > T> +#endif /* SFBUF */ > T> + > T> +#ifndef SFBUF_NOMD > T> +#include > T> +#endif > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> +#include > T> +#endif > T> + > T> +#ifdef SFBUF > T> +struct sf_buf *sf_buf_alloc(struct vm_page *, int); > T> +void sf_buf_free(struct sf_buf *); > T> + > T> +static inline vm_offset_t > T> +sf_buf_kva(struct sf_buf *sf) > T> +{ > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return (VM_PAGE_TO_PHYS((vm_page_t)sf)); > T> +#endif > T> + > T> + return (sf->kva); > T> +} > T> + > T> +static inline vm_page_t > T> +sf_buf_page(struct sf_buf *sf) > T> +{ > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return ((vm_page_t)sf); > T> +#endif > T> + > T> + return (sf->m); > T> +} > T> + > T> +#ifndef SFBUF_MAP > T> +#include > T> + > T> +static inline void > T> +sf_buf_map(struct sf_buf *sf, int flags) > T> +{ > T> + > T> + pmap_qenter(sf->kva, &sf->m, 1); > T> +} > T> + > T> +static inline int > T> +sf_buf_unmap(struct sf_buf *sf) > T> +{ > T> + > T> + return (0); > T> +} > T> +#endif /* SFBUF_MAP */ > T> + > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> +void sf_buf_shootdown(struct sf_buf *, int); > T> +#endif > T> + > T> +#ifdef SFBUF_PROCESS_PAGE > T> +boolean_t sf_buf_process_page(vm_page_t, void (*)(struct sf_buf = *)); > T> +#endif > T> + > T> +#else /* ! SFBUF */ > T> + > T> +static inline struct sf_buf * > T> +sf_buf_alloc(struct vm_page *m, int pri) > T> +{ > T> + > T> + return ((struct sf_buf *)m); > T> +} > T> + > T> +static inline void > T> +sf_buf_free(struct sf_buf *sf) > T> +{ > T> +} > T> +#endif /* SFBUF */ > T> + > T> /* > T> * Options to sf_buf_alloc() are specified through its flags = argument. This > T> * argument's value should be the result of a bitwise or'ing of = one or more > T> @@ -40,19 +148,6 @@ > T> #define SFB_DEFAULT 0 > T> #define SFB_NOWAIT 4 /* Return NULL if all = bufs are used. */ > T> =20 > T> -struct vm_page; > T> - > T> -struct sfstat { /* sendfile statistics = */ > T> - uint64_t sf_iocnt; /* times sendfile had to do disk = I/O */ > T> - uint64_t sf_allocfail; /* times sfbuf allocation failed = */ > T> - uint64_t sf_allocwait; /* times sfbuf allocation had to = wait */ > T> -}; > T> - > T> -#ifdef _KERNEL > T> -#include > T> -#include > T> -#include > T> - > T> extern counter_u64_t sfstat[sizeof(struct sfstat) / = sizeof(uint64_t)]; > T> #define SFSTAT_ADD(name, val) \ > T> counter_u64_add(sfstat[offsetof(struct sfstat, name) / = sizeof(uint64_t)],\ >=20 > T> _______________________________________________ > T> freebsd-current@freebsd.org mailing list > T> http://lists.freebsd.org/mailman/listinfo/freebsd-current > T> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 >=20 > --=20 > Totus tuus, Glebius. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 13:20:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC2A3D8E; Tue, 29 Jul 2014 13:20:07 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-03.shaw.ca [64.59.136.139]) by mx1.freebsd.org (Postfix) with ESMTP id 908DD2E9B; Tue, 29 Jul 2014 13:20:07 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=ryrf5q5p6c4dCQYR2lAej91p2ozDt6sfPnRAuS/Q8hc= c=1 sm=1 a=cQ5pcHtl6RgA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=s6FIl2w8AAAA:8 a=BWvPGDcYAAAA:8 a=eTcz2Vil-Y1R6Uq0KPwA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=cGv0LpZPy6cA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 29 Jul 2014 07:20:06 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 4DBF09C1E; Tue, 29 Jul 2014 06:20:06 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6TDK5Pa005331; Tue, 29 Jul 2014 06:20:05 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6TDK5ZS005328; Tue, 29 Jul 2014 06:20:05 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407291320.s6TDK5ZS005328@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Kevin Oberman Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message from Kevin Oberman of "Mon, 28 Jul 2014 15:07:32 -0700." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Jul 2014 06:20:04 -0700 Cc: Darren Reed , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 13:20:07 -0000 In message , Kevin Oberman writes: > On Mon, Jul 28, 2014 at 2:41 AM, Darren Reed wrote: > > > On 27/07/2014 4:43 AM, Cy Schubert wrote: > > > In message <53D395E4.1070006@fastmail.net>, Darren Reed writes: > > >> On 24/07/2014 1:42 AM, Cy Schubert wrote: > > >>>>> But, lack of ipv6 fragment processing still causes ongoing pain. > > That'= > > >>>>> s our=20 > > >>>>> #1 wish list item for the cluster. > > >>> Taking this discussion slightly sideways but touching on this thread a > > >>> little, each of our packet filters will need nat66 support too. Pf > > doesn't > > >>> support it for sure. I've been told that ipfw may and I suspect > > ipfilter > > >>> doesn't as it was on Darren's todo list from 2009. > > >> ipfiler 5 handles fragments for ipv6. > > > Switching gears and leaving the discussion of ipv6 fragments to mention > > > nat66. A lot of people have been talking about nat66. I could be wrong > > but > > > I don't think it can handle nat66. I need to do some testing to verify > > > this. I remember reading on sourceforge that it was on your todo list. It > > > doesn't look like it was checked off as being completed. > > > > IPFilter 5 does IPv6 NAT. > > > > With the import of 5.1.2, map, rdr and rewrite rules will all work with > > IPv6 addresses. > > > > NAT66 is a specific implementation of IPv6 NAT behaviour. > > > > Cheers, > > Darren > > > > And all IPv6 NAT is evil and should be cast into (demonic residence of your > choosing) on sight! That I don't disagree with, IPv6 NAT makes no logical sense. Having said that I've received emails asking about NAT66 specifically. It is on people's minds. > > NAT on IPv6 serves no useful purpose at all. It only serves to complicate > things and make clueless security officers happy. It adds zero security. It > is a great example of people who assume that NAT is a security feature in > IPv4 (it's not) so it should also be in IPv6. Agreed. People think NAT is a security feature (and those same people tout the "security" of reverse proxies too). It's a checkbox item. > > The problem is that this meme is so pervasive that even when people > understand that it is bad, they still insist on it because there will be an > unchecked box on the security checklist for "All systems not pubic servers > are in RFC1918 space? -- YES NO". The checklist item should be (usually) > "All systems behind a stateful firewall with an appropriate rule set? -- > YES NO" as it is a stateful firewall (which is mandatory for NAT that > provides all of the security. Exactly! That's pretty much what people who know better are saying. > > I say "usually" because the major research lab where I worked ran without a > firewall (and probably still does) and little, if any, NAT. It was tested > regularly by red teams hired by the feds and they never were able to > penetrate anything due to a very aggressive IDS/IPS system, but most people > and companies should NOT go this route. I have IPv6 at home (Comcast) and > my router runs a stateful firewall with a rule set functionally the same as > that used for IPv4 and that provides the protection needed. Not part of this discussion: I think you need both. Firewalls and IPS with IDS. OTOH using NAT as a means of securing a network is illogical. I worked at one place where they would NAT already NATted packets, themselves having previously been processed by previous NAT, all for the sake of "security" only terribly broke the network to the point there were issues to numerous to discuss in a quick reply here. > > So putting support for NAT66 or any IPv6 NAT into a firewall is just making > things worse. Please don't do it! -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 14:48:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75A065B8 for ; Tue, 29 Jul 2014 14:48:12 +0000 (UTC) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 27B232834 for ; Tue, 29 Jul 2014 14:48:11 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3hN12x4D5mz13X for ; Tue, 29 Jul 2014 16:48:09 +0200 (CEST) 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=jakla2; t=1406645282; x=1409237283; bh=WiR 6m4sZF7yGiB1ioEaFfaH2KXabAyAhLOTvCOK3FDA=; b=c2zVjCm5E7UJhVsVxZ6 OIvby7rtHdgI1OFsglkrDNvXg2P3IKu8P5wvNfDv40kb0F5XeHTmTDhRJ9O1gN+h Akb1VrB0vTd/NHx9YqAgKTYQfUVLOQwrpXA+KMvY0Tj/5KJJqU3/dxXl9Jw6i/SJ 0k/CdhtnEwYb4zfb0j/I5eh4= X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 4r5EdXG_zkg4 for ; Tue, 29 Jul 2014 16:48:02 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Tue, 29 Jul 2014 16:48:02 +0200 (CEST) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by mildred.ijs.si (Postfix) with ESMTP id 3hN12p1yb1zRw for ; Tue, 29 Jul 2014 16:48:02 +0200 (CEST) Received: from neli.ijs.si ([2001:1470:ff80:88:21c:c0ff:feb1:8c91]) by neli.ijs.si with HTTP (HTTP/1.1 POST); Tue, 29 Jul 2014 16:48:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 2014 16:48:02 +0200 From: Mark Martinec To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD =?UTF-8?Q?=3F=20-=20does?= =?UTF-8?Q?=20it=20have=20one=20=3F?= Organization: J. Stefan Institute In-Reply-To: <201407291320.s6TDK5ZS005328@slippy.cwsent.com> References: <201407291320.s6TDK5ZS005328@slippy.cwsent.com> Message-ID: <444fc5248aaa7d474cf9bde66f3d7f64@mailbox.ijs.si> X-Sender: Mark.Martinec+freebsd@ijs.si User-Agent: Roundcube Webmail/1.0.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 14:48:12 -0000 me wrote: > we are talking about NAT64 (IPv6-only datacenter's path to a legacy > world), > and NPT66 (prefix transalation). I doubt anyone had a traditional NAT > in mind. Kevin Oberman wrote: > No, all of the messages in the thread are specific about NAT66, not > NPT66. > NPT66 may have real value. I hate it, but it may well be better than > alternatives. [...] Cy Schubert wrote: > That I don't disagree with, IPv6 NAT makes no logical sense. Having > said > that I've received emails asking about NAT66 specifically. It is on > people's minds. My impression is that often the term NAT66 is used indiscriminately, even when NPT66 (static prefix translation) is meant. Mark From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 16:54:29 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0981C42A for ; Tue, 29 Jul 2014 16:54:29 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83F95280F for ; Tue, 29 Jul 2014 16:54:28 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id u10so7193525lbd.35 for ; Tue, 29 Jul 2014 09:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=v6eSx6Zr/G8W4FtSz4mpm8qEZV4a3hetLJeUa2ufJis=; b=YwCmW3uv3PhtU2oFjkc0HMnuuxrON2G1lGw4zmSiqRrD1Iuwhk7XDmLkmAzkCPBVV0 tRyZCLOfT1M4KualIG6tZZF3XuvIz+HQyIhhCqLntlC8ApW6ytWOdLt70PklBtpTUqRG r57Qzs25knGgCC6yswAqRFtrWVBL7Uz0x0Rt2bBsP650E2+rcXWJCSN/JHG2R9IL1PHU og93JnPjzVBDmeEBOQwZwwQqQ0GWs8cozoj2iDgNDpuZRbwx4GOttyxE2GdlbaQzIMra 29874JgHsG1e0oyuyQG0/ROyq2NXSNkCwhlf3VNel0ZC10w5RzhQVYZYYIGaypeIfn/J vg8Q== MIME-Version: 1.0 X-Received: by 10.112.204.164 with SMTP id kz4mr3563613lbc.15.1406652866383; Tue, 29 Jul 2014 09:54:26 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.112.215.73 with HTTP; Tue, 29 Jul 2014 09:54:26 -0700 (PDT) In-Reply-To: <444fc5248aaa7d474cf9bde66f3d7f64@mailbox.ijs.si> References: <201407291320.s6TDK5ZS005328@slippy.cwsent.com> <444fc5248aaa7d474cf9bde66f3d7f64@mailbox.ijs.si> Date: Tue, 29 Jul 2014 09:54:26 -0700 X-Google-Sender-Auth: WjLM1bonDpqG-_RcRwJ9iO5c42w Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Kevin Oberman To: Mark Martinec Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 16:54:29 -0000 On Tue, Jul 29, 2014 at 7:48 AM, Mark Martinec wrote: > me wrote: > >> we are talking about NAT64 (IPv6-only datacenter's path to a legacy >> world), >> and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in >> mind. >> > > Kevin Oberman wrote: > >> No, all of the messages in the thread are specific about NAT66, not NPT66. >> NPT66 may have real value. I hate it, but it may well be better than >> alternatives. [...] >> > > Cy Schubert wrote: > >> That I don't disagree with, IPv6 NAT makes no logical sense. Having said >> that I've received emails asking about NAT66 specifically. It is on >> people's minds. >> > > My impression is that often the term NAT66 is used indiscriminately, > even when NPT66 (static prefix translation) is meant. > > Mark > > I would hope that is not the case. While NAT66 is "well known" and has been a topic of discussion for years, NPT66 is relatively new. It does share many concepts with NAT66 (and, most likely implementations also share code), but does not require any state, making it vastly less complex and no longer breaks point to point networking. The names look similar, which may result in unfortunate confusion, but NPT66 may be the bast solution to a real problem and it does not create the issues of NAT66. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 17:05:14 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7BF7C5FC for ; Tue, 29 Jul 2014 17:05:14 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BD7C28FC for ; Tue, 29 Jul 2014 17:05:14 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id j5so10487731qga.15 for ; Tue, 29 Jul 2014 10:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VlleDqn2WeywwI+C+yMzVgUDmJdZjkQQ+f6qELD4pbI=; b=R6JdtCP9iRcpsb2C05iO1ZxzRMInvGckfNVh9ciZBDPvfGrunaYPsNB6nu9SNBLQE2 TGs2XOzPmc1yhF9sXZ40L9VHOQh9r0Jd1IjggU3+saOb6pZiVIq8kg7ANO9pNjOpuPEn aPNb/zbKG4HtWUBORRGQij4CpE+nU2RDD5pRT3p03N8FT3K9B7HdiPyuKYLY6xH1tX+a BO9E99fWLTkQiOXb9oSM52fCdaRIN4t5hphdbWlYQ/F4E7zw7ntlABsRBrOiBKfWfI3T Wc5WJ+ElpA+0DD3gEDzDNf2rThRHJUOh6yAQ3lDYHi+GKCkLSdTpbQ4FENOZsr0qSq3Y SCsw== MIME-Version: 1.0 X-Received: by 10.140.92.13 with SMTP id a13mr5254823qge.88.1406653513369; Tue, 29 Jul 2014 10:05:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Tue, 29 Jul 2014 10:05:13 -0700 (PDT) In-Reply-To: References: <201407291320.s6TDK5ZS005328@slippy.cwsent.com> <444fc5248aaa7d474cf9bde66f3d7f64@mailbox.ijs.si> Date: Tue, 29 Jul 2014 10:05:13 -0700 X-Google-Sender-Auth: fGgz77S18BlP3JL1NLFSrjwoseA Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: Adrian Chadd To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: Mark Martinec , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 17:05:14 -0000 On 29 July 2014 09:54, Kevin Oberman wrote: > On Tue, Jul 29, 2014 at 7:48 AM, Mark Martinec > wrote: > >> me wrote: >> >>> we are talking about NAT64 (IPv6-only datacenter's path to a legacy >>> world), >>> and NPT66 (prefix transalation). I doubt anyone had a traditional NAT in >>> mind. >>> >> >> Kevin Oberman wrote: >> >>> No, all of the messages in the thread are specific about NAT66, not NPT66. >>> NPT66 may have real value. I hate it, but it may well be better than >>> alternatives. [...] >>> >> >> Cy Schubert wrote: >> >>> That I don't disagree with, IPv6 NAT makes no logical sense. Having said >>> that I've received emails asking about NAT66 specifically. It is on >>> people's minds. >>> >> >> My impression is that often the term NAT66 is used indiscriminately, >> even when NPT66 (static prefix translation) is meant. >> >> Mark >> >> > I would hope that is not the case. While NAT66 is "well known" and has been > a topic of discussion for years, NPT66 is relatively new. It does share > many concepts with NAT66 (and, most likely implementations also share > code), but does not require any state, making it vastly less complex and no > longer breaks point to point networking. The names look similar, which may > result in unfortunate confusion, but NPT66 may be the bast solution to a > real problem and it does not create the issues of NAT66. Course it will. All those bad protocols that embed IP addresses in them to connect to. Or wait, is everything written these days mindful of NAT/NPT and tries desperately to work around it? Hm... -a From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 17:29:53 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 337BDE7B; Tue, 29 Jul 2014 17:29:53 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EB382B37; Tue, 29 Jul 2014 17:29:52 +0000 (UTC) Received: from [192.168.1.200] (p548188AB.dip0.t-ipconnect.de [84.129.136.171]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C10E71C0C069E; Tue, 29 Jul 2014 19:29:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT/CFR] machine independent sf_bufs From: Michael Tuexen In-Reply-To: <20140729104156.GD89995@FreeBSD.org> Date: Tue, 29 Jul 2014 19:29:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140719062725.GB85917@FreeBSD.org> <20140729104156.GD89995@FreeBSD.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1878.6) Cc: kib@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 17:29:53 -0000 On 29 Jul 2014, at 12:41, Gleb Smirnoff wrote: > Hi! >=20 > Sorry for top quoting, this is to annoy you :) I got zero > replies on the below email during a week. I'd really appreciate > testing on different platforms. Any takers? OK, it works on an Raspberry pi running r269231 with your patch. The only suspicious thing I observed was that the number of 'requests for I/O initiated by sendfile' in netstat -m doesn't always increase. I would expect that. However, I'm not sure if this is ARM related (I would not think so) or is related to your patch at all. Let me know if you need more information. Best regards Michael >=20 > On Sat, Jul 19, 2014 at 10:27:25AM +0400, Gleb Smirnoff wrote: > T> Hi! > T>=20 > T> we've got a lot of common code in sys/*/*/vm_machdep.c wrt the > T> sf_buf allocation. I have gathered it into kern/subr_sfbuf.c. > T>=20 > T> o No MD code left in sys/*/*/vm_machdep.c. > T> o The arches that have physical map have their implementation in > T> machine/sf_buf.h > T> o The arches that needs sf_bufs use subr_sfbuf.c, optionally having > T> some stuff in machine/sf_buf.h > T>=20 > T> I can test only i386. I'd be grateful for testing: > T>=20 > T> arm > T> mips > T> mips64 > T> sparc64 > T> powerpc > T> i386 XEN > T>=20 > T> The test is a simple use of any applcation or test that uses = sendfile(2). > T> The box shouldn't crash :) of course, and after end of a test there > T> should be no evidence of sf_buf leak (observed via netstat -m). > T>=20 > T> --=20 > T> Totus tuus, Glebius. >=20 > T> Index: sys/amd64/include/sf_buf.h > T> =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 > T> --- sys/amd64/include/sf_buf.h (revision 268750) > T> +++ sys/amd64/include/sf_buf.h (working copy) > T> @@ -29,10 +29,6 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#include > T> -#include > T> -#include > T> - > T> /* > T> * On this machine, the only purpose for which sf_buf is used is = to implement > T> * an opaque pointer required by the machine-independent parts of = the kernel. > T> @@ -39,21 +35,7 @@ > T> * That pointer references the vm_page that is "mapped" by the = sf_buf. The > T> * actual mapping is provided by the direct virtual-to-physical = mapping. =20 > T> */ > T> -struct sf_buf; > T> - > T> -static inline struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int pri) > T> -{ > T> - > T> - return ((struct sf_buf *)m); > T> -} > T> - > T> -static inline void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> -} > T> - > T> -static __inline vm_offset_t > T> +static inline vm_offset_t > T> sf_buf_kva(struct sf_buf *sf) > T> { > T> =20 > T> @@ -60,11 +42,10 @@ sf_buf_kva(struct sf_buf *sf) > T> return (PHYS_TO_DMAP(VM_PAGE_TO_PHYS((vm_page_t)sf))); > T> } > T> =20 > T> -static __inline vm_page_t > T> +static inline vm_page_t > T> sf_buf_page(struct sf_buf *sf) > T> { > T> =20 > T> return ((vm_page_t)sf); > T> } > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/arm/arm/vm_machdep.c > T> =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 > T> --- sys/arm/arm/vm_machdep.c (revision 268750) > T> +++ sys/arm/arm/vm_machdep.c (working copy) > T> @@ -50,7 +50,6 @@ __FBSDID("$FreeBSD$"); > T> #include > T> #include > T> #include > T> -#include > T> #include > T> #include > T> #include > T> @@ -83,43 +82,7 @@ __FBSDID("$FreeBSD$"); > T> CTASSERT(sizeof(struct switchframe) =3D=3D 24); > T> CTASSERT(sizeof(struct trapframe) =3D=3D 80); > T> =20 > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> -LIST_HEAD(sf_head, sf_buf); > T> - > T> /* > T> - * A hash table of active sendfile(2) buffers > T> - */ > T> -static struct sf_head *sf_buf_active; > T> -static u_long sf_buf_hashmask; > T> - > T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) > T> - > T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> -static u_int sf_buf_alloc_want; > T> - > T> -/* > T> - * A lock used to synchronize access to the hash table and free = list > T> - */ > T> -static struct mtx sf_buf_lock; > T> - > T> -/* > T> * Finish a fork operation, with process p2 nearly set up. > T> * Copy and update the pcb, set up the stack so that the child > T> * ready to run and return to user mode. > T> @@ -184,107 +147,7 @@ cpu_thread_swapout(struct thread *td) > T> { > T> } > T> =20 > T> -/* > T> - * Detatch mapped page and release resources back to the system. > T> - */ > T> void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - > T> - mtx_lock(&sf_buf_lock); > T> - sf->ref_count--; > T> - if (sf->ref_count =3D=3D 0) { > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> - nsfbufsused--; > T> - pmap_kremove(sf->kva); > T> - sf->m =3D NULL; > T> - LIST_REMOVE(sf, list_entry); > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_buf_freelist); > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> -} > T> - > T> -/* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - =09 > T> - sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> - TAILQ_INIT(&sf_buf_freelist); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - sf->ref_count++; > T> - if (sf->ref_count =3D=3D 1) { > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> - } > T> - goto done; > T> - } > T> - } > T> - while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - goto done; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> -=09 > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - goto done; > T> - } > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> - if (sf->m !=3D NULL) > T> - LIST_REMOVE(sf, list_entry); > T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> - sf->ref_count =3D 1; > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_kenter(sf->kva, VM_PAGE_TO_PHYS(sf->m)); > T> -done: > T> - mtx_unlock(&sf_buf_lock); > T> - return (sf); > T> -} > T> - > T> -void > T> cpu_set_syscall_retval(struct thread *td, int error) > T> { > T> struct trapframe *frame; > T> Index: sys/arm/include/sf_buf.h > T> =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 > T> --- sys/arm/include/sf_buf.h (revision 268750) > T> +++ sys/arm/include/sf_buf.h (working copy) > T> @@ -29,33 +29,18 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#include > T> - > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> - int ref_count; /* usage of this mapping */ > T> -}; > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> +static inline void > T> +sf_buf_map(struct sf_buf *sf, int flags) > T> { > T> =20 > T> - return (sf->kva); > T> + pmap_kenter(sf->kva, VM_PAGE_TO_PHYS(sf->m)); > T> } > T> =20 > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> +static inline int > T> +sf_buf_unmap(struct sf_buf *sf) > T> { > T> =20 > T> - return (sf->m); > T> + pmap_kremove(sf->kva); > T> + return (1); > T> } > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/arm/include/vmparam.h > T> =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 > T> --- sys/arm/include/vmparam.h (revision 268750) > T> +++ sys/arm/include/vmparam.h (working copy) > T> @@ -170,4 +170,7 @@ extern vm_offset_t vm_max_kernel_address; > T> #define VM_MAX_AUTOTUNE_MAXUSERS 384 > T> #endif > T> =20 > T> +#define SFBUF > T> +#define SFBUF_MAP > T> + > T> #endif /* _MACHINE_VMPARAM_H_ */ > T> Index: sys/conf/files.arm > T> =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 > T> --- sys/conf/files.arm (revision 268750) > T> +++ sys/conf/files.arm (working copy) > T> @@ -77,6 +77,7 @@ font.h optional = sc \ > T> clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16 = ${SC_DFLT_FONT}-8x8" > T> kern/subr_busdma_bufalloc.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> +kern/subr_sfbuf.c standard > T> libkern/arm/aeabi_unwind.c standard > T> libkern/arm/divsi3.S standard > T> libkern/arm/ffs.S standard > T> Index: sys/conf/files.i386 > T> =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 > T> --- sys/conf/files.i386 (revision 268750) > T> +++ sys/conf/files.i386 (working copy) > T> @@ -520,6 +520,7 @@ isa/vga_isa.c optional vga > T> kern/kern_clocksource.c standard > T> kern/imgact_aout.c optional compat_aout > T> kern/imgact_gzip.c optional gzip > T> +kern/subr_sfbuf.c standard > T> libkern/divdi3.c standard > T> libkern/flsll.c standard > T> libkern/memmove.c standard > T> Index: sys/conf/files.mips > T> =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 > T> --- sys/conf/files.mips (revision 268750) > T> +++ sys/conf/files.mips (working copy) > T> @@ -51,6 +51,7 @@ mips/mips/vm_machdep.c standard > T> kern/kern_clocksource.c standard > T> kern/link_elf_obj.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> +kern/subr_sfbuf.c optional mips | mipsel | = mipsn32 > T> =20 > T> # gcc/clang runtime > T> libkern/ffsl.c standard > T> Index: sys/conf/files.pc98 > T> =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 > T> --- sys/conf/files.pc98 (revision 268750) > T> +++ sys/conf/files.pc98 (working copy) > T> @@ -205,6 +205,7 @@ i386/svr4/svr4_machdep.c optional = compat_svr4 > T> kern/kern_clocksource.c standard > T> kern/imgact_aout.c optional compat_aout > T> kern/imgact_gzip.c optional gzip > T> +kern/subr_sfbuf.c standard > T> libkern/divdi3.c standard > T> libkern/flsll.c standard > T> libkern/memmove.c standard > T> Index: sys/conf/files.powerpc > T> =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 > T> --- sys/conf/files.powerpc (revision 268750) > T> +++ sys/conf/files.powerpc (working copy) > T> @@ -71,6 +71,7 @@ dev/vt/hw/ofwfb/ofwfb.c optional = vt aim > T> kern/kern_clocksource.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> kern/syscalls.c optional ktr > T> +kern/subr_sfbuf.c standard > T> libkern/ashldi3.c optional powerpc > T> libkern/ashrdi3.c optional powerpc > T> libkern/bcmp.c standard > T> Index: sys/conf/files.sparc64 > T> =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 > T> --- sys/conf/files.sparc64 (revision 268750) > T> +++ sys/conf/files.sparc64 (working copy) > T> @@ -63,6 +63,7 @@ dev/uart/uart_kbd_sun.c optional = uart sc | vt > T> kern/kern_clocksource.c standard > T> kern/subr_dummy_vdso_tc.c standard > T> kern/syscalls.c optional ktr > T> +kern/subr_sfbuf.c standard > T> libkern/ffs.c standard > T> libkern/ffsl.c standard > T> libkern/fls.c standard > T> Index: sys/i386/i386/vm_machdep.c > T> =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 > T> --- sys/i386/i386/vm_machdep.c (revision 268750) > T> +++ sys/i386/i386/vm_machdep.c (working copy) > T> @@ -118,38 +118,6 @@ static u_int cpu_reset_proxyid; > T> static volatile u_int cpu_reset_proxy_active; > T> #endif > T> =20 > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> -LIST_HEAD(sf_head, sf_buf); > T> - > T> -/* > T> - * A hash table of active sendfile(2) buffers > T> - */ > T> -static struct sf_head *sf_buf_active; > T> -static u_long sf_buf_hashmask; > T> - > T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & = sf_buf_hashmask) > T> - > T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> -static u_int sf_buf_alloc_want; > T> - > T> -/* > T> - * A lock used to synchronize access to the hash table and free = list > T> - */ > T> -static struct mtx sf_buf_lock; > T> - > T> extern int _ucodesel, _udatasel; > T> =20 > T> /* > T> @@ -750,122 +718,13 @@ cpu_reset_real() > T> } > T> =20 > T> /* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> - TAILQ_INIT(&sf_buf_freelist); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> -} > T> - > T> -/* > T> - * Invalidate the cache lines that may belong to the page, if > T> - * (possibly old) mapping of the page by sf buffer exists. = Returns > T> - * TRUE when mapping was found and cache invalidated. > T> - */ > T> -boolean_t > T> -sf_buf_invalidate_cache(vm_page_t m) > T> -{ > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> - boolean_t ret; > T> - > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - ret =3D FALSE; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - /* > T> - * Use pmap_qenter to update the pte for > T> - * existing mapping, in particular, the PAT > T> - * settings are recalculated. > T> - */ > T> - pmap_qenter(sf->kva, &m, 1); > T> - pmap_invalidate_cache_range(sf->kva, sf->kva + > T> - PAGE_SIZE); > T> - ret =3D TRUE; > T> - break; > T> - } > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> - return (ret); > T> -} > T> - > T> -/* > T> * Get an sf_buf from the freelist. May block if none are = available. > T> */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> +void > T> +sf_buf_map(struct sf_buf *sf, int flags) > T> { > T> pt_entry_t opte, *ptep; > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> -#ifdef SMP > T> - cpuset_t other_cpus; > T> - u_int cpuid; > T> -#endif > T> - int error; > T> =20 > T> - KASSERT(curthread->td_pinned > 0 || (flags & SFB_CPUPRIVATE) =3D=3D= 0, > T> - ("sf_buf_alloc(SFB_CPUPRIVATE): curthread not pinned")); > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - sf->ref_count++; > T> - if (sf->ref_count =3D=3D 1) { > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> - } > T> -#ifdef SMP > T> - goto shootdown;=09 > T> -#else > T> - goto done; > T> -#endif > T> - } > T> - } > T> - while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - goto done; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep.=20= > T> - */ > T> - if (error) > T> - goto done; > T> - } > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> - if (sf->m !=3D NULL) > T> - LIST_REMOVE(sf, list_entry); > T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> - sf->ref_count =3D 1; > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - > T> /* > T> * Update the sf_buf's virtual-to-physical mapping, flushing the > T> * virtual address from the TLB. Since the reference count for=20= > T> @@ -876,11 +735,11 @@ cpu_reset_real() > T> ptep =3D vtopte(sf->kva); > T> opte =3D *ptep; > T> #ifdef XEN > T> - PT_SET_MA(sf->kva, xpmap_ptom(VM_PAGE_TO_PHYS(m)) | pgeflag > T> - | PG_RW | PG_V | pmap_cache_bits(m->md.pat_mode, 0)); > T> + PT_SET_MA(sf->kva, xpmap_ptom(VM_PAGE_TO_PHYS(sf->m)) | = pgeflag > T> + | PG_RW | PG_V | pmap_cache_bits(sf->m->md.pat_mode, 0)); > T> #else > T> - *ptep =3D VM_PAGE_TO_PHYS(m) | pgeflag | PG_RW | PG_V | > T> - pmap_cache_bits(m->md.pat_mode, 0); > T> + *ptep =3D VM_PAGE_TO_PHYS(sf->m) | pgeflag | PG_RW | PG_V | > T> + pmap_cache_bits(sf->m->md.pat_mode, 0); > T> #endif > T> =20 > T> /* > T> @@ -892,7 +751,21 @@ cpu_reset_real() > T> #ifdef SMP > T> if ((opte & (PG_V | PG_A)) =3D=3D (PG_V | PG_A)) > T> CPU_ZERO(&sf->cpumask); > T> -shootdown: > T> + > T> + sf_buf_shootdown(sf, flags); > T> +#else > T> + if ((opte & (PG_V | PG_A)) =3D=3D (PG_V | PG_A)) > T> + pmap_invalidate_page(kernel_pmap, sf->kva); > T> +#endif > T> +} > T> + > T> +#ifdef SMP > T> +void > T> +sf_buf_shootdown(struct sf_buf *sf, int flags) > T> +{ > T> + cpuset_t other_cpus; > T> + u_int cpuid; > T> + > T> sched_pin(); > T> cpuid =3D PCPU_GET(cpuid); > T> if (!CPU_ISSET(cpuid, &sf->cpumask)) { > T> @@ -909,42 +782,50 @@ cpu_reset_real() > T> } > T> } > T> sched_unpin(); > T> +} > T> +#endif > T> + > T> +/* > T> + * MD part of sf_buf_free(). > T> + */ > T> +int > T> +sf_buf_unmap(struct sf_buf *sf) > T> +{ > T> +#ifdef XEN > T> + /* > T> + * Xen doesn't like having dangling R/W mappings > T> + */ > T> + pmap_qremove(sf->kva, 1); > T> + return (1); > T> #else > T> - if ((opte & (PG_V | PG_A)) =3D=3D (PG_V | PG_A)) > T> - pmap_invalidate_page(kernel_pmap, sf->kva); > T> + return (0); > T> #endif > T> -done: > T> - mtx_unlock(&sf_buf_lock); > T> - return (sf); > T> } > T> =20 > T> +static void > T> +sf_buf_invalidate(struct sf_buf *sf) > T> +{ > T> + vm_page_t m =3D sf->m; > T> + > T> + /* > T> + * Use pmap_qenter to update the pte for > T> + * existing mapping, in particular, the PAT > T> + * settings are recalculated. > T> + */ > T> + pmap_qenter(sf->kva, &m, 1); > T> + pmap_invalidate_cache_range(sf->kva, sf->kva + PAGE_SIZE); > T> +} > T> + > T> /* > T> - * Remove a reference from the given sf_buf, adding it to the free > T> - * list when its reference count reaches zero. A freed sf_buf = still, > T> - * however, retains its virtual-to-physical mapping until it is > T> - * recycled or reactivated by sf_buf_alloc(9). > T> + * Invalidate the cache lines that may belong to the page, if > T> + * (possibly old) mapping of the page by sf buffer exists. = Returns > T> + * TRUE when mapping was found and cache invalidated. > T> */ > T> -void > T> -sf_buf_free(struct sf_buf *sf) > T> +boolean_t > T> +sf_buf_invalidate_cache(vm_page_t m) > T> { > T> =20 > T> - mtx_lock(&sf_buf_lock); > T> - sf->ref_count--; > T> - if (sf->ref_count =3D=3D 0) { > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> - nsfbufsused--; > T> -#ifdef XEN > T> -/* > T> - * Xen doesn't like having dangling R/W mappings > T> - */ > T> - pmap_qremove(sf->kva, 1); > T> - sf->m =3D NULL; > T> - LIST_REMOVE(sf, list_entry); > T> -#endif > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_buf_freelist); > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> + return (sf_buf_process_page(m, sf_buf_invalidate)); > T> } > T> =20 > T> /* > T> Index: sys/i386/include/sf_buf.h > T> =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 > T> --- sys/i386/include/sf_buf.h (revision 268750) > T> +++ sys/i386/include/sf_buf.h (working copy) > T> @@ -1,5 +1,5 @@ > T> /*- > T> - * Copyright (c) 2003, 2005 Alan L. Cox > T> + * Copyright (c) 2014 Gleb Smirnoff > T> * All rights reserved. > T> * > T> * Redistribution and use in source and binary forms, with or = without > T> @@ -29,39 +29,8 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#include > T> -#include > T> +void sf_buf_map(struct sf_buf *, int); > T> +int sf_buf_unmap(struct sf_buf *); > T> +boolean_t sf_buf_invalidate_cache(vm_page_t); > T> =20 > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> - int ref_count; /* usage of this mapping */ > T> -#ifdef SMP > T> - cpuset_t cpumask; /* cpus on which mapping is = valid */ > T> -#endif > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->m); > T> -} > T> - > T> -boolean_t sf_buf_invalidate_cache(vm_page_t m); > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/i386/include/vmparam.h > T> =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 > T> --- sys/i386/include/vmparam.h (revision 268750) > T> +++ sys/i386/include/vmparam.h (working copy) > T> @@ -198,4 +198,9 @@ > T> #define VM_MAX_AUTOTUNE_MAXUSERS 384 > T> #endif > T> =20 > T> +#define SFBUF > T> +#define SFBUF_MAP > T> +#define SFBUF_CPUSET > T> +#define SFBUF_PROCESS_PAGE > T> + > T> #endif /* _MACHINE_VMPARAM_H_ */ > T> Index: sys/kern/subr_sfbuf.c > T> =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 > T> --- sys/kern/subr_sfbuf.c (revision 0) > T> +++ sys/kern/subr_sfbuf.c (working copy) > T> @@ -0,0 +1,226 @@ > T> +/*- > T> + * Copyright (c) 2014 Gleb Smirnoff > T> + * Copyright (c) 2003, 2005 Alan L. Cox > T> + * All rights reserved. > T> + * > T> + * Redistribution and use in source and binary forms, with or = without > T> + * modification, are permitted provided that the following = conditions > T> + * are met: > T> + * 1. Redistributions of source code must retain the above = copyright > T> + * notice, this list of conditions and the following = disclaimer. > T> + * 2. Redistributions in binary form must reproduce the above = copyright > T> + * notice, this list of conditions and the following disclaimer = in the > T> + * documentation and/or other materials provided with the = distribution. > T> + * > T> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS = IS'' AND > T> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED = TO, THE > T> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A = PARTICULAR PURPOSE > T> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS = BE LIABLE > T> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > T> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF = SUBSTITUTE GOODS > T> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > T> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN = CONTRACT, STRICT > T> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING = IN ANY WAY > T> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE = POSSIBILITY OF > T> + * SUCH DAMAGE. > T> + */ > T> + > T> +#include > T> +__FBSDID("$FreeBSD$"); > T> + > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> + > T> +#include > T> +#include > T> +#include > T> + > T> +#ifndef NSFBUFS > T> +#define NSFBUFS (512 + maxusers * 16) > T> +#endif > T> + > T> +static int nsfbufs; > T> +static int nsfbufspeak; > T> +static int nsfbufsused; > T> + > T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> + "Maximum number of sendfile(2) sf_bufs available"); > T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> + "Number of sendfile(2) sf_bufs at peak usage"); > T> +SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> + "Number of sendfile(2) sf_bufs in use"); > T> + > T> +static void sf_buf_init(void *arg); > T> +SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> + > T> +LIST_HEAD(sf_head, sf_buf); > T> + > T> +/* > T> + * A hash table of active sendfile(2) buffers > T> + */ > T> +static struct sf_head *sf_buf_active; > T> +static u_long sf_buf_hashmask; > T> + > T> +#define SF_BUF_HASH(m) (((m) - vm_page_array) & = sf_buf_hashmask) > T> + > T> +static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> +static u_int sf_buf_alloc_want; > T> + > T> +/* > T> + * A lock used to synchronize access to the hash table and free = list > T> + */ > T> +static struct mtx sf_buf_lock; > T> + > T> +/* > T> + * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> + */ > T> +static void > T> +sf_buf_init(void *arg) > T> +{ > T> + struct sf_buf *sf_bufs; > T> + vm_offset_t sf_base; > T> + int i; > T> + > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return; > T> +#endif > T> + > T> + nsfbufs =3D NSFBUFS; > T> + TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> + > T> + sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> + TAILQ_INIT(&sf_buf_freelist); > T> + sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> + sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> + M_NOWAIT | M_ZERO); > T> + KASSERT(sf_bufs, ("%s: malloc failure", __func__)); > T> + for (i =3D 0; i < nsfbufs; i++) { > T> + sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> + TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> + } > T> + sf_buf_alloc_want =3D 0; > T> + mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> +} > T> + > T> +/* > T> + * Get an sf_buf from the freelist. May block if none are = available. > T> + */ > T> +struct sf_buf * > T> +sf_buf_alloc(struct vm_page *m, int flags) > T> +{ > T> + struct sf_head *hash_list; > T> + struct sf_buf *sf; > T> + int error; > T> + > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return ((struct sf_buf *)m); > T> +#endif > T> + > T> + KASSERT(curthread->td_pinned > 0 || (flags & SFB_CPUPRIVATE) =3D=3D= 0, > T> + ("sf_buf_alloc(SFB_CPUPRIVATE): curthread not pinned")); > T> + hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> + mtx_lock(&sf_buf_lock); > T> + LIST_FOREACH(sf, hash_list, list_entry) { > T> + if (sf->m =3D=3D m) { > T> + sf->ref_count++; > T> + if (sf->ref_count =3D=3D 1) { > T> + TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> + nsfbufsused++; > T> + nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> + } > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> + sf_buf_shootdown(sf, flags); > T> +#endif > T> + goto done; > T> + } > T> + } > T> + while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> + if (flags & SFB_NOWAIT) > T> + goto done; > T> + sf_buf_alloc_want++; > T> + SFSTAT_INC(sf_allocwait); > T> + error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> + (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> + sf_buf_alloc_want--; > T> + > T> + /* > T> + * If we got a signal, don't risk going back to sleep.=20= > T> + */ > T> + if (error) > T> + goto done; > T> + } > T> + TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> + if (sf->m !=3D NULL) > T> + LIST_REMOVE(sf, list_entry); > T> + LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> + sf->ref_count =3D 1; > T> + sf->m =3D m; > T> + nsfbufsused++; > T> + nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> + sf_buf_map(sf, flags); > T> +done: > T> + mtx_unlock(&sf_buf_lock); > T> + return (sf); > T> +} > T> + > T> +/* > T> + * Remove a reference from the given sf_buf, adding it to the free > T> + * list when its reference count reaches zero. A freed sf_buf = still, > T> + * however, retains its virtual-to-physical mapping until it is > T> + * recycled or reactivated by sf_buf_alloc(9). > T> + */ > T> +void > T> +sf_buf_free(struct sf_buf *sf) > T> +{ > T> + > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return; > T> +#endif > T> + > T> + mtx_lock(&sf_buf_lock); > T> + sf->ref_count--; > T> + if (sf->ref_count =3D=3D 0) { > T> + TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> + nsfbufsused--; > T> + if (sf_buf_unmap(sf)) { > T> + sf->m =3D NULL; > T> + LIST_REMOVE(sf, list_entry); > T> + } > T> + if (sf_buf_alloc_want > 0) > T> + wakeup(&sf_buf_freelist); > T> + } > T> + mtx_unlock(&sf_buf_lock); > T> +} > T> + > T> +#ifdef SFBUF_PROCESS_PAGE > T> +/* > T> + * Run callback function on sf_buf that holds a certain page. > T> + */ > T> +boolean_t > T> +sf_buf_process_page(vm_page_t m, void (*cb)(struct sf_buf *)) > T> +{ > T> + struct sf_head *hash_list; > T> + struct sf_buf *sf; > T> + > T> + hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> + mtx_lock(&sf_buf_lock); > T> + LIST_FOREACH(sf, hash_list, list_entry) { > T> + if (sf->m =3D=3D m) { > T> + cb(sf); > T> + mtx_unlock(&sf_buf_lock); > T> + return (TRUE); > T> + } > T> + } > T> + mtx_unlock(&sf_buf_lock); > T> + return (FALSE); > T> +} > T> +#endif /* SFBUF_PROCESS_PAGE */ > T>=20 > T> Property changes on: sys/kern/subr_sfbuf.c > T> ___________________________________________________________________ > T> Added: svn:mime-type > T> ## -0,0 +1 ## > T> +text/plain > T> \ No newline at end of property > T> Added: svn:keywords > T> ## -0,0 +1 ## > T> +FreeBSD=3D%H > T> \ No newline at end of property > T> Added: svn:eol-style > T> ## -0,0 +1 ## > T> +native > T> \ No newline at end of property > T> Index: sys/mips/include/sf_buf.h > T> =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 > T> --- sys/mips/include/sf_buf.h (revision 268750) > T> +++ sys/mips/include/sf_buf.h (working copy) > T> @@ -29,31 +29,9 @@ > T> #ifndef _MACHINE_SF_BUF_H_ > T> #define _MACHINE_SF_BUF_H_ > T> =20 > T> -#ifdef __mips_n64 > T> -#include > T> -#include > T> -#include > T> -#else > T> -#include > T> -#endif > T> +#ifdef __mips_n64 /* In 64 bit the whole memory is directly mapped = */ > T> =20 > T> -#ifdef __mips_n64 > T> -/* In 64 bit the whole memory is directly mapped */ > T> -struct sf_buf; > T> - > T> -static inline struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int pri) > T> -{ > T> - > T> - return ((struct sf_buf *)m); > T> -} > T> - > T> -static inline void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> -} > T> - > T> -static __inline vm_offset_t > T> +static inline vm_offset_t > T> sf_buf_kva(struct sf_buf *sf) > T> { > T> vm_page_t m; > T> @@ -62,7 +40,7 @@ sf_buf_kva(struct sf_buf *sf) > T> return (MIPS_PHYS_TO_DIRECT(VM_PAGE_TO_PHYS(m))); > T> } > T> =20 > T> -static __inline struct vm_page * > T> +static inline struct vm_page * > T> sf_buf_page(struct sf_buf *sf) > T> { > T> =20 > T> @@ -69,31 +47,5 @@ sf_buf_page(struct sf_buf *sf) > T> return ((vm_page_t)sf); > T> } > T> =20 > T> -#else /* ! __mips_n64 */ > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - SLIST_ENTRY(sf_buf) free_list; /* list of free buffer slots */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->m); > T> -} > T> #endif /* __mips_n64 */ > T> - > T> #endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/mips/include/vmparam.h > T> =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 > T> --- sys/mips/include/vmparam.h (revision 268750) > T> +++ sys/mips/include/vmparam.h (working copy) > T> @@ -187,4 +187,8 @@ > T> =20 > T> #define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ > T> =20 > T> +#ifndef __mips_n64 > T> +#define SFBUF > T> +#endif > T> + > T> #endif /* !_MACHINE_VMPARAM_H_ */ > T> Index: sys/mips/mips/vm_machdep.c > T> =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 > T> --- sys/mips/mips/vm_machdep.c (revision 268750) > T> +++ sys/mips/mips/vm_machdep.c (working copy) > T> @@ -76,9 +76,6 @@ __FBSDID("$FreeBSD$"); > T> =20 > T> #include > T> #include > T> -#ifndef __mips_n64 > T> -#include > T> -#endif > T> =20 > T> /* Duplicated from asm.h */ > T> #if defined(__mips_o32) > T> @@ -92,39 +89,7 @@ __FBSDID("$FreeBSD$"); > T> #define CALLFRAME_SIZ (SZREG * 4) > T> #endif > T> =20 > T> -#ifndef __mips_n64 > T> - > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> /* > T> - * Expanded sf_freelist head. Really an SLIST_HEAD() in disguise, = with the > T> - * sf_freelist head with the sf_lock mutex. > T> - */ > T> -static struct { > T> - SLIST_HEAD(, sf_buf) sf_head; > T> - struct mtx sf_lock; > T> -} sf_freelist; > T> - > T> -static u_int sf_buf_alloc_want; > T> -#endif /* !__mips_n64 */ > T> - > T> -/* > T> * Finish a fork operation, with process p2 nearly set up. > T> * Copy and update the pcb, set up the stack so that the child > T> * ready to run and return to user mode. > T> @@ -513,84 +478,6 @@ cpu_set_upcall_kse(struct thread *td, void = (*entry > T> #define ZIDLE_HI(v) ((v) * 4 / 5) > T> =20 > T> /* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -#ifndef __mips_n64 > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - mtx_init(&sf_freelist.sf_lock, "sf_bufs list lock", NULL, = MTX_DEF); > T> - SLIST_INIT(&sf_freelist.sf_head); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, &sf_bufs[i], = free_list); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - mtx_lock(&sf_freelist.sf_lock); > T> - while ((sf =3D SLIST_FIRST(&sf_freelist.sf_head)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - break; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_freelist, &sf_freelist.sf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - break; > T> - } > T> - if (sf !=3D NULL) { > T> - SLIST_REMOVE_HEAD(&sf_freelist.sf_head, free_list); > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_qenter(sf->kva, &sf->m, 1); > T> - } > T> - mtx_unlock(&sf_freelist.sf_lock); > T> - return (sf); > T> -} > T> - > T> -/* > T> - * Release resources back to the system. > T> - */ > T> -void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - pmap_qremove(sf->kva, 1); > T> - mtx_lock(&sf_freelist.sf_lock); > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, sf, free_list); > T> - nsfbufsused--; > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_freelist); > T> - mtx_unlock(&sf_freelist.sf_lock); > T> -} > T> -#endif /* !__mips_n64 */ > T> - > T> -/* > T> * Software interrupt handler for queued VM system processing. > T> */ > T> void > T> Index: sys/powerpc/include/sf_buf.h > T> =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 > T> --- sys/powerpc/include/sf_buf.h (revision 268750) > T> +++ sys/powerpc/include/sf_buf.h (working copy) > T> @@ -1,80 +0,0 @@ > T> -/*- > T> - * Copyright (c) 2003 Alan L. Cox > T> - * All rights reserved. > T> - * > T> - * Redistribution and use in source and binary forms, with or = without > T> - * modification, are permitted provided that the following = conditions > T> - * are met: > T> - * 1. Redistributions of source code must retain the above = copyright > T> - * notice, this list of conditions and the following = disclaimer. > T> - * 2. Redistributions in binary form must reproduce the above = copyright > T> - * notice, this list of conditions and the following disclaimer = in the > T> - * documentation and/or other materials provided with the = distribution. > T> - * > T> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS = IS'' AND > T> - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED = TO, THE > T> - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A = PARTICULAR PURPOSE > T> - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS = BE LIABLE > T> - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > T> - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF = SUBSTITUTE GOODS > T> - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > T> - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN = CONTRACT, STRICT > T> - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING = IN ANY WAY > T> - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE = POSSIBILITY OF > T> - * SUCH DAMAGE. > T> - * > T> - * $FreeBSD$ > T> - */ > T> - > T> -#ifndef _MACHINE_SF_BUF_H_ > T> -#define _MACHINE_SF_BUF_H_ > T> - > T> -#include > T> -#include > T> -#include > T> -#include > T> -#include > T> - > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> - TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> - int ref_count; /* usage of this mapping */ > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -/* > T> - * On 32-bit OEA, the only purpose for which sf_buf is used is to = implement > T> - * an opaque pointer required by the machine-independent parts of = the kernel. > T> - * That pointer references the vm_page that is "mapped" by the = sf_buf. The > T> - * actual mapping is provided by the direct virtual-to-physical = mapping. =20 > T> - * > T> - * On OEA64 and Book-E, we need to do something a little more = complicated. Use > T> - * the runtime-detected hw_direct_map to pick between the two = cases. Our > T> - * friends in vm_machdep.c will do the same to ensure nothing gets = confused. > T> - */ > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - if (hw_direct_map) > T> - return (VM_PAGE_TO_PHYS((vm_page_t)sf)); > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - if (hw_direct_map) > T> - return ((vm_page_t)sf); > T> - > T> - return (sf->m); > T> -} > T> - > T> -#endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/powerpc/include/vmparam.h > T> =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 > T> --- sys/powerpc/include/vmparam.h (revision 268750) > T> +++ sys/powerpc/include/vmparam.h (working copy) > T> @@ -197,4 +197,18 @@ struct pmap_physseg { > T> =20 > T> #define ZERO_REGION_SIZE (64 * 1024) /* 64KB */ > T> =20 > T> +/* > T> + * On 32-bit OEA, the only purpose for which sf_buf is used is to = implement > T> + * an opaque pointer required by the machine-independent parts of = the kernel. > T> + * That pointer references the vm_page that is "mapped" by the = sf_buf. The > T> + * actual mapping is provided by the direct virtual-to-physical = mapping. > T> + * > T> + * On OEA64 and Book-E, we need to do something a little more = complicated. Use > T> + * the runtime-detected hw_direct_map to pick between the two = cases. Our > T> + * friends in vm_machdep.c will do the same to ensure nothing gets = confused. > T> + */ > T> +#define SFBUF > T> +#define SFBUF_NOMD > T> +#define SFBUF_OPTIONAL_DIRECT_MAP hw_direct_map > T> +=20 > T> #endif /* _MACHINE_VMPARAM_H_ */ > T> Index: sys/powerpc/powerpc/vm_machdep.c > T> =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 > T> --- sys/powerpc/powerpc/vm_machdep.c (revision 268750) > T> +++ sys/powerpc/powerpc/vm_machdep.c (working copy) > T> @@ -80,7 +80,6 @@ > T> #include > T> #include > T> #include > T> -#include > T> #include > T> #include > T> #include > T> @@ -100,47 +99,6 @@ > T> #include > T> #include > T> =20 > T> -/* > T> - * On systems without a direct mapped region (e.g. PPC64), > T> - * we use the same code as the Book E implementation. Since > T> - * we need to have runtime detection of this, define some = machinery > T> - * for sf_bufs in this case, and ignore it on systems with direct = maps. > T> - */ > T> - > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> -=20 > T> -LIST_HEAD(sf_head, sf_buf); > T> -=20 > T> -/* A hash table of active sendfile(2) buffers */ > T> -static struct sf_head *sf_buf_active; > T> -static u_long sf_buf_hashmask; > T> - > T> -#define SF_BUF_HASH(m) (((m) - vm_page_array) & sf_buf_hashmask) > T> - > T> -static TAILQ_HEAD(, sf_buf) sf_buf_freelist; > T> -static u_int sf_buf_alloc_want; > T> - > T> -/* > T> - * A lock used to synchronize access to the hash table and free = list > T> - */ > T> -static struct mtx sf_buf_lock; > T> - > T> #ifdef __powerpc64__ > T> extern uintptr_t tocbase; > T> #endif > T> @@ -245,124 +203,6 @@ cpu_exit(struct thread *td) > T> } > T> =20 > T> /* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - /* Don't bother on systems with a direct map */ > T> - if (hw_direct_map) > T> - return; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - sf_buf_active =3D hashinit(nsfbufs, M_TEMP, &sf_buf_hashmask); > T> - TAILQ_INIT(&sf_buf_freelist); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, &sf_bufs[i], = free_entry); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> - mtx_init(&sf_buf_lock, "sf_buf", NULL, MTX_DEF); > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_head *hash_list; > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - if (hw_direct_map) { > T> - /* Shortcut the direct mapped case */ > T> - return ((struct sf_buf *)m); > T> - } > T> - > T> - hash_list =3D &sf_buf_active[SF_BUF_HASH(m)]; > T> - mtx_lock(&sf_buf_lock); > T> - LIST_FOREACH(sf, hash_list, list_entry) { > T> - if (sf->m =3D=3D m) { > T> - sf->ref_count++; > T> - if (sf->ref_count =3D=3D 1) { > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, = free_entry); > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, = nsfbufsused); > T> - } > T> - goto done; > T> - } > T> - } > T> - > T> - while ((sf =3D TAILQ_FIRST(&sf_buf_freelist)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - goto done; > T> - > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_buf_freelist, &sf_buf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - goto done; > T> - } > T> - > T> - TAILQ_REMOVE(&sf_buf_freelist, sf, free_entry); > T> - if (sf->m !=3D NULL) > T> - LIST_REMOVE(sf, list_entry); > T> - > T> - LIST_INSERT_HEAD(hash_list, sf, list_entry); > T> - sf->ref_count =3D 1; > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_qenter(sf->kva, &sf->m, 1); > T> -done: > T> - mtx_unlock(&sf_buf_lock); > T> - return (sf); > T> -} > T> - > T> -/* > T> - * Detach mapped page and release resources back to the system. > T> - * > T> - * Remove a reference from the given sf_buf, adding it to the free > T> - * list when its reference count reaches zero. A freed sf_buf = still, > T> - * however, retains its virtual-to-physical mapping until it is > T> - * recycled or reactivated by sf_buf_alloc(9). > T> - */ > T> -void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - if (hw_direct_map) > T> - return; > T> - > T> - mtx_lock(&sf_buf_lock); > T> - sf->ref_count--; > T> - if (sf->ref_count =3D=3D 0) { > T> - TAILQ_INSERT_TAIL(&sf_buf_freelist, sf, free_entry); > T> - nsfbufsused--; > T> - > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_buf_freelist); > T> - } > T> - mtx_unlock(&sf_buf_lock); > T> -} > T> - > T> -/* > T> * Software interrupt handler for queued VM system processing. > T> */ > T> void > T> Index: sys/sparc64/include/sf_buf.h > T> =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 > T> --- sys/sparc64/include/sf_buf.h (revision 268750) > T> +++ sys/sparc64/include/sf_buf.h (working copy) > T> @@ -1,59 +0,0 @@ > T> -/*- > T> - * Copyright (c) 2003 Alan L. Cox > T> - * All rights reserved. > T> - * > T> - * Redistribution and use in source and binary forms, with or = without > T> - * modification, are permitted provided that the following = conditions > T> - * are met: > T> - * 1. Redistributions of source code must retain the above = copyright > T> - * notice, this list of conditions and the following = disclaimer. > T> - * 2. Redistributions in binary form must reproduce the above = copyright > T> - * notice, this list of conditions and the following disclaimer = in the > T> - * documentation and/or other materials provided with the = distribution. > T> - * > T> - * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS = IS'' AND > T> - * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED = TO, THE > T> - * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A = PARTICULAR PURPOSE > T> - * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS = BE LIABLE > T> - * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > T> - * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF = SUBSTITUTE GOODS > T> - * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > T> - * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN = CONTRACT, STRICT > T> - * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING = IN ANY WAY > T> - * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE = POSSIBILITY OF > T> - * SUCH DAMAGE. > T> - * > T> - * $FreeBSD$ > T> - */ > T> - > T> -#ifndef _MACHINE_SF_BUF_H_ > T> -#define _MACHINE_SF_BUF_H_ > T> - > T> -#include > T> - > T> -struct vm_page; > T> - > T> -struct sf_buf { > T> - SLIST_ENTRY(sf_buf) free_list; /* list of free buffer slots */ > T> - struct vm_page *m; /* currently mapped page */ > T> - vm_offset_t kva; /* va of mapping */ > T> -}; > T> - > T> -struct sf_buf * sf_buf_alloc(struct vm_page *m, int flags); > T> -void sf_buf_free(struct sf_buf *sf); > T> - > T> -static __inline vm_offset_t > T> -sf_buf_kva(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->kva); > T> -} > T> - > T> -static __inline struct vm_page * > T> -sf_buf_page(struct sf_buf *sf) > T> -{ > T> - > T> - return (sf->m); > T> -} > T> - > T> -#endif /* !_MACHINE_SF_BUF_H_ */ > T> Index: sys/sparc64/include/vmparam.h > T> =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 > T> --- sys/sparc64/include/vmparam.h (revision 268750) > T> +++ sys/sparc64/include/vmparam.h (working copy) > T> @@ -239,4 +239,7 @@ extern vm_offset_t vm_max_kernel_address; > T> */ > T> #define ZERO_REGION_SIZE PAGE_SIZE > T> =20 > T> +#define SFBUF > T> +#define SFBUF_NOMD > T> + > T> #endif /* !_MACHINE_VMPARAM_H_ */ > T> Index: sys/sparc64/sparc64/vm_machdep.c > T> =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 > T> --- sys/sparc64/sparc64/vm_machdep.c (revision 268750) > T> +++ sys/sparc64/sparc64/vm_machdep.c (working copy) > T> @@ -53,7 +53,6 @@ __FBSDID("$FreeBSD$"); > T> #include > T> #include > T> #include > T> -#include > T> #include > T> #include > T> #include > T> @@ -84,35 +83,6 @@ __FBSDID("$FreeBSD$"); > T> #include > T> #include > T> =20 > T> -#ifndef NSFBUFS > T> -#define NSFBUFS (512 + maxusers * 16) > T> -#endif > T> - > T> -static int nsfbufs; > T> -static int nsfbufspeak; > T> -static int nsfbufsused; > T> - > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufs, CTLFLAG_RDTUN, &nsfbufs, = 0, > T> - "Maximum number of sendfile(2) sf_bufs available"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufspeak, CTLFLAG_RD, = &nsfbufspeak, 0, > T> - "Number of sendfile(2) sf_bufs at peak usage"); > T> -SYSCTL_INT(_kern_ipc, OID_AUTO, nsfbufsused, CTLFLAG_RD, = &nsfbufsused, 0, > T> - "Number of sendfile(2) sf_bufs in use"); > T> - > T> -static void sf_buf_init(void *arg); > T> -SYSINIT(sock_sf, SI_SUB_MBUF, SI_ORDER_ANY, sf_buf_init, NULL); > T> - > T> -/* > T> - * Expanded sf_freelist head. Really an SLIST_HEAD() in disguise, = with the > T> - * sf_freelist head with the sf_lock mutex. > T> - */ > T> -static struct { > T> - SLIST_HEAD(, sf_buf) sf_head; > T> - struct mtx sf_lock; > T> -} sf_freelist; > T> - > T> -static u_int sf_buf_alloc_want; > T> - > T> PMAP_STATS_VAR(uma_nsmall_alloc); > T> PMAP_STATS_VAR(uma_nsmall_alloc_oc); > T> PMAP_STATS_VAR(uma_nsmall_free); > T> @@ -417,84 +387,7 @@ is_physical_memory(vm_paddr_t addr) > T> return (0); > T> } > T> =20 > T> -/* > T> - * Allocate a pool of sf_bufs (sendfile(2) or "super-fast" if you = prefer. :-)) > T> - */ > T> -static void > T> -sf_buf_init(void *arg) > T> -{ > T> - struct sf_buf *sf_bufs; > T> - vm_offset_t sf_base; > T> - int i; > T> - > T> - nsfbufs =3D NSFBUFS; > T> - TUNABLE_INT_FETCH("kern.ipc.nsfbufs", &nsfbufs); > T> - > T> - mtx_init(&sf_freelist.sf_lock, "sf_bufs list lock", NULL, = MTX_DEF); > T> - SLIST_INIT(&sf_freelist.sf_head); > T> - sf_base =3D kva_alloc(nsfbufs * PAGE_SIZE); > T> - sf_bufs =3D malloc(nsfbufs * sizeof(struct sf_buf), M_TEMP, > T> - M_NOWAIT | M_ZERO); > T> - for (i =3D 0; i < nsfbufs; i++) { > T> - sf_bufs[i].kva =3D sf_base + i * PAGE_SIZE; > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, &sf_bufs[i], = free_list); > T> - } > T> - sf_buf_alloc_want =3D 0; > T> -} > T> - > T> -/* > T> - * Get an sf_buf from the freelist. Will block if none are = available. > T> - */ > T> -struct sf_buf * > T> -sf_buf_alloc(struct vm_page *m, int flags) > T> -{ > T> - struct sf_buf *sf; > T> - int error; > T> - > T> - mtx_lock(&sf_freelist.sf_lock); > T> - while ((sf =3D SLIST_FIRST(&sf_freelist.sf_head)) =3D=3D NULL) { > T> - if (flags & SFB_NOWAIT) > T> - break; > T> - sf_buf_alloc_want++; > T> - SFSTAT_INC(sf_allocwait); > T> - error =3D msleep(&sf_freelist, &sf_freelist.sf_lock, > T> - (flags & SFB_CATCH) ? PCATCH | PVM : PVM, "sfbufa", = 0); > T> - sf_buf_alloc_want--; > T> - > T> - /* > T> - * If we got a signal, don't risk going back to sleep. > T> - */ > T> - if (error) > T> - break; > T> - } > T> - if (sf !=3D NULL) { > T> - SLIST_REMOVE_HEAD(&sf_freelist.sf_head, free_list); > T> - sf->m =3D m; > T> - nsfbufsused++; > T> - nsfbufspeak =3D imax(nsfbufspeak, nsfbufsused); > T> - pmap_qenter(sf->kva, &sf->m, 1); > T> - } > T> - mtx_unlock(&sf_freelist.sf_lock); > T> - return (sf); > T> -} > T> - > T> -/* > T> - * Release resources back to the system. > T> - */ > T> void > T> -sf_buf_free(struct sf_buf *sf) > T> -{ > T> - > T> - pmap_qremove(sf->kva, 1); > T> - mtx_lock(&sf_freelist.sf_lock); > T> - SLIST_INSERT_HEAD(&sf_freelist.sf_head, sf, free_list); > T> - nsfbufsused--; > T> - if (sf_buf_alloc_want > 0) > T> - wakeup(&sf_freelist); > T> - mtx_unlock(&sf_freelist.sf_lock); > T> -} > T> - > T> -void > T> swi_vm(void *v) > T> { > T> =20 > T> Index: sys/sys/sf_buf.h > T> =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 > T> --- sys/sys/sf_buf.h (revision 268750) > T> +++ sys/sys/sf_buf.h (working copy) > T> @@ -29,6 +29,114 @@ > T> #ifndef _SYS_SF_BUF_H_ > T> #define _SYS_SF_BUF_H_ > T> =20 > T> +struct sfstat { /* sendfile statistics = */ > T> + uint64_t sf_iocnt; /* times sendfile had to do disk = I/O */ > T> + uint64_t sf_allocfail; /* times sfbuf allocation failed = */ > T> + uint64_t sf_allocwait; /* times sfbuf allocation had to = wait */ > T> +}; > T> + > T> +#ifdef _KERNEL > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> +#include > T> + > T> +#ifdef SFBUF > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> +#include > T> +#endif > T> +#include > T> + > T> +struct sf_buf { > T> + LIST_ENTRY(sf_buf) list_entry; /* list of buffers */ > T> + TAILQ_ENTRY(sf_buf) free_entry; /* list of buffers */ > T> + vm_page_t m; /* currently mapped page = */ > T> + vm_offset_t kva; /* va of mapping */ > T> + int ref_count; /* usage of this mapping = */ > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> + cpuset_t cpumask; /* where mapping is = valid */ > T> +#endif > T> +}; > T> +#else /* ! SFBUF */ > T> +struct sf_buf; > T> +#endif /* SFBUF */ > T> + > T> +#ifndef SFBUF_NOMD > T> +#include > T> +#endif > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> +#include > T> +#endif > T> + > T> +#ifdef SFBUF > T> +struct sf_buf *sf_buf_alloc(struct vm_page *, int); > T> +void sf_buf_free(struct sf_buf *); > T> + > T> +static inline vm_offset_t > T> +sf_buf_kva(struct sf_buf *sf) > T> +{ > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return (VM_PAGE_TO_PHYS((vm_page_t)sf)); > T> +#endif > T> + > T> + return (sf->kva); > T> +} > T> + > T> +static inline vm_page_t > T> +sf_buf_page(struct sf_buf *sf) > T> +{ > T> +#ifdef SFBUF_OPTIONAL_DIRECT_MAP > T> + if (SFBUF_OPTIONAL_DIRECT_MAP) > T> + return ((vm_page_t)sf); > T> +#endif > T> + > T> + return (sf->m); > T> +} > T> + > T> +#ifndef SFBUF_MAP > T> +#include > T> + > T> +static inline void > T> +sf_buf_map(struct sf_buf *sf, int flags) > T> +{ > T> + > T> + pmap_qenter(sf->kva, &sf->m, 1); > T> +} > T> + > T> +static inline int > T> +sf_buf_unmap(struct sf_buf *sf) > T> +{ > T> + > T> + return (0); > T> +} > T> +#endif /* SFBUF_MAP */ > T> + > T> +#if defined(SMP) && defined(SFBUF_CPUSET) > T> +void sf_buf_shootdown(struct sf_buf *, int); > T> +#endif > T> + > T> +#ifdef SFBUF_PROCESS_PAGE > T> +boolean_t sf_buf_process_page(vm_page_t, void (*)(struct sf_buf = *)); > T> +#endif > T> + > T> +#else /* ! SFBUF */ > T> + > T> +static inline struct sf_buf * > T> +sf_buf_alloc(struct vm_page *m, int pri) > T> +{ > T> + > T> + return ((struct sf_buf *)m); > T> +} > T> + > T> +static inline void > T> +sf_buf_free(struct sf_buf *sf) > T> +{ > T> +} > T> +#endif /* SFBUF */ > T> + > T> /* > T> * Options to sf_buf_alloc() are specified through its flags = argument. This > T> * argument's value should be the result of a bitwise or'ing of = one or more > T> @@ -40,19 +148,6 @@ > T> #define SFB_DEFAULT 0 > T> #define SFB_NOWAIT 4 /* Return NULL if all = bufs are used. */ > T> =20 > T> -struct vm_page; > T> - > T> -struct sfstat { /* sendfile statistics = */ > T> - uint64_t sf_iocnt; /* times sendfile had to do disk = I/O */ > T> - uint64_t sf_allocfail; /* times sfbuf allocation failed = */ > T> - uint64_t sf_allocwait; /* times sfbuf allocation had to = wait */ > T> -}; > T> - > T> -#ifdef _KERNEL > T> -#include > T> -#include > T> -#include > T> - > T> extern counter_u64_t sfstat[sizeof(struct sfstat) / = sizeof(uint64_t)]; > T> #define SFSTAT_ADD(name, val) \ > T> counter_u64_add(sfstat[offsetof(struct sfstat, name) / = sizeof(uint64_t)],\ >=20 > T> _______________________________________________ > T> freebsd-current@freebsd.org mailing list > T> http://lists.freebsd.org/mailman/listinfo/freebsd-current > T> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 >=20 > --=20 > Totus tuus, Glebius. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >=20 From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 18:00:47 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94F239E3; Tue, 29 Jul 2014 18:00:47 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 178952F5B; Tue, 29 Jul 2014 18:00:46 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6TI0hgP072844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Jul 2014 22:00:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6TI0h5D072843; Tue, 29 Jul 2014 22:00:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 29 Jul 2014 22:00:43 +0400 From: Gleb Smirnoff To: Michael Tuexen Subject: Re: [CFT/CFR] machine independent sf_bufs Message-ID: <20140729180043.GG89995@glebius.int.ru> References: <20140719062725.GB85917@FreeBSD.org> <20140729104156.GD89995@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: kib@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 18:00:47 -0000 On Tue, Jul 29, 2014 at 07:29:43PM +0200, Michael Tuexen wrote: M> > Sorry for top quoting, this is to annoy you :) I got zero M> > replies on the below email during a week. I'd really appreciate M> > testing on different platforms. Any takers? M> OK, it works on an Raspberry pi running r269231 with your patch. M> The only suspicious thing I observed was that the number of M> 'requests for I/O initiated by sendfile' in netstat -m doesn't M> always increase. I would expect that. However, I'm not sure if M> this is ARM related (I would not think so) or is related to your M> patch at all. Thanks a lot, Michael! The observation on number of I/Os is absolutely okay, since VM cashes pages. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 21:10:58 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2AA6C54D; Tue, 29 Jul 2014 21:10:58 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1A5925E6; Tue, 29 Jul 2014 21:10:57 +0000 (UTC) Received: from [192.168.1.200] (p548188AB.dip0.t-ipconnect.de [84.129.136.171]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 549F31C0E96AC; Tue, 29 Jul 2014 23:10:54 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFT/CFR] machine independent sf_bufs From: Michael Tuexen In-Reply-To: <20140729180043.GG89995@glebius.int.ru> Date: Tue, 29 Jul 2014 23:10:53 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20140719062725.GB85917@FreeBSD.org> <20140729104156.GD89995@FreeBSD.org> <20140729180043.GG89995@glebius.int.ru> To: Gleb Smirnoff X-Mailer: Apple Mail (2.1878.6) Cc: kib@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 21:10:58 -0000 On 29 Jul 2014, at 20:00, Gleb Smirnoff wrote: > On Tue, Jul 29, 2014 at 07:29:43PM +0200, Michael Tuexen wrote: > M> > Sorry for top quoting, this is to annoy you :) I got zero > M> > replies on the below email during a week. I'd really appreciate > M> > testing on different platforms. Any takers? > M> OK, it works on an Raspberry pi running r269231 with your patch. > M> The only suspicious thing I observed was that the number of > M> 'requests for I/O initiated by sendfile' in netstat -m doesn't > M> always increase. I would expect that. However, I'm not sure if > M> this is ARM related (I would not think so) or is related to your > M> patch at all. > > Thanks a lot, Michael! > > The observation on number of I/Os is absolutely okay, since VM > cashes pages. Ahh, OK, makes sense. I was transmitting the same file several times... Best regards Michael > > > -- > Totus tuus, Glebius. > From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 21:49:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7FD33E7 for ; Tue, 29 Jul 2014 21:49:00 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACE5D29A8 for ; Tue, 29 Jul 2014 21:49:00 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XCFGU-0006Ns-Tp for freebsd-current@freebsd.org; Tue, 29 Jul 2014 14:48:58 -0700 Date: Tue, 29 Jul 2014 14:48:58 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <1406670538802-5933179.post@n5.nabble.com> Subject: zdb: specify object_id for dataset of the zpool name MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 29 Jul 2014 21:49:00 -0000 If I do "zdb -dd mypool", It shows me the data from entire pool and all its datasets, when in fact I only want the list from the mypool dataset. The dataset ID is 21, so is there any syntax like: # zdb -dd ID=21 I'm not trying to filter the output - I'm trying to dozdb -ddddd mypool object_id "", which does not work when using the zpool name because zdb looks at the pool-level data and returns error (no such object). ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zdb-specify-object-id-for-dataset-of-the-zpool-name-tp5933179.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 05:34:58 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B6CA23FE; Wed, 30 Jul 2014 05:34:58 +0000 (UTC) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B3AC2AE2; Wed, 30 Jul 2014 05:34:57 +0000 (UTC) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.14.8/8.14.8) with ESMTP id s6U5Yla7044021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Jul 2014 13:34:47 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.14.8/8.14.8/Submit) id s6U5YlmT044020; Wed, 30 Jul 2014 13:34:47 +0800 (CST) (envelope-from kevlo) Date: Wed, 30 Jul 2014 13:34:46 +0800 From: Kevin Lo To: Gleb Smirnoff Subject: Re: [CFT/CFR] machine independent sf_bufs Message-ID: <20140730053446.GA44008@ns.kevlo.org> References: <20140719062725.GB85917@FreeBSD.org> <20140729104156.GD89995@FreeBSD.org> <20140729180043.GG89995@glebius.int.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140729180043.GG89995@glebius.int.ru> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: kib@FreeBSD.org, Michael Tuexen , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 05:34:58 -0000 On Tue, Jul 29, 2014 at 10:00:43PM +0400, Gleb Smirnoff wrote: > > On Tue, Jul 29, 2014 at 07:29:43PM +0200, Michael Tuexen wrote: > M> > Sorry for top quoting, this is to annoy you :) I got zero > M> > replies on the below email during a week. I'd really appreciate > M> > testing on different platforms. Any takers? > M> OK, it works on an Raspberry pi running r269231 with your patch. > M> The only suspicious thing I observed was that the number of > M> 'requests for I/O initiated by sendfile' in netstat -m doesn't > M> always increase. I would expect that. However, I'm not sure if > M> this is ARM related (I would not think so) or is related to your > M> patch at all. > > Thanks a lot, Michael! > > The observation on number of I/Os is absolutely okay, since VM > cashes pages. Hi Gleb, I tested your patch on FreeBSD/arm (OpenBlocks AX3), it seems to be working fine. > -- > Totus tuus, Glebius. Kevin From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 06:16:18 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC717A5C; Wed, 30 Jul 2014 06:16:18 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E9022F32; Wed, 30 Jul 2014 06:16:16 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6U6GA8E086050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Jul 2014 10:16:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6U6GAwk086049; Wed, 30 Jul 2014 10:16:10 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 30 Jul 2014 10:16:10 +0400 From: Gleb Smirnoff To: Kevin Lo Subject: Re: [CFT/CFR] machine independent sf_bufs Message-ID: <20140730061610.GA2402@glebius.int.ru> References: <20140719062725.GB85917@FreeBSD.org> <20140729104156.GD89995@FreeBSD.org> <20140729180043.GG89995@glebius.int.ru> <20140730053446.GA44008@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140730053446.GA44008@ns.kevlo.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: kib@FreeBSD.org, Michael Tuexen , current@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 06:16:18 -0000 On Wed, Jul 30, 2014 at 01:34:46PM +0800, Kevin Lo wrote: K> I tested your patch on FreeBSD/arm (OpenBlocks AX3), it seems to be working K> fine. Thanks a lot, Kevin! -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 07:19:35 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91DDDE89; Wed, 30 Jul 2014 07:19:35 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05F112547; Wed, 30 Jul 2014 07:19:34 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hi2so1771884wib.11 for ; Wed, 30 Jul 2014 00:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition:user-agent; bh=r3KPDzewZ3B9o79stgpbkiOM4GBJ4bQre83Vki7MRJQ=; b=oXe9br7hfMOWwarQMkCypipSdHxOkJiUd3yMAYKUTSgJHgnvi0N5sXyh3kKC7N8udn j07jbijZcJ0au4+d7MfnYXLZP0828uy8jPmQaL1AZvwH3GGf3IaWm+AVEnEe44oQmLIr DD+5LdShFfRRkJ/6M0v99mk+yTS3zQV9QMmXS1Oly69jMWgadsX7hE/FaX8TVPlD8CE0 Pl6cf31PUrwjUJULVM1zK/P7v/MdgkUNxBChi++HD8AvZKSJCPqr79po61ZNoFxW9ITn kIHRq3HLnmP49SCAHZHLS6RJ4w5biL0IFI90bIhCX7RC/hEuPCaeIvENUYn/heNrnBNK mbZQ== X-Received: by 10.194.89.168 with SMTP id bp8mr3157579wjb.73.1406704773315; Wed, 30 Jul 2014 00:19:33 -0700 (PDT) Received: from pc5.home (adhd145.neoplus.adsl.tpnet.pl. [79.184.159.145]) by mx.google.com with ESMTPSA id o2sm52171524wij.24.2014.07.30.00.19.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 00:19:32 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 30 Jul 2014 09:19:33 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: [CFT] Autofs. Message-ID: <20140730071933.GA20122@pc5.home> Mail-Followup-To: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 07:19:35 -0000 At the link below you will find a patch that adds the new automounter. The patch is against yesterdays 11.0-CURRENT. http://people.freebsd.org/~trasz/autofs-head-20140729.diff Slides that explain the project scope and deliverables are here: http://people.freebsd.org/~trasz/autofs.pdf Testing is welcome. Please start with manual pages, eg. automount(8). Note that you need not only to rebuild both kernel and world, but also to run mergemaster, to install required /etc files. To run at startup, add 'autofs_enable="YES"' to /etc/rc.conf. This project is being sponsored by FreeBSD Foundation. From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 18:53:24 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7F44EA7; Wed, 30 Jul 2014 18:53:24 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D75F26D2; Wed, 30 Jul 2014 18:53:24 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id at20so2121582iec.22 for ; Wed, 30 Jul 2014 11:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=690lI0wQIpTrXsPqOJ66ajjpWf+6VdgVsfBE/pP0EwE=; b=W9up9v6YfisuI3R/6J66aaqrDd4iMZ7Fslb1AsBXLHr2o0lgezxjMREQ5J3VvXh+bA F77IJs7tjwo2EnTb/Q58kFPRkICXt8qudbhypWaGrgrr7OvB4FpfmBcGBBv/Udbo37eI Ww++UiDdqWr6cm+LnbyZRRs65O9v0EGlzXuIgzsekgjTrX48Wvtnyhaj6CUHFqSudLEM zSPFFXqK4NV2EtLimoOkhkhKjEFi2GbHNI/+A8regfZvaszl0P/3m2SCIEVPum+nSjpT oLatA4h47I38Xuhh8mBPpO7FG54od/l7pmtmTYHwHLiSIr6L5A3OlrHr0yJgJAgSeecu 8Rsw== MIME-Version: 1.0 X-Received: by 10.50.43.193 with SMTP id y1mr10578848igl.32.1406746404017; Wed, 30 Jul 2014 11:53:24 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.107.163.148 with HTTP; Wed, 30 Jul 2014 11:53:23 -0700 (PDT) In-Reply-To: <20140730071933.GA20122@pc5.home> References: <20140730071933.GA20122@pc5.home> Date: Wed, 30 Jul 2014 11:53:23 -0700 X-Google-Sender-Auth: taYXqfOSHndf4oImoAvuh3IfQS0 Message-ID: Subject: Re: [CFT] Autofs. From: Kevin Oberman To: FreeBSD Current , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 18:53:25 -0000 On Wed, Jul 30, 2014 at 12:19 AM, Edward Tomasz Napiera=C5=82a wrote: > At the link below you will find a patch that adds the new automounter. > The patch is against yesterdays 11.0-CURRENT. > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > Slides that explain the project scope and deliverables are here: > > http://people.freebsd.org/~trasz/autofs.pdf > > Testing is welcome. Please start with manual pages, eg. automount(8). > Note that you need not only to rebuild both kernel and world, but also > to run mergemaster, to install required /etc files. To run at startup, > add 'autofs_enable=3D"YES"' to /etc/rc.conf. > > This project is being sponsored by FreeBSD Foundation. > > This may be a silly question, but can autofs properly handle fusefs file systems like ntfs-3g and exfat? -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 19:55:20 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B079869 for ; Wed, 30 Jul 2014 19:55:20 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D6C32CFF for ; Wed, 30 Jul 2014 19:55:20 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id c1so3569826igq.9 for ; Wed, 30 Jul 2014 12:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=X3jV3ZV1XtPas9GBi/kqVJRq7AjoypQtSTQ+LkiJ6JU=; b=lqw0eDJv+wM3B+i3gjIc79wif8qc5N4J64d/WQYMoYUdDhUbYL9OJtW7GWCvGEViTT exqNhljMt+TqDCgO/7SZeLILYkJVLa38Jnsz9aWh2NRimxmeiZcitkOoYWKZkcsDUnvs FAclckGDJeYHfBO8q3lRJJrvEc1/VtkbmpuKXJrckM0HOH3Z5aEuGa+jAlp8hJuThUui izresvNQi1B8BNVNXE3MOfUnS8K6ydhbrYwQP0NA0Pd90FH/FXa1Y7sIMugWh2nz+cSj 4v8i8K2Qy7MQsaUrIrj6N3WJBbdsHlgfMVvNZbh0kCi18stA2qcEEMfnIcprSSBOlv9Z faWQ== X-Received: by 10.42.247.137 with SMTP id mc9mr8448307icb.13.1406750119740; Wed, 30 Jul 2014 12:55:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.134.199 with HTTP; Wed, 30 Jul 2014 12:54:59 -0700 (PDT) From: Gabor Radnai Date: Wed, 30 Jul 2014 21:54:59 +0200 Message-ID: Subject: Re: Several minor annoyances on Current To: freebsd-current@freebsd.org X-Mailman-Approved-At: Wed, 30 Jul 2014 20:58:36 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 19:55:20 -0000 Hi, > * I have a kernel with all witness/debug code disabled, and the zfs root is > on a Sata3-SSD. The boot process seems a little slow to me and I'm curious > as to possible reasons. Other than disabling debug, what else can I do to > speed-up boot process (CPU: AMD Phenom II X4 B60 3415.38-MHz K8-class) hm, I have similar experience with 10-stable see http://lists.freebsd.org/pipermail/freebsd-questions/2014-July/259067.html If anybody has any idea/suggestion please please share. Thanks. From owner-freebsd-current@FreeBSD.ORG Wed Jul 30 21:53:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D72E6FFD; Wed, 30 Jul 2014 21:53:55 +0000 (UTC) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4616129D2; Wed, 30 Jul 2014 21:53:55 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id u56so1859219wes.0 for ; Wed, 30 Jul 2014 14:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=ciE7qob5TNnlbQibL++oS3fXsvjqBA9Rblz9skFYbdk=; b=EeY6OsSp+kGWTmI9Ei6C3LZVqFQjrPbRa1Dkjwq3yemkUYXFfq5VzI7scbZGswyhCF UeQt4UtzIuFKHKsh8WFIn44FCNzryPz3+vXsf1//jmTjpcMK89YfxEKjTcbD45/FJjpG hvE8JStvH6omqQgrhEj6f7QRPgndOCkJoSQ9bUPBEMo+jDzm20/PyFX0uTNMISMr5aCh iWiIT9bkRfPrMiRqvUlPMNrBY8L9S1BdCm+//KQi2ncTcqke6/ReKiVwr0fQWNUwqHYJ SZEA+aZVjZwDfOxoEwhvngGAs9L5M+DGk0WgIAaTlCdNDqJ2p2uFqoot70HwVkiAFiVG rx/Q== X-Received: by 10.194.22.166 with SMTP id e6mr10518018wjf.88.1406757233526; Wed, 30 Jul 2014 14:53:53 -0700 (PDT) Received: from brick.home (acd38.neoplus.adsl.tpnet.pl. [83.25.55.38]) by mx.google.com with ESMTPSA id ev18sm602005wid.1.2014.07.30.14.53.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jul 2014 14:53:53 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Wed, 30 Jul 2014 23:53:51 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Kevin Oberman Subject: Re: [CFT] Autofs. Message-ID: <20140730215351.GC11391@brick.home> Mail-Followup-To: Kevin Oberman , FreeBSD Current , "freebsd-arch@freebsd.org" References: <20140730071933.GA20122@pc5.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 30 Jul 2014 21:53:55 -0000 On 0730T1153, Kevin Oberman wrote: > On Wed, Jul 30, 2014 at 12:19 AM, Edward Tomasz NapieraÅ‚a > wrote: > > > At the link below you will find a patch that adds the new automounter. > > The patch is against yesterdays 11.0-CURRENT. > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > > > Slides that explain the project scope and deliverables are here: > > > > http://people.freebsd.org/~trasz/autofs.pdf > > > > Testing is welcome. Please start with manual pages, eg. automount(8). > > Note that you need not only to rebuild both kernel and world, but also > > to run mergemaster, to install required /etc files. To run at startup, > > add 'autofs_enable="YES"' to /etc/rc.conf. > > > > This project is being sponsored by FreeBSD Foundation. > > > > This may be a silly question, but can autofs properly handle fusefs file > systems like ntfs-3g and exfat? Yes, it's pretty much filesystem-agnostic, except for the -hosts map, which is NFS-specific by definition. From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 01:51:23 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4863EF8; Thu, 31 Jul 2014 01:51:23 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 996F321D4; Thu, 31 Jul 2014 01:51:22 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so1557308lam.28 for ; Wed, 30 Jul 2014 18:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=htDwpTKLF/mkQORBz7du2bWdDfzEjX/9MMLcyZygFgc=; b=awo+grd9mW4qecLgn9zMaGstY4TCRnF+BZOuLKnRJ5eh8RGOuw48+yWIF6ryvoVH5D qLF/LhOqkzCtdAZg458eh8B5eNbBoWJxfb09ExDLFqtl0ZGVydtP9KrlwbcwJhQ9ZnGE eEs+aARF8ytCnNoun5uDJZt148kNWHGJW5T6I8RAzCGG+bnsfjPgXriKlMF6Kofz47o4 WYZeTOzClRguUhQFgsf/q5bfamhq9h3rjswYP6J0ziOsRoWXe36A/xcS9lUm8gKlB996 hnfuUkjxXBBOjNvMvyVonHFgw/heQyh7Hh01TzbloEedvb0seO7uzTK8YIxuXEOaeXZ/ uz3A== MIME-Version: 1.0 X-Received: by 10.112.60.5 with SMTP id d5mr8259683lbr.26.1406771479615; Wed, 30 Jul 2014 18:51:19 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.225.34 with HTTP; Wed, 30 Jul 2014 18:51:19 -0700 (PDT) In-Reply-To: <20140730071933.GA20122@pc5.home> References: <20140730071933.GA20122@pc5.home> Date: Wed, 30 Jul 2014 18:51:19 -0700 X-Google-Sender-Auth: 1kF4cWStzhp-eEg1DwP4hcTkjKQ Message-ID: Subject: Re: [CFT] Autofs. From: Craig Rodrigues To: freebsd-current Current , freebsd-arch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 01:51:23 -0000 On Wed, Jul 30, 2014 at 12:19 AM, Edward Tomasz Napiera=C5=82a wrote: > At the link below you will find a patch that adds the new automounter. > The patch is against yesterdays 11.0-CURRENT. > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > Hi, Nice stuff! I updated a current system, and tried the patch. I put autofs_enable=3D"YES" in /etc/rc.conf In my network, I have a system, testhost with some NFS exports. /dir1/export1 /dir1/export2 /dir1/export3 I did: cd /net/testhost This operation seemed to timeout. In dmesg, I saw these errors: WARNING: autofs_callout: request 0 for /net/ timed out after 30 seconds WARNING: autofs_trigger_one: request for /net/ completed with error 60 autofs_trigger: trigger failed with error 60; will retry in 1 seconds, 2 attempts left WARNING: autofs_callout: request 1 for /net/ timed out after 30 seconds WARNING: autofs_trigger_one: request for /net/ completed with error 60 autofs_trigger: trigger failed with error 60; will retry in 1 seconds, 1 attempts left WARNING: autofs_callout: request 2 for /net/ timed out after 30 seconds WARNING: autofs_trigger_one: request for /net/ completed with error 60 autofs_trigger: trigger failed 3 times; returning error 60 I used my Mac laptop in the same network, and did: cd /net/testhost and the command did not timeout, and I could do an ls and see that /net/testhost/dir1/ was visible. Any ideas? This is cool stuff, and I hope you can get it into the 10.1 RELEASE. -- Craig From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 06:31:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8910EB9; Thu, 31 Jul 2014 06:31:43 +0000 (UTC) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 062432D47; Thu, 31 Jul 2014 06:31:42 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so3525145wiv.3 for ; Wed, 30 Jul 2014 23:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=/QnkKsq7MQuDAGX9dwh0j9zpU5aEg7Uo3c8DXgV5Dyo=; b=G5/Q4S9P1o/Xiv4jx0Dfo+pTLX+IwRoetVGZnDwam9AaBVHkkYuvreyeZgnAaaH1XR dRMRM5M9w7dLatuIikFnXhxRGGQGQkZj63Q2W5XIZ+5ZnzIVnzp8td7PK9voiB/80BG7 neS0jkZ+0sQjjQzQgqAg6TfPG2gexnYNlphKv8YgzuyfYPcHiavY+O6XrV13juKKj6oD V1QL5vNKsZ9bywb6izUEBKDVrDSp39kEuEI6yUCW4V4a9C20T6RKmofPhXxKBYbB1ZDb Jy7qlnIj9blhFhtsiyTgEWZjusW6ceOmLAn25Hw5OCNFiwb3gSlILMG7ztTpuuprhtcn TCrw== X-Received: by 10.194.122.73 with SMTP id lq9mr13054924wjb.133.1406788301201; Wed, 30 Jul 2014 23:31:41 -0700 (PDT) Received: from brick.home (acd38.neoplus.adsl.tpnet.pl. [83.25.55.38]) by mx.google.com with ESMTPSA id u10sm17328847wix.14.2014.07.30.23.31.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jul 2014 23:31:40 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Thu, 31 Jul 2014 08:31:38 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Craig Rodrigues Subject: Re: [CFT] Autofs. Message-ID: <20140731063138.GA12000@brick.home> Mail-Followup-To: Craig Rodrigues , freebsd-current Current , freebsd-arch References: <20140730071933.GA20122@pc5.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current Current , freebsd-arch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 06:31:43 -0000 On 0730T1851, Craig Rodrigues wrote: > On Wed, Jul 30, 2014 at 12:19 AM, Edward Tomasz NapieraÅ‚a > wrote: > > > At the link below you will find a patch that adds the new automounter. > > The patch is against yesterdays 11.0-CURRENT. > > > > http://people.freebsd.org/~trasz/autofs-head-20140729.diff > > > > > Hi, > > Nice stuff! I updated a current system, and tried the patch. > I put autofs_enable="YES" in /etc/rc.conf > > In my network, I have a system, testhost with some NFS exports. > > /dir1/export1 > /dir1/export2 > /dir1/export3 > > I did: > > cd /net/testhost > > This operation seemed to timeout. > In dmesg, I saw these errors: > > WARNING: autofs_callout: request 0 for /net/ timed out after 30 seconds > WARNING: autofs_trigger_one: request for /net/ completed with error 60 > autofs_trigger: trigger failed with error 60; will retry in 1 seconds, 2 > attempts left Here is how to debug it: kill automountd, and then start it like this: while :; do automountd -d; done This will make automountd print debug information to standard output, which should provide a clue on what's wrong. From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 07:41:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4299D65D; Thu, 31 Jul 2014 07:41:07 +0000 (UTC) Received: from mario.brtsvcs.net (mario.brtsvcs.net [IPv6:2607:fc50:0:a400::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 164762544; Thu, 31 Jul 2014 07:41:06 +0000 (UTC) Received: from chombo.houseloki.net (c-73-37-112-64.hsd1.or.comcast.net [73.37.112.64]) by mario.brtsvcs.net (Postfix) with ESMTPSA id F1B7A2C1630; Thu, 31 Jul 2014 00:40:57 -0700 (PDT) Received: from [IPv6:2601:7:2280:38b:baca:3aff:fe83:bd29] (unknown [IPv6:2601:7:2280:38b:baca:3aff:fe83:bd29]) by chombo.houseloki.net (Postfix) with ESMTPSA id 6F6DDD73; Thu, 31 Jul 2014 00:40:55 -0700 (PDT) Message-ID: <53D9F300.2010308@bluerosetech.com> Date: Thu, 31 Jul 2014 00:40:48 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <20140729101806.GB89995@FreeBSD.org> In-Reply-To: <20140729101806.GB89995@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Kristian K. Nielsen" , Franco Fichtner , freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 07:41:07 -0000 On 7/29/2014 3:18 AM, Gleb Smirnoff wrote: > Darren, > > On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote: > D> Never mistake silence for consent. > D> > D> The vast majority of people don't know pf is outdated and broken on > D> FreeBSD because they don't know what they're missing and likely aren't > D> using IPv6 yet. The moment you turn on IPv6 and restart a validating > D> unbound, you run full-speed into pf's broken behaviour. Make an > D> EDNS0-enabled query for a signed zone and you'll get a fragmented UDP > D> packet that will never make it through unless you tell pf to allow all > D> fragments unconditionally. They'll simply think something is wrong with > D> unbound, turn off EDNS0 and/or validation, hurt peformance and/or > D> security in the process, and never realize their firewall is doing > D> literally the worst possible thing it could do. > D> > D> All because over half a decade ago some folks got all butthurt over a > D> config file format change. > > Do I understand you right, that you propose a tens thousands lines of > untrivial code bulk update in order to fix a particular bug, that can be > nailed down separately? No. I believe pf should be removed from FreeBSD and efforts refocused on keeping ipfw up to date and feature complete. It makes more sense to look at what pf, ipf, nbtables, etc. are all doing as a source of ideas for what we can do with ipfw. A decade ago, there was justification for adding pf: at the time, ipfw lacked some major features. Ipfw has since caught up. I see no remaining value in having more than one packet filter in the base. Ipfw is more mature and less broken, so we should keep it and ditch the rest in the name of survival efficiency. > Do you also say that breaking configuration > files for a large number of people is okay if the update is expected > to fix a bug unrelated to configuration? Yes. Loss of configuration file backward compatibility is a fact of progress. Here are some examples of places where FreeBSD broke backward compatibility of a configuration file: - rc.conf (with every major version change) - resolv.conf - kernels - make.conf vs. src.conf - the ports collection - pkg vs. pkgng - pkgng changes within pkgng 1.x On top of that, we also have whole chunks of the OS where compatibility was broken (e.g., the toolchain, switch to unbound, etc.). > For me sounds like hunting a sparrow with a cannon. The whole thing, to me, was an example of lobbyist politics: a vocal minority had the resources and access to stop progress. Now we are all suffering for their ignorance and arrogance. If anything, we should rename pf to tppf (short for "Tea Party Packet Filter"). From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 08:15:42 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6045C1FB; Thu, 31 Jul 2014 08:15:42 +0000 (UTC) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E3254286D; Thu, 31 Jul 2014 08:15:41 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 11F8B25D3897; Thu, 31 Jul 2014 08:15:38 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 193A0C258A7; Thu, 31 Jul 2014 08:15:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ebGYssvR6AyY; Thu, 31 Jul 2014 08:15:36 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:c537:2f45:eabc:eba5] (unknown [IPv6:fde9:577b:c1a9:4410:c537:2f45:eabc:eba5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id C98B5C258A6; Thu, 31 Jul 2014 08:15:35 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: m4 still broken on gcc platforms Date: Thu, 31 Jul 2014 08:15:32 +0000 Message-Id: <1D4B336F-CCE0-4FD2-AE50-1C766D8990E2@lists.zabbadoz.net> To: freebsd-current@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Cc: Baptiste Daroussin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 08:15:42 -0000 Hi, I am still seeing this with arm/power/sparc/mips. Can somene please fix = it? =3D=3D=3D> usr.bin/m4/tests (all) cc1: warnings being treated as errors /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c: In function 'm4errx': /scratch/tmp/bz/head.svn/usr.bin/m4/misc.c:268: warning: declaration of = 'eval' shadows a global declaration /scratch/tmp/bz/head.svn/usr.bin/m4/extern.h:40: warning: shadowed = declaration is here --- misc.o --- *** [misc.o] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 cc1: warnings being treated as errors /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function = 'ohash_remove': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:123: warning: cast = discards qualifiers from pointer target type /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function = 'ohash_find': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:144: warning: cast = discards qualifiers from pointer target type /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c: In function = 'ohash_next': /scratch/tmp/bz/head.svn/usr.bin/m4/lib/ohash.c:183: warning: cast = discards qualifiers from pointer target type --- ohash.o --- *** [ohash.o] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin/m4 --- all_subdir_m4 --- *** [all_subdir_m4] Error code 1 bmake: stopped in /scratch/tmp/bz/head.svn/usr.bin =3D=3D=3D> usr.bin/mail (all) =97=20 Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983 From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 12:20:42 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A75AB5F for ; Thu, 31 Jul 2014 12:20:42 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 6AE9B247B for ; Thu, 31 Jul 2014 12:20:41 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by gateway1.nyi.internal (Postfix) with ESMTP id 1FE1D2114F for ; Thu, 31 Jul 2014 08:20:30 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 31 Jul 2014 08:20:30 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=jI7/psPp7RgNiKed66890B tj7So=; b=oxF8p+C+iAiN0xarkPol5e+CHBo/a1YZEGgf1YI4Y8/pVtyC2abzwL UsftR32AT5pYucXLGbbHTUWOZgPYrzzqvTdWxTgc67bNlAy+HOFm8eiWGT7UNWph mhUPGlc45wstf3wF3qI49ggx0Ud992BtnRBtiCcJ84sqx1DW0jAz8= X-Sasl-enc: 6DUKxZxMGpJzXwThFLDnM6rKfZJ1Lzro11KiWEsnPB+8 1406809229 Received: from [192.168.1.31] (unknown [203.206.138.26]) by mail.messagingengine.com (Postfix) with ESMTPA id 403CFC00005 for ; Thu, 31 Jul 2014 08:20:29 -0400 (EDT) Message-ID: <53DA3488.2050801@freebsd.org> Date: Thu, 31 Jul 2014 22:20:24 +1000 From: Darren Reed User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <201407291320.s6TDK5ZS005328@slippy.cwsent.com> <444fc5248aaa7d474cf9bde66f3d7f64@mailbox.ijs.si> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 12:20:42 -0000 On 30/07/2014 2:54 AM, Kevin Oberman wrote: > ... > I would hope that is not the case. While NAT66 is "well known" and has been > a topic of discussion for years, NPT66 is relatively new. It does share > many concepts with NAT66 (and, most likely implementations also share > code), but does not require any state, making it vastly less complex and no > longer breaks point to point networking. The names look similar, which may > result in unfortunate confusion, but NPT66 may be the bast solution to a > real problem and it does not create the issues of NAT66. NPT66 is a subset of NAT66. Cheers, Darren From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 12:02:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBBBA7D0; Thu, 31 Jul 2014 12:02:28 +0000 (UTC) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34120221A; Thu, 31 Jul 2014 12:02:28 +0000 (UTC) Received: from laptop3.herveybayaustralia.com.au (laptop3.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 34F4B27363; Thu, 31 Jul 2014 22:02:23 +1000 (EST) Message-ID: <53DA304E.6020105@herveybayaustralia.com.au> Date: Thu, 31 Jul 2014 22:02:22 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Gleb Smirnoff , "Mike." Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> <201407201230590265.00B479C4@smtp.24cl.home> <20140729103512.GC89995@FreeBSD.org> In-Reply-To: <20140729103512.GC89995@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 31 Jul 2014 12:43:30 +0000 Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 12:02:28 -0000 On 07/29/14 20:35, Gleb Smirnoff wrote: > On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: > M> |> imho, the root problem here is that an effort to implement a > M> single > M> |> feature improvement (multi-threading) has caused the FreeBSD > M> version > M> |> of pf to apparently reach a near-unmaintainable position in the > M> |> FreeBSD community because improvements from OpenBSD can no longer > M> be > M> |> ported over easily. FreeBSD's pf has been put in a virtual > M> |> isolation chamber due to the multi-threaded enhancement. > M> |> > M> |> Was it worth it? > M> | > M> |Yes. This happened *three times* in BSD land now. How much more > M> |proof does it take to make that clear? > M> |[snip] > M> > M> In this instance, more proof would consist of pf development not > M> wallowing in inactivity. > M> > M> imo, tactical changes were implemented in pf without the strategic > M> negative consequences affecting the decision process guiding the > M> implementation of those tactical features. And that's backwards. > M> Strategies direct tactics, not vice versa. > > I would strongly disagree with you. I would claim that directions > I've put in pf in 2012 are strategically correct, while previous > life of pf in FreeBSD was not. > > History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already > outdated. It isn't possible otherwise. While Max spent time on porting > some stable version, the OpenBSD moved forward. It was later updated > again by Max, and again right after update it was outdated. I mean > that people who a) believe that OpenBSD pf is the one true b) eager > for bleeding edge version, these people simply cannot be satisfied. > A porter needs to take latest stable version from OpenBSD and spend > some time working on it. So, pf in FreeBSD was always "outdated", > even before my SMP work on it. > Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. > In 2004 we've got 10 years of diverging developement between FreeBSD > and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in > 9.x is again outdated and introduces a number of bugs that were not > present in 8.x (regressions). Most regressions didn't came from OpenBSD, > but were artifacts of porting. Also, the number of #ifdefs in code > became so unbearable that no one would want to go through code > fixing bugs. > > In 2012 for me it was obvious that following this route is strategically > incorrect. You are never "up to date". You need more efforts to port > pf, and you yield in a port of worse and worse quality over time. > > So, in 2012 I put a lot of efforts to not only bring pf out of a > single mutex, but also make it more native to FreeBSD. You can > read this through commit logs. > > The net result is that we got our own pf, that can be maintained > further. Unfortunately, still no person is seen on horizon who can > take maintainership. > That explains it rather well. Thank you for the enlightenment on this. Without diminishing your efforts so far, what do you think about pitching all efforts into IPFW to combine effort and reduce overhead of maintaining separate firewalls in the core? Is there an advantage to having our own pf? From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 13:41:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3580F50; Thu, 31 Jul 2014 13:41:58 +0000 (UTC) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebius.int.ru", Issuer "cell.glebius.int.ru" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 74DFE20BB; Thu, 31 Jul 2014 13:41:57 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.9/8.14.9) with ESMTP id s6VDflZ7071560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Jul 2014 17:41:47 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.9/8.14.9/Submit) id s6VDflO1071559; Thu, 31 Jul 2014 17:41:47 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 31 Jul 2014 17:41:47 +0400 From: Gleb Smirnoff To: Da Rock Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140731134147.GH2402@glebius.int.ru> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> <201407201230590265.00B479C4@smtp.24cl.home> <20140729103512.GC89995@FreeBSD.org> <53DA304E.6020105@herveybayaustralia.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53DA304E.6020105@herveybayaustralia.com.au> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "Mike." , freebsd-current@freebsd.org, freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 13:41:59 -0000 On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: D> Without diminishing your efforts so far, what do you think about D> pitching all efforts into IPFW to combine effort and reduce overhead of D> maintaining separate firewalls in the core? Is there an advantage to D> having our own pf? Is there any disadvantage keeping it? It is a plugin. It is optional and loadable. I removed most additions to the network stack that live outside netpfil/pf. Some people like it and use it. It is also the only tool to configure ALTQ now. -- Totus tuus, Glebius. From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 14:21:03 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C9CECB2 for ; Thu, 31 Jul 2014 14:21:03 +0000 (UTC) Received: from heechee.tobez.org (heechee.tobez.org [IPv6:2001:2010:1::feef]) by mx1.freebsd.org (Postfix) with ESMTP id 12D7725B8 for ; Thu, 31 Jul 2014 14:21:02 +0000 (UTC) Received: by heechee.tobez.org (Postfix, from userid 1001) id 17BB645634; Thu, 31 Jul 2014 16:21:01 +0200 (CEST) Date: Thu, 31 Jul 2014 16:21:01 +0200 From: Anton Berezin To: freebsd-current@freebsd.org Subject: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction Message-ID: <20140731142100.GP92036@heechee.tobez.org> Mail-Followup-To: Anton Berezin , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 31 Jul 2014 15:48:42 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 14:21:03 -0000 Hi, Previously I ran CURRENT from some time in April without any problems. Symptoms: Consistently high LA (2.6 to 8.0) with all CPUs idle. At the console, depressing and holding a key does not lead to auto-repeat. At the console, sometimes a key only appears on the terminal after another key is pressed. In xorg, key auto-repeat sorta works, but visibly slower than active xset settings, and jerky as well. Moving mouse around helps. During reboot, when the kernel prints the number of dirty buffers periodically before shutting down, it "freezes" and does not print the next number until I press a key. So it takes multiple presses of "Shift" or "Control" before it actually boots. Nothing suspicious according to vmstat, vmstat -i, pcmstat, top, top -SH, top -m io. What I tried, by myself and because of various advices on IRC: - replacing sc with vt & disabling sc - removing atkbdc from kernel configuration - removing uart from kernel configuration - putting "off" for ttyu0 in /etc/ttys (it had "onifconsole") No luck. Verbose dmesg can be obtained from: http://www.tobez.org/download/dmesg.verbose.2014-07-31.txt Any thought? Thanks in advance, \Anton. -- Our society can survive even a large amount of irrational regulation. -- John McCarthy From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 15:56:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8E24EEF for ; Thu, 31 Jul 2014 15:56:28 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8128F2218 for ; Thu, 31 Jul 2014 15:56:28 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w62so3032410wes.1 for ; Thu, 31 Jul 2014 08:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=a2dE5ro5e15ydPK+0nllDTnv3jA012+wAONchAaCqNI=; b=ArLiCz48laRzSSIHefIz4TKD4NPJrUscgC31u6zaD+3xbZK+5K3+nXb2+LnMDr4qaD xhq7epVmVN9crGhxodDGY4LoHcxUED7FnFUl9kj0FhmVW2zCItjsM9KanaJVIHE8oN+v oSAJHwxOWrkSGp2RUcz+DzAHfYWeWo/6oCg84DDzhZx3XpwfvyOFoe88vdI/ggvJov3Q /Wdc8+QVmF4FoN1rfDJUQWzEcWWJSZCx+JOS+ndpTDcS788Wi7NMEvZt9ACvc6zAxAdZ ijvXDKwpGDNzynkZ2GjK/wp525JLND6AokQtq4+Y9NhibtIbk4Uxpw2F/5ZaHOacbDC4 4/VQ== X-Received: by 10.180.183.36 with SMTP id ej4mr17301181wic.77.1406822186288; Thu, 31 Jul 2014 08:56:26 -0700 (PDT) Received: from [192.168.178.122] (p5B36FD34.dip0.t-ipconnect.de. [91.54.253.52]) by mx.google.com with ESMTPSA id b9sm56027911wic.23.2014.07.31.08.56.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 08:56:25 -0700 (PDT) Message-ID: <53DA6727.7080702@gmail.com> Date: Thu, 31 Jul 2014 17:56:23 +0200 From: =?ISO-8859-1?Q?Jan_Kokem=FCller?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Anton Berezin , freebsd-current@freebsd.org Subject: Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction References: <20140731142100.GP92036@heechee.tobez.org> In-Reply-To: <20140731142100.GP92036@heechee.tobez.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 15:56:29 -0000 Hi, On 31.07.2014 16:21, Anton Berezin wrote: > At the console, depressing and holding a key does not lead to auto-repeat. > > At the console, sometimes a key only appears on the terminal after another > key is pressed. Maybe this is a problem caused by a misdetected clock source? I've had this problem as well. Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other settings that are listed in kern.timecounter.choice and kern.eventtimer.choice, such as HPET which works great for me. Cheers, Jan From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 16:22:28 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B22B6EFB for ; Thu, 31 Jul 2014 16:22:28 +0000 (UTC) Received: from heechee.tobez.org (heechee.tobez.org [IPv6:2001:2010:1::feef]) by mx1.freebsd.org (Postfix) with ESMTP id 75FAB267C for ; Thu, 31 Jul 2014 16:22:28 +0000 (UTC) Received: by heechee.tobez.org (Postfix, from userid 1001) id 4CF0545635; Thu, 31 Jul 2014 18:22:27 +0200 (CEST) Date: Thu, 31 Jul 2014 18:22:27 +0200 From: Anton Berezin To: Jan =?utf-8?Q?Kokem=C3=BCller?= Subject: Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction Message-ID: <20140731162227.GQ92036@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Jan =?utf-8?Q?Kokem=C3=BCller?= , freebsd-current@freebsd.org References: <20140731142100.GP92036@heechee.tobez.org> <53DA6727.7080702@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53DA6727.7080702@gmail.com> X-Powered-By: FreeBSD http://www.freebsd.org/ User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Thu, 31 Jul 2014 16:46:39 +0000 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 16:22:28 -0000 Jan, On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokemüller wrote: > On 31.07.2014 16:21, Anton Berezin wrote: > >At the console, depressing and holding a key does not lead to auto-repeat. > > > >At the console, sometimes a key only appears on the terminal after another > >key is pressed. > > Maybe this is a problem caused by a misdetected clock source? I've had this > problem as well. > > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to other > settings that are listed in kern.timecounter.choice and > kern.eventtimer.choice, such as HPET which works great for me. Setting both to HPET certainly helped the LA. I cannot check the keyboard input until tomorrow, but chances are that it is indeed the fix. Thanks a bunch! \Anton. -- Our society can survive even a large amount of irrational regulation. -- John McCarthy From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 17:47:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCFF37B1; Thu, 31 Jul 2014 17:47:32 +0000 (UTC) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BFCE20DB; Thu, 31 Jul 2014 17:47:32 +0000 (UTC) Received: by mail-qg0-f51.google.com with SMTP id a108so4403348qge.24 for ; Thu, 31 Jul 2014 10:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=4WCTctv1rV01g+nilN6EpaCze3S1FJT3D1Vu8Y1npfk=; b=cXNCJ34k7JJoVD2VpxNLGhhMkyXYQjczjE0cJcm66ePR7zHKeS3zaO5oz1R+WJUjgn cGD5a/UwL2x/4skmHSQFDHBFrwlXXDXf9PnRKQ1Ff+ed2wADcEi4zAEc5w0Nwn9X0pf/ UwFCawPagLJ4feJbQfJzE9ZCw3IwBf9/3Lvb8eRSYF5lyxewLQeu126rGh+rhaitSWip H4NsbArXOagaoGk31oQIfSC5zvo1w8axcEzu3FjohUqKNTMOEP3MRx+ATEpj+K6toCWw 4Ukec7mE8tOwHRZjbrwm6XSeDsgYRylorC9HFaDdzI1cw8AxcFhHbJt2laagJvvsTK3E EATw== MIME-Version: 1.0 X-Received: by 10.224.53.137 with SMTP id m9mr20893065qag.66.1406828851550; Thu, 31 Jul 2014 10:47:31 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.140.30.230 with HTTP; Thu, 31 Jul 2014 10:47:31 -0700 (PDT) In-Reply-To: References: <20140730071933.GA20122@pc5.home> Date: Thu, 31 Jul 2014 10:47:31 -0700 X-Google-Sender-Auth: YFjgXg5PZibWk2qN0V8JQn4-OfA Message-ID: Subject: Re: [CFT] Autofs. From: Craig Rodrigues To: freebsd-current Current , freebsd-arch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 17:47:32 -0000 On Wed, Jul 30, 2014 at 6:51 PM, Craig Rodrigues wrote: > On Wed, Jul 30, 2014 at 12:19 AM, Edward Tomasz Napiera=C5=82a < > trasz@freebsd.org> wrote: > >> At the link below you will find a patch that adds the new automounter. >> The patch is against yesterdays 11.0-CURRENT. >> >> http://people.freebsd.org/~trasz/autofs-head-20140729.diff >> >> > Hi, > > Nice stuff! I updated a current system, and tried the patch. > I put autofs_enable=3D"YES" in /etc/rc.conf > > In my network, I have a system, testhost with some NFS exports. > > /dir1/export1 > /dir1/export2 > /dir1/export3 > > I did: > > cd /net/testhost > > This operation seemed to timeout. > In dmesg, I saw these errors: > > WARNING: autofs_callout: request 0 for /net/ timed out after 30 seconds > WARNING: autofs_trigger_one: request for /net/ completed with error 60 > autofs_trigger: trigger failed with error 60; will retry in 1 seconds, = 2 > attempts left > WARNING: autofs_callout: request 1 for /net/ timed out after 30 seconds > WARNING: autofs_trigger_one: request for /net/ completed with error 60 > autofs_trigger: trigger failed with error 60; will retry in 1 seconds, = 1 > attempts left > WARNING: autofs_callout: request 2 for /net/ timed out after 30 seconds > WARNING: autofs_trigger_one: request for /net/ completed with error 60 > autofs_trigger: trigger failed 3 times; returning error 60 > > I used my Mac laptop in the same network, and did: > > cd /net/testhost > > and the command did not timeout, and I could do an ls and see that > /net/testhost/dir1/ was visible. > > Any ideas? > > This is cool stuff, and I hope you can get it into the 10.1 RELEASE. > > -- > Craig > > Hi, I cannot reproduce this problem at all. Now, when I do: cd /net/testhost it "just works", and I can access all the NFS exports. My previous problem might have been due to a temporary networking problem on my side. Yay! The only additional comment that I have for you is that the rc.conf variable is "autofs_enable", but the /etc/rc.d/ scripts are /etc/rc.d/automount and /etc/rc.d/automountd. It's not a big deal, but it would be nice if there was a single /etc/rc.d/autofs script to consolidate all this stuff, that would make it easier for admins to figure out where all the rc.d stuff related to autofs lives. Also, if your rc script introduced an autofs_flags (or automount_flags) variable, so that people could put the "-d" flag in there to enable more automount debugging, that would be nice. Other than that, I would say: Great work! I hope you can get this into 10.1-RELEASE! -- Craig From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 17:55:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB1C4AD0; Thu, 31 Jul 2014 17:55:25 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86B8F21AF; Thu, 31 Jul 2014 17:55:25 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j15so2690592qaq.15 for ; Thu, 31 Jul 2014 10:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nZ0EqS5LPUE2vIoVzuGuMjnhUqpiH+HWQ8tTDQHpKzA=; b=FZbvV+TgXpdR7KDTY9An35zbM8+sgNtvbwMW3vUmPdHKxH2wjQCBfkNccHWTlZfK8v 8KZegph+5gxLilM3HCNlRVpcy6656T45Ikd6pA3VvN0Xr3jnmqDOWUwkuGrl1buqKl8E Uy+OHD51agZ+x4PejojPO1Rpsmmdsovmc03ml4e1RbQz5nNygLogU9oV+UBeHMkIe1Bn +HIlQwT11oWX+GEJhWy8avF5P46/Lcp3nBU+Rk9R4e4NGy1qNW4zG6TB5/F2OGIo1Jqc 5iKci6SkR8SXjhog+YmjsCCzZn6D8Ci+kALeExfcVud4+3T+JxqiHd6S2yD/7fJ410Hv 1PwQ== MIME-Version: 1.0 X-Received: by 10.140.25.226 with SMTP id 89mr19975758qgt.62.1406829323617; Thu, 31 Jul 2014 10:55:23 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.140.30.230 with HTTP; Thu, 31 Jul 2014 10:55:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 10:55:23 -0700 X-Google-Sender-Auth: usdsVOxtgryj6VuzH_XA9rzayHE Message-ID: Subject: Re: BAFUG July 10: libvirt virtualization API for controlling bhyve virtual machines From: Craig Rodrigues To: "freebsd-virtualization@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-current Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 17:55:26 -0000 Hi, Thanks to Cao Pham at iXsystems, video for this presentation has been posted online: https://www.youtube.com/watch?v=LRLV_SZo6Sw -- Craig On Mon, Jun 30, 2014 at 5:30 PM, Craig Rodrigues wrote: > Hi, > > On July 10, 2014, in Mountain View, California, I will be giving a brief > tech talk on: > > "libvirt virtualization API for controlling bhyve virtual machines" > > I have been testing the extensions that Roman Bogorodskiy < > novel@freebsd.org> > has made to the lbivirt library for supporting bhyve. I will talk about > my experiences with libvirt and bhyve. > > Here are more details about the talk plus directions to the location: > > http://www.meetup.com/BAFUG-Bay-Area-FreeBSD-User-Group/events/191061222/ > > Feel free to sign up on the meetup site and attend if you are in the area! > -- > Craig > From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 18:12:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCF02290; Thu, 31 Jul 2014 18:12:02 +0000 (UTC) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E660248B; Thu, 31 Jul 2014 18:12:02 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id q107so4369630qgd.0 for ; Thu, 31 Jul 2014 11:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=ul6w8cIWxKTnk6zaUXbdpEYlDiQI8C1RW3p6OxiCtPw=; b=jkUIkTl/PuGKhGYBK8v3YrF8yxXAah+VUTi4vKjYD/59VrQvNI2CV0uG+igkLjm9jl lB6TsCu1aH/ZAFWsUbCMQdb4L/p9M3rAeiTWRmXc4jLsC3KhvKEKgojowYcOfN35Bz+7 Nr3QIX9QLJ/OqdIRrQiSHkQH8RdZP2HnpMVRXkWM1VCzoz9S9pwsmtghcRuu0O06WUNj g1blphJpwFYUR/J1eJFkKo3SGByls3ZQui28jYzjOJ19/sHytP9JkEcqVd7yDjYVM5o6 Di3Hnh+UltnadoaMqwNEdYb0WMf6gvilCkSKboQ9o7oT+0J1PHme8DuOTtHqr5u71SIX IDYg== MIME-Version: 1.0 X-Received: by 10.140.26.110 with SMTP id 101mr19963710qgu.1.1406830320710; Thu, 31 Jul 2014 11:12:00 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.140.30.230 with HTTP; Thu, 31 Jul 2014 11:12:00 -0700 (PDT) Date: Thu, 31 Jul 2014 11:12:00 -0700 X-Google-Sender-Auth: C3ZRdrQ7vnT5j506Og4ixpxfEV0 Message-ID: Subject: [Video] Upcoming RSS enhancements to the FreeBSD Network Stack From: Craig Rodrigues To: freebsd-net@freebsd.org, freebsd-current Current Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 18:12:02 -0000 Hi, On July 10, at the Bay Area FreeBSD Users Group ( http://bafug.org ), Adrian Chadd gave a very nice talk: "Upcoming RSS enhancements to the FreeBSD Network Stack" https://www.youtube.com/watch?v=7CvIztTz-RQ Thanks to Adrian for doing the work and giving the talk! Thanks to Cao Pham for recording the video and posting it online! -- Craig From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 18:30:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2FCC3710 for ; Thu, 31 Jul 2014 18:30:56 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C5EAA25C2 for ; Thu, 31 Jul 2014 18:30:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8EAB2K2lODaFve/2dsb2JhbABbhDuCdLBal1CHWoEjd4QtgQsCDRkCX4hVokmPKJdlF4EsjWyDNIFRBbA3g2UhgXQ X-IronPort-AV: E=Sophos;i="5.01,773,1400040000"; d="scan'208";a="144646161" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 31 Jul 2014 14:30:54 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2EA24B402B for ; Thu, 31 Jul 2014 14:30:54 -0400 (EDT) Date: Thu, 31 Jul 2014 14:30:54 -0400 (EDT) From: Rick Macklem To: freebsd-current Current Message-ID: <1021165841.5947380.1406831454174.JavaMail.root@uoguelph.ca> Subject: MFC of NFSv4.1 server code? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 18:30:56 -0000 Hi, There has been little comment w.r.t. the NFSv4.1 server code I dropped into head a month ago. It changes the internal interfaces between the NFS related kernel modules, but I do not believe that these would be considered KPIs. I`d like to MFC it to stable10 for 10.1. Does anyone have a strong opinion on this. Thanks in advance for any comments, rick From owner-freebsd-current@FreeBSD.ORG Thu Jul 31 20:56:37 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B5F58D2 for ; Thu, 31 Jul 2014 20:56:37 +0000 (UTC) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 29EFD26B6 for ; Thu, 31 Jul 2014 20:56:36 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1XCxOt-0002Rb-Dh for freebsd-current@freebsd.org; Thu, 31 Jul 2014 13:56:35 -0700 Date: Thu, 31 Jul 2014 13:56:35 -0700 (PDT) From: Beeblebrox To: freebsd-current@freebsd.org Message-ID: <20140731235539.70284a6c@rsbsd.rsb> In-Reply-To: References: <1406282699515-5931653.post@n5.nabble.com> Subject: Re: Several minor annoyances on Current MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 31 Jul 2014 20:56:37 -0000 > hm, I have similar experience with 10-stable see > http://lists.freebsd.org/pipermail/freebsd-questions/2014-July/259067.html Thankfully, my boot time is not so severe. I have no ideas to help however. * preventing coredump files: setting in ~/.cshrc below does not work. What is the correct syntax? ulimit -c 0 setenv ulimit -c 0 * What is the error below? Could this output hold clues to finding deeper errors? This occurred during an install requiring opengl, but could Radeon-KMS be a contributing cause? Not running in a graphics capable console, and unable to find one. svgalib: ark: Unknown chiptype 29. Not running in a graphics capable console, and unable to find one. Not running in a graphics capable console, and unable to find one. *** Error code 1 ----- FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Several-minor-annoyances-on-Current-tp5931653p5933755.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 07:39:12 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3FE360D; Fri, 1 Aug 2014 07:39:12 +0000 (UTC) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 755B625A3; Fri, 1 Aug 2014 07:39:12 +0000 (UTC) Received: by mail-yk0-f175.google.com with SMTP id q200so2227254ykb.6 for ; Fri, 01 Aug 2014 00:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JXYzz+rAzTjStTfz9EOffugXH0LOQhzSVicI0sOoF0E=; b=HrI0XN8mRFqm03Cjwy/Iv+aR7HOxd3DC9eFBwdU9Hb4z79+Q1C1WfbZy03T6gFyDyI OmEcf8S3o5RZhPMfbUMpkEAFlCYMOVGDaBTsjXZ1aBd531xNkrDatIzKBMOH1HGOHovo al3LstRVo/bxQxq+hZu6w2Q+5nMOv2K9rbJzC9s9bdYPbKArFDtthVKpL9Kd/J81a1Pe hCaWugbksU04Xj3zB+3IczP+ZSevkEGrF3b0BthIQo4GjBZQiqaUMQmmMTtsfYwnTIwC MrKHnnXOnl6o/RMVn0H81dPtopf+JEf7fxQ0abUc+W3FiLjG0iThOnlHA9BIC68V6gGk 7Vaw== MIME-Version: 1.0 X-Received: by 10.236.85.208 with SMTP id u56mr5673462yhe.48.1406878751382; Fri, 01 Aug 2014 00:39:11 -0700 (PDT) Received: by 10.170.132.80 with HTTP; Fri, 1 Aug 2014 00:39:11 -0700 (PDT) In-Reply-To: <20140731134147.GH2402@glebius.int.ru> References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> <201407201230590265.00B479C4@smtp.24cl.home> <20140729103512.GC89995@FreeBSD.org> <53DA304E.6020105@herveybayaustralia.com.au> <20140731134147.GH2402@glebius.int.ru> Date: Fri, 1 Aug 2014 08:39:11 +0100 Message-ID: Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? From: krad To: Gleb Smirnoff X-Mailman-Approved-At: Fri, 01 Aug 2014 11:39:40 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: freebsd-current@freebsd.org, FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 07:39:12 -0000 I always found natting in ipfw rather awkward and harder than in pf. Looking at the man page it doesnt seem to have changed. I should probably give it another go though as it has been about 10 years now On 31 July 2014 14:41, Gleb Smirnoff wrote: > On Thu, Jul 31, 2014 at 10:02:22PM +1000, Da Rock wrote: > D> Without diminishing your efforts so far, what do you think about > D> pitching all efforts into IPFW to combine effort and reduce overhead of > D> maintaining separate firewalls in the core? Is there an advantage to > D> having our own pf? > > Is there any disadvantage keeping it? It is a plugin. It is optional > and loadable. I removed most additions to the network stack that live > outside netpfil/pf. > > Some people like it and use it. > > It is also the only tool to configure ALTQ now. > > -- > Totus tuus, Glebius. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 10:43:39 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4469F7EA for ; Fri, 1 Aug 2014 10:43:39 +0000 (UTC) Received: from smtpbgie1.qq.com (ec2-54-194-6-37.eu-west-1.compute.amazonaws.com [54.194.6.37]) (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 424E82A86 for ; Fri, 1 Aug 2014 10:43:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201307; t=1406889795; bh=H/Qs3Rqcgd0DSVUofZYClKjzLTPSBXnBzYZuDfkplFg=; h=X-QQ-FEAT:X-QQ-SSF:X-QQ-WAPMAIL:X-QQ-BUSINESS-ORIGIN: X-Originating-IP:References:X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Date: X-Priority:Message-ID:X-QQ-MIME:X-Mailer:X-QQ-Mailer: X-QQ-ReplyHash:X-QQ-SENDSIZE; b=rZkuZhzRjOglomggampaiyqCIpv1JDVGeNGez5Rd1um/4jWJitRUL/cgniuvBIk0U SVBrxcZv0ZFhql/LrrvGXPguXP6X5cUu1ZvCfN/3dQFfLnv+iWLMTnFofbpTGc8E2M oLvkJ3mida+0Y8TDENMWrSdf7FRLDlgKVJk0aSbE= X-QQ-FEAT: VaTxXibkloqmajrSsAVfUtg2wLVteTrHDrEkDXKM1djj/OC4MlAnhhJnl6aJX qWPzD3Tcx54Dy4ZeB5k5fLWt3LNKCStJYCjd+dEw61+ROJoUHGWhXNoeqlB1h7207xw+DSD qPnnh2bw7992QzF4BGNWOvegXmQ+3ncsTH7YDH9FUf5GWI4q4KDm506Jy3Ug X-QQ-SSF: 0000000000000000 X-QQ-WAPMAIL: 1 X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 218.201.214.164 References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> <201407201230590265.00B479C4@smtp.24cl.home> <20140729103512.GC89995@FreeBSD.org> <53DA304E.6020105@herveybayaustralia.com.au> <20140731134147.GH2402@glebius.int.ru> X-QQ-STYLE: X-QQ-mid: wapmail79t1406889793t276842 From: "=?gb18030?B?MjgwMjcxNzg0Mg==?=" <2802717842@qq.com> To: "=?gb18030?B?a3JhZHVr?=" , "=?gb18030?B?Z2xlYml1cw==?=" Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Mime-Version: 1.0 Date: Fri, 1 Aug 2014 18:43:13 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-ReplyHash: 408811189 X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 X-Mailman-Approved-At: Fri, 01 Aug 2014 11:40:00 +0000 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: =?gb18030?B?ZnJlZWJzZC1jdXJyZW50?= , =?gb18030?B?ZnJlZWJzZC1xdWVzdGlvbnM=?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 10:43:39 -0000 wLTQxcrVtb2jrNC70LujoSANCi0tLdStyrzTyrz+LS0tDQpGcm9tOiJrcmFkIjxrcmFkdWtA Z21haWwuY29tPjsNCkRhdGU6MjAxNMTqONTCMcjVKNDHxtrO5Skgz8LO5zM6MzkNClRvOiJH bGViIFNtaXJub2ZmIjxnbGViaXVzQGZyZWVic2Qub3JnPjsNCkNjOiJmcmVlYnNkLWN1cnJl bnQiPGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZz47IkZyZWVCU0QgUXVlc3Rpb25zIjxm cmVlYnNkLXF1ZXN0aW9uc0BmcmVlYnNkLm9yZz47DQpTdWJqZWN0OlJlOiBGdXR1cmUgb2Yg cGYgLyBmaXJld2FsbCBpbiBGcmVlQlNEID8gLSBkb2VzIGl0IGhhdmUgb25lID8NCg0KSSBh bHdheXMgZm91bmQgbmF0dGluZyBpbiBpcGZ3IHJhdGhlciBhd2t3YXJkIGFuZCBoYXJkZXIg dGhhbiBpbiBwZi4NCkxvb2tpbmcgYXQgdGhlIG1hbiBwYWdlIGl0IGRvZXNudCBzZWVtIHRv IGhhdmUgY2hhbmdlZC4gSSBzaG91bGQgcHJvYmFibHkNCmdpdmUgaXQgYW5vdGhlciBnbyB0 aG91Z2ggYXMgaXQgaGFzIGJlZW4gYWJvdXQgMTAgeWVhcnMgbm93DQoNCg0KT24gMzEgSnVs eSAyMDE0IDE0OjQxLCBHbGViIFNtaXJub2ZmIDxnbGViaXVzQGZyZWVic2Qub3JnPiB3cm90 ZToNCg0KPiBPbiBUaHUsIEp1bCAzMSwgMjAxNCBhdCAxMDowMjoyMlBNICsxMDAwLCBEYSBS b2NrIHdyb3RlOg0KPiBEPiBXaXRob3V0IGRpbWluaXNoaW5nIHlvdXIgZWZmb3J0cyBzbyBm YXIsIHdoYXQgZG8geW91IHRoaW5rIGFib3V0DQo+IEQ+IHBpdGNoaW5nIGFsbCBlZmZvcnRz IGludG8gSVBGVyB0byBjb21iaW5lIGVmZm9ydCBhbmQgcmVkdWNlIG92ZXJoZWFkIG9mDQo+ IEQ+IG1haW50YWluaW5nIHNlcGFyYXRlIGZpcmV3YWxscyBpbiB0aGUgY29yZT8gSXMgdGhl cmUgYW4gYWR2YW50YWdlIHRvDQo+IEQ+IGhhdmluZyBvdXIgb3duIHBmPw0KPg0KPiBJcyB0 aGVyZSBhbnkgZGlzYWR2YW50YWdlIGtlZXBpbmcgaXQ/IEl0IGlzIGEgcGx1Z2luLiBJdCBp cyBvcHRpb25hbA0KPiBhbmQgbG9hZGFibGUuIEkgcmVtb3ZlZCBtb3N0IGFkZGl0aW9ucyB0 byB0aGUgbmV0d29yayBzdGFjayB0aGF0IGxpdmUNCj4gb3V0c2lkZSBuZXRwZmlsL3BmLg0K Pg0KPiBTb21lIHBlb3BsZSBsaWtlIGl0IGFuZCB1c2UgaXQuDQo+DQo+IEl0IGlzIGFsc28g dGhlIG9ubHkgdG9vbCB0byBjb25maWd1cmUgQUxUUSBub3cuDQo+DQo+IC0tDQo+IFRvdHVz IHR1dXMsIEdsZWJpdXMuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGZyZWVic2QtcXVlc3Rpb25zQGZyZWVic2Qub3JnIG1haWxpbmcg bGlzdA0KPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVl YnNkLXF1ZXN0aW9ucw0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiDQo+ IGZyZWVic2QtcXVlc3Rpb25zLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0KPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmZyZWVic2QtcXVl c3Rpb25zQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qu b3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1xdWVzdGlvbnMNClRvIHVuc3Vic2NyaWJl LCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLXF1ZXN0aW9ucy11bnN1YnNjcmliZUBmcmVl YnNkLm9yZyI= From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 10:43:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8AEA7F9 for ; Fri, 1 Aug 2014 10:43:49 +0000 (UTC) Received: from smtpbgbr1.qq.com (smtpbgbr1.qq.com [54.207.19.206]) (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 D6EEA2A8B for ; Fri, 1 Aug 2014 10:43:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201307; t=1406889806; bh=slHNgOghDZkiwEWLGqubBVhw440dVFzuT7OtbiG18XM=; h=X-QQ-FEAT:X-QQ-SSF:X-QQ-WAPMAIL:X-QQ-BUSINESS-ORIGIN: X-Originating-IP:References:X-QQ-STYLE:X-QQ-mid:From:To:Cc:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Date: X-Priority:Message-ID:X-QQ-MIME:X-Mailer:X-QQ-Mailer: X-QQ-ReplyHash:X-QQ-SENDSIZE; b=idUJ3sCoZjaCBhM7cwS010f28lEbq9qOjqub5KvNTIpjUlgWCW35QP3L+uK2IRh1b irgtgenWIaGtn+JyHsrdPzk/skFfq0P6aRzXE51L8ERqlhUg0UWJwryAlyXzkd8eYe JBgP1LIxpq7z3mxvGSZAUjdJlGsJXUpLzKmAs7dM= X-QQ-FEAT: 3wpCNwMhQw2vsOv4d0cu2pFL//psympU8JpFM0We1awEmuP2jGd9NUxHAeQnd IbKip8W53nNxsIZ7izR1L+PY6KkHzCHbc/4VBe93k0eHlaRjQwR0EelSdnC39IeKODZ1WKd qoIXoIuT3e7TegrWYXcEjTnEgsqCA6Ha5yE89RWYbNs0zfGF8wLb2A9/y70J X-QQ-SSF: 0000000000000000 X-QQ-WAPMAIL: 1 X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 218.201.214.164 References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> <201407201230590265.00B479C4@smtp.24cl.home> <20140729103512.GC89995@FreeBSD.org> <53DA304E.6020105@herveybayaustralia.com.au> <20140731134147.GH2402@glebius.int.ru> X-QQ-STYLE: X-QQ-mid: wapmail79t1406889805t348182 From: "=?gb18030?B?MjgwMjcxNzg0Mg==?=" <2802717842@qq.com> To: "=?gb18030?B?a3JhZHVr?=" , "=?gb18030?B?Z2xlYml1cw==?=" Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Mime-Version: 1.0 Date: Fri, 1 Aug 2014 18:43:25 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-ReplyHash: 408811189 X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 X-Mailman-Approved-At: Fri, 01 Aug 2014 11:45:38 +0000 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: =?gb18030?B?ZnJlZWJzZC1jdXJyZW50?= , =?gb18030?B?ZnJlZWJzZC1xdWVzdGlvbnM=?= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 10:43:50 -0000 wLTQxcrVtb2jrNC70LujoSANCi0tLdStyrzTyrz+LS0tDQpGcm9tOiJrcmFkIjxrcmFkdWtA Z21haWwuY29tPjsNCkRhdGU6MjAxNMTqONTCMcjVKNDHxtrO5Skgz8LO5zM6MzkNClRvOiJH bGViIFNtaXJub2ZmIjxnbGViaXVzQGZyZWVic2Qub3JnPjsNCkNjOiJmcmVlYnNkLWN1cnJl bnQiPGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZz47IkZyZWVCU0QgUXVlc3Rpb25zIjxm cmVlYnNkLXF1ZXN0aW9uc0BmcmVlYnNkLm9yZz47DQpTdWJqZWN0OlJlOiBGdXR1cmUgb2Yg cGYgLyBmaXJld2FsbCBpbiBGcmVlQlNEID8gLSBkb2VzIGl0IGhhdmUgb25lID8NCg0KSSBh bHdheXMgZm91bmQgbmF0dGluZyBpbiBpcGZ3IHJhdGhlciBhd2t3YXJkIGFuZCBoYXJkZXIg dGhhbiBpbiBwZi4NCkxvb2tpbmcgYXQgdGhlIG1hbiBwYWdlIGl0IGRvZXNudCBzZWVtIHRv IGhhdmUgY2hhbmdlZC4gSSBzaG91bGQgcHJvYmFibHkNCmdpdmUgaXQgYW5vdGhlciBnbyB0 aG91Z2ggYXMgaXQgaGFzIGJlZW4gYWJvdXQgMTAgeWVhcnMgbm93DQoNCg0KT24gMzEgSnVs eSAyMDE0IDE0OjQxLCBHbGViIFNtaXJub2ZmIDxnbGViaXVzQGZyZWVic2Qub3JnPiB3cm90 ZToNCg0KPiBPbiBUaHUsIEp1bCAzMSwgMjAxNCBhdCAxMDowMjoyMlBNICsxMDAwLCBEYSBS b2NrIHdyb3RlOg0KPiBEPiBXaXRob3V0IGRpbWluaXNoaW5nIHlvdXIgZWZmb3J0cyBzbyBm YXIsIHdoYXQgZG8geW91IHRoaW5rIGFib3V0DQo+IEQ+IHBpdGNoaW5nIGFsbCBlZmZvcnRz IGludG8gSVBGVyB0byBjb21iaW5lIGVmZm9ydCBhbmQgcmVkdWNlIG92ZXJoZWFkIG9mDQo+ IEQ+IG1haW50YWluaW5nIHNlcGFyYXRlIGZpcmV3YWxscyBpbiB0aGUgY29yZT8gSXMgdGhl cmUgYW4gYWR2YW50YWdlIHRvDQo+IEQ+IGhhdmluZyBvdXIgb3duIHBmPw0KPg0KPiBJcyB0 aGVyZSBhbnkgZGlzYWR2YW50YWdlIGtlZXBpbmcgaXQ/IEl0IGlzIGEgcGx1Z2luLiBJdCBp cyBvcHRpb25hbA0KPiBhbmQgbG9hZGFibGUuIEkgcmVtb3ZlZCBtb3N0IGFkZGl0aW9ucyB0 byB0aGUgbmV0d29yayBzdGFjayB0aGF0IGxpdmUNCj4gb3V0c2lkZSBuZXRwZmlsL3BmLg0K Pg0KPiBTb21lIHBlb3BsZSBsaWtlIGl0IGFuZCB1c2UgaXQuDQo+DQo+IEl0IGlzIGFsc28g dGhlIG9ubHkgdG9vbCB0byBjb25maWd1cmUgQUxUUSBub3cuDQo+DQo+IC0tDQo+IFRvdHVz IHR1dXMsIEdsZWJpdXMuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGZyZWVic2QtcXVlc3Rpb25zQGZyZWVic2Qub3JnIG1haWxpbmcg bGlzdA0KPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVl YnNkLXF1ZXN0aW9ucw0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiDQo+ IGZyZWVic2QtcXVlc3Rpb25zLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0KPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmZyZWVic2QtcXVl c3Rpb25zQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qu b3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1xdWVzdGlvbnMNClRvIHVuc3Vic2NyaWJl LCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLXF1ZXN0aW9ucy11bnN1YnNjcmliZUBmcmVl YnNkLm9yZyI= From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 12:46:21 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 477FDB51; Fri, 1 Aug 2014 12:46:21 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.feld.me", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D7A932968; Fri, 1 Aug 2014 12:46:20 +0000 (UTC) Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 1f9a8358; Fri, 1 Aug 2014 07:46:09 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=feld.me; h=mime-version :date:content-type:content-transfer-encoding:message-id:from :subject:to:cc:in-reply-to:references:sender; s=blargle2; bh=Gk6 Jx9A5ErnVDFRd6ea8rYnhe/g=; b=ySRLoGJIvsreI7Cud7NK/EbVUF+8SnDjs/D XuydgoJAVNXlN/aB+bCtZvyI5+JP3x1jKcVf8GIoTvlo0KXDTftwz3wNxlJsMKX5 3KCL+EOtpE26KBlu6ZG1AvzMbnSzhkjAJ7OnupZ+GsrxOvgpweKRQIRiojkqxyii dYKyhlg+8uAWhOopI07sE2xFMw2epczdxe4BVAsXI1vCk/J338LbNpyFy0iKr9VQ 2aJW7RasEAXf3IWfILfuEqa9CgRCPpF8/tle6vylFW+qyiEORf49Jjrs8Y4irzgQ uWat83i90y1CzxKE9ri1vLKxGnCCA73HP0ejeVOv/GOJISiB8dQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=feld.me; h=mime-version:date :content-type:content-transfer-encoding:message-id:from:subject :to:cc:in-reply-to:references:sender; q=dns; s=blargle2; b=MnCrL 47E4fVxC9S+I9wEtLMuAtZLiGdomMdBfWp1NYXlY9iy/qBuYJ4KJzJmz/+kIA94C Uw82b+odsA/CXY42PUmWw5IttvLJA30cpjUWq6qYKGNxSzWCsK5wWdhYjYiH81m9 GbKFt7A2wQt03FDux/xY6BpVyuzsJU3W9F6e71GyIBwRPWOGdng548p1sTnECDrZ HAKifrg6laxXFiq/s/oFBLl8etao4DypJlmzXEdounsf6LPGMSfvoq6zPgHody3v F0E5VVIGwLMfhGyNivf91k7kwtGTHy6xSodMaeabPYYt2q1VKso0W8cB7zxs9b4j BR7X6JwjvB8yALgow== Received: from mail.feld.me (mail.feld.me [66.170.3.6]); by mail.feld.me (OpenSMTPD) with ESMTP id 2566f43c; Fri, 1 Aug 2014 07:46:09 -0500 (CDT) Received: from feld@feld.me by mail.feld.me (Archiveopteryx 3.2.0) with esmtpa id 1406897168-26244-26241/5/9; Fri, 1 Aug 2014 12:46:08 +0000 Mime-Version: 1.0 Date: Fri, 1 Aug 2014 12:46:08 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <74dec781e44c3a81c78e9c4ff1d51c2a@mail.feld.me> X-Mailer: RainLoop/1.6.8.151 From: Mark Felder Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? To: Darren Pilgrim , Gleb Smirnoff In-Reply-To: <53D9F300.2010308@bluerosetech.com> References: <53D9F300.2010308@bluerosetech.com> <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <20140729101806.GB89995@FreeBSD.org> Sender: feld@feld.me Cc: freebsd-current@freebsd.org, freebsd-questions@FreeBSD.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 12:46:21 -0000 July 31 2014 2:41 AM, "Darren Pilgrim" wrote: >> >> No. I believe pf should be removed from FreeBSD and efforts refocused >> on keeping ipfw up to date and feature complete. It makes more sense = to >> look at what pf, ipf, nbtables, etc. are all doing as a source of = ideas >> for what we can do with ipfw. A decade ago, there was justification = for >> adding pf: at the time, ipfw lacked some major features. >> >> Ipfw has since caught up. I see no remaining value in having more than >> one packet filter in the base. Ipfw is more mature and less broken, so >> we should keep it and ditch the rest in the name of survival efficienc= y. >> pf is not simply replaceable in many environments. For example, people = use it specifically for its integration with the spamd greylisting = daemon. I think it's reasonable to assume they did so because the whole = spam filtering stack performs better on FreeBSD than on OpenBSD. This = was just recently mentioned on twitter: @ng_security Why was the pf ioctl needed buffer reduced in FreeBSD 10? I'm not able = to load my full spamd blacklist anymore. @freebsd #spamd #pf https://twitter.com/ng_security/status/494982307905040384 I personally use pf for many reasons, spamd included. I don't think = anyone out there is interested in forking spamd to play ball with ipfw = so we would also be alienating these users who can't just change packet = filters. Is there even an equivalent to pfsync for ipfw? I didn't think = so, but I could be wrong...=20 In the world of firewalls pf has been put on a quite a pedestal. OpenBSD = pushed it hard and it marketed it well; people found it both powerful = and easy to use which created a cult following and lots of word of mouth = advertising. I find it hard to agree with removing pf from FreeBSD = because of the existing userbase. If there was an experimental label on = it I would find its removal easier to swallow. I think it's worth pointing out that nobody really wanted to maintain an = incompatible fork of ZFS indefinitely either; it would be a monumental = if not suicidal task. And who wants to deal with the bad PR about = FreeBSD being years behind Illumos features or, *gasp*, even letting a = native Linux implementation one-up us? People found a way to collaborate,= OpenZFS movement was founded, and this is a mostly solved problem, OS = nuances aside. I can appreciate that people seem to care more about = their data than their packet filters and FreeBSD ZFS certainly moves a = lot of servers and appliances furthering the userbase whether or not = they're using FreeBSD or TrueOS or some other derivative. Let's continue = to give people another reason to put FreeBSD in their datacenters. Let's = try to compete in the firewall/packet filter space too. On a side note I'd also like to point out that FreeBSD has been advertisi= ng pf by listing it first in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html I'm sure there's a subliminal message being sent there, intentional or = not. I don't want to see FreeBSD lose mindshare from its absence in a time = where FreeBSD uptake seems to be rising thanks in part to bad decisions = in the GNU/Linux camp. This feels like a solvable problem if funding and = enthusiasm is put behind it. OpenBSD really sounds willing to collaborate= if not just because they're tired of seeing neglected forks of one of = their prized babies: FreeBSD, NetBSD, DragonFlyBSD, OSX, iOS... From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 13:04:07 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D12E3CF; Fri, 1 Aug 2014 13:04:07 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (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 C08022B64; Fri, 1 Aug 2014 13:04:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s71D3tUO035321; Fri, 1 Aug 2014 23:03:56 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 1 Aug 2014 23:03:55 +1000 (EST) From: Ian Smith To: Da Rock Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? In-Reply-To: Message-ID: <20140801215415.G62404@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Fri, 01 Aug 2014 13:29:57 +0000 Cc: "Mike." , freebsd-current@freebsd.org, Gleb Smirnoff , freebsd-questions@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 13:04:07 -0000 In freebsd-questions Digest, Vol 530, Issue 5, Message: 1 On Thu, 31 Jul 2014 22:02:22 +1000 Da Rock wrote: > On 07/29/14 20:35, Gleb Smirnoff wrote: > > On Sun, Jul 20, 2014 at 12:30:59PM -0400, Mike. wrote: > > M> |> imho, the root problem here is that an effort to implement a > > M> single > > M> |> feature improvement (multi-threading) has caused the FreeBSD > > M> version > > M> |> of pf to apparently reach a near-unmaintainable position in the > > M> |> FreeBSD community because improvements from OpenBSD can no longer > > M> be > > M> |> ported over easily. FreeBSD's pf has been put in a virtual > > M> |> isolation chamber due to the multi-threaded enhancement. > > M> |> > > M> |> Was it worth it? > > M> | > > M> |Yes. This happened *three times* in BSD land now. How much more > > M> |proof does it take to make that clear? > > M> |[snip] > > M> > > M> In this instance, more proof would consist of pf development not > > M> wallowing in inactivity. > > M> > > M> imo, tactical changes were implemented in pf without the strategic > > M> negative consequences affecting the decision process guiding the > > M> implementation of those tactical features. And that's backwards. > > M> Strategies direct tactics, not vice versa. > > > > I would strongly disagree with you. I would claim that directions > > I've put in pf in 2012 are strategically correct, while previous > > life of pf in FreeBSD was not. > > > > History: pf appeared in FreeBSD in 2004 in 5.3-RELEASE. It was already > > outdated. It isn't possible otherwise. While Max spent time on porting > > some stable version, the OpenBSD moved forward. It was later updated > > again by Max, and again right after update it was outdated. I mean > > that people who a) believe that OpenBSD pf is the one true b) eager > > for bleeding edge version, these people simply cannot be satisfied. > > A porter needs to take latest stable version from OpenBSD and spend > > some time working on it. So, pf in FreeBSD was always "outdated", > > even before my SMP work on it. > > Further history: in 2012 Ermal updates pf and 9.0-RELEASE is shipped. > > In 2004 we've got 10 years of diverging developement between FreeBSD > > and OpenBSD. In 2012 it was 18 years. Porting got harder. The pf in > > 9.x is again outdated and introduces a number of bugs that were not > > present in 8.x (regressions). Most regressions didn't came from OpenBSD, > > but were artifacts of porting. Also, the number of #ifdefs in code > > became so unbearable that no one would want to go through code > > fixing bugs. > > > > In 2012 for me it was obvious that following this route is strategically > > incorrect. You are never "up to date". You need more efforts to port > > pf, and you yield in a port of worse and worse quality over time. > > > > So, in 2012 I put a lot of efforts to not only bring pf out of a > > single mutex, but also make it more native to FreeBSD. You can > > read this through commit logs. > > > > The net result is that we got our own pf, that can be maintained > > further. Unfortunately, still no person is seen on horizon who can > > take maintainership. > > That explains it rather well. Thank you for the enlightenment on this. Indeed. This potted history covers a lot of ground, and work, to most of which I've been largely oblivious. I've used ipfw since '98; it well suited my assembler background and perhaps overly orthogonal tendencies, and I found dummynet hugely useful for herding small networks of unruly cats, so I've felt no need to explore pf, nor ipfilter. > Without diminishing your efforts so far, what do you think about > pitching all efforts into IPFW to combine effort and reduce overhead of > maintaining separate firewalls in the core? Is there an advantage to > having our own pf? Quoting Gleb's response from a later message: > Is there any disadvantage keeping it? It is a plugin. It is optional > and loadable. I removed most additions to the network stack that live > outside netpfil/pf. > > Some people like it and use it. > > It is also the only tool to configure ALTQ now. I think each of those is sufficient reason for existence, as long as there's ongoing people - at least a few - who care enough about it. Maybe it needs to become 'fpf' and be happy to complete its forking? I can't imagine pf or ipfilter people deciding to work on ipfw. For one thing, ipfw has quite a few people working on aspects, development is conservatively ongoing, with no discernable shortage of volunteers. For another, I feel that there are distinct philosophical differences at the level of rule definition languages. From my little reading, pf uses more high-level symbolic language, where ipfw is relentlessly linear and closer to bare metal. Different people will be attracted to, and will be able to work most efficiently with, such different approaches. I've no idea how pf works at the kernel level, as compared with ipfw's virtual machine opcode execution; I daresay each has its strengths and weaknesses. However it's the ruleset configuration language that is the main concern of most packet filter users, not kernel level operation. I believe in ecosystem strength through diversity, as much in projects like FreeBSD as anywhere in the 'real' world. It could even discourage (for example) ongoing ipfw development if there were no other options. cheers, Ian From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 14:12:33 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 23FEEB4 for ; Fri, 1 Aug 2014 14:12:33 +0000 (UTC) Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D023F25D8 for ; Fri, 1 Aug 2014 14:12:32 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id j5so5847083qga.15 for ; Fri, 01 Aug 2014 07:12:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gihBDKF4k4g7lgVxhhYZtW3cB8cQr5KJlzc6+hdLtHY=; b=DovEYE3cElqA8z+MPqbxjXq+/phoaa3vBUwOl85jf9csOUfV0Gq58MopDIau59hL9f oRS7RGtICxpUQkI0kTlxMoeb/cXvQWMZBQWrlrwAsdsPwl/jfh7x0AHr16KNsaVm/wez UY0QdK47ADOECuoF4vbBfaaW6DRLrBQP9UvEMjyn+Fxy7/KDnaJQtKC0A3C7m6TPlVvQ TrySxiOTgCGpyL9zs3Q3xR/zlkWv06H1DsYyxTYci1RV+/OfL60cT0lVCgt+OikT54SG UVBwA7XM3ACQfl13c5Pb517FcEAKmDTGg5zssMoXgOT55bWTTLQjKydKEAO2j16o84xi TQRw== X-Gm-Message-State: ALoCoQnFZBKgI4aEw3gZLoJ/g2Bt9V80OLyT4Ahork6+82zDRQ1EYdFhC5BxgWk9AkUngaC3UF5X X-Received: by 10.140.30.73 with SMTP id c67mr8954687qgc.16.1406902345919; Fri, 01 Aug 2014 07:12:25 -0700 (PDT) Received: from [192.168.2.65] ([96.236.21.80]) by mx.google.com with ESMTPSA id x12sm15299760qaw.1.2014.08.01.07.12.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 07:12:25 -0700 (PDT) Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Paul Kraus In-Reply-To: <74dec781e44c3a81c78e9c4ff1d51c2a@mail.feld.me> Date: Fri, 1 Aug 2014 10:12:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4F589754-EF79-4E59-87FE-08A7DBDF7211@kraus-haus.org> References: <53D9F300.2010308@bluerosetech.com> <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <20140729101806.GB89995@FreeBSD.org> <74dec781e44c3a81c78e9c4ff1d51c2a@mail.feld.me> To: Mark Felder X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Fri, 01 Aug 2014 15:29:48 +0000 Cc: freebsd-questions@FreeBSD.org, Gleb Smirnoff , Darren Pilgrim , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 14:12:33 -0000 On Aug 1, 2014, at 8:46, Mark Felder wrote: > I personally use pf for many reasons, spamd included. I don't think = anyone out there is interested in forking spamd to play ball with ipfw = so we would also be alienating these users who can't just change packet = filters. Is there even an equivalent to pfsync for ipfw? I didn't think = so, but I could be wrong...=20 >=20 > In the world of firewalls pf has been put on a quite a pedestal. = OpenBSD pushed it hard and it marketed it well; people found it both = powerful and easy to use which created a cult following and lots of word = of mouth advertising. I find it hard to agree with removing pf from = FreeBSD because of the existing userbase. If there was an experimental = label on it I would find its removal easier to swallow. I have remained silent on this for two reasons: 1. I am a consumer of FreeBSD. I am a sysadmin, I am NOT a coder and *I* = would not want any code that *I* wrote in the kernel of an OS that I was = running. I know my limitations. So I could not contribute to the = development of pf in FreeBSD 2. Where I use packet filters on a host, and that is not very much, I = tend to use ipfilter because in those case my needs are simple. For = heavy duty (read: gateway) filtering I use commercial firewalls like the = Checkpoint 600 series. So the inclusion or exclusion of pf has no direct = effect on me. Having said all that, the reason I use FreeBSD over other open source = OSes right now is that it is, in my opinion, the most =93grown up=94 = option. I have never seen Linux as an Enterprise tier OS due to a number = of basic design decisions made by Linus and those around him. Illumos is = very good, but fairly narrow in both it=92s hardware support and feature = set. I never took a long hard look at the other BSDs as FreeBSD was = recommended by a friend and I liked what I found, ESPECIALLY the = documentation in the Handbook. I have read a lot of arguments on both sides of the pf in FreeBSD debate = over the past weeks. Realistically I think what it comes down to is = whether there is someone, a person, an individual with the necessary = skill set and drive and desire (and that can be motivated by funding) to = take ownership of it and run with it. If there is not, then I think pf = in FreeBSD dies. No matter how many people want it to continue, no = matter if it is best for FreeBSD for it to continue. Without someone to = take ownership of it, then even if it continues it will not be top = quality, and having something in FreeBSD that is not top quality would = be a mistake (IMHO). -- Paul Kraus paul@kraus-haus.org From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 16:26:06 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E30C74D3 for ; Fri, 1 Aug 2014 16:26:06 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 A02C025E7 for ; Fri, 1 Aug 2014 16:26:06 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtp (envelope-from ) id <1XDFeY-001nsk-4U>; Fri, 01 Aug 2014 18:25:58 +0200 Received: from e179186103.adsl.alicedsl.de ([85.179.186.103] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.82) for freebsd-current@freebsd.org with esmtpsa (envelope-from ) id <1XDFeY-001TIA-2N>; Fri, 01 Aug 2014 18:25:58 +0200 Date: Fri, 1 Aug 2014 18:25:53 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: local_unbound update corrupts network accessibility! Message-ID: <20140801182553.28cd5561.ohartman@zedat.fu-berlin.de> Organization: FU Berlin X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/1mg+pKLpmVdycukxXdvclwP"; protocol="application/pgp-signature" X-Originating-IP: 85.179.186.103 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 16:26:07 -0000 --Sig_/1mg+pKLpmVdycukxXdvclwP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable After the unbound update - or coinciding this update in CURRENT - I have ma= ssive and disturbing problems connecting to some sites, email servers and even the SV= N server of FreeBSD (ports and src). For some name resoltions I receive Host xxx.xxx.de not found: 2(SERVFAIL), while another domain then gets reso= lved without problems. The disturbing part is that this problem occured out of the blue and I conn= ect it with the update of unbound. It doesn't matter wether I use the old configuration= or use a stupid vanilla one.=20 The blockage is also affecting Email. It takes a while until connections ar= e made. Sites, which could not resolved in the first place, get resolved after minutes, bu= t then the data transfer is bumpy or gets stuck. I need to fix this. Boxes with older CURRENT than FreeBSD 11.0-CURRENT #0 r269339: Thu Jul 31 20:47:17 CEST 2014 amd64 do not= show this nasty behaviour. What is up with the system? I tried to follow the UPDATING, but there is no= thing special about essential changes.=20 oh --Sig_/1mg+pKLpmVdycukxXdvclwP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJT27+VAAoJEOgBcD7A/5N8hiIH/0Xjqd4LCjEqyOAFtVl9ROwN Uofo0DFz1gE7lrZElPXGiONPeWOWqDfjaNEGRqnEfCZ3g6frEx4KkCeQv9KGAFpa XxWYJXozotCoRMqK7RUd9GOT6m6zzTwK34MRpmxSf+kcirl7tG/F0AIKwetzgGoH gkRpEIlIkYvVXnG7SWAz0ZwxE4uBToUJtOmwu0QRpNJSzdiXkx6pv0uEKxuqMnxF X3Vjjtti9dVU72T3Pkq+ZII8BHFwekUg0Q5JGYeS+bUM4yZtux/8O48DWVjYOL/x vPgLb3zv7h6szubncLSu67BdyE97+z7b33GA6XfFYfPMGh88JrSnTuNjmaf4DSA= =1Vf6 -----END PGP SIGNATURE----- --Sig_/1mg+pKLpmVdycukxXdvclwP-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 16:57:40 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B879BD8C for ; Fri, 1 Aug 2014 16:57:40 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F7F728CA for ; Fri, 1 Aug 2014 16:57:40 +0000 (UTC) Received: from mandree.no-ip.org ([78.48.16.149]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LgZ7h-1WjCF43CVR-00o0C1 for ; Fri, 01 Aug 2014 18:57:31 +0200 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 28EA823CEB6 for ; Fri, 1 Aug 2014 18:57:30 +0200 (CEST) Message-ID: <53DBC6FA.3070702@gmx.de> Date: Fri, 01 Aug 2014 18:57:30 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: local_unbound update corrupts network accessibility! References: <20140801182553.28cd5561.ohartman@zedat.fu-berlin.de> In-Reply-To: <20140801182553.28cd5561.ohartman@zedat.fu-berlin.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uhCiL9QR9LyIoutU5ObDk49rXof15JyOf79qiKlA8Hd81DDViOE T7kGUhDkYHFcSuq49pLtNBctbLqkpPF4EUQNqNFA0v8Z0wNZO5M9wNLuyuwlwXL4naHj8fH 6nmuUafck3lqy4cMPPNmNl1WV8GriQkp7bU5UEHWGG48c43BhpKbwov7tUtQHavEM1nw/L8 jSJYDOw4aTcGp3TD9wYgQ== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 16:57:40 -0000 Am 01.08.2014 um 18:25 schrieb O. Hartmann: > > After the unbound update - or coinciding this update in CURRENT - I have massive and > disturbing problems connecting to some sites, email servers and even the SVN server of > FreeBSD (ports and src). > > For some name resoltions I receive > > Host xxx.xxx.de not found: 2(SERVFAIL), while another domain then gets resolved without > problems. Are you using dnssec? Check http://dnssec.vs.uni-due.de/ From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 18:18:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E6173FF0 for ; Fri, 1 Aug 2014 18:18:15 +0000 (UTC) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 830122264 for ; Fri, 1 Aug 2014 18:18:15 +0000 (UTC) Received: from mouf.net (swills@mouf [199.48.129.64]) by mouf.net (8.14.5/8.14.5) with ESMTP id s71II5fS018737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Aug 2014 18:18:10 GMT (envelope-from swills@mouf.net) Received: (from swills@localhost) by mouf.net (8.14.5/8.14.5/Submit) id s71II42R018735; Fri, 1 Aug 2014 18:18:04 GMT (envelope-from swills) Date: Fri, 1 Aug 2014 18:18:04 +0000 From: Steve Wills To: Anton Berezin , Jan =?iso-8859-1?Q?Kokem=FCller?= , freebsd-current@freebsd.org Subject: Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction Message-ID: <20140801181800.GA18604@mouf.net> References: <20140731142100.GP92036@heechee.tobez.org> <53DA6727.7080702@gmail.com> <20140731162227.GQ92036@heechee.tobez.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20140731162227.GQ92036@heechee.tobez.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Fri, 01 Aug 2014 18:18:10 +0000 (UTC) X-Spam-Status: No, score=0.0 required=4.5 tests=none autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mouf.net X-Virus-Scanned: clamav-milter 0.98.1 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 18:18:16 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jul 31, 2014 at 06:22:27PM +0200, Anton Berezin wrote: > Jan, >=20 > On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokem=FCller wrote: > > On 31.07.2014 16:21, Anton Berezin wrote: > > >At the console, depressing and holding a key does not lead to auto-rep= eat. > > > > > >At the console, sometimes a key only appears on the terminal after ano= ther > > >key is pressed. > >=20 > > Maybe this is a problem caused by a misdetected clock source? I've had = this > > problem as well. > >=20 > > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to ot= her > > settings that are listed in kern.timecounter.choice and > > kern.eventtimer.choice, such as HPET which works great for me. >=20 > Setting both to HPET certainly helped the LA. I cannot check the keyboard > input until tomorrow, but chances are that it is indeed the fix. Just wanted to throw in another datapoint, I had this issue too and setting kern.eventtimer.timer=3DHPET alone solved it for me. Steve --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJT29nXAAoJEPXPYrMgexuh86UH/iVK/hBdAwezpJWeWZ0WaM6X I7rRnHR3yBXt4fPc0NAGsVs9r2GX2YnUlTgESICTE4gnBwo8MdyEbRmP6+8RcoRj 6xznY0+5zdDjHdURfGv05izlRP+2CSrd7gUOEAO4i31ZYCFvhm/yjPZ6ygYpsSuo +VRmeAAQEmmNSlj+DXkWOIbZh+DMRt5Xc9w1h0zIiXDeMP9EOJx5F2sMG2+BrXGa 3343TU5MjxyZJVkpfQhVQg6CIGZ5suwH6n+Dv9zFzXfhG64IqOI0la8SxeNhxh8B iOA5MckrOvrqrK6qbBGqu+4Qhy0m7jel7i1eni2/Vpm7EaRBd8PrzWTnnL/YT+4= =aDT4 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 18:21:32 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 786FE25F; Fri, 1 Aug 2014 18:21:32 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 277182412; Fri, 1 Aug 2014 18:21:32 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id j107so6241781qga.36 for ; Fri, 01 Aug 2014 11:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=rlLT1/V9zpSYVnkUnF3kul7kCJdvh0H1fn3Tker2zsY=; b=FXGTsM7aciCSyZ1jXe/veIynRzQ8XAwp1OhZi9rUpARS27SnJZd0AOnQlXNPYPvphv T0ZOzeRRBNfuvdB8eaVsxcdD6rBd2DgR40RYbWsOckL6OLdAWDC30hilsXt9x3VJddOj KMBsAgzw6OLHfKoR9GR1rxs8AbXlEvKvjZBvY9GsqyGUedjSBKBP5Pe1owYxvYIALE6U 2K3EUwi70eLEb21OE0J7ZVK9gjMT6vS2KBqXC7j+stHnBc2xu/m13tlo5SuhBs55qBh4 SFa5757j17QWiI285O7J2p3sN2TqECa9FwWyEVH2dFCQR6XtFvOPfD4xjMMDZgeM7h0f Mz8A== MIME-Version: 1.0 X-Received: by 10.229.38.3 with SMTP id z3mr5962669qcd.17.1406917291276; Fri, 01 Aug 2014 11:21:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 1 Aug 2014 11:21:31 -0700 (PDT) In-Reply-To: <20140801181800.GA18604@mouf.net> References: <20140731142100.GP92036@heechee.tobez.org> <53DA6727.7080702@gmail.com> <20140731162227.GQ92036@heechee.tobez.org> <20140801181800.GA18604@mouf.net> Date: Fri, 1 Aug 2014 11:21:31 -0700 X-Google-Sender-Auth: i4bUaIU-wbsR2X0jztp5C8cfxa4 Message-ID: Subject: Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction From: Adrian Chadd To: Steve Wills Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: =?UTF-8?Q?Jan_Kokem=C3=BCller?= , freebsd-current , Anton Berezin X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 18:21:32 -0000 Hi! On 1 August 2014 11:18, Steve Wills wrote: > Hi, > > On Thu, Jul 31, 2014 at 06:22:27PM +0200, Anton Berezin wrote: >> Jan, >> >> On Thu, Jul 31, 2014 at 05:56:23PM +0200, Jan Kokem=C3=BCller wrote: >> > On 31.07.2014 16:21, Anton Berezin wrote: >> > >At the console, depressing and holding a key does not lead to auto-re= peat. >> > > >> > >At the console, sometimes a key only appears on the terminal after an= other >> > >key is pressed. >> > >> > Maybe this is a problem caused by a misdetected clock source? I've had= this >> > problem as well. >> > >> > Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to o= ther >> > settings that are listed in kern.timecounter.choice and >> > kern.eventtimer.choice, such as HPET which works great for me. >> >> Setting both to HPET certainly helped the LA. I cannot check the keyboa= rd >> input until tomorrow, but chances are that it is indeed the fix. > > Just wanted to throw in another datapoint, I had this issue too and setti= ng > kern.eventtimer.timer=3DHPET alone solved it for me. Please throw this into a bug report ticket and poke mav@ about it. -a From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 18:36:57 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B1CA4930; Fri, 1 Aug 2014 18:36:57 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A131255F; Fri, 1 Aug 2014 18:36:57 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s71IastB051249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2014 11:36:55 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s71IarVE051247; Fri, 1 Aug 2014 11:36:53 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Aug 2014 11:36:53 -0700 From: John-Mark Gurney To: Cy Schubert Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? Message-ID: <20140801183653.GC50495@funkthat.com> Mail-Followup-To: Cy Schubert , Adrian Chadd , freebsd-current , krad , Gleb Smirnoff , Gerrit =?iso-8859-1?Q?K=FChn?= , FreeBSD Mailing List , Matt Bettinger References: <201407231619.s6NGJBQF025702@slippy.cwsent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407231619.s6NGJBQF025702@slippy.cwsent.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Aug 2014 11:36:55 -0700 (PDT) Cc: Adrian Chadd , krad , freebsd-current , Gleb Smirnoff , Gerrit =?iso-8859-1?Q?K=FChn?= , FreeBSD Mailing List , Matt Bettinger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 18:36:57 -0000 Cy Schubert wrote this message on Wed, Jul 23, 2014 at 09:18 -0700: > In message om> > , Adrian Chadd writes: > > On 18 July 2014 07:34, krad wrote: > > > that is true and I have not problem using man pages, however thats not the > > > way most of the world work and search engines arent exactly new either. We > > > should be trying to engage more people not less, and part of that is > > > reaching out. > > > > Then do the port and maintain it. > > > > The problem isn't the desire to keep things up to date, it's a lack of > > people who want that _and_ are willing/able to do it _and_ are funded > > somehow. > > Funding is the issue. Sure, some of us maintain software because a personal > need however without funding one has to fit maintaining software into > whatever time is left. For those of us who do this without funding you > manage to squeeze in an hour here or there. Then write a proposal and submit it to the Foundation.. If you don't ask for funding, it rarely shows up... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 18:48:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1ED5ACAE for ; Fri, 1 Aug 2014 18:48:49 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A711E268E for ; Fri, 1 Aug 2014 18:48:48 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ho1so1852728wib.14 for ; Fri, 01 Aug 2014 11:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=y7tFhVGU51yVVz9c+qDhRRhSnpPTShf/XN18x+NlfKo=; b=ndmxqtQFxaK/sBUVPP68K8xE1AbX0sUmWuTb7EHwscK+elxJ6FUlnv6X5ymc9A/otR ULhqov0QEC8hUxvQ2rL5XNi5P/u6o5PbedTaU5wo+6eXBu+GywO7FAJSsgOjJE52amo6 EI72u68FAW8vZAOl3EBnuAEoI5ibuuOytCguow08XG1KL7iQsqtouNsQKG2yd1qyO/sN 4He+LTSE8m9eQNmA2F/FYtAj48V8vS/luJfzKUqB4+z5ZUUTDD8dRaKeJ/GX2m/Fov5l flr8LZZSRMtqs3ukicvtkL48rCodWiwXS3ai1VQqpfJInPKy+pRdueNwMjY9ZY/bxeB/ UB8Q== X-Received: by 10.194.219.225 with SMTP id pr1mr10960160wjc.34.1406918926242; Fri, 01 Aug 2014 11:48:46 -0700 (PDT) Received: from [192.168.178.122] (p5B36F3D4.dip0.t-ipconnect.de. [91.54.243.212]) by mx.google.com with ESMTPSA id f16sm11212618wic.7.2014.08.01.11.48.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 11:48:45 -0700 (PDT) Message-ID: <53DBE10B.9010202@gmail.com> Date: Fri, 01 Aug 2014 20:48:43 +0200 From: =?ISO-8859-1?Q?Jan_Kokem=FCller?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction References: <20140731142100.GP92036@heechee.tobez.org> <53DA6727.7080702@gmail.com> In-Reply-To: <53DA6727.7080702@gmail.com> Content-Type: multipart/mixed; boundary="------------080104080403040701080004" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 18:48:49 -0000 This is a multi-part message in MIME format. --------------080104080403040701080004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, > Maybe this is a problem caused by a misdetected clock source? I've had > this problem as well. I've appended the patch I've been using to fix this problem on this Intel Core2Duo T6570 processor. There are some model IDs hardcoded in the TSC detection code that enable TSC even though it's not invariant here (no TSC_INVARIANT bit set on the CPU). There is some quirk code further down that disables TSC once again, but it only works for processors that have C3 power states (the T6570 doesn't). I don't think any of this model checking code is necessary, but maybe I'm wrong. Cheers, Jan --------------080104080403040701080004 Content-Type: text/x-patch; name="fix-invariant-tsc-detection.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="fix-invariant-tsc-detection.patch" diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c index 2a6c81d..a30424e 100644 --- a/sys/x86/x86/tsc.c +++ b/sys/x86/x86/tsc.c @@ -57,7 +57,8 @@ int tsc_perf_stat; static eventhandler_tag tsc_levels_tag, tsc_pre_tag, tsc_post_tag; SYSCTL_INT(_kern_timecounter, OID_AUTO, invariant_tsc, CTLFLAG_RDTUN, - &tsc_is_invariant, 0, "Indicates whether the TSC is P-state invariant"); + &tsc_is_invariant, 0, + "Indicates whether the TSC is ACPI P-, C- and T-state invariant"); TUNABLE_INT("kern.timecounter.invariant_tsc", &tsc_is_invariant); #ifdef SMP @@ -272,9 +273,7 @@ probe_tsc_freq(void) switch (cpu_vendor_id) { case CPU_VENDOR_AMD: - if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0 || - (vm_guest == VM_GUEST_NO && - CPUID_TO_FAMILY(cpu_id) >= 0x10)) + if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0) tsc_is_invariant = 1; if (cpu_feature & CPUID_SSE2) { tsc_timecounter.tc_get_timecount = @@ -282,12 +281,7 @@ probe_tsc_freq(void) } break; case CPU_VENDOR_INTEL: - if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0 || - (vm_guest == VM_GUEST_NO && - ((CPUID_TO_FAMILY(cpu_id) == 0x6 && - CPUID_TO_MODEL(cpu_id) >= 0xe) || - (CPUID_TO_FAMILY(cpu_id) == 0xf && - CPUID_TO_MODEL(cpu_id) >= 0x3)))) + if ((amd_pminfo & AMDPM_TSC_INVARIANT) != 0) tsc_is_invariant = 1; if (cpu_feature & CPUID_SSE2) { tsc_timecounter.tc_get_timecount = @@ -554,20 +548,6 @@ init_TSC_tc(void) } /* - * We cannot use the TSC if it stops incrementing in deep sleep. - * Currently only Intel CPUs are known for this problem unless - * the invariant TSC bit is set. - */ - if (cpu_can_deep_sleep && cpu_vendor_id == CPU_VENDOR_INTEL && - (amd_pminfo & AMDPM_TSC_INVARIANT) == 0) { - tsc_timecounter.tc_quality = -1000; - tsc_timecounter.tc_flags |= TC_FLAGS_C3STOP; - if (bootverbose) - printf("TSC timecounter disabled: C3 enabled.\n"); - goto init; - } - - /* * We can not use the TSC in SMP mode unless the TSCs on all CPUs * are synchronized. If the user is sure that the system has * synchronized TSCs, set kern.timecounter.smp_tsc tunable to a --------------080104080403040701080004-- From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 18:59:18 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9151E149 for ; Fri, 1 Aug 2014 18:59:18 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 51B6B2789 for ; Fri, 1 Aug 2014 18:59:18 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id j5so6210958qga.29 for ; Fri, 01 Aug 2014 11:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=JOWq6rzZQbUgNsPCzwARLZxx2OVjrXc+0pFvmEOxVJM=; b=lUWHb6RZ1SCI0L01cleddiedPoj+ht1K67J2NstiaizRG3ngNCDDriXK2ViQiwpgfV qerWJit/PQQ/ltEvLOai1RbXQzwu/06wX5kWue1IY+WuRP1QumS3n0apXpKSNqGhznKv tHfNeeWwe109u43Q22nDou3PEakvERGvqW7eMynwUma/wvd10Smz6/dmbtbuzdrwGDa9 YpQb8swTwYN3+bil7/LC7pj76BND562/ejNghk3odMY0mZIp/E8CYtGeVWdrUnfg6jiE DBe+8ybFvD1Ua10aZaDbIyFd7rUOJv7DFiymsMRQRR7ET2uQGXXf28hENzWnX8/Slmiv OfHQ== MIME-Version: 1.0 X-Received: by 10.224.71.198 with SMTP id i6mr12423605qaj.76.1406919556260; Fri, 01 Aug 2014 11:59:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 1 Aug 2014 11:59:16 -0700 (PDT) In-Reply-To: <53DBE10B.9010202@gmail.com> References: <20140731142100.GP92036@heechee.tobez.org> <53DA6727.7080702@gmail.com> <53DBE10B.9010202@gmail.com> Date: Fri, 1 Aug 2014 11:59:16 -0700 X-Google-Sender-Auth: _oa7_M1EpinrocV12ffx7R2OdX0 Message-ID: Subject: Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction From: Adrian Chadd To: =?UTF-8?Q?Jan_Kokem=C3=BCller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 18:59:18 -0000 Can you file a pr with this patch? https://bugs.freebsd.org/submit/ That way we don't lose track of it. Thanks! -a On 1 August 2014 11:48, Jan Kokem=C3=BCller wro= te: > Hi, > > >> Maybe this is a problem caused by a misdetected clock source? I've had >> this problem as well. > > > I've appended the patch I've been using to fix this problem on this Intel > Core2Duo T6570 processor. There are some model IDs hardcoded in the TSC > detection code that enable TSC even though it's not invariant here (no > TSC_INVARIANT bit set on the CPU). There is some quirk code further down > that disables TSC once again, but it only works for processors that have = C3 > power states (the T6570 doesn't). I don't think any of this model checkin= g > code is necessary, but maybe I'm wrong. > > Cheers, > Jan > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Aug 1 19:16:00 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEE878DE; Fri, 1 Aug 2014 19:16:00 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3258A298A; Fri, 1 Aug 2014 19:16:00 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w62so4830897wes.15 for ; Fri, 01 Aug 2014 12:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WlYLMXx97n+ETjUjXIFcD65q/nE7ASRskU/chGr0TFw=; b=qrmFuRB3KNN2Q40d9e4Bx+BBDTX/mzI4eDpA5yrhB0cnJFzqfW276hgZ0jKnGS0Fzq ubVjeEvbVsL+80XvGcd8mzTaWMACDN+F67rLkCIy0r3MieC153Ym27EOkWGwRPmPJqRC BXoZoLepB9TlhpxXbVgKlv6jqkmf5fda0K1BckgLrBzi8QMmmM8drUHBRxp4eq00XnCw s5k6yG7E69UMxUgm4fvRAIzz1PYbFkAuRpcJ7PiVXW3p11Z/qOwWUdAQjKLy8/zctlkl X2MEvY5Nevj5rurJ2mC5ArVkh2MLbng4qX70ZQ/l8SFvShxGySUrrP7mf1uiuicOBsJd NwEA== X-Received: by 10.194.236.35 with SMTP id ur3mr10778352wjc.127.1406920556282; Fri, 01 Aug 2014 12:15:56 -0700 (PDT) Received: from [192.168.178.122] (p5B36F3D4.dip0.t-ipconnect.de. [91.54.243.212]) by mx.google.com with ESMTPSA id wu6sm22829840wjb.46.2014.08.01.12.15.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 12:15:55 -0700 (PDT) Message-ID: <53DBE769.3060803@gmail.com> Date: Fri, 01 Aug 2014 21:15:53 +0200 From: =?UTF-8?B?SmFuIEtva2Vtw7xsbGVy?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction References: <20140731142100.GP92036@heechee.tobez.org> <53DA6727.7080702@gmail.com> <53DBE10B.9010202@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 19:16:00 -0000 On 01.08.2014 20:59, Adrian Chadd wrote: > Can you file a pr with this patch? Done: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316 Cheers, Jan From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 19:34:04 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98FD7EB for ; Fri, 1 Aug 2014 19:34:04 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 790602BA2 for ; Fri, 1 Aug 2014 19:34:04 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s71JY37P052042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Aug 2014 12:34:03 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s71JY3eP052041 for freebsd-current@FreeBSD.org; Fri, 1 Aug 2014 12:34:03 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Aug 2014 12:34:03 -0700 From: John-Mark Gurney To: freebsd-current@FreeBSD.org Subject: domain_add(xxx) after domainfinalize... Message-ID: <20140801193403.GE50495@funkthat.com> Mail-Followup-To: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Aug 2014 12:34:04 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 19:34:04 -0000 So, I have a laptop that devd loads the bluetooth module every time.. This means I get the following error on every boot: WARNING: attempt to domain_add(bluetooth) after domainfinalize() WARNING: attempt to domain_add(netgraph) after domainfinalize() Is there any real benefit to this warning? I just looked at the code, and the domain gets added despite the warning... Also, it looks like the pervious warning, we should just make that an if/panic since it's clearly a programming bug, or kill the ifndef INVARIANTS... Index: uipc_domain.c =================================================================== --- uipc_domain.c (revision 266964) +++ uipc_domain.c (working copy) @@ -227,15 +227,6 @@ printf("WARNING: attempt to domain_add(%s) before " "domaininit()\n", dp->dom_name); #endif -#ifdef notyet - KASSERT(domain_init_status < 2, - ("attempt to domain_add(%s) after domainfinalize()", - dp->dom_name)); -#else - if (domain_init_status >= 2) - printf("WARNING: attempt to domain_add(%s) after " - "domainfinalize()\n", dp->dom_name); -#endif mtx_unlock(&dom_mtx); } -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 21:18:47 2014 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31341149; Fri, 1 Aug 2014 21:18:47 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0958C285B; Fri, 1 Aug 2014 21:18:46 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s71LIj37053429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2014 14:18:45 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s71LIjU9053428; Fri, 1 Aug 2014 14:18:45 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Aug 2014 14:18:45 -0700 From: John-Mark Gurney To: freebsd-current@FreeBSD.org Subject: comments on vt as console... Message-ID: <20140801211845.GG50495@funkthat.com> Mail-Followup-To: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Aug 2014 14:18:45 -0700 (PDT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 21:18:47 -0000 So, I decided to play around w/ vt after the recent UTF-8 discussion, and noticed some issues w/ it... First, if you load the gallant font, things don't look very good... This is probably because of the fact that I'm using the vga driver: VT: running with driver "vga". and the default resolution is 640x480... The gallant font is probably much higher res, and when I load it, the text screen size drops to 53x21, and the text is all chopped off. This is probably due to bad calculation on scaling... Second, once one vty has the gallant font loaded, if you switch vty's, it can occure that the new vty does not display ANY text.. The display is mostly blank... Third, w/ the other font loaded, the border doesn't always properly get cleared... Fourth, when switching screens, there is a brief flash of vertical stripes before the new screen comes on... Can we do something to make sure that this transition is clean? Either a completely blank screen, or ideally, no blank screen, but the new text appearing? $ sysctl kern.vt kern.vt.enable_altgr: 1 kern.vt.debug: 0 kern.vt.deadtimer: 15 kern.vt.suspendswitch: 1 $ uname -a FreeBSD pciehp 11.0-CURRENT FreeBSD 11.0-CURRENT #3 r267710M: Thu Jul 31 21:39:53 ICT 2014 jmg@pciehp:/usr/home/jmg/freebsd.pciehp/sys/amd64/compile/GENERIC amd64 Let me know if you need any more info. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 22:05:38 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB9AD218 for ; Fri, 1 Aug 2014 22:05:38 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CDA62EA0 for ; Fri, 1 Aug 2014 22:05:38 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id k15so4625255qaq.27 for ; Fri, 01 Aug 2014 15:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a9e/Sj3rIpjAmplfzjHuMGxM481YO1SXz14KHkMmqgU=; b=OyurMh3+uvYge4+URmvhL/LbgMNaWrjIi4yVBMX6AonF6EWvYMN2hPNtvd0T6thmly j98OUJpgCCUtPVXfG9fJAlCPh2SKhBALCi76Id90hS+JWWjtD9pq6EoVLEPWvWn27nSj ZAO0sSzrF7V0Heyiy18NEIG6opFAvxngvsLr/xi+N6FIJIAnW4cof6sCJq4vW3+L1tXD mTy+/kAKsxGq7aLcvF3ULZF/5ckBh/zaMCNbNS6R2xRNvfxjrFJYebHWdcN5UrJcasCj XqWK9IiyiSKqlLu06kwjC+KMi45ve3ipx/XXueBYFDiOiaix34R9QySKmdyAnVqmDkAG qTng== MIME-Version: 1.0 X-Received: by 10.224.30.1 with SMTP id s1mr14053955qac.70.1406930737523; Fri, 01 Aug 2014 15:05:37 -0700 (PDT) Received: by 10.140.48.2 with HTTP; Fri, 1 Aug 2014 15:05:37 -0700 (PDT) In-Reply-To: <20140801193403.GE50495@funkthat.com> References: <20140801193403.GE50495@funkthat.com> Date: Sat, 2 Aug 2014 00:05:37 +0200 Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Svatopluk Kraus To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: jmg@funkthat.com X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 22:05:38 -0000 Just what I've got in January 2011: http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html Svata On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney wrote: > So, I have a laptop that devd loads the bluetooth module every time.. > > This means I get the following error on every boot: > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > Is there any real benefit to this warning? I just looked at the code, > and the domain gets added despite the warning... > > Also, it looks like the pervious warning, we should just make that an > if/panic since it's clearly a programming bug, or kill the ifndef > INVARIANTS... > > Index: uipc_domain.c > =================================================================== > --- uipc_domain.c (revision 266964) > +++ uipc_domain.c (working copy) > @@ -227,15 +227,6 @@ > printf("WARNING: attempt to domain_add(%s) before " > "domaininit()\n", dp->dom_name); > #endif > -#ifdef notyet > - KASSERT(domain_init_status < 2, > - ("attempt to domain_add(%s) after domainfinalize()", > - dp->dom_name)); > -#else > - if (domain_init_status >= 2) > - printf("WARNING: attempt to domain_add(%s) after " > - "domainfinalize()\n", dp->dom_name); > -#endif > mtx_unlock(&dom_mtx); > } > > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Aug 1 22:21:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF5AD4E1 for ; Fri, 1 Aug 2014 22:21:19 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A2B72078 for ; Fri, 1 Aug 2014 22:21:19 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s71MLI3e054376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2014 15:21:18 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s71MLImm054375; Fri, 1 Aug 2014 15:21:18 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Aug 2014 15:21:18 -0700 From: John-Mark Gurney To: Svatopluk Kraus Subject: Re: domain_add(xxx) after domainfinalize... Message-ID: <20140801222118.GH50495@funkthat.com> Mail-Followup-To: Svatopluk Kraus , freebsd-current@freebsd.org References: <20140801193403.GE50495@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Aug 2014 15:21:18 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 22:21:19 -0000 Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200: > Just what I've got in January 2011: > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html Sadly, after three (or six+) years, it is clear that these bugs will not be fixed, and this warning message is not useful, since no one has stepped up to fix them.. btw, you might want to create a bug w/ the information you tracked down to hopefully help the person that decides to finally fix them, though I doubt they will ever be fixed as people apparently don't see bad behavior... Unless someone fixes the bugs in the next few days, I will commit the following patch: Index: uipc_domain.c =================================================================== --- uipc_domain.c (revision 266964) +++ uipc_domain.c (working copy) @@ -227,15 +227,10 @@ printf("WARNING: attempt to domain_add(%s) before " "domaininit()\n", dp->dom_name); #endif -#ifdef notyet - KASSERT(domain_init_status < 2, - ("attempt to domain_add(%s) after domainfinalize()", - dp->dom_name)); -#else - if (domain_init_status >= 2) - printf("WARNING: attempt to domain_add(%s) after " - "domainfinalize()\n", dp->dom_name); -#endif + /* + * XXX - there are bugs WRT to adding domain after domain_finalize is + * called + */ mtx_unlock(&dom_mtx); } > On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney wrote: > > > So, I have a laptop that devd loads the bluetooth module every time.. > > > > This means I get the following error on every boot: > > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > > > Is there any real benefit to this warning? I just looked at the code, > > and the domain gets added despite the warning... > > > > Also, it looks like the pervious warning, we should just make that an > > if/panic since it's clearly a programming bug, or kill the ifndef > > INVARIANTS... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 22:42:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3A8C7B69 for ; Fri, 1 Aug 2014 22:42:31 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F039A223B for ; Fri, 1 Aug 2014 22:42:30 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id w8so4588433qac.16 for ; Fri, 01 Aug 2014 15:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=AWb3quM70LSiq/wkYz7p8zGsQGE0fgm5IKHqhGuWXUg=; b=u3wUk4woSNS93JdKCrvjbb90IWPkQcaN5/vEeb/y4l7bzGJ1+utpQQhDKBlm8iT7M8 ydnUAYy5p1Bf9NPT7hzlk0WwIOZEAqrYwYne0/yM3rSSpslRYxejYV58QZTLVqGiQIjA k1qbCiRr3JZNIscjpy8KAbnmzcdnDGFbdAmYtwbFgA6dEDOb59Iki2YKZ/++O+AXiK/b xNDBR05vcV0w7dFdNCukM7gGDNHfHi3gYqRzFTz/5Kel1/RHys+WmXlga2MdCndKII0B yZabI5UDg4rJLo/3u6s8yS1veIHjY11vheN9AN3PdWZ8UtY8hG/g/kFvIF5ft147B56p O6Ow== MIME-Version: 1.0 X-Received: by 10.224.171.197 with SMTP id i5mr14513778qaz.55.1406932950062; Fri, 01 Aug 2014 15:42:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 1 Aug 2014 15:42:30 -0700 (PDT) In-Reply-To: <20140801222118.GH50495@funkthat.com> References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> Date: Fri, 1 Aug 2014 15:42:30 -0700 X-Google-Sender-Auth: 4p-aCfwmaDETk6lW-QhQIC4fHWs Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Adrian Chadd To: Svatopluk Kraus , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 22:42:31 -0000 I'd just make it a panic. :) -a On 1 August 2014 15:21, John-Mark Gurney wrote: > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200: >> Just what I've got in January 2011: >> http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html > > Sadly, after three (or six+) years, it is clear that these bugs will > not be fixed, and this warning message is not useful, since no one has > stepped up to fix them.. > > btw, you might want to create a bug w/ the information you tracked down > to hopefully help the person that decides to finally fix them, though > I doubt they will ever be fixed as people apparently don't see bad > behavior... > > Unless someone fixes the bugs in the next few days, I will commit the > following patch: > Index: uipc_domain.c > =================================================================== > --- uipc_domain.c (revision 266964) > +++ uipc_domain.c (working copy) > @@ -227,15 +227,10 @@ > printf("WARNING: attempt to domain_add(%s) before " > "domaininit()\n", dp->dom_name); > #endif > -#ifdef notyet > - KASSERT(domain_init_status < 2, > - ("attempt to domain_add(%s) after domainfinalize()", > - dp->dom_name)); > -#else > - if (domain_init_status >= 2) > - printf("WARNING: attempt to domain_add(%s) after " > - "domainfinalize()\n", dp->dom_name); > -#endif > + /* > + * XXX - there are bugs WRT to adding domain after domain_finalize is > + * called > + */ > mtx_unlock(&dom_mtx); > } > > >> On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney wrote: >> >> > So, I have a laptop that devd loads the bluetooth module every time.. >> > >> > This means I get the following error on every boot: >> > WARNING: attempt to domain_add(bluetooth) after domainfinalize() >> > WARNING: attempt to domain_add(netgraph) after domainfinalize() >> > >> > Is there any real benefit to this warning? I just looked at the code, >> > and the domain gets added despite the warning... >> > >> > Also, it looks like the pervious warning, we should just make that an >> > if/panic since it's clearly a programming bug, or kill the ifndef >> > INVARIANTS... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Aug 1 22:56:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39C9FEE0; Fri, 1 Aug 2014 22:56:22 +0000 (UTC) Received: from mail.fer.hr (mail.fer.hr [161.53.72.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.fer.hr", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 950DA2437; Fri, 1 Aug 2014 22:56:20 +0000 (UTC) Received: from x23 (31.147.14.167) by MAIL.fer.hr (161.53.72.233) with Microsoft SMTP Server (TLS) id 14.2.342.3; Sat, 2 Aug 2014 00:55:02 +0200 Date: Sat, 2 Aug 2014 00:55:20 +0200 From: Marko Zec To: Adrian Chadd Subject: Re: domain_add(xxx) after domainfinalize... Message-ID: <20140802005520.29ca841b@x23> In-Reply-To: References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> Organization: FER X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; amd64-portbld-freebsd9.1) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.147.14.167] Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 22:56:22 -0000 On Fri, 1 Aug 2014 15:42:30 -0700 Adrian Chadd wrote: > I'd just make it a panic. :) Are you prepared to say goodbye to kldloading netgraph at runtime? Marko > > -a > > > On 1 August 2014 15:21, John-Mark Gurney wrote: > > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 > > +0200: > >> Just what I've got in January 2011: > >> http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html > > > > Sadly, after three (or six+) years, it is clear that these bugs will > > not be fixed, and this warning message is not useful, since no one > > has stepped up to fix them.. > > > > btw, you might want to create a bug w/ the information you tracked > > down to hopefully help the person that decides to finally fix them, > > though I doubt they will ever be fixed as people apparently don't > > see bad behavior... > > > > Unless someone fixes the bugs in the next few days, I will commit > > the following patch: > > Index: uipc_domain.c > > =================================================================== > > --- uipc_domain.c (revision 266964) > > +++ uipc_domain.c (working copy) > > @@ -227,15 +227,10 @@ > > printf("WARNING: attempt to domain_add(%s) before " > > "domaininit()\n", dp->dom_name); > > #endif > > -#ifdef notyet > > - KASSERT(domain_init_status < 2, > > - ("attempt to domain_add(%s) after domainfinalize()", > > - dp->dom_name)); > > -#else > > - if (domain_init_status >= 2) > > - printf("WARNING: attempt to domain_add(%s) after " > > - "domainfinalize()\n", dp->dom_name); > > -#endif > > + /* > > + * XXX - there are bugs WRT to adding domain after > > domain_finalize is > > + * called > > + */ > > mtx_unlock(&dom_mtx); > > } > > > > > >> On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney > >> wrote: > >> > >> > So, I have a laptop that devd loads the bluetooth module every > >> > time.. > >> > > >> > This means I get the following error on every boot: > >> > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > >> > WARNING: attempt to domain_add(netgraph) after domainfinalize() > >> > > >> > Is there any real benefit to this warning? I just looked at the > >> > code, and the domain gets added despite the warning... > >> > > >> > Also, it looks like the pervious warning, we should just make > >> > that an if/panic since it's clearly a programming bug, or kill > >> > the ifndef INVARIANTS... > > > > -- > > John-Mark Gurney Voice: +1 415 225 > > 5579 > > > > "All that I will do, has been done, All that I have, has not." > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://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 Aug 1 23:25:15 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4188B7A3 for ; Fri, 1 Aug 2014 23:25:15 +0000 (UTC) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 030AD26CA for ; Fri, 1 Aug 2014 23:25:14 +0000 (UTC) Received: by mail-qg0-f53.google.com with SMTP id q107so6562848qgd.26 for ; Fri, 01 Aug 2014 16:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=T618sDv6SqM6S9OyBOQr1yNRUpYh3P05aI2cvCqQtE4=; b=Cv1BA6Qged5S9F8psDPw28rNx9ETcBhaiz81ep+zHhSPOkPdhgm2kODOlFFQcgB6Ig lDDa+qVA2WPIwf6y5edv4cfwM3qQ/Bpns4pEWOZvMx3VobSEnp+TrXflTTod1+DCwLVJ lolnj8AKqtrlrRQgUjGBaW7hmurltYLHfAWKOX3n/YczlD37iaBxTEF2zbL23KUclJVQ 42mQmzYjFB3RORnaho+PaOX+yuWczEHrd2FZVotu7j/N+OPMVZ/kF8dujGxPVR8Wm5m5 1xa21cMP8wBSj9b2j3bZcuAGLqoV2frtXLF7hD0oXWma4d2Aaqqf6qhyWGIkEpvXt0s5 gcQQ== MIME-Version: 1.0 X-Received: by 10.140.19.176 with SMTP id 45mr13400666qgh.46.1406935514106; Fri, 01 Aug 2014 16:25:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 1 Aug 2014 16:25:14 -0700 (PDT) In-Reply-To: <20140802005520.29ca841b@x23> References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> <20140802005520.29ca841b@x23> Date: Fri, 1 Aug 2014 16:25:14 -0700 X-Google-Sender-Auth: -9FZGDgmGRIr12dtf_-VnnCx7pg Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Adrian Chadd To: Marko Zec Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 23:25:15 -0000 On 1 August 2014 15:55, Marko Zec wrote: > On Fri, 1 Aug 2014 15:42:30 -0700 > Adrian Chadd wrote: > >> I'd just make it a panic. :) > > Are you prepared to say goodbye to kldloading netgraph at runtime? Well, why is it saying that? is there actually a problem? -a From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 23:42:59 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFED6ED7; Fri, 1 Aug 2014 23:42:59 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8FAE28A6; Fri, 1 Aug 2014 23:42:59 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s71NgsBH055555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2014 16:42:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s71NgsLH055554; Fri, 1 Aug 2014 16:42:54 -0700 (PDT) (envelope-from jmg) Date: Fri, 1 Aug 2014 16:42:53 -0700 From: John-Mark Gurney To: Adrian Chadd Subject: Re: domain_add(xxx) after domainfinalize... Message-ID: <20140801234253.GK50495@funkthat.com> Mail-Followup-To: Adrian Chadd , Marko Zec , freebsd-current References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> <20140802005520.29ca841b@x23> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 01 Aug 2014 16:42:54 -0700 (PDT) Cc: freebsd-current , Marko Zec X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 23:43:00 -0000 Adrian Chadd wrote this message on Fri, Aug 01, 2014 at 16:25 -0700: > On 1 August 2014 15:55, Marko Zec wrote: > > On Fri, 1 Aug 2014 15:42:30 -0700 > > Adrian Chadd wrote: > > > >> I'd just make it a panic. :) > > > > Are you prepared to say goodbye to kldloading netgraph at runtime? > > Well, why is it saying that? is there actually a problem? Please read the thread. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Aug 1 23:45:54 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90D8E219; Fri, 1 Aug 2014 23:45:54 +0000 (UTC) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 408DB28C7; Fri, 1 Aug 2014 23:45:54 +0000 (UTC) Received: by mail-qg0-f43.google.com with SMTP id a108so6731874qge.30 for ; Fri, 01 Aug 2014 16:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=7UvaUUf88mQuPNFZ/9qQ3t+9nELIWDwksroc+mUpG2c=; b=CdIxXALVuYiwZayIvfYoBIoTdcfPmiirixGZMKuYbXbLWtyoP245r8R9FFgPjcPb8w beSmBCqWXGznV+kw1UGwZp2FQ0mxhOkDRqIGb9dNgu3iJdQEKhLNwORY3mkt2IFw2gOQ vAsa3cs0ilKOBV3nx1+lKOzW2Y9YC8JNvZhpO0VoKjFYUDmaYVNk9PnVkuTfVpUi7tbL Oj8d9Oo4WQLdG8Aj3wYmJEdV6DnI5zzWTLtm35KobGNvxI8KGpMENQYV/FPFGwdOpum6 KCVsz6zWbH+unI5fErsl0dPMX4/jgI3KhRPmCdO/cFq91Y2XPUkOlOodhlAARhRZrUXe cHDQ== MIME-Version: 1.0 X-Received: by 10.224.171.197 with SMTP id i5mr14903326qaz.55.1406936753405; Fri, 01 Aug 2014 16:45:53 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Fri, 1 Aug 2014 16:45:53 -0700 (PDT) In-Reply-To: <20140801234253.GK50495@funkthat.com> References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> <20140802005520.29ca841b@x23> <20140801234253.GK50495@funkthat.com> Date: Fri, 1 Aug 2014 16:45:53 -0700 X-Google-Sender-Auth: khnUh4uZy6ukejeDJI_C9Mo6LHY Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Adrian Chadd To: Adrian Chadd , Marko Zec , freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 01 Aug 2014 23:45:54 -0000 On 1 August 2014 16:42, John-Mark Gurney wrote: > Adrian Chadd wrote this message on Fri, Aug 01, 2014 at 16:25 -0700: >> On 1 August 2014 15:55, Marko Zec wrote: >> > On Fri, 1 Aug 2014 15:42:30 -0700 >> > Adrian Chadd wrote: >> > >> >> I'd just make it a panic. :) >> > >> > Are you prepared to say goodbye to kldloading netgraph at runtime? >> >> Well, why is it saying that? is there actually a problem? > > Please read the thread. Thanks. I've read the thread. I wanted to see what the reactions are. The linked message thread has much more useful information than this thread. Ie, there's some table that isn't lock protected and likely should be. -a From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 00:30:19 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6762BB33 for ; Sat, 2 Aug 2014 00:30:19 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3918B2CFA for ; Sat, 2 Aug 2014 00:30:19 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h3so2485799igd.14 for ; Fri, 01 Aug 2014 17:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=AEga5cExQBvYCZUMJnv5pQ9Wsj30d0K26mORsXCjVuA=; b=Eyk9QocLxcdWFS71evPQTuRfijISz8H+PuG1yMFcNw35kkvk4Pa7qj/MbW25LC3Zm1 ptyQasORGg2il/sjQuaP5W1wCJ6x+BHSQQX64BlZS2eDfy3uxWDhR2GNv/+4eLmxqlgI M0BhHspUGuPlGBn+5x6Sxi/yhFOq02oaVnwKIZAg+qXUolmE9hLtZYehLPJhRNuDfflb f5KiNEePgtWQbCJkdWqZz6nbPJj6C12n2ZF2gE9ptb/3kHM1d2ycfPLzheQxp4d/fann F9D6jWizOBxr4H7d47LQ7ykxA3/NwNnoBHBMjEDZF5LfXY29oTpbtbq1QkazT3EPO0cz ydvQ== MIME-Version: 1.0 X-Received: by 10.50.112.1 with SMTP id im1mr11986688igb.33.1406939418349; Fri, 01 Aug 2014 17:30:18 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.107.131.38 with HTTP; Fri, 1 Aug 2014 17:30:18 -0700 (PDT) In-Reply-To: <20140801211845.GG50495@funkthat.com> References: <20140801211845.GG50495@funkthat.com> Date: Fri, 1 Aug 2014 20:30:18 -0400 X-Google-Sender-Auth: tcG9NKYlFZDYPz-7Y23hH_uYunc Message-ID: Subject: Re: comments on vt as console... From: Ed Maste To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 00:30:19 -0000 On 1 August 2014 17:18, John-Mark Gurney wrote: > So, I decided to play around w/ vt after the recent UTF-8 discussion, > and noticed some issues w/ it... > > First, if you load the gallant font, things don't look very good... This > is probably because of the fact that I'm using the vga driver: > VT: running with driver "vga". Yes, this is an issue with vt_vga, and affects fonts other than a multiple of 8 pixels wide. It's pr191591. > Second, once one vty has the gallant font loaded, if you switch vty's, > it can occure that the new vty does not display ANY text.. The display > is mostly blank... > > Third, w/ the other font loaded, the border doesn't always properly > get cleared... > > Fourth, when switching screens, there is a brief flash of vertical > stripes before the new screen comes on... Can we do something to make > sure that this transition is clean? Either a completely blank screen, > or ideally, no blank screen, but the new text appearing? I think #2 and #4 are variations on the same issue, and only affect vt_vga as far as I know. Can you submit a PR for that issue, and one for #3? From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 04:13:56 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD0439BD; Sat, 2 Aug 2014 04:13:56 +0000 (UTC) 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 7A9662495; Sat, 2 Aug 2014 04:13:55 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-253-202.lns20.per2.internode.on.net [121.45.253.202]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s724Dh8b032311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Aug 2014 21:13:47 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <53DC6571.1080202@freebsd.org> Date: Sat, 02 Aug 2014 12:13:37 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: krad , Gleb Smirnoff Subject: Re: Future of pf / firewall in FreeBSD ? - does it have one ? References: <53C706C9.6090506@com.jkkn.dk> <6326AB9D-C19A-434B-9681-380486C037E2@lastsummer.de> <53CB4736.90809@bluerosetech.com> <201407200939020335.0017641F@smtp.24cl.home> <788274E2-7D66-45D9-89F6-81E8C2615D14@lastsummer.de> <201407201230590265.00B479C4@smtp.24cl.home> <20140729103512.GC89995@FreeBSD.org> <53DA304E.6020105@herveybayaustralia.com.au> <20140731134147.GH2402@glebius.int.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, FreeBSD Questions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 04:13:56 -0000 On 8/1/14, 3:39 PM, krad wrote: > I always found natting in ipfw rather awkward and harder than in pf. > Looking at the man page it doesnt seem to have changed. I should probably > give it another go though as it has been about 10 years now since ipfw now has a 'nat' keyword you might say that is has changed in that 10 years. > From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 09:40:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5D9C5DB; Sat, 2 Aug 2014 09:40:04 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78BC92839; Sat, 2 Aug 2014 09:40:04 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id f51so6730197qge.39 for ; Sat, 02 Aug 2014 02:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=8IAdaKslnIZn10Sm9Ta60kc8Pk9V/U4k1e16mrD0R2o=; b=YQssxVmrSypbMDOS7TzHIT5W2uzngo/RCMfJ1dvkT/OYLQyQXt4+k+bHpZ/k8tec6T eRQOr+SoiJwUrSVVRP9Lgg35iev7CST2re6svk8CaS3Y20doLkTEvenaYDcNSlEgt7kG DOfjm8CpwGgcXqiLoxjhQuUtx69+R71y3Dq1SkeovyP6DK66BKIrim/jB9z+GXl/O+NS HLl2289xRyd720lDUUzyrhps1a5hOtk7o+TUK+dnsmCt7bCElyqgOvxIu0VjHuCOrMKf aHzqizo3q5Dd0gT58GHIyWHlQ7LmHTZp5bAE8HhLGwuRD2CLXeQSy+Xpmk/D6qkjOLQ2 z9Og== X-Received: by 10.229.211.132 with SMTP id go4mr17470792qcb.0.1406972403527; Sat, 02 Aug 2014 02:40:03 -0700 (PDT) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.96.198.227 with HTTP; Sat, 2 Aug 2014 02:39:43 -0700 (PDT) From: Fedor Indutny Date: Sat, 2 Aug 2014 13:39:43 +0400 X-Google-Sender-Auth: 9llRlbfxgOIvFJt-6R3cRu5BLQE Message-ID: Subject: KQueue 0-length UDP packet To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 09:40:05 -0000 Hello! I'm trying to figure out, why this code: https://github.com/indutny/0-udp Which basically sends a 0-length UDP packet to a server and polls kqueue events on the server fd. Return 1 kevent on FreeBSD, and blocks indefinitely without returning any events on OSX. So far I could see that FreeBSD and OSX are treating NOTE_LOWAT differently: * https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 * https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not involved here by default, I'm failing to see where exactly this event could pass through kqueue filter. Could anyone with UDP and/or KQueue implementation knowledge share some insights with me? Thank you very much! Fedor. (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed to the ML) From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 10:41:48 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FA71355; Sat, 2 Aug 2014 10:41:48 +0000 (UTC) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40509210B; Sat, 2 Aug 2014 10:41:48 +0000 (UTC) Received: by mail-qa0-f49.google.com with SMTP id dc16so5010224qab.22 for ; Sat, 02 Aug 2014 03:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=pUvlUmoH6gqwFdCgf1z+dVBlJvqBS5DrKRCd3reGE94=; b=ajcWe0dN0hjMAtZ0GIU2C8dvPKLrn3JiTVGdAZs51xP/3Ddp1cfwY9uORfOgI+Dvoo ouaz7ahXBlLLfhEQwR70xNNXLMpebLi5pGTbtBXapKd81/7jzyQsNT9ULfc6rP5MyEoN c0ScvcBKXturU/SMrJqKtr4YNt8BvD/p2D6Le07qXCTxBaDlwHxXzhLHcvH3eKtqYmZR uINajmgwCJJxDwpk2IAjIW0DhUICWu2dH/7hKTehWTN8IXnb1SNwwlFUifDbO+be8RVs EkrDULX5t3R3BJXV23b4rOShW7BcRTOCbSP/nG9sYisQNxTjjpwUSyHJiFp9KF8voA6D yx9A== X-Received: by 10.140.42.181 with SMTP id c50mr6496180qga.17.1406976107243; Sat, 02 Aug 2014 03:41:47 -0700 (PDT) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.96.198.227 with HTTP; Sat, 2 Aug 2014 03:41:27 -0700 (PDT) In-Reply-To: References: From: Fedor Indutny Date: Sat, 2 Aug 2014 14:41:27 +0400 X-Google-Sender-Auth: MvhClYFHK9b7Gc2XjYWZnQ8-KC8 Message-ID: Subject: Re: KQueue 0-length UDP packet To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 10:41:48 -0000 Guess I know the answer: https://cloudup.com/cCkjLhI4M2r Basically, OSX is checking `kn_data` and FreeBSD is using `so->so_rcv.sb_cc`. Thank you anyway! On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: > Hello! > > I'm trying to figure out, why this code: > > https://github.com/indutny/0-udp > > Which basically sends a 0-length UDP packet to a server and polls > kqueue events on the server fd. > > Return 1 kevent on FreeBSD, and blocks indefinitely without > returning any events on OSX. > > So far I could see that FreeBSD and OSX are treating NOTE_LOWAT > differently: > > * > https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 > * > https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 > > FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using > SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not > involved here by default, I'm failing to see where exactly this > event could pass through kqueue filter. > > Could anyone with UDP and/or KQueue implementation knowledge > share some insights with me? > > Thank you very much! > Fedor. > > (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed > to the ML) > From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 10:57:43 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7182D4F5; Sat, 2 Aug 2014 10:57:43 +0000 (UTC) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 213F221D1; Sat, 2 Aug 2014 10:57:43 +0000 (UTC) Received: by mail-qa0-f42.google.com with SMTP id j15so5091546qaq.29 for ; Sat, 02 Aug 2014 03:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=45i4zSYmoNwbNkkvswWj1t2I+/OpN9kg5cfiDexCQH0=; b=eKvhIfytxkrSrH27fjhng46fvo8Ffo+twmU/G4VIR4X58HkfPxpbek0xWCLmWB/iej SmDj1LmFiqTk8N17M0kVIXhylGWXrVGuwR0GeilxMfBhqsSi5siCrZAwywbkxQb3LT6L v26ReGt4rwjv5yqueG5GU1fWNiRNyjbqegv/5MjdP5CCJqpQKyaIVyZw7odJUnW4lqI/ 1guXHhCChzzIcxj8R4KFlRgbC9HClL9SVn60zXKCUrnVCs3p4UQTVrTqzTuuhJl6XY2V UgwLSwFhBVqKjVvgYdfc4FZlcOWqqFsTbAPCq3sIIznV5OEV8eV5yPNabCYx9acNdia2 k3qQ== X-Received: by 10.224.151.138 with SMTP id c10mr17846672qaw.41.1406977062288; Sat, 02 Aug 2014 03:57:42 -0700 (PDT) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.96.198.227 with HTTP; Sat, 2 Aug 2014 03:57:22 -0700 (PDT) In-Reply-To: References: From: Fedor Indutny Date: Sat, 2 Aug 2014 14:57:22 +0400 X-Google-Sender-Auth: cfhYyN8lyr7Gq9ZKU2SyABHURpE Message-ID: Subject: Re: KQueue 0-length UDP packet To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: Mark Johnston X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 10:57:43 -0000 After reading that line more carefully, I wonder if this behavior is really intentional here. It seems to me that `SO_RCVLOWAT` is supposed to set watermark value in terms of packet data bytes, not just raw packet size. And this is how `NOTE_LOWAT` actually works there, right? Could anyone please comment on this? Is it a bug? ---------------------- Regarding OSX: Submitted Apple Bug # 17894467 , with a patch. If anyone has friends at Apple who could help getting this in, please let me know! Cheers, Fedor. On Sat, Aug 2, 2014 at 2:41 PM, Fedor Indutny wrote: > Guess I know the answer: > > https://cloudup.com/cCkjLhI4M2r > > Basically, OSX is checking `kn_data` and FreeBSD is using > `so->so_rcv.sb_cc`. > > Thank you anyway! > > > On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: > >> Hello! >> >> I'm trying to figure out, why this code: >> >> https://github.com/indutny/0-udp >> >> Which basically sends a 0-length UDP packet to a server and polls >> kqueue events on the server fd. >> >> Return 1 kevent on FreeBSD, and blocks indefinitely without >> returning any events on OSX. >> >> So far I could see that FreeBSD and OSX are treating NOTE_LOWAT >> differently: >> >> * >> https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461 >> * >> https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164 >> >> FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using >> SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not >> involved here by default, I'm failing to see where exactly this >> event could pass through kqueue filter. >> >> Could anyone with UDP and/or KQueue implementation knowledge >> share some insights with me? >> >> Thank you very much! >> Fedor. >> >> (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed >> to the ML) >> > > From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 13:20:50 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D44CD4D for ; Sat, 2 Aug 2014 13:20:50 +0000 (UTC) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E6E72F53 for ; Sat, 2 Aug 2014 13:20:50 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id v10so5088527qac.19 for ; Sat, 02 Aug 2014 06:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YWhjRMRfDnMgWHLrMlJCMMvTu5SuQ3ei2kG+bDzXiz8=; b=0ajhej8AHXdytyLaZJBnPq2JDrvYnR0UZcmVZYxu/i+riojEQa7dgxscWt59XbpV4y u35G4AR5V3fm/abY3Yw6uo6vaNR5xuBTyvZGHHjd9TZom2XZvlZOP69jg6u+P6NgXzNG NHKSya07PqATj8pjSVlJBv/QmvaTPSYsjFjFOFmAxt3ZhjyA+h75qI/WJKSj3pMvqa3f +pmcBBNSRluzwLS1g4nbd4Il1NQWW1orL3zqus3+5MhwQ1ADa3TMbMOqMdHHI/Jfoj+g 17nx49Q+UN7lEF1GtrCuKvhOn8fvkaAaQeIhcIFPnUPEqxAuuIBIcPL0Q91i4JmylV4P 9xoA== MIME-Version: 1.0 X-Received: by 10.140.41.133 with SMTP id z5mr17894188qgz.99.1406985649178; Sat, 02 Aug 2014 06:20:49 -0700 (PDT) Received: by 10.140.48.2 with HTTP; Sat, 2 Aug 2014 06:20:49 -0700 (PDT) In-Reply-To: <20140801222118.GH50495@funkthat.com> References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> Date: Sat, 2 Aug 2014 15:20:49 +0200 Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Svatopluk Kraus To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: John-Mark Gurney X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 13:20:50 -0000 Well, I did not look at network stack for long time, so the following things could be obsolete now, but at least: (1) There is some room left in mbuf header on its allocation, so protocols (link) headers can be added in the front of data without need of reallocation or data copying. The size of the room is evaluated from all domains at boot time. (2) All network address masks are shared among domains and protocols in mask radix tree. The tree is created with particular key size, which is again evaluated from all domains as maximal size of all known addresses. So, if new domain added after these evaluations does not break both them and some other things, there is no problem. Otherwise, some warnings are always nice if things go bad. Maybe some function which examine new domain and say there is no risk to add it would be nice. Svata On Sat, Aug 2, 2014 at 12:21 AM, John-Mark Gurney wrote: > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200: > > Just what I've got in January 2011: > > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html > > Sadly, after three (or six+) years, it is clear that these bugs will > not be fixed, and this warning message is not useful, since no one has > stepped up to fix them.. > > btw, you might want to create a bug w/ the information you tracked down > to hopefully help the person that decides to finally fix them, though > I doubt they will ever be fixed as people apparently don't see bad > behavior... > > Unless someone fixes the bugs in the next few days, I will commit the > following patch: > Index: uipc_domain.c > =================================================================== > --- uipc_domain.c (revision 266964) > +++ uipc_domain.c (working copy) > @@ -227,15 +227,10 @@ > printf("WARNING: attempt to domain_add(%s) before " > "domaininit()\n", dp->dom_name); > #endif > -#ifdef notyet > - KASSERT(domain_init_status < 2, > - ("attempt to domain_add(%s) after domainfinalize()", > - dp->dom_name)); > -#else > - if (domain_init_status >= 2) > - printf("WARNING: attempt to domain_add(%s) after " > - "domainfinalize()\n", dp->dom_name); > -#endif > + /* > + * XXX - there are bugs WRT to adding domain after domain_finalize > is > + * called > + */ > mtx_unlock(&dom_mtx); > } > > > > On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney > wrote: > > > > > So, I have a laptop that devd loads the bluetooth module every time.. > > > > > > This means I get the following error on every boot: > > > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > > > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > > > > > Is there any real benefit to this warning? I just looked at the code, > > > and the domain gets added despite the warning... > > > > > > Also, it looks like the pervious warning, we should just make that an > > > if/panic since it's clearly a programming bug, or kill the ifndef > > > INVARIANTS... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 18:33:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7D804766 for ; Sat, 2 Aug 2014 18:33:08 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 586CF2015 for ; Sat, 2 Aug 2014 18:33:08 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s72IWxSG069458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Aug 2014 11:33:00 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s72IWxT2069457; Sat, 2 Aug 2014 11:32:59 -0700 (PDT) (envelope-from jmg) Date: Sat, 2 Aug 2014 11:32:59 -0700 From: John-Mark Gurney To: Svatopluk Kraus Subject: Re: domain_add(xxx) after domainfinalize... Message-ID: <20140802183259.GL50495@funkthat.com> Mail-Followup-To: Svatopluk Kraus , freebsd-current@freebsd.org References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 02 Aug 2014 11:33:00 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 18:33:08 -0000 Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 15:20 +0200: > Well, I did not look at network stack for long time, so the following > things could be obsolete now, but at least: > > (1) There is some room left in mbuf header on its allocation, so protocols > (link) headers can be added in the front of data without need of > reallocation or data copying. The size of the room is evaluated from all > domains at boot time. > > (2) All network address masks are shared among domains and protocols in > mask radix tree. The tree is created with particular key size, which is > again evaluated from all domains as maximal size of all known addresses. > > So, if new domain added after these evaluations does not break both them > and some other things, there is no problem. Otherwise, some warnings are > always nice if things go bad. But would anyone who sees these issues know that this is the problem? And what would they do, report the problem? We'd say, yeh, we know, but do you hit this every day? Nope, ok, we won't fix it... > Maybe some function which examine new domain and say there is no risk to > add it would be nice. I agree... These things should have been done in the first place, but clearly this warning wasn't enough to cause anyone to fix it.. :) > On Sat, Aug 2, 2014 at 12:21 AM, John-Mark Gurney wrote: > > > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200: > > > Just what I've got in January 2011: > > > > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html > > > > Sadly, after three (or six+) years, it is clear that these bugs will > > not be fixed, and this warning message is not useful, since no one has > > stepped up to fix them.. > > > > btw, you might want to create a bug w/ the information you tracked down > > to hopefully help the person that decides to finally fix them, though > > I doubt they will ever be fixed as people apparently don't see bad > > behavior... > > > > Unless someone fixes the bugs in the next few days, I will commit the > > following patch: > > Index: uipc_domain.c > > =================================================================== > > --- uipc_domain.c (revision 266964) > > +++ uipc_domain.c (working copy) > > @@ -227,15 +227,10 @@ > > printf("WARNING: attempt to domain_add(%s) before " > > "domaininit()\n", dp->dom_name); > > #endif > > -#ifdef notyet > > - KASSERT(domain_init_status < 2, > > - ("attempt to domain_add(%s) after domainfinalize()", > > - dp->dom_name)); > > -#else > > - if (domain_init_status >= 2) > > - printf("WARNING: attempt to domain_add(%s) after " > > - "domainfinalize()\n", dp->dom_name); > > -#endif > > + /* > > + * XXX - there are bugs WRT to adding domain after domain_finalize > > is > > + * called > > + */ > > mtx_unlock(&dom_mtx); > > } > > > > > > > On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney > > wrote: > > > > > > > So, I have a laptop that devd loads the bluetooth module every time.. > > > > > > > > This means I get the following error on every boot: > > > > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > > > > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > > > > > > > Is there any real benefit to this warning? I just looked at the code, > > > > and the domain gets added despite the warning... > > > > > > > > Also, it looks like the pervious warning, we should just make that an > > > > if/panic since it's clearly a programming bug, or kill the ifndef > > > > INVARIANTS... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 19:27:04 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCB602DA for ; Sat, 2 Aug 2014 19:27:04 +0000 (UTC) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7B26B24DE for ; Sat, 2 Aug 2014 19:27:04 +0000 (UTC) Received: by mail-qg0-f50.google.com with SMTP id q108so7233322qgd.23 for ; Sat, 02 Aug 2014 12:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=22QmvO6Vsg7P6l7Pl5jDtO+gNk3I+63pxe7BCB9J0cs=; b=qP6/0Onue4AAKEXyd98rwFMFhuNlV0TyTdBIBuOEs4Eg8Cj5HDJ6CXzmqHWRfKYKsO D344MJd9v4jjTDs4fG4cFU92QMz2DGSugkgQlLyLORIMyP/EpFpVWXSFiPrT3OIU3S00 QO/6y3ThEHjyrmpBbQEzZdktf5ckS3PRzr20qgsfGubvoLDSMzGxhZOqx0c6jH4VDdVh +6lqg9GRLea/ZFYQJfFkYgVWmXq1/l3Lq9ePSx0SIYVaQk0UA3SFeYyC08JycTP61uZG RcwE5T2/NrWv1XuGYMEjE31Po+bY8ayNPdwJdeuCOowkE5C/8DzUArnWVn5FJTw9eH+a 9gUQ== MIME-Version: 1.0 X-Received: by 10.140.27.108 with SMTP id 99mr20661539qgw.77.1407007623184; Sat, 02 Aug 2014 12:27:03 -0700 (PDT) Received: by 10.140.48.2 with HTTP; Sat, 2 Aug 2014 12:27:03 -0700 (PDT) In-Reply-To: <20140802183259.GL50495@funkthat.com> References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> <20140802183259.GL50495@funkthat.com> Date: Sat, 2 Aug 2014 21:27:03 +0200 Message-ID: Subject: Re: domain_add(xxx) after domainfinalize... From: Svatopluk Kraus To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: John-Mark Gurney X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 19:27:04 -0000 On Sat, Aug 2, 2014 at 8:32 PM, John-Mark Gurney wrote: > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 15:20 +0200: > > Well, I did not look at network stack for long time, so the following > > things could be obsolete now, but at least: > > > > (1) There is some room left in mbuf header on its allocation, so > protocols > > (link) headers can be added in the front of data without need of > > reallocation or data copying. The size of the room is evaluated from all > > domains at boot time. > > > > (2) All network address masks are shared among domains and protocols in > > mask radix tree. The tree is created with particular key size, which is > > again evaluated from all domains as maximal size of all known addresses. > > > > So, if new domain added after these evaluations does not break both them > > and some other things, there is no problem. Otherwise, some warnings are > > always nice if things go bad. > > But would anyone who sees these issues know that this is the problem? > And what would they do, report the problem? We'd say, yeh, we know, > but do you hit this every day? Nope, ok, we won't fix it... > > > Maybe some function which examine new domain and say there is no risk to > > add it would be nice. > > I agree... These things should have been done in the first place, but > clearly this warning wasn't enough to cause anyone to fix it.. :) > You are right, but the warning is remainder that there is something unresolved. Remove the warning and forget, imho, it's not well. Anyhow, when I asked the question in January 2011, I did not really mean to remove the warning. I was mainly aware if I did not miss something what could screw up things. Svata > > > On Sat, Aug 2, 2014 at 12:21 AM, John-Mark Gurney > wrote: > > > > > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 00:05 +0200: > > > > Just what I've got in January 2011: > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-hackers/2011-January/034037.html > > > > > > Sadly, after three (or six+) years, it is clear that these bugs will > > > not be fixed, and this warning message is not useful, since no one has > > > stepped up to fix them.. > > > > > > btw, you might want to create a bug w/ the information you tracked down > > > to hopefully help the person that decides to finally fix them, though > > > I doubt they will ever be fixed as people apparently don't see bad > > > behavior... > > > > > > Unless someone fixes the bugs in the next few days, I will commit the > > > following patch: > > > Index: uipc_domain.c > > > =================================================================== > > > --- uipc_domain.c (revision 266964) > > > +++ uipc_domain.c (working copy) > > > @@ -227,15 +227,10 @@ > > > printf("WARNING: attempt to domain_add(%s) before " > > > "domaininit()\n", dp->dom_name); > > > #endif > > > -#ifdef notyet > > > - KASSERT(domain_init_status < 2, > > > - ("attempt to domain_add(%s) after domainfinalize()", > > > - dp->dom_name)); > > > -#else > > > - if (domain_init_status >= 2) > > > - printf("WARNING: attempt to domain_add(%s) after " > > > - "domainfinalize()\n", dp->dom_name); > > > -#endif > > > + /* > > > + * XXX - there are bugs WRT to adding domain after > domain_finalize > > > is > > > + * called > > > + */ > > > mtx_unlock(&dom_mtx); > > > } > > > > > > > > > > On Fri, Aug 1, 2014 at 9:34 PM, John-Mark Gurney > > > wrote: > > > > > > > > > So, I have a laptop that devd loads the bluetooth module every > time.. > > > > > > > > > > This means I get the following error on every boot: > > > > > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > > > > > WARNING: attempt to domain_add(netgraph) after domainfinalize() > > > > > > > > > > Is there any real benefit to this warning? I just looked at the > code, > > > > > and the domain gets added despite the warning... > > > > > > > > > > Also, it looks like the pervious warning, we should just make that > an > > > > > if/panic since it's clearly a programming bug, or kill the ifndef > > > > > INVARIANTS... > > -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > From owner-freebsd-current@FreeBSD.ORG Sat Aug 2 20:01:51 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E93F916 for ; Sat, 2 Aug 2014 20:01:51 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E965627BD for ; Sat, 2 Aug 2014 20:01:50 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s72K1nHL070804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Aug 2014 13:01:49 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s72K1n7k070803; Sat, 2 Aug 2014 13:01:49 -0700 (PDT) (envelope-from jmg) Date: Sat, 2 Aug 2014 13:01:49 -0700 From: John-Mark Gurney To: Svatopluk Kraus Subject: Re: domain_add(xxx) after domainfinalize... Message-ID: <20140802200149.GO50495@funkthat.com> Mail-Followup-To: Svatopluk Kraus , freebsd-current@freebsd.org References: <20140801193403.GE50495@funkthat.com> <20140801222118.GH50495@funkthat.com> <20140802183259.GL50495@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 02 Aug 2014 13:01:50 -0700 (PDT) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 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, 02 Aug 2014 20:01:51 -0000 Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 21:27 +0200: > On Sat, Aug 2, 2014 at 8:32 PM, John-Mark Gurney wrote: > > > Svatopluk Kraus wrote this message on Sat, Aug 02, 2014 at 15:20 +0200: > > > Well, I did not look at network stack for long time, so the following > > > things could be obsolete now, but at least: > > > > > > (1) There is some room left in mbuf header on its allocation, so > > protocols > > > (link) headers can be added in the front of data without need of > > > reallocation or data copying. The size of the room is evaluated from all > > > domains at boot time. > > > > > > (2) All network address masks are shared among domains and protocols in > > > mask radix tree. The tree is created with particular key size, which is > > > again evaluated from all domains as maximal size of all known addresses. > > > > > > So, if new domain added after these evaluations does not break both them > > > and some other things, there is no problem. Otherwise, some warnings are > > > always nice if things go bad. > > > > But would anyone who sees these issues know that this is the problem? > > And what would they do, report the problem? We'd say, yeh, we know, > > but do you hit this every day? Nope, ok, we won't fix it... > > > > > Maybe some function which examine new domain and say there is no risk to > > > add it would be nice. > > > > I agree... These things should have been done in the first place, but > > clearly this warning wasn't enough to cause anyone to fix it.. :) > > You are right, but the warning is remainder that there is something > unresolved. Remove the warning and forget, imho, it's not well. Sorry, nine years[1] of the warning existing yet no fix clearly demonstrates that it's already been forgoten, otherwise it would have been fixed by now.. Also, a bug report or XXX comment is enough IMO, and will probably receive the same amount of attention over the next nine years... [1] https://svnweb.freebsd.org/changeset/base/138239 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."