From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 8 21:51:33 2012 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB92E106566B; Sun, 8 Jan 2012 21:51:33 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3ACE8FC0A; Sun, 8 Jan 2012 21:51:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q08LpXLt079607; Sun, 8 Jan 2012 21:51:33 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q08LpXJG079606; Sun, 8 Jan 2012 21:51:33 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Sun, 8 Jan 2012 22:51:29 +0100 From: Baptiste Daroussin To: current@FreeBSD.org, hackers@FreeBSD.org Message-ID: <20120108215129.GA77039@azathoth.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: flex or reflex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 21:51:33 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I am willing to update our flex in base, my first motivation is to be able to have reentrant lexer in base, I first went to the http://flex.sourceforge.net derivative from flex 2.5.4, I've imported it in contrib, and I'm able to build the whole base using the 2.5.35 version (almost vanilla) and with just one or two small fixes from from .l files (mostly adding %option nounistd to fix warnings) One of the major "problem" of this version is that it uses m4 (it is compatible with our m4 version in base - the recently updated one). Another alternative is to use reflex (http://www.invisible-island.net/reflex/reflex.html) which seems a good one because, it is more respectful of the POSIX lex unfortunately it doesn't seem to be able to create reentrant lexer. Given this, I think it is better for us to choose flex. Of course it is still possible to add reentrant feature to our flex, but it would be more painful. After this I plan to import byacc http://www.invisible-island.net/byacc/byacc.html which can generate reentrant parser. regards, Bapt --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk8KD+EACgkQ8kTtMUmk6EyiXACglK0W+uALd7MIRAu3reItkShs uR4An04psiQyxSHWLJYjWL4268o13qsW =xJks -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 9 17:44:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782E41065672; Mon, 9 Jan 2012 17:44:36 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F1018FC1D; Mon, 9 Jan 2012 17:44:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=xcCxe4SNUXAy5EgtNiPCEpOgme09V92IFwTL4nxHa2M=; b=V9ERe0mnIyaLiLC29YbzTZaFp8/XqfozWn2W/HlpRB/QYucQugtWr27x1x5ekBRWN12h30eOO/SrbN5Xy797nUZBDe0RzEXaDUcagv2wTyNAUhRMiO6atnyoHCAjHQA1; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RkJGp-00085m-9X; Mon, 09 Jan 2012 11:44:35 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1326131065-88972-88971/5/9; Mon, 9 Jan 2012 17:44:25 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org References: <20120107.211122.2051906580877809031.hrs@allbsd.org> <891fe25c-1560-479f-b855-1713c1c7a976@email.android.com> <20120108.052346.1749642548460957219.hrs@allbsd.org> Date: Mon, 9 Jan 2012 11:44:25 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120108.052346.1749642548460957219.hrs@allbsd.org> User-Agent: Opera Mail/11.61 (FreeBSD) X-SA-Score: -1.0 Cc: hrs@FreeBSD.org Subject: Re: accepting rtadv broken on 9-STABLE, re driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:44:36 -0000 On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato wrote: > It is an unexpected behavior and the flag should be set on all > interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and > the result of "ifconfig -a"? Back at work so I have access to the machine again: rc.conf: hostname="tech304.office.xxx.net" ifconfig_re0="inet 192.168.93.23/24" defaultrouter="192.168.93.1" ipv6_activate_all_interfaces="YES" ipv6_ifconfig_re0="inet6 accept_rtadv" sshd_enable="YES" linux_enable="YES" ntpd_enable="YES" ntpdate_enable="YES" vboxnet_enable="YES" tcp_drop_synfin="YES" icmp_log_redirect="YES" update_motd="NO" dbus_enable="YES" hald_enable="YES" moused_enable="NO" moused_nondefault_enable="NO" oss_enable="NO" #nginx nginx_enable="YES" fcgiwrap_enable="YES" fcgiwrap_user="www" samba_enable="YES" #samba_config="/usr/local/etc/samba34/smb.conf" lpd_enable="YES" #slim_enable="YES" exim_enable="YES" sendmail_enable="NONE" nfs_client_enable="YES" smartd_enable="YES" zfs_enable="YES" sysctl.conf: # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 net.inet.tcp.drop_synfin=1 net.inet.icmp.log_redirect=1 vfs.usermount=1 net.inet6.ip6.accept_rtadv=1 # ifconfig -a 11:43:29 tech304:~ > ifconfig -a re0: flags=8943 metric 0 mtu 1500 options=209b ether d0:67:e5:17:e1:32 inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 inet 192.168.93.23 netmask 0xffffff00 broadcast 192.168.93.255 inet6 2607:f4e0:100:104:d267:e5ff:fe17:e132 prefixlen 64 autoconf nd6 options=23 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 nd6 options=23 Regards, Mark From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 9 20:06:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DAAD106566C for ; Mon, 9 Jan 2012 20:06:46 +0000 (UTC) (envelope-from lenny@Colorado.EDU) Received: from ipmx2.colorado.edu (ipmx2.colorado.edu [128.138.128.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6688FC18 for ; Mon, 9 Jan 2012 20:06:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAPQ+C0/AqBGb/2dsb2JhbABDrViCMxyCCIdulnOWcIkFiHeCN2MEiDmfKQ X-IronPort-AV: E=Sophos;i="4.71,481,1320649200"; d="scan'208";a="488813753" Received: from omr-raz-2-priv.int.colorado.edu ([192.168.17.155]) by ipmx2-priv.int.colorado.edu with ESMTP; 09 Jan 2012 12:38:10 -0700 Received: from 67.51.249.130 (EHLO _10.126.1.146_) ([67.51.249.130]) by omr-raz-2-priv.int.colorado.edu (MOS 4.1.10-GA FastPath queued) with ESMTP id CUW36902 (AUTH maiorani); Mon, 09 Jan 2012 12:38:09 -0700 (MST) From: Lenny Maiorani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jan 2012 12:38:08 -0700 Message-Id: <502112AF-3908-429C-9DA4-B1D0E94EB9DE@colorado.edu> To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: building on FreeBSD 7.3 with Clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:06:46 -0000 Hi. I am trying to build a userspace application on FreeBSD 7.3 with Clang. = I have come across 2 problems so far and I am looking for any tips or = guidance the community has. My problems are both related to binutils so far: 1. Missing symbols : http://llvm.org/bugs/show_bug.cgi?id=3D9758 2. crtendS.o problem : = http://sourceware.org/bugzilla/show_bug.cgi?id=3D12887 At this point I need to rebuild my toolchain to get a new crtendS.o. Are = there other pitfalls I need to be aware of? Thanks, -Lenny From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 9 20:55:08 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA7DD1065673; Mon, 9 Jan 2012 20:55:08 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 98B398FC08; Mon, 9 Jan 2012 20:55:07 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q09KsjFI062746; Tue, 10 Jan 2012 05:54:55 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q09Kshdv068425; Tue, 10 Jan 2012 05:54:45 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 10 Jan 2012 04:02:24 +0900 (JST) Message-Id: <20120110.040224.1057547871207328114.hrs@allbsd.org> To: feld@feld.me From: Hiroki Sato In-Reply-To: References: <891fe25c-1560-479f-b855-1713c1c7a976@email.android.com> <20120108.052346.1749642548460957219.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Jan_10_04_02_24_2012_782)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Tue, 10 Jan 2012 05:54:58 +0900 (JST) X-Spam-Status: No, score=-103.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,FAKEDWORD_ZERO,QENCPTR1,RDNS_NONE,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: accepting rtadv broken on 9-STABLE, re driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:55:08 -0000 ----Security_Multipart(Tue_Jan_10_04_02_24_2012_782)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Felder wrote in : fe> On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato fe> wrote: fe> fe> > It is an unexpected behavior and the flag should be set on all fe> > interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and fe> > the result of "ifconfig -a"? fe> fe> Back at work so I have access to the machine again: (snip) fe> # ifconfig -a fe> fe> 11:43:29 tech304:~ > ifconfig -a fe> re0: flags=8943 metric fe> 0 mtu 1500 fe> options=209b fe> ether d0:67:e5:17:e1:32 fe> inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 fe> inet 192.168.93.23 netmask 0xffffff00 broadcast 192.168.93.255 fe> inet6 2607:f4e0:100:104:d267:e5ff:fe17:e132 prefixlen 64 autoconf fe> nd6 options=23 fe> media: Ethernet autoselect (100baseTX ) fe> status: active re0 seems to have ACCEPT_RTADV. What is the problem? fe> lo0: flags=8049 metric 0 mtu 16384 fe> options=3 fe> inet6 ::1 prefixlen 128 fe> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 fe> inet 127.0.0.1 netmask 0xff000000 fe> nd6 options=21 fe> vboxnet0: flags=8802 metric 0 mtu 1500 fe> ether 0a:00:27:00:00:00 fe> nd6 options=23 -- Hiroki ----Security_Multipart(Tue_Jan_10_04_02_24_2012_782)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8LOcAACgkQTyzT2CeTzy1K6wCdHmKjart3w8ky2Zi4HqfXlNiN s4kAn2nQRLHQ3j+foxOOBM3/74qSU3NK =fCdP -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Jan_10_04_02_24_2012_782)---- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 9 21:07:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CFA6106564A; Mon, 9 Jan 2012 21:07:14 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 216658FC13; Mon, 9 Jan 2012 21:07:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=7eIBfVd7LCXOYp1ezWltHqvuglG/nxN9dcuihy9xhEU=; b=NtaHO8HNLmd3d7Uf6jDWWrQZBdvh/bowVfY1WXpoQpQMeQp9vGfzVDAVAc58GjtqZRf1PfS0+mtG0e9TmOC/APvqRpzni0HYC3MmzhUaaM1fzfLFOeaTPj+UElA6oldO; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RkMQj-000Dfh-IR; Mon, 09 Jan 2012 15:07:13 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1326143211-88972-88971/5/10; Mon, 9 Jan 2012 21:06:51 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org References: <891fe25c-1560-479f-b855-1713c1c7a976@email.android.com> <20120108.052346.1749642548460957219.hrs@allbsd.org> <20120110.040224.1057547871207328114.hrs@allbsd.org> Date: Mon, 9 Jan 2012 15:06:51 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120110.040224.1057547871207328114.hrs@allbsd.org> User-Agent: Opera Mail/11.61 (FreeBSD) X-SA-Score: -1.0 Cc: Subject: Re: accepting rtadv broken on 9-STABLE, re driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 21:07:14 -0000 On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato wrote: > re0 seems to have ACCEPT_RTADV. What is the problem? That's because I haven't rebooted.... Let's start fresh. The normal ipv6 configuration anyone would use: -ipv6_activate_all_interfaces="YES" in rc.conf -NO mention of net.inet6.ip6.accept_rtadv in sysctl.conf I boot up, re0 *does not* have ACCEPT_RTADV. I try forcing via the sysctl: net.inet6.ip6.accept_rtadv=1 Still doesn't work! I finally have to result to: ifconfig re0 inet6 accept_rtadv Why? What makes this machine different? All the other machines I run do not require this to get ACCEPT_RTADV. Is it the re driver? My other machines have em and ath interfaces. Thanks, Mark From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 9 23:38:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F8321065672 for ; Mon, 9 Jan 2012 23:38:45 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by mx1.freebsd.org (Postfix) with ESMTP id 810FE8FC12 for ; Mon, 9 Jan 2012 23:38:45 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta14.emeryville.ca.mail.comcast.net with comcast id KZmE1i00A1smiN4AEbelKJ; Mon, 09 Jan 2012 23:38:45 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta20.emeryville.ca.mail.comcast.net with comcast id Kbej1i01L4NgCEG8gbekDv; Mon, 09 Jan 2012 23:38:44 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q09Ncg66025723 for ; Mon, 9 Jan 2012 16:38:42 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-hackers In-Reply-To: <201201051033.53081.jhb@freebsd.org> References: <1325715749.25037.36.camel@revolution.hippie.lan> <201201051033.53081.jhb@freebsd.org> Content-Type: text/plain Date: Mon, 09 Jan 2012 16:38:42 -0700 Message-Id: <1326152322.2199.42.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: trouble with atrtc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 23:38:45 -0000 On Thu, 2012-01-05 at 10:33 -0500, John Baldwin wrote: > On Wednesday, January 04, 2012 5:22:29 pm Ian Lepore wrote: > > [...] > > Because atrtc.c has a long and rich history of modifcations, some of > > them fairly recent, I thought it would be a good idea to toss out my > > ideas for changes here and solicit feedback up front, rather than just > > blindly posting a PR with a patch... > > > > It turns out to be very easy to probe for the latched-read behavior with > > just a few lines of code in atrtc_start(), so I'd propose doing that and > > setting a flag that the in/out code can use to disable the caching of > > the current register number on hardware that needs it. > > > > I'd like to add a new public function, atrtc_nmi_enable(int enable) that > > drivers can use to manipulate the NMI flag safely under clock_lock and > > playing nicely with the register number caching code. > > > > Completely unrelated but nice to have: I'd like to add a tuneable to > > control the use of inb(0x84) ops to insert delays after writing to 0x70 > > and 0x71. Modern hardware doesn't need this, so I think it should > > default to not inserting delays. > > > > I've done all these things in our local 8.2 code base and tested them on > > all the hardware I've got on hand. If these changes sound acceptable > > I'll prepare patches to -current as well. > > These changes all sound good to me. > Here is the patch for -current and 9. I can provide a patch to 8-stable as well; it's essentially the same patch with small context differences. I've tested this using -current on several systems, recent and old hardware, including manually bumping up the quality score for the rtc event timer to force it to get used, and it seems to work without trouble (and of course I've been testing the same patch in 8.2 for a while on a bunch of different hardware). Index: sys/isa/rtc.h =================================================================== RCS file: /local/base/FreeBSD-CVS/src/sys/isa/rtc.h,v retrieving revision 1.16.2.1 diff -u -p -r1.16.2.1 rtc.h --- sys/isa/rtc.h 23 Sep 2011 00:51:37 -0000 1.16.2.1 +++ sys/isa/rtc.h 9 Jan 2012 22:04:12 -0000 @@ -117,6 +117,7 @@ extern int atrtcclock_disable; int rtcin(int reg); void atrtc_restore(void); void writertc(int reg, u_char val); +void atrtc_nmi_enable(int enable); #endif #endif /* _I386_ISA_RTC_H_ */ Index: sys/x86/isa/atrtc.c =================================================================== RCS file: /local/base/FreeBSD-CVS/src/sys/x86/isa/atrtc.c,v retrieving revision 1.13.2.1 diff -u -p -r1.13.2.1 atrtc.c --- sys/x86/isa/atrtc.c 23 Sep 2011 00:51:37 -0000 1.13.2.1 +++ sys/x86/isa/atrtc.c 9 Jan 2012 22:04:12 -0000 @@ -55,28 +55,59 @@ __FBSDID("$FreeBSD: src/sys/x86/isa/atrt #define RTC_LOCK mtx_lock_spin(&clock_lock) #define RTC_UNLOCK mtx_unlock_spin(&clock_lock) +/* atrtcclock_disable is set to 1 by apm_attach() or by hint.atrtc.0.clock=0 */ int atrtcclock_disable = 0; -static int rtc_reg = -1; -static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; -static u_char rtc_statusb = RTCSB_24HR; +static int use_iodelay = 0; /* set from hint.atrtc.0.use_iodelay */ + +#define RTC_REINDEX_REQUIRED 0xffU +#define NMI_ENABLE_BIT 0x80U + +static u_char nmi_enable; +static u_char rtc_reg = RTC_REINDEX_REQUIRED; +static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; +static u_char rtc_statusb = RTCSB_24HR; + +/* + * Delay after writing to IO_RTC[+1] registers. Modern hardware doesn't + * require this expensive delay, so it's a tuneable that's disabled by default. + */ +static __inline void +rtc_iodelay(void) +{ + if (use_iodelay) + inb(0x84); +} /* * RTC support routines + * + * Most rtc chipsets let you write a value into the index register and then each + * read of the IO register obtains a new value from the indexed location. Others + * behave as if they latch the indexed value when you write to the index, and + * repeated reads keep returning the same value until you write to the index + * register again. atrtc_start() probes for this behavior and leaves rtc_reg + * set to RTC_REINDEX_REQUIRED if reads keep returning the same value. */ +static __inline void +rtcindex(u_char reg) +{ + if (rtc_reg != reg) { + if (rtc_reg != RTC_REINDEX_REQUIRED) + rtc_reg = reg; + outb(IO_RTC, reg | nmi_enable); + rtc_iodelay(); + } +} + int rtcin(int reg) { u_char val; RTC_LOCK; - if (rtc_reg != reg) { - inb(0x84); - outb(IO_RTC, reg); - rtc_reg = reg; - inb(0x84); - } + rtcindex(reg); val = inb(IO_RTC + 1); RTC_UNLOCK; return (val); @@ -87,14 +118,9 @@ writertc(int reg, u_char val) { RTC_LOCK; - if (rtc_reg != reg) { - inb(0x84); - outb(IO_RTC, reg); - rtc_reg = reg; - inb(0x84); - } + rtcindex(reg); outb(IO_RTC + 1, val); - inb(0x84); + rtc_iodelay(); RTC_UNLOCK; } @@ -104,12 +130,31 @@ readrtc(int port) return(bcd2bin(rtcin(port))); } +/* + * At start, probe read-without-reindex behavior. Reading RTC_INTR clears it; + * read until it has a non-zero value, then read it again without re-writing the + * index register. If 2nd read returns a different value it's safe to cache the + * current index with this chipset; enable by changing rtc_reg to current index. + */ static void atrtc_start(void) { + int status; - writertc(RTC_STATUSA, rtc_statusa); + writertc(RTC_STATUSA, RTCSA_DIVIDER | RTCSA_8192); writertc(RTC_STATUSB, RTCSB_24HR); + + RTC_LOCK; + do { + rtcindex(RTC_INTR); + status = inb(IO_RTC+1); + } while (status == 0); + + if (status != inb(IO_RTC+1)) + rtc_reg = RTC_INTR; + RTC_UNLOCK; + + writertc(RTC_STATUSA, RTCSA_DIVIDER | RTCSA_NOPROF); } static void @@ -139,6 +184,17 @@ atrtc_disable_intr(void) } void +atrtc_nmi_enable(int enable) +{ + /* Must not write to 0x70 without a following read or write of 0x71 on + * some chipsets, so do a read. Also, must access a register other than + * the current rtc_reg to force rtcin to push a change out to 0x70. + */ + nmi_enable = enable ? NMI_ENABLE_BIT : 0x00; + rtcin((rtc_reg == RTC_STATUSA) ? RTC_STATUSB : RTC_STATUSA); +} + +void atrtc_restore(void) { @@ -249,6 +305,7 @@ atrtc_attach(device_t dev) IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res == NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); + resource_int_value("atrtc", 0, "use_iodelay", &use_iodelay); atrtc_start(); clock_register(dev, 1000000); bzero(&sc->et, sizeof(struct eventtimer)); From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 01:57:16 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9241106566B; Tue, 10 Jan 2012 01:57:16 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 996FB8FC13; Tue, 10 Jan 2012 01:57:15 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q0A1urwq036352; Tue, 10 Jan 2012 10:57:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q0A1up85070426; Tue, 10 Jan 2012 10:56:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 10 Jan 2012 10:56:47 +0900 (JST) Message-Id: <20120110.105647.2218023206500143768.hrs@allbsd.org> To: feld@feld.me From: Hiroki Sato In-Reply-To: References: <20120110.040224.1057547871207328114.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Jan_10_10_56_47_2012_244)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Tue, 10 Jan 2012 10:57:04 +0900 (JST) X-Spam-Status: No, score=-104.6 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT, RDNS_NONE, SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: accepting rtadv broken on 9-STABLE, re driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 01:57:16 -0000 ----Security_Multipart(Tue_Jan_10_10_56_47_2012_244)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Felder wrote in : fe> On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato fe> wrote: fe> fe> > re0 seems to have ACCEPT_RTADV. What is the problem? fe> fe> That's because I haven't rebooted.... fe> fe> Let's start fresh. fe> fe> The normal ipv6 configuration anyone would use: fe> fe> -ipv6_activate_all_interfaces="YES" in rc.conf fe> fe> -NO mention of net.inet6.ip6.accept_rtadv in sysctl.conf fe> fe> I boot up, re0 *does not* have ACCEPT_RTADV. This is an expected behavior. ACCEPT_RTADV is disabled by default on 9.X. fe> I try forcing via the sysctl: net.inet6.ip6.accept_rtadv=1 fe> fe> Still doesn't work! This needs a reboot. Did you reboot the box? fe> Why? What makes this machine different? All the other machines I run fe> do not require this to get ACCEPT_RTADV. Is it the re driver? My other fe> machines have em and ath interfaces. Putting the following line net.inet6.ip6.accept_rtadv=1 into /etc/sysctl.conf, and then removing the following line ipv6_ifconfig_re0="inet6 accept_rtadv" should work, I think. (Of course a reboot is needed after that). -- Hiroki ----Security_Multipart(Tue_Jan_10_10_56_47_2012_244)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk8Lmt8ACgkQTyzT2CeTzy1aBwCggmuaf14QUdlQz+KZGCZUdj1T bHIAn1m8ZIcSvsFMDvMXdZbVKjX2Q03i =HzrJ -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Jan_10_10_56_47_2012_244)---- From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 02:02:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8520A106564A; Tue, 10 Jan 2012 02:02:13 +0000 (UTC) (envelope-from feld@feld.me) Received: from mwi1.coffeenet.org (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 49FCA8FC12; Tue, 10 Jan 2012 02:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Date:References:Subject:Cc:To:Content-Type; bh=sh6A6f51ZCckeQ1GzjYoi7yvLLdOiWHjHc7cKpZTnRM=; b=U8JPj3vbjue/e2Omr3pAfi7GOnkXqol2FA/l9P44b/m3CaJuPdcCdRA4+gzwAd+RQr5L1DMSA4i2SOjWtjPwyoXb+tJFIhOKzfloK3HPSm78+xogKxFeBMgRvPHAP3wr; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by mwi1.coffeenet.org with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RkR2R-000Liu-FM; Mon, 09 Jan 2012 20:02:12 -0600 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpsa id 1326160925-88972-88971/5/12; Tue, 10 Jan 2012 02:02:05 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org References: <20120110.040224.1057547871207328114.hrs@allbsd.org> <20120110.105647.2218023206500143768.hrs@allbsd.org> Date: Mon, 9 Jan 2012 20:02:05 -0600 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <20120110.105647.2218023206500143768.hrs@allbsd.org> User-Agent: Opera Mail/11.61 (FreeBSD) X-SA-Score: -1.0 Cc: Hiroki Sato Subject: Re: accepting rtadv broken on 9-STABLE, re driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 02:02:13 -0000 On Mon, 09 Jan 2012 19:56:47 -0600, Hiroki Sato wrote: > > This is an expected behavior. ACCEPT_RTADV is disabled by default on > 9.X. > Thanks for clarifying. I'll make sure I update our documentation at work regarding how exactly to get ACCEPT_RTADV working so this is clarified. Regards, Mark From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 03:17:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CD41106564A for ; Tue, 10 Jan 2012 03:17:00 +0000 (UTC) (envelope-from kamikadze29@o2.pl) Received: from tur.go2.pl (tur.go2.pl [193.17.41.50]) by mx1.freebsd.org (Postfix) with ESMTP id EBC3A8FC1A for ; Tue, 10 Jan 2012 03:16:59 +0000 (UTC) Received: from moh2-ve2.go2.pl (moh2-ve2.go2.pl [193.17.41.200]) by tur.go2.pl (Postfix) with ESMTP id 358D7230BA7 for ; Tue, 10 Jan 2012 04:01:31 +0100 (CET) Received: from moh2-ve2.go2.pl (unknown [10.0.0.200]) by moh2-ve2.go2.pl (Postfix) with ESMTP id 6401AB01040 for ; Tue, 10 Jan 2012 04:01:27 +0100 (CET) Received: from o2.pl (unknown [10.0.0.3]) by moh2-ve2.go2.pl (Postfix) with SMTP for ; Tue, 10 Jan 2012 04:01:27 +0100 (CET) From: =?UTF-8?Q?=C5=81ukasz_Kurek?= To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Message-ID: <192396d2.4ca0430d.4f0baa06.40411@o2.pl> Date: Tue, 10 Jan 2012 04:01:26 +0100 X-Originator: 88.199.93.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: backup BIOS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 03:17:00 -0000 Hi, Is=20it=20possible=20to=20backup=20BIOS=20settings=20(CMOS=20configuratio= n)=20to=20file=20and=20restore=20this=20settings=20on=20the=20other=20mac= hine=20(the=20same=20hardware=20configuration=20and=20the=20same=20BIOS)?= I=20try=20do=20it=20for=20this=20way: kldload=20nvram dd=20if=3D/dev/nvram=20of=3Dnvram.bin=20=20=20(backup) dd=20if=3Dnvram.bin=20of=3D/dev/nvram=20=20=20(restore) but=20this=20way=20always=20load=20default=20BIOS=20settings,=20not=20my=20= (probably=20there=20is=20some=20kind=20of=20error). From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 03:52:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6573106566B for ; Tue, 10 Jan 2012 03:52:30 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id C7DC68FC0A for ; Tue, 10 Jan 2012 03:52:30 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta08.emeryville.ca.mail.comcast.net with comcast id KfnX1i0040lTkoCA8fsWVs; Tue, 10 Jan 2012 03:52:30 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta04.emeryville.ca.mail.comcast.net with comcast id KfsV1i00G4NgCEG8QfsVsY; Tue, 10 Jan 2012 03:52:30 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0A3qRXL025820; Mon, 9 Jan 2012 20:52:27 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: =?iso-8859-2?Q?=A3ukasz?= Kurek In-Reply-To: <192396d2.4ca0430d.4f0baa06.40411@o2.pl> References: <192396d2.4ca0430d.4f0baa06.40411@o2.pl> Content-Type: text/plain; charset="iso-8859-2" Date: Mon, 09 Jan 2012 20:52:27 -0700 Message-Id: <1326167547.2199.54.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: backup BIOS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 03:52:31 -0000 On Tue, 2012-01-10 at 04:01 +0100, Łukasz Kurek wrote: > Hi, > Is it possible to backup BIOS settings (CMOS configuration) to file and restore this settings on the other machine (the same hardware configuration and the same BIOS)? > > I try do it for this way: > > kldload nvram > > dd if=/dev/nvram of=nvram.bin (backup) > > dd if=nvram.bin of=/dev/nvram (restore) > > > but this way always load default BIOS settings, not my (probably there is some kind of error). Examine the contents of the nvram.bin file with hexdump. If every byte has the same value, I just posted a patch to this list earlier today (subject is "trouble with atrtc") that will fix the problem. Many new RTC chipsets have more than the original 114 bytes of nvram. The nvram driver doesn't currently provide access to the extra banks. I'm not sure whether the BIOS would store anything in those other banks, but if so, failing to save and restore those values might cause the behavior you see. Also, it's not directly related to your question, but I notice the nvram(4) manpage says the driver does nothing about the checksum, but looking at the driver code, it does recalculate the checksum when it writes to nvram. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 04:03:29 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A465106566C for ; Tue, 10 Jan 2012 04:03:29 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id D4EBE8FC08 for ; Tue, 10 Jan 2012 04:03:28 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta12.emeryville.ca.mail.comcast.net with comcast id Kg3R1i00A1eYJf8ACg3UKu; Tue, 10 Jan 2012 04:03:28 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id Kg3T1i00j4NgCEG01g3ToW; Tue, 10 Jan 2012 04:03:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0A43PX8025829; Mon, 9 Jan 2012 21:03:25 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: =?iso-8859-2?Q?=A3ukasz?= Kurek In-Reply-To: <192396d2.4ca0430d.4f0baa06.40411@o2.pl> References: <192396d2.4ca0430d.4f0baa06.40411@o2.pl> Content-Type: text/plain; charset="iso-8859-2" Date: Mon, 09 Jan 2012 21:03:25 -0700 Message-Id: <1326168205.2199.56.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-hackers@freebsd.org Subject: Re: backup BIOS settings X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 04:03:29 -0000 On Tue, 2012-01-10 at 04:01 +0100, Łukasz Kurek wrote: > Hi, > Is it possible to backup BIOS settings (CMOS configuration) to file and restore this settings on the other machine (the same hardware configuration and the same BIOS)? > > I try do it for this way: > > kldload nvram > > dd if=/dev/nvram of=nvram.bin (backup) > > dd if=nvram.bin of=/dev/nvram (restore) > > > but this way always load default BIOS settings, not my (probably there is some kind of error). Oh wait, the patch I posted can't help, because it fixes a problem that only happens when you read the same location repeatedly, and the nvram driver never does that. But it would still be interesting to examine the nvram.bin file and see if it "looks reasonable". -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 10:23:50 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A59106566C; Tue, 10 Jan 2012 10:23:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 554F98FC18; Tue, 10 Jan 2012 10:23:48 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA01118; Tue, 10 Jan 2012 12:23:47 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1RkYrp-0007X0-Sn; Tue, 10 Jan 2012 12:23:45 +0200 Message-ID: <4F0C11B1.1070508@FreeBSD.org> Date: Tue, 10 Jan 2012 12:23:45 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: John Baldwin References: <4EED20C7.1090704@FreeBSD.org> <201112200911.43880.jhb@freebsd.org> In-Reply-To: <201112200911.43880.jhb@freebsd.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org Subject: Re: RB_NOSYNC -> no device_shutdown ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 10:23:50 -0000 on 20/12/2011 16:11 John Baldwin said the following: > On Saturday, December 17, 2011 6:07:51 pm Andriy Gapon wrote: [snip] >> and wonder why RB_NOSYNC is overloaded to mean that no >> MOD_SHUTDOWN/device_shutdown cleanup should be done? > > Presumably most device_shutdown handlers were used for syncing storage when > the module stuff was first added. I'm not sure how you would fix this now > since you can't easily pass the 'arg2' flags down to each handler so that the > appropriate ones could skip their shutdown actions. I see what you are saying. Couple of thoughts: - maybe MOD_EVENT interface could/should be extended to pass another argument along with the event type - maybe various sync-ing stuff should be done in shutdown_post_sync event handlers, or even via a new dedicated event Hmm, it looks like the latter might actually already be the case. And another tangentially related idea: maybe we should inhibit device/module shutdown for the RB_HALT case given that it is a quite special case where the system actually stays up and at least the keyboard is expected to be still operational. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 11:44:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B295A106564A for ; Tue, 10 Jan 2012 11:44:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 72B928FC12 for ; Tue, 10 Jan 2012 11:44:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:c412:ce36:3c98:43b8] (unknown [IPv6:2001:7b8:3a7:0:c412:ce36:3c98:43b8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 95D845C37; Tue, 10 Jan 2012 12:43:59 +0100 (CET) Message-ID: <4F0C2480.5020704@FreeBSD.org> Date: Tue, 10 Jan 2012 12:44:00 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120106 Thunderbird/10.0 MIME-Version: 1.0 To: Lenny Maiorani References: <502112AF-3908-429C-9DA4-B1D0E94EB9DE@colorado.edu> In-Reply-To: <502112AF-3908-429C-9DA4-B1D0E94EB9DE@colorado.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: building on FreeBSD 7.3 with Clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 11:44:00 -0000 On 2012-01-09 20:38, Lenny Maiorani wrote: > Hi. > > I am trying to build a userspace application on FreeBSD 7.3 with Clang. I have come across 2 problems so far and I am looking for any tips or guidance the community has. > > My problems are both related to binutils so far: > 1. Missing symbols : http://llvm.org/bugs/show_bug.cgi?id=9758 > 2. crtendS.o problem : http://sourceware.org/bugzilla/show_bug.cgi?id=12887 > > At this point I need to rebuild my toolchain to get a new crtendS.o. Are there other pitfalls I need to be aware of? It's probably easiest to install the binutils port, and use that for building clang and your application. Otherwise, you can manually apply the patches mentioned in LLVM PR 9758 to your system binutils, and recompile them. From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 12:15:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F9E7106566B for ; Tue, 10 Jan 2012 12:15:35 +0000 (UTC) (envelope-from tdamas@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C6B428FC08 for ; Tue, 10 Jan 2012 12:15:34 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so5377640vcb.13 for ; Tue, 10 Jan 2012 04:15:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=LRQucFgZyv8fgRgc39WeqjhYKPPeWWZdE1iUP52ND9M=; b=WSJXFkGLe4a53ecM8Vs0VpYBfsyF/7JTbUniVkm/DuBKrkLj5olk3bg6jq7rtHcC/5 lc/EBuMYZaYxaTURdHxJe/t4/3l6EYV4hX8/73VJgNc8m3Ui77DCT3fYjkvUPCYdCbSK Nt6Ca6JHaky2rouOdymRk2DDwu/f1mjylDYRc= Received: by 10.220.149.68 with SMTP id s4mr11280333vcv.43.1326196216366; Tue, 10 Jan 2012 03:50:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.215.2 with HTTP; Tue, 10 Jan 2012 03:49:55 -0800 (PST) From: Thiago Damas Date: Tue, 10 Jan 2012 09:49:55 -0200 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: bsdinstaller X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 12:15:35 -0000 Hi, in this new freebsd installer (bsdinstall) can I have only the ssys extracted? Can I delete all src directories after install, just leaving sys intact? Is it some dependency between the sources? Why the default now its extracting all? Thiago From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 15:14:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6E0106564A; Tue, 10 Jan 2012 15:14:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D5F708FC1A; Tue, 10 Jan 2012 15:14:05 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 7901C46B3B; Tue, 10 Jan 2012 10:14:05 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07197B925; Tue, 10 Jan 2012 10:14:05 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 10 Jan 2012 08:38:17 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201100838.17862.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 10 Jan 2012 10:14:05 -0500 (EST) Cc: Thiago Damas , nwhitehorn@freebsd.org Subject: Re: bsdinstaller X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:14:06 -0000 On Tuesday, January 10, 2012 6:49:55 am Thiago Damas wrote: > Hi, > in this new freebsd installer (bsdinstall) can I have only the ssys > extracted? Can I delete all src directories after install, just > leaving sys intact? > Is it some dependency between the sources? Why the default now its > extracting all? The new installer just builds the src tarball that way. I asked for the same feature, but it didn't make it into 9. Deleting all the extra bits will work for now. If you are up for it, you can look at patching the release build process and bsdinstall to restore this feature. I'm not sure it would be useful to split out all the top-level src directories as the old installer did, but having one tarball for the equivalent of the old 'sbase' + 'ssys' and a second tarball for the rest of the source tree (so you can do 'none', 'kernel-only' or 'full source') would probably be a useful thing to implement. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 15:14:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05E4F106566B; Tue, 10 Jan 2012 15:14:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D14888FC16; Tue, 10 Jan 2012 15:14:06 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 8915E46B09; Tue, 10 Jan 2012 10:14:06 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EC9DBB962; Tue, 10 Jan 2012 10:14:05 -0500 (EST) From: John Baldwin To: Andriy Gapon Date: Tue, 10 Jan 2012 08:43:30 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <4EED20C7.1090704@FreeBSD.org> <201112200911.43880.jhb@freebsd.org> <4F0C11B1.1070508@FreeBSD.org> In-Reply-To: <4F0C11B1.1070508@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201100843.30893.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 10 Jan 2012 10:14:06 -0500 (EST) Cc: freebsd-hackers@freebsd.org Subject: Re: RB_NOSYNC -> no device_shutdown ? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:14:07 -0000 On Tuesday, January 10, 2012 5:23:45 am Andriy Gapon wrote: > on 20/12/2011 16:11 John Baldwin said the following: > > On Saturday, December 17, 2011 6:07:51 pm Andriy Gapon wrote: > [snip] > >> and wonder why RB_NOSYNC is overloaded to mean that no > >> MOD_SHUTDOWN/device_shutdown cleanup should be done? > > > > Presumably most device_shutdown handlers were used for syncing storage when > > the module stuff was first added. I'm not sure how you would fix this now > > since you can't easily pass the 'arg2' flags down to each handler so that the > > appropriate ones could skip their shutdown actions. > > I see what you are saying. > Couple of thoughts: > - maybe MOD_EVENT interface could/should be extended to pass another argument > along with the event type > - maybe various sync-ing stuff should be done in shutdown_post_sync event > handlers, or even via a new dedicated event > > Hmm, it looks like the latter might actually already be the case. I almost think the best way (ugh) is to have a global variable similar to boothowto that device_shutdown methods can use to skip behavior if needed. It may only be a fairly small number of devices that need to skip their shutdown routine (or portions thereof) during a nosync shutdown. > And another tangentially related idea: maybe we should inhibit device/module > shutdown for the RB_HALT case given that it is a quite special case where the > system actually stays up and at least the keyboard is expected to be still > operational. I think we still want to do device_shutdown in that case. The mfi(4) driver sends a specific command to note a clean shutdown that then affects how the event log behaves on the next boot, for example. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 10 18:48:45 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7805F106566C for ; Tue, 10 Jan 2012 18:48:45 +0000 (UTC) (envelope-from lenny@Colorado.EDU) Received: from ipmx2.colorado.edu (ipmx2.colorado.edu [128.138.128.232]) by mx1.freebsd.org (Postfix) with ESMTP id 4A3A88FC0C for ; Tue, 10 Jan 2012 18:48:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EACqGDE/AqBGb/2dsb2JhbABDrV+BcgEBBAE6HCMFCwsOCi5XBieHZgita4kFizBjBIg6nyw X-IronPort-AV: E=Sophos;i="4.71,488,1320649200"; d="scan'208";a="489753094" Received: from omr-raz-2-priv.int.colorado.edu ([192.168.17.155]) by ipmx2-priv.int.colorado.edu with ESMTP; 10 Jan 2012 11:48:36 -0700 Received: from 67.51.249.130 (EHLO _10.126.1.146_) ([67.51.249.130]) by omr-raz-2-priv.int.colorado.edu (MOS 4.1.10-GA FastPath queued) with ESMTP id CVI90741 (AUTH maiorani); Tue, 10 Jan 2012 11:48:33 -0700 (MST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lenny Maiorani In-Reply-To: <4F0C2480.5020704@FreeBSD.org> Date: Tue, 10 Jan 2012 11:48:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0C4D8E46-26DA-4AAC-AD75-66A418699D9E@Colorado.EDU> References: <502112AF-3908-429C-9DA4-B1D0E94EB9DE@colorado.edu> <4F0C2480.5020704@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Re: building on FreeBSD 7.3 with Clang X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:48:45 -0000 On Jan 10, 2012, at 4:44 AM, Dimitry Andric wrote: > On 2012-01-09 20:38, Lenny Maiorani wrote: >> Hi. >>=20 >> I am trying to build a userspace application on FreeBSD 7.3 with = Clang. I have come across 2 problems so far and I am looking for any = tips or guidance the community has. >>=20 >> My problems are both related to binutils so far: >> 1. Missing symbols : http://llvm.org/bugs/show_bug.cgi?id=3D9758 >> 2. crtendS.o problem : = http://sourceware.org/bugzilla/show_bug.cgi?id=3D12887 >>=20 >> At this point I need to rebuild my toolchain to get a new crtendS.o. = Are there other pitfalls I need to be aware of? >=20 > It's probably easiest to install the binutils port, and use that for > building clang and your application. >=20 > Otherwise, you can manually apply the patches mentioned in LLVM PR = 9758 > to your system binutils, and recompile them. Hi Dimitry, Do you mean the binutils port from 9.0? I will try that. Thanks for the info, -Lenny From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 11:36:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 611AC106566B for ; Wed, 11 Jan 2012 11:36:36 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 1C4848FC17 for ; Wed, 11 Jan 2012 11:36:35 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RkwFI-0004k5-IG for freebsd-hackers@freebsd.org; Wed, 11 Jan 2012 12:21:32 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jan 2012 12:21:32 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Jan 2012 12:21:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 11 Jan 2012 12:21:18 +0100 Lines: 19 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120110 Thunderbird/9.0 Subject: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 11:36:36 -0000 The lang/python27 port can optionally be built with the support for POSIX semaphores - i.e. sem(4). This option is labeled as experimental so it may be that the code is simply incorrect. I've tried it and get frequent hangs with the python process in the "usem" state. The kernel stack is as follows and looks reasonable: # procstat -kk 19008 PID TID COMM TDNAME KSTACK 19008 101605 python - mi_switch+0x174 sleepq_catch_signals+0x2f4 sleepq_wait_sig+0x16 _sleep+0x269 do_sem_wait+0xa19 __umtx_op_sem_wait+0x51 amd64_syscall+0x450 Xfast_syscall+0xf7 The process doesn't react to SIGINT or SIGTERM but fortunately reacts to SIGKILL. This could be an error in Python code but OTOH this code is not FreeBSD-specific so it's unlikely. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 13:06:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 568F71065675; Wed, 11 Jan 2012 13:06:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2E5B48FC0A; Wed, 11 Jan 2012 13:06:35 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id D8B4B46B52; Wed, 11 Jan 2012 08:06:34 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 42C60B977; Wed, 11 Jan 2012 08:06:34 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Wed, 11 Jan 2012 08:06:30 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201201110806.30620.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 11 Jan 2012 08:06:34 -0500 (EST) Cc: Ivan Voras , davidxu@freebsd.org Subject: Re: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 13:06:35 -0000 On Wednesday, January 11, 2012 6:21:18 am Ivan Voras wrote: > The lang/python27 port can optionally be built with the support for > POSIX semaphores - i.e. sem(4). This option is labeled as experimental > so it may be that the code is simply incorrect. I've tried it and get > frequent hangs with the python process in the "usem" state. The kernel > stack is as follows and looks reasonable: > > # procstat -kk 19008 > PID TID COMM TDNAME KSTACK > > 19008 101605 python - mi_switch+0x174 > sleepq_catch_signals+0x2f4 sleepq_wait_sig+0x16 _sleep+0x269 > do_sem_wait+0xa19 __umtx_op_sem_wait+0x51 amd64_syscall+0x450 > Xfast_syscall+0xf7 > > The process doesn't react to SIGINT or SIGTERM but fortunately reacts to > SIGKILL. > > This could be an error in Python code but OTOH this code is not > FreeBSD-specific so it's unlikely. This is using the new umtx-based semaphore code that David Xu wrote. He is probably the best person to ask (cc'd). -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 15:02:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DA3E106564A; Wed, 11 Jan 2012 15:02:00 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 34F0F8FC08; Wed, 11 Jan 2012 15:01:59 +0000 (UTC) Received: by yhfq46 with SMTP id q46so362729yhf.13 for ; Wed, 11 Jan 2012 07:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=kfoQUaNb8cfSWSsmoRuBuRVBfK7axGGu2TXpZKYdt50=; b=Y3LXNiloRe6DD3amTNZAcoobDcF9qk0B2UmCnMocXCu09BTHYQmNce152s2WN/ZlEn y/m3f00UAhnC/kKpwWPsdcwKNAGW4cXo9DDpgBGTWSi09GmsShSWvg7iCb68RP56J06E 2buROt9lTmZremVsOW1oZhKehYDz4YYGcYScg= Received: by 10.236.139.199 with SMTP id c47mr31753460yhj.113.1326292451156; Wed, 11 Jan 2012 06:34:11 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.214.14 with HTTP; Wed, 11 Jan 2012 06:33:30 -0800 (PST) In-Reply-To: <201201110806.30620.jhb@freebsd.org> References: <201201110806.30620.jhb@freebsd.org> From: Ivan Voras Date: Wed, 11 Jan 2012 15:33:30 +0100 X-Google-Sender-Auth: 5e2Q9teYIR8MmbZr6sD50-eF-Qs Message-ID: To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, davidxu@freebsd.org Subject: Re: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:02:00 -0000 On 11 January 2012 14:06, John Baldwin wrote: > On Wednesday, January 11, 2012 6:21:18 am Ivan Voras wrote: >> The lang/python27 port can optionally be built with the support for >> POSIX semaphores - i.e. sem(4). This option is labeled as experimental >> so it may be that the code is simply incorrect. I've tried it and get >> frequent hangs with the python process in the "usem" state. The kernel >> stack is as follows and looks reasonable: >> >> # procstat -kk 19008 >> =C2=A0 =C2=A0PID =C2=A0 =C2=A0TID COMM =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 TDNAME =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 KSTACK >> >> 19008 101605 python =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mi_switch+0x174 >> sleepq_catch_signals+0x2f4 sleepq_wait_sig+0x16 _sleep+0x269 >> do_sem_wait+0xa19 __umtx_op_sem_wait+0x51 amd64_syscall+0x450 >> Xfast_syscall+0xf7 >> >> The process doesn't react to SIGINT or SIGTERM but fortunately reacts to >> SIGKILL. >> >> This could be an error in Python code but OTOH this code is not >> FreeBSD-specific so it's unlikely. > > This is using the new umtx-based semaphore code that David Xu wrote. =C2= =A0He is > probably the best person to ask (cc'd). > Ok, I've encountered the problem repeatedly while building databases/tdb: it uses Python in the build process (but maybe it needs something else in parallel to provoke the problem). From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 15:06:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49E8B106566B; Wed, 11 Jan 2012 15:06:57 +0000 (UTC) (envelope-from olli@fromme.com) Received: from haluter.fromme.com (unknown [IPv6:2a01:170:102f:0:2a0:c9ff:fe42:8524]) by mx1.freebsd.org (Postfix) with ESMTP id B6B178FC0C; Wed, 11 Jan 2012 15:06:56 +0000 (UTC) Received: from haluter.fromme.com (irc_sucks@localhost [127.0.0.1]) by haluter.fromme.com (8.14.4/8.14.4) with ESMTP id q0BF6fwl067590; Wed, 11 Jan 2012 16:06:50 +0100 (CET) (envelope-from olli@fromme.com) Received: (from olli@localhost) by haluter.fromme.com (8.14.4/8.14.4/Submit) id q0BF6eAx067588; Wed, 11 Jan 2012 16:06:40 +0100 (CET) (envelope-from olli) From: Oliver Fromme Message-Id: <201201111506.q0BF6eAx067588@haluter.fromme.com> To: bzeeb-lists@lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed, 11 Jan 2012 16:06:40 +0100 (CET) In-Reply-To: X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (haluter.fromme.com [127.0.0.1]); Wed, 11 Jan 2012 16:06:50 +0100 (CET) X-Mailman-Approved-At: Wed, 11 Jan 2012 16:38:40 +0000 Cc: freebsd-net@freebsd.org, olli@secnetix.de, "Paul A. Procacci" , freebsd-hackers@freebsd.org Subject: Re: Processes' FIBs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:06:57 -0000 Bjoern A. Zeeb wrote: > On 10. Jan 2012, at 20:32 , Paul A. Procacci wrote: > > On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote: > > > Is there a way to find out the default FIB number of a > > > process (from a shell script)? I've checked the > > > manpages of ps and procstat, but they don't mention > > > FIBs. I'm using stable/8, if that matters. > > > > http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.html > > > > Not sure about ps/et al, but you can do it according to that post. Nearly 2 years old now. To be honest, I prefer not to fumble around in kernel memory with kgdb in a shell script. Also, it requires root privilege (setfib does not). > If you are thinking in terms of multiple forwarding information bases, yes > sysctl net.my_fibnum Thanks. Would it make sense to document that in setfib(1)? However, I need to find the default FIB number for arbitrary processes, not necessarily for the calling process. I'm currently looking at the source code of ps, but adding a field for the FIB isn't as trivial as I thought because ps only sees struct kinfo_proc (via sysctl kern.proc.*) which doesn't contain the FIB. procstat does the same. I'm currently trying to write a patch that copies p_fibnum from struct proc to struct kinfo_proc (just like p_nice, for example). Does that make sense? If so, does the patch below look reasonable? (I've made it on a stable/8 system, but it should apply to 9 and 10, too.) Best regards Oliver --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 @@ -83,7 +83,7 @@ * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and * function kvm_proclist in lib/libkvm/kvm_proc.c . */ -#define KI_NSPARE_INT 9 +#define KI_NSPARE_INT 8 #define KI_NSPARE_LONG 12 #define KI_NSPARE_PTR 6 @@ -177,6 +177,7 @@ */ char ki_sparestrings[68]; /* spare string space */ int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ + int ki_fibnum; /* Default FIB number */ u_int ki_cr_flags; /* Credential flags */ int ki_jid; /* Process jail ID */ int ki_numthreads; /* XXXKSE number of threads in total */ --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 @@ -775,6 +775,7 @@ kp->ki_swtime = (ticks - p->p_swtick) / hz; kp->ki_pid = p->p_pid; kp->ki_nice = p->p_nice; + kp->ki_fibnum = p->p_fibnum; PROC_SLOCK(p); rufetch(p, &kp->ki_rusage); kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime); --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 @@ -90,6 +90,7 @@ NULL, 0}, {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0}, {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 16:47:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ED49106564A; Wed, 11 Jan 2012 16:47:13 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8178FC15; Wed, 11 Jan 2012 16:47:12 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so1739781obb.13 for ; Wed, 11 Jan 2012 08:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZlZxdgcZCYqFJbR6cNmxTndqEAOaBTmcTddIrRSPXrg=; b=F1sO1ZCMjJ3ayB2TJ2r1TOXQxVUOpT9PXwG1VGQe0cKjTgzHdSb9JQCF7VM/8UZkd7 qNdEQWLug97CCRS5WuQEY3fw/gy5dzymTwP1l0LJ6ZCRstAg1tAF0WnIEhsYJxXxSCwX U6tq76EpRu9Br//wMyws8B6NfX6GjQzjqHqIc= MIME-Version: 1.0 Received: by 10.182.49.106 with SMTP id t10mr22959001obn.49.1326300432484; Wed, 11 Jan 2012 08:47:12 -0800 (PST) Received: by 10.182.152.6 with HTTP; Wed, 11 Jan 2012 08:47:12 -0800 (PST) In-Reply-To: References: <201201110806.30620.jhb@freebsd.org> Date: Wed, 11 Jan 2012 08:47:12 -0800 Message-ID: From: Garrett Cooper To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Xin LI , davidxu@freebsd.org Subject: Re: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 16:47:13 -0000 On Wed, Jan 11, 2012 at 6:33 AM, Ivan Voras wrote: > On 11 January 2012 14:06, John Baldwin wrote: >> On Wednesday, January 11, 2012 6:21:18 am Ivan Voras wrote: >>> The lang/python27 port can optionally be built with the support for >>> POSIX semaphores - i.e. sem(4). This option is labeled as experimental >>> so it may be that the code is simply incorrect. I've tried it and get >>> frequent hangs with the python process in the "usem" state. The kernel >>> stack is as follows and looks reasonable: >>> >>> # procstat -kk 19008 >>> =A0 =A0PID =A0 =A0TID COMM =A0 =A0 =A0 =A0 =A0 =A0 TDNAME =A0 =A0 =A0 = =A0 =A0 KSTACK >>> >>> 19008 101605 python =A0 =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0mi_switch+0x174 >>> sleepq_catch_signals+0x2f4 sleepq_wait_sig+0x16 _sleep+0x269 >>> do_sem_wait+0xa19 __umtx_op_sem_wait+0x51 amd64_syscall+0x450 >>> Xfast_syscall+0xf7 >>> >>> The process doesn't react to SIGINT or SIGTERM but fortunately reacts t= o >>> SIGKILL. >>> >>> This could be an error in Python code but OTOH this code is not >>> FreeBSD-specific so it's unlikely. >> >> This is using the new umtx-based semaphore code that David Xu wrote. =A0= He is >> probably the best person to ask (cc'd). >> > > Ok, I've encountered the problem repeatedly while building databases/tdb: > =A0it uses Python in the build process (but maybe it needs something else= in > parallel to provoke the problem). Glad to see that iXsystems isn't the only one ([1] -- please add a "me too" to the PR). The problem is that we do FreeNAS nightlies and they frequently get stuck building tdb (10%~20% of the time) and it sticks when doing interactive builds as well. The issue appears to be exacerbated when we have more builds running in parallel on the same machine. I've also run into the same issue compiling talloc because it uses the same waf infrastructure as tdb, which was designed to "speed things up by forcing builds to be parallelized" (It builds kern.smp.ncpus jobs instead of -j 1). Furthermore, it seems to occur regardless of whether or not we have the WITH_SEM enabled in python or not (build.ix's copy of python doesn't have it enabled, but streetfighter.ix, my system bayonetta, etc do). I haven't actually enabled WITNESS or the deadlock resolver and checked for LORs / deadlocks, but that might be an alternate avenue to pursue in debugging the issue; my gut is that the issue exists within the code that handles the subprocessing stuff and/or the GIL stuff in the python interpreter and that the race condition between a command actually finishing and not is relatively small (in most cases) and in most cases python's code wins and continues on as usual. It could also be some non-threadsafe code trying to run in parallel touching things that it shouldn't in the python interpreter. It would also be interesting to see what python3k brings to the table, but using that would be introducing some extra unknowns into the equation. It can be reproduced by running continuous builds of talloc or tdb. Thanks! -Garrett 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/163489 From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 16:51:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 449601065679 for ; Wed, 11 Jan 2012 16:51:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id F14D28FC08 for ; Wed, 11 Jan 2012 16:51:16 +0000 (UTC) Received: by iazz13 with SMTP id z13so2029097iaz.13 for ; Wed, 11 Jan 2012 08:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=la+MZWQ6NQ9GRlNje7F2FM90pegV6TCE0x6WUlGj4KM=; b=AXi8my+IG77MjXXPrE+/7CIDLLfPwhVHTps5CmxdxWmAZlZMmMFvyF1Bgj0qrX2SCu vNuk6/dHHkcQr/69jxs1JLBekXDtITGQJPwpKFKXoXMh5qNFKyssFxgj6wGjkJkpL4za ULr4XRH8uGnxwiRE1e+Ijq60nshH0i3BxcCOE= MIME-Version: 1.0 Received: by 10.42.246.71 with SMTP id lx7mr6163927icb.54.1326300676292; Wed, 11 Jan 2012 08:51:16 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.42.243.65 with HTTP; Wed, 11 Jan 2012 08:51:16 -0800 (PST) In-Reply-To: References: <201201110806.30620.jhb@freebsd.org> Date: Wed, 11 Jan 2012 08:51:16 -0800 X-Google-Sender-Auth: wN40Ni6dDyRnxagqftfL9cUxbHI Message-ID: From: Adrian Chadd To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Xin LI , Ivan Voras , davidxu@freebsd.org Subject: Re: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 16:51:17 -0000 ... yes, enable WITNESS already and see if you can find LORs. :) (Sheesh, that's what it's for! :) Adrian On 11 January 2012 08:47, Garrett Cooper wrote: > On Wed, Jan 11, 2012 at 6:33 AM, Ivan Voras wrote: >> On 11 January 2012 14:06, John Baldwin wrote: >>> On Wednesday, January 11, 2012 6:21:18 am Ivan Voras wrote: >>>> The lang/python27 port can optionally be built with the support for >>>> POSIX semaphores - i.e. sem(4). This option is labeled as experimental >>>> so it may be that the code is simply incorrect. I've tried it and get >>>> frequent hangs with the python process in the "usem" state. The kernel >>>> stack is as follows and looks reasonable: >>>> >>>> # procstat -kk 19008 >>>> =A0 =A0PID =A0 =A0TID COMM =A0 =A0 =A0 =A0 =A0 =A0 TDNAME =A0 =A0 =A0 = =A0 =A0 KSTACK >>>> >>>> 19008 101605 python =A0 =A0 =A0 =A0 =A0 - =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0mi_switch+0x174 >>>> sleepq_catch_signals+0x2f4 sleepq_wait_sig+0x16 _sleep+0x269 >>>> do_sem_wait+0xa19 __umtx_op_sem_wait+0x51 amd64_syscall+0x450 >>>> Xfast_syscall+0xf7 >>>> >>>> The process doesn't react to SIGINT or SIGTERM but fortunately reacts = to >>>> SIGKILL. >>>> >>>> This could be an error in Python code but OTOH this code is not >>>> FreeBSD-specific so it's unlikely. >>> >>> This is using the new umtx-based semaphore code that David Xu wrote. = =A0He is >>> probably the best person to ask (cc'd). >>> >> >> Ok, I've encountered the problem repeatedly while building databases/tdb= : >> =A0it uses Python in the build process (but maybe it needs something els= e in >> parallel to provoke the problem). > > Glad to see that iXsystems isn't the only one ([1] -- please add a "me > too" to the PR). The problem is that we do FreeNAS nightlies and they > frequently get stuck building tdb (10%~20% of the time) and it sticks > when doing interactive builds as well. The issue appears to be > exacerbated when we have more builds running in parallel on the same > machine. I've also run into the same issue compiling talloc because it > uses the same waf infrastructure as tdb, which was designed to "speed > things up by forcing builds to be parallelized" (It builds > kern.smp.ncpus jobs instead of -j 1). Furthermore, it seems to occur > regardless of whether or not we have the WITH_SEM enabled in python or > not (build.ix's copy of python doesn't have it enabled, but > streetfighter.ix, my system bayonetta, etc do). > > I haven't actually enabled WITNESS or the deadlock resolver and > checked for LORs / deadlocks, but that might be an alternate avenue to > pursue in debugging the issue; my gut is that the issue exists within > the code that handles the subprocessing stuff and/or the GIL stuff in > the python interpreter and that the race condition between a command > actually finishing and not is relatively small (in most cases) and in > most cases python's code wins and continues on as usual. It could also > be some non-threadsafe code trying to run in parallel touching things > that it shouldn't in the python interpreter. It would also be > interesting to see what python3k brings to the table, but using that > would be introducing some extra unknowns into the equation. > > It can be reproduced by running continuous builds of talloc or tdb. > > Thanks! > -Garrett > > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/163489 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 17:16:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55212106566B; Wed, 11 Jan 2012 17:16:47 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id DF71A8FC13; Wed, 11 Jan 2012 17:16:46 +0000 (UTC) Received: by yenm1 with SMTP id m1so469895yen.13 for ; Wed, 11 Jan 2012 09:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=YSpeY/pvDzUqWzxPCSCX7YmtRSMUSDz8lOoq54v+vAM=; b=Rv0Rj6UDaQzijgW5+NCiwsBb+9lSh3wGZgQhyBz5teKdLxDEWN95mKlhjfSRfWA8M/ 9xJLKVmZDaWkZ8WlyqOtCp/GTUOqd2+wq4f4Di9D5hf+vdaQeFhRy/L5Z77vfeXqivwX iDBf7Vx91vBm7EE/kLp+bA2U3OZ4c+7KZsdoU= Received: by 10.236.155.40 with SMTP id i28mr33617859yhk.130.1326302206180; Wed, 11 Jan 2012 09:16:46 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.100.214.14 with HTTP; Wed, 11 Jan 2012 09:16:05 -0800 (PST) In-Reply-To: References: <201201110806.30620.jhb@freebsd.org> From: Ivan Voras Date: Wed, 11 Jan 2012 18:16:05 +0100 X-Google-Sender-Auth: ly_t-964BKD9AFWJGk8idagMCzc Message-ID: To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Xin LI , davidxu@freebsd.org Subject: Re: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:16:47 -0000 On 11 January 2012 17:47, Garrett Cooper wrote: > when doing interactive builds as well. The issue appears to be > exacerbated when we have more builds running in parallel on the same > machine. I've also run into the same issue compiling talloc because it > uses the same waf infrastructure as tdb, which was designed to "speed > things up by forcing builds to be parallelized" (It builds > kern.smp.ncpus jobs instead of -j 1). Furthermore, it seems to occur > regardless of whether or not we have the WITH_SEM enabled in python or > not ... which is interesting as I've habitually enabled WITH_SEM on 8.x systems and there it worked without problems. Must be the new code. From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 22:41:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7EF5106566B; Wed, 11 Jan 2012 22:41:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-tul01m020-f182.google.com (mail-tul01m020-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 74C5C8FC12; Wed, 11 Jan 2012 22:41:08 +0000 (UTC) Received: by obbwd18 with SMTP id wd18so2301595obb.13 for ; Wed, 11 Jan 2012 14:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KZRT371D8SG/OoajzGdUlklyBE5UnzLREnq4UUfJzWA=; b=d5CEsnBaFTegOZgvdXjsTqMZ682fPPrvp6tU7YaRZgtUO+9uofeW/DWgFZUQ0fM9vi 5GA6SXxQ4yFk3sAtOCGb0FQfaeCZeM6B9zQ7gt+P55Lhk8MrcymLaSP4qqUnXb0YQnHX /wgLnTIBPvzOp01knwiqJ1rqsfZcPa4BOBRRg= MIME-Version: 1.0 Received: by 10.182.49.106 with SMTP id t10mr940320obn.49.1326321668021; Wed, 11 Jan 2012 14:41:08 -0800 (PST) Received: by 10.182.152.6 with HTTP; Wed, 11 Jan 2012 14:41:07 -0800 (PST) In-Reply-To: References: <201201110806.30620.jhb@freebsd.org> Date: Wed, 11 Jan 2012 14:41:07 -0800 Message-ID: From: Garrett Cooper To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Xin LI , davidxu@freebsd.org Subject: Re: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:41:08 -0000 On Wed, Jan 11, 2012 at 9:16 AM, Ivan Voras wrote: > On 11 January 2012 17:47, Garrett Cooper wrote: > >> when doing interactive builds as well. The issue appears to be >> exacerbated when we have more builds running in parallel on the same >> machine. I've also run into the same issue compiling talloc because it >> uses the same waf infrastructure as tdb, which was designed to "speed >> things up by forcing builds to be parallelized" (It builds >> kern.smp.ncpus jobs instead of -j 1). Furthermore, it seems to occur >> regardless of whether or not we have the WITH_SEM enabled in python or >> not > > ... which is interesting as I've habitually enabled WITH_SEM on 8.x > systems and there it worked without problems. Must be the new code. Maybe, maybe not. I've repro'ed this issue once on my 8-core 9.0 box too, but remember that tdb and talloc were converted over to use waf stuff recently... and this might be a race that's easier to repro on 9.x+ than 8.x :). Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 11 23:56:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5663D1065670 for ; Wed, 11 Jan 2012 23:56:00 +0000 (UTC) (envelope-from gmnt99@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6278FC12 for ; Wed, 11 Jan 2012 23:55:59 +0000 (UTC) Received: by yenm1 with SMTP id m1so714931yen.13 for ; Wed, 11 Jan 2012 15:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Lvfah6ORseIYnZf8GtX9F2iRhiHiQkGWOm0z8A8mgFM=; b=UYhaqBBM2R8FpKJ7R5AU5zuqyHg4kQZbDawKYRdpTQHGsOujVlFnARozbOpgxc8+gM ar+EsSOcW/xOEXww1d2NBjEhhfFEgEty84rSzsF7KNYOzD7p5zhIYoy1sAKaIOqJ2czi naIkdTzG6ZAFs4EZYNpDx8Y285N+snOh7R33Y= MIME-Version: 1.0 Received: by 10.236.93.4 with SMTP id k4mr1254495yhf.114.1326324391330; Wed, 11 Jan 2012 15:26:31 -0800 (PST) Received: by 10.100.88.15 with HTTP; Wed, 11 Jan 2012 15:26:31 -0800 (PST) Date: Wed, 11 Jan 2012 23:26:31 +0000 Message-ID: From: Gerald McNulty To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Assigning the PRIV_NETINET_BINDANY privilege required for setsockopt(IP_BINDANY) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 23:56:00 -0000 Hello, Using IP_BINDANY to facilitate transparent proxying works as specified. According the ip(4) man page and sys/netinet/ip_output.c, the PRIV_NETINET_BINDANY privilege is required in order to make a setsockopt() call with IP_BINDANY. I would like to use this in an app that does not run as uid 0. Is it possible to assign the PRIV_NETINET_BINDANY privilege to a specific uid or process or can this mechanism only be used in jails to reduce root privileges further? Thank you -- Gerald McNulty From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 01:00:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F5541065692; Thu, 12 Jan 2012 01:00:33 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 46ED88FC30; Thu, 12 Jan 2012 01:00:27 +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 1BCD625D3899; Thu, 12 Jan 2012 01:00:25 +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 2928FBD800E; Thu, 12 Jan 2012 01:00:25 +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 K5lL9u9LTk22; Thu, 12 Jan 2012 01:00:23 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 989DBBD8010; Thu, 12 Jan 2012 01:00:22 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <201201111506.q0BF6eAx067588@haluter.fromme.com> Date: Thu, 12 Jan 2012 01:00:22 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201111506.q0BF6eAx067588@haluter.fromme.com> To: Oliver Fromme X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, olli@secnetix.de, "Paul A. Procacci" , freebsd-hackers@freebsd.org Subject: Re: Processes' FIBs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 01:00:33 -0000 On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: >=20 > Bjoern A. Zeeb wrote: >> On 10. Jan 2012, at 20:32 , Paul A. Procacci wrote: >>> On Tue, Jan 10, 2012 at 09:12:17PM +0100, Oliver Fromme wrote: >>>> Is there a way to find out the default FIB number of a >>>> process (from a shell script)? I've checked the >>>> manpages of ps and procstat, but they don't mention >>>> FIBs. I'm using stable/8, if that matters. >>>=20 >>> = http://lists.freebsd.org/pipermail/freebsd-questions/2009-April/196532.htm= l >>>=20 >>> Not sure about ps/et al, but you can do it according to that post. = Nearly 2 years old now. >=20 > To be honest, I prefer not to fumble around in kernel memory > with kgdb in a shell script. Also, it requires root privilege > (setfib does not). >=20 >> If you are thinking in terms of multiple forwarding information = bases, yes >> sysctl net.my_fibnum >=20 > Thanks. Would it make sense to document that in setfib(1)? >=20 > However, I need to find the default FIB number for arbitrary > processes, not necessarily for the calling process. >=20 > I'm currently looking at the source code of ps, but adding > a field for the FIB isn't as trivial as I thought because > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > which doesn't contain the FIB. procstat does the same. >=20 > I'm currently trying to write a patch that copies p_fibnum > from struct proc to struct kinfo_proc (just like p_nice, > for example). Does that make sense? If so, does the patch > below look reasonable? (I've made it on a stable/8 system, > but it should apply to 9 and 10, too.) I am not sure it makes too much sense in ps. It might make sense in sockstat maybe? > Best regards > Oliver >=20 > --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 > +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 > @@ -83,7 +83,7 @@ > * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c = and > * function kvm_proclist in lib/libkvm/kvm_proc.c . > */ > -#define KI_NSPARE_INT 9 > +#define KI_NSPARE_INT 8 > #define KI_NSPARE_LONG 12 > #define KI_NSPARE_PTR 6 >=20 > @@ -177,6 +177,7 @@ > */ > char ki_sparestrings[68]; /* spare string space */ > int ki_spareints[KI_NSPARE_INT]; /* spare room for growth = */ > + int ki_fibnum; /* Default FIB number */ > u_int ki_cr_flags; /* Credential flags */ > int ki_jid; /* Process jail ID */ > int ki_numthreads; /* XXXKSE number of threads in = total */ > --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 = +0200 > +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 > @@ -775,6 +775,7 @@ > kp->ki_swtime =3D (ticks - p->p_swtick) / hz; > kp->ki_pid =3D p->p_pid; > kp->ki_nice =3D p->p_nice; > + kp->ki_fibnum =3D p->p_fibnum; > PROC_SLOCK(p); > rufetch(p, &kp->ki_rusage); > kp->ki_runtime =3D cputick2usec(p->p_rux.rux_runtime); > --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 > +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 > @@ -90,6 +90,7 @@ > NULL, 0}, > {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, = NULL, 0}, > {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, > + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, = "d", 0}, > {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, = 0}, > {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), = LONG, >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 01:01:59 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10FB5106564A; Thu, 12 Jan 2012 01:01:59 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id D53D28FC0C; Thu, 12 Jan 2012 01:01:58 +0000 (UTC) Received: by pbdt13 with SMTP id t13so8916pbd.13 for ; Wed, 11 Jan 2012 17:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mhjevjwm7Qowxafinm0IS/mjQ6AwYsbs9kVWqEQXTcc=; b=L6E6f4Rd+6x+IreyLH+lH3HmjhBpaB6e+KZpoqen+Sv+0ejPMsPC7ntQ1Zl+eUIeTv sZ/WPx3nZ/SEuDaCh3OVusBCAi0vJ6dcjs/nw1/OF6MY4Th8ptqiCwnwL+NtqrlaF+Yh ruvgU/oOa3LYd9zSJtLhl6kHJYTdcF1R5Ftfc= MIME-Version: 1.0 Received: by 10.68.197.7 with SMTP id iq7mr1603059pbc.62.1326328229331; Wed, 11 Jan 2012 16:30:29 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.68.42.73 with HTTP; Wed, 11 Jan 2012 16:30:29 -0800 (PST) In-Reply-To: <20100724121539.D57851@maildrop.int.zabbadoz.net> References: <20100724121539.D57851@maildrop.int.zabbadoz.net> Date: Thu, 12 Jan 2012 01:30:29 +0100 X-Google-Sender-Auth: tK4xB2e8ADOURTA_ohH4IzIwx2s Message-ID: From: "K. Macy" To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, alan yang , freebsd-hackers@freebsd.org Subject: Re: interface for import/export flowtable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 01:01:59 -0000 On Sat, Jul 24, 2010 at 2:17 PM, Bjoern A. Zeeb wrote: > On Thu, 22 Jul 2010, alan yang wrote: > > Hey, > > >> Wonder people had implemented interface to import / export flowtable. > Yes I did, and I added an API to query it more generally. I didn't add it to net/flowtable.c because my usage seemed too niche. > > what exactly do you want to accomplish with that? I used it for redirecting flows in an application that did L7 DSR load balancing. HTH. Cheers > -- > Bjoern A. Zeeb =A0 =A0From August on I will have a life. =A0It's now up t= o you > to do the maths and count to 64. =A0 =A0 -- Bondorf, Germany, 14th June 2= 010 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 05:02:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39F58106564A; Thu, 12 Jan 2012 05:02:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 53E648FC0C; Thu, 12 Jan 2012 05:02:01 +0000 (UTC) Received: by lahd3 with SMTP id d3so982062lah.13 for ; Wed, 11 Jan 2012 21:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=3OFuFvI0rONAZdWcBZ0nTTYHOSMOFZRhXxhLz6CTM0Y=; b=Y1hQtd0ul+bEQUrghgcBzHnbQzEQ6luTyHXbDLn1HYaHMKDti/xYdXBiX7LN/M0H7g +SIE37p4y57zSthrbH7IUZP/ioLSgD5k93Kbf9kl3ZkY6icLY0et9Pv0hVbniB2GUdMV Q4HDLE12SZZ4VYFJgSh7LzKGmzRz+iJd9fo4Q= Received: by 10.152.144.133 with SMTP id sm5mr922055lab.38.1326344520120; Wed, 11 Jan 2012 21:02:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.129.8 with HTTP; Wed, 11 Jan 2012 21:01:29 -0800 (PST) From: Eitan Adler Date: Thu, 12 Jan 2012 00:01:29 -0500 Message-ID: To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Cc: jilles@freebsd.org, Colin Percival Subject: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 05:02:02 -0000 This is an implementation of dup3 for FreeBSD: man page here (with a FreeBSD patch coming soon): https://www.kernel.org/doc/man-pages/online/pages/man2/dup.2.html Is this implementation correct? If so any objection to adding this as a supported syscall? Index: sys/kern/kern_descrip.c =================================================================== --- sys/kern/kern_descrip.c (revision 229830) +++ sys/kern/kern_descrip.c (working copy) @@ -110,6 +110,7 @@ /* Flags for do_dup() */ #define DUP_FIXED 0x1 /* Force fixed allocation */ #define DUP_FCNTL 0x2 /* fcntl()-style errors */ +#define DUP_CLOEXEC 0x4 /* Enable O_CLOEXEC on the new fs */ static int do_dup(struct thread *td, int flags, int old, int new, register_t *retval); @@ -307,7 +308,39 @@ return (0); } +#ifndef _SYS_SYSPROTO_H_ +struct dup3_args { + u_int from; + u_int to; + int flags; +}; +#endif + /* + * Duplicate a file descriptor and allow for O_CLOEXEC + */ + +/* ARGSUSED */ +int +sys_dup3(struct thread * const td, struct dup3_args * const uap) { + + KASSERT(td != NULL, ("%s: td == NULL", __func__)); + KASSERT(uap != NULL, ("%s: uap == NULL", __func__)); + + if (uap->from == uap->to) + return EINVAL; + + if (uap->flags & ~O_CLOEXEC) + return EINVAL; + + const int dupflags = (uap->flags == O_CLOEXEC) ? DUP_FIXED|DUP_CLOEXEC : DUP_FIXED; + + return (do_dup(td, dupflags, (int)uap->from, (int)uap->to, + td->td_retval)); + return (0); +} + +/* * Duplicate a file descriptor to a particular value. * * Note: keep in mind that a potential race condition exists when closing @@ -912,6 +945,9 @@ fdp->fd_lastfile = new; *retval = new; + if (flags & DUP_CLOEXEC) + fdp->fd_ofileflags[new] |= UF_EXCLOSE; + /* * If we dup'd over a valid file, we now own the reference to it * and must dispose of it using closef() semantics (as if a Index: sys/kern/syscalls.master =================================================================== --- sys/kern/syscalls.master (revision 229830) +++ sys/kern/syscalls.master (working copy) @@ -951,5 +951,6 @@ off_t offset, off_t len); } 531 AUE_NULL STD { int posix_fadvise(int fd, off_t offset, \ off_t len, int advice); } +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } ; Please copy any additions and changes to the following compatability tables: ; sys/compat/freebsd32/syscalls.master Index: sys/compat/freebsd32/syscalls.master =================================================================== --- sys/compat/freebsd32/syscalls.master (revision 229830) +++ sys/compat/freebsd32/syscalls.master (working copy) @@ -997,3 +997,4 @@ uint32_t offset1, uint32_t offset2,\ uint32_t len1, uint32_t len2, \ int advice); } +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 06:03:57 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F204106564A for ; Thu, 12 Jan 2012 06:03:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A3E968FC19 for ; Thu, 12 Jan 2012 06:03:56 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so1811999vcb.13 for ; Wed, 11 Jan 2012 22:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KFuxV+SJxUVBw5szVuy5d+3a0TvHOoh/8unXTYo+p9E=; b=XdX0S/VxrE2/G37E5P/IbdEL8Ikv7KAmpZRp9f0eWB55g58Yn+WoSyB7iD66tUmJNf uZOTZzfmTPgNJmk7KeqigZswyLX8tP2dWfG9A5o/fRj23DO6rZF955OqnaJJeQXpcB9T cYfoQTnEqGkz6zykdIZGu98656guxcsnDN/fo= MIME-Version: 1.0 Received: by 10.220.156.134 with SMTP id x6mr1359284vcw.17.1326348236027; Wed, 11 Jan 2012 22:03:56 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.52.36.5 with HTTP; Wed, 11 Jan 2012 22:03:56 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Jan 2012 22:03:56 -0800 X-Google-Sender-Auth: KD9l1Yja08gGmi3JBvXyaVjX-hQ Message-ID: From: Adrian Chadd To: Gerald McNulty Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: Assigning the PRIV_NETINET_BINDANY privilege required for setsockopt(IP_BINDANY) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 06:03:57 -0000 On 11 January 2012 15:26, Gerald McNulty wrote: > Hello, > > Using IP_BINDANY to facilitate transparent proxying works as specified. > According the ip(4) man page and sys/netinet/ip_output.c, the > PRIV_NETINET_BINDANY privilege is required in order to make a setsockopt() > call with IP_BINDANY. > > I would like to use this in an app that does not run as uid 0. Is it > possible to assign the PRIV_NETINET_BINDANY privilege to a specific uid or > process or can this mechanism only be used in jails to reduce root > privileges further? I'm not sure if the relevant bits of MAC have been committed. Robert? Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 07:45:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 915FE106564A; Thu, 12 Jan 2012 07:45:38 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 1F6518FC19; Thu, 12 Jan 2012 07:45:38 +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 57C2B25D37C7; Thu, 12 Jan 2012 07:45:36 +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 8FCB7BD9007; Thu, 12 Jan 2012 07:45:35 +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 ljoh80jqKhZk; Thu, 12 Jan 2012 07:45:34 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id A5DE0BD9006; Thu, 12 Jan 2012 07:45:34 +0000 (UTC) From: "Bjoern A. Zeeb" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 12 Jan 2012 07:45:34 +0000 Message-Id: <511C0E5F-DBA1-4E41-B8CF-6DEEE35E14D6@FreeBSD.org> To: FreeBSD current mailing list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: freebsd-hackers@freebsd.org Subject: Build Option Survey results X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 07:45:38 -0000 Hey, after two years I had the opportunity to run the build option survey, initially done by phk, again. The number of options seems to have grown quite a bit it felt. I have not even looked at the results yet but here they are fresh off the machine: http://people.freebsd.org/~bz/build_option_survey_20120106/ Special thanks go to np, sbruno and bhaga for bringing worm back to life. /bz PS: the last run from 2010 can still be found here: http://people.freebsd.org/~bz/build_option_survey_20100104/ -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 09:35:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBB0F1065672; Thu, 12 Jan 2012 09:35:17 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5D0AF8FC1A; Thu, 12 Jan 2012 09:35:17 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so1987936vcb.13 for ; Thu, 12 Jan 2012 01:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Bh8XzL0vRfa5CHUT+FvcOGekYpYfDC70p0IQiQYtgMQ=; b=WowQS6LsuelmUGwcEn0oznj1aY2mNt4+77MtWuVpQ56tUq7jfH2dHcf9zRibdxT7fZ edWnrd90z2HdmcI/7OaXNT1ZmiHvsxwW0fgpNb8b18zMIstCk/R+IsmUg7vACTCF/Bxh HrM+k7fziSmUlirzCGHn1SBZbUQDFyT15Z628= MIME-Version: 1.0 Received: by 10.220.148.138 with SMTP id p10mr1571103vcv.28.1326359205204; Thu, 12 Jan 2012 01:06:45 -0800 (PST) Received: by 10.52.181.199 with HTTP; Thu, 12 Jan 2012 01:06:45 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Jan 2012 10:06:45 +0100 Message-ID: From: Davide Italiano To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:35:17 -0000 On Thu, Jan 12, 2012 at 6:01 AM, Eitan Adler wrote: > This is an implementation of dup3 for FreeBSD: > man page here (with a FreeBSD patch coming soon): > https://www.kernel.org/doc/man-pages/online/pages/man2/dup.2.html > > Is this implementation correct? If so any objection to adding this as > a supported syscall? > > > Index: sys/kern/kern_descrip.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_descrip.c =A0 =A0 (revision 229830) > +++ sys/kern/kern_descrip.c =A0 =A0 (working copy) > @@ -110,6 +110,7 @@ > =A0/* Flags for do_dup() */ > =A0#define DUP_FIXED =A0 =A0 =A00x1 =A0 =A0 /* Force fixed allocation */ > =A0#define DUP_FCNTL =A0 =A0 =A00x2 =A0 =A0 /* fcntl()-style errors */ > +#define DUP_CLOEXEC =A0 =A00x4 =A0 =A0 /* Enable O_CLOEXEC on the new fs= */ > > =A0static int do_dup(struct thread *td, int flags, int old, int new, > =A0 =A0 register_t *retval); > @@ -307,7 +308,39 @@ > =A0 =A0 =A0 =A0return (0); > =A0} > > +#ifndef _SYS_SYSPROTO_H_ > +struct dup3_args { > + =A0 =A0 =A0 u_int =A0 from; > + =A0 =A0 =A0 u_int =A0 to; > + =A0 =A0 =A0 int =A0 =A0 flags; > +}; > +#endif > + > =A0/* > + * Duplicate a file descriptor and allow for O_CLOEXEC > + */ > + > +/* ARGSUSED */ > +int > +sys_dup3(struct thread * const td, struct dup3_args * const uap) { > + > + =A0 =A0 =A0 KASSERT(td !=3D NULL, ("%s: td =3D=3D NULL", __func__)); > + =A0 =A0 =A0 KASSERT(uap !=3D NULL, ("%s: uap =3D=3D NULL", __func__)); > + > + =A0 =A0 =A0 if (uap->from =3D=3D uap->to) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return EINVAL; > + > + =A0 =A0 =A0 if (uap->flags & ~O_CLOEXEC) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return EINVAL; > + > + =A0 =A0 =A0 const int dupflags =3D (uap->flags =3D=3D O_CLOEXEC) ? > DUP_FIXED|DUP_CLOEXEC : DUP_FIXED; > + > + =A0 =A0 =A0 return (do_dup(td, dupflags, (int)uap->from, (int)uap->to, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 td->td_retval)); > + =A0 =A0 =A0 return (0); > +} > + > +/* > =A0* Duplicate a file descriptor to a particular value. > =A0* > =A0* Note: keep in mind that a potential race condition exists when closi= ng > @@ -912,6 +945,9 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fdp->fd_lastfile =3D new; > =A0 =A0 =A0 =A0*retval =3D new; > > + =A0 =A0 =A0 if (flags & DUP_CLOEXEC) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 fdp->fd_ofileflags[new] |=3D UF_EXCLOSE; > + > =A0 =A0 =A0 =A0/* > =A0 =A0 =A0 =A0 * If we dup'd over a valid file, we now own the reference= to it > =A0 =A0 =A0 =A0 * and must dispose of it using closef() semantics (as if = a > Index: sys/kern/syscalls.master > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/syscalls.master =A0 =A0(revision 229830) > +++ sys/kern/syscalls.master =A0 =A0(working copy) > @@ -951,5 +951,6 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of= f_t offset, off_t len); } > =A0531 =A0 =A0AUE_NULL =A0 =A0 =A0 =A0STD =A0 =A0 { int posix_fadvise(int= fd, off_t offset, \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of= f_t len, int advice); } > +532 =A0 =A0AUE_NULL =A0 =A0 =A0 =A0STD =A0 =A0 { int dup3(u_int from, u_= int to, int flags); } > =A0; Please copy any additions and changes to the following compatability= tables: > =A0; sys/compat/freebsd32/syscalls.master > Index: sys/compat/freebsd32/syscalls.master > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/compat/freebsd32/syscalls.master =A0 =A0 =A0 =A0(revision 229830) > +++ sys/compat/freebsd32/syscalls.master =A0 =A0 =A0 =A0(working copy) > @@ -997,3 +997,4 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ui= nt32_t offset1, uint32_t offset2,\ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ui= nt32_t len1, uint32_t len2, \ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in= t advice); } > +532 =A0 =A0AUE_NULL =A0 =A0 =A0 =A0STD =A0 =A0 { int dup3(u_int from, u_= int to, int flags); } > > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >From what I can see it seems that dup3() is Linux specific and not POSIX, so maybe there are some issues in adding it, but I may be wrong. Davide From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 09:44:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78A84106564A; Thu, 12 Jan 2012 09:44:53 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4D2DA8FC14; Thu, 12 Jan 2012 09:44:53 +0000 (UTC) Received: from [192.168.2.105] (host86-161-238-124.range86-161.btcentralplus.com [86.161.238.124]) by cyrus.watson.org (Postfix) with ESMTPSA id 30DA746B92; Thu, 12 Jan 2012 04:44:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: Date: Thu, 12 Jan 2012 09:44:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1440BE37-28E4-4D4F-B8A0-54FD0BB76AA4@freebsd.org> References: To: Adrian Chadd X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-hackers@freebsd.org, Gerald McNulty Subject: Re: Assigning the PRIV_NETINET_BINDANY privilege required for setsockopt(IP_BINDANY) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:44:53 -0000 On 12 Jan 2012, at 06:03, Adrian Chadd wrote: > On 11 January 2012 15:26, Gerald McNulty wrote: >> Using IP_BINDANY to facilitate transparent proxying works as = specified. >> According the ip(4) man page and sys/netinet/ip_output.c, the >> PRIV_NETINET_BINDANY privilege is required in order to make a = setsockopt() >> call with IP_BINDANY. >>=20 >> I would like to use this in an app that does not run as uid 0. Is it >> possible to assign the PRIV_NETINET_BINDANY privilege to a specific = uid or >> process or can this mechanism only be used in jails to reduce root >> privileges further? >=20 > I'm not sure if the relevant bits of MAC have been committed. Robert? Hi Adrian, Gerald: Currently there isn't a general-purpose privilege management policy in = FreeBSD. The MAC Framework supports specialised policies that modify OS = notions of privilege -- for example, the Biba policy does this, but it's = not what you're looking for. We have vague intent to do two things: (1) Add a role-based privilege model, allowing privileges to be assigned = to users as already possible in some other systems (such as Solaris) (2) Allow masks of privileges available to root (etc) in jails to be = explicitly managed, rather than relying on the hard-coded privilege list = currently in the Jail implementation The groundwork was laid for this in FreeBSD 7.0 with the itemisation of = available privileges, but a significant amount of further work remains = to be done. Despite the best intentions, it happened neither for 8.0 nor = 9.0. Some downstream consumers of FreeBSD use specialised MAC policies = to delegate rights to non-root users, but I'm not aware of a policy = implementation currently appropriate for upstreaming to us. I'd very much like to see this happen for 10.0, perhaps even with a = merge to 9.x, but currently there isn't an owner for this project. It = involves quite a bit of subtlety and care -- getting it wrong has the = potential to make a system more, rather than less, vulnerable. Robert= From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 09:56:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7148D106566C; Thu, 12 Jan 2012 09:56:58 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id A6D888FC0A; Thu, 12 Jan 2012 09:56:57 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id C77E92A28CDE; Thu, 12 Jan 2012 10:56:56 +0100 (CET) Date: Thu, 12 Jan 2012 10:56:56 +0100 From: Ed Schouten To: Eitan Adler Message-ID: <20120112095656.GD5300@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1IYcr18XUmgwOrO2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:56:58 -0000 --1IYcr18XUmgwOrO2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Eitan, * Eitan Adler , 20120112 06:01: > This is an implementation of dup3 for FreeBSD: > man page here (with a FreeBSD patch coming soon): > https://www.kernel.org/doc/man-pages/online/pages/man2/dup.2.html >=20 > Is this implementation correct? If so any objection to adding this as > a supported syscall? I suspect that not long after we add dup3(), some random person asks us to implement F_DUP3FD. Any chance you can implement this without using a system call, but through fcntl()? Thanks, --=20 Ed Schouten WWW: http://80386.nl/ --1IYcr18XUmgwOrO2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJPDq5oAAoJEG5e2P40kaK7rgoQAKnJvxf+ILpBiLJRkrnFJbXn ZV8DhTu1bBcAwSdmPvkJofHocNXyJyZPBqnNPhPVtAxAvJWiK9860kptsJYzjUN8 vIeoEThQjsWIIGl3XvRWCObDdDr6cfvww62Dz+mh3DgXse1Wx4GjgvebaKZKiDtQ 8/nV2PUKTmDjUDfRimjHzbyp1f91gYM5arLl6k7B9CYVhQEcPBfSHJ1e34VFupb6 630jyNghdg1zRkvLXA4xo9vBwOKH4on0XBwQwvqyTwwfLr0kVZun+g22QeI/oaXI saBwMrssG7u/b+2/9ifXVI85i06c8LVr+5o48gEWHHpHgcq4V/A0rIyCA/2dwwPu u8Mldbdng/SqQlztvfBVBBpworJqsbZNbwkCPNMR3l+42bQWhfigIHXgDQ7VawOa zqK624aEjAs05tbr99VxuF3tZcdSO1b7S5jinV4Ipzm2ARnReBmRRNOM1kG5gUed q4v4L3C8RwbqlsvfQdvnrUrp7EM+WQWF0zA23Wkf7BTBbHNQO6+qygauF1A12uo6 PUA+PhM1aYEH0Hevz7xoR4BDODiGue7CdOo4xLZDrRyTXEelMO8LdYy6bU1WyTQL C/t6nHfEHRQ4wqn7MY5a7rP7WajVw9tD4fp4PDzZTI2ZxXCcvrlQ4sZg9ratqS+F lkgzLGD47Z/6sr3YxgYp =hOWz -----END PGP SIGNATURE----- --1IYcr18XUmgwOrO2-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 10:08:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6786B1065673; Thu, 12 Jan 2012 10:08:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 764A88FC17; Thu, 12 Jan 2012 10:08:53 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0CA8ewi015401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 12:08:41 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0CA8ebn073427; Thu, 12 Jan 2012 12:08:40 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0CA8eVO073426; Thu, 12 Jan 2012 12:08:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Jan 2012 12:08:40 +0200 From: Kostik Belousov To: Eitan Adler Message-ID: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+hILXQfXzEY/zLuK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:08:54 -0000 --+hILXQfXzEY/zLuK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2012 at 12:01:29AM -0500, Eitan Adler wrote: > This is an implementation of dup3 for FreeBSD: > man page here (with a FreeBSD patch coming soon): > https://www.kernel.org/doc/man-pages/online/pages/man2/dup.2.html >=20 > Is this implementation correct? If so any objection to adding this as > a supported syscall? >=20 >=20 > Index: sys/kern/kern_descrip.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/kern_descrip.c (revision 229830) > +++ sys/kern/kern_descrip.c (working copy) > @@ -110,6 +110,7 @@ > /* Flags for do_dup() */ > #define DUP_FIXED 0x1 /* Force fixed allocation */ > #define DUP_FCNTL 0x2 /* fcntl()-style errors */ > +#define DUP_CLOEXEC 0x4 /* Enable O_CLOEXEC on the new fs */ >=20 > static int do_dup(struct thread *td, int flags, int old, int new, > register_t *retval); > @@ -307,7 +308,39 @@ > return (0); > } >=20 > +#ifndef _SYS_SYSPROTO_H_ > +struct dup3_args { > + u_int from; > + u_int to; > + int flags; > +}; > +#endif > + The _SYS_SYSPROTO_H_ should have been obsoleted and removed long time ago. I see no reasons to continue its agony for new syscalls. > /* > + * Duplicate a file descriptor and allow for O_CLOEXEC > + */ > + > +/* ARGSUSED */ ARGUSED is from the same category as SYS_SYSPROTO_H. > +int > +sys_dup3(struct thread * const td, struct dup3_args * const uap) { The td and uap are not constant in the prototypes generated by makesyscalls.sh. This makes me seriosly wonder was the patch compiled at all. > + > + KASSERT(td !=3D NULL, ("%s: td =3D=3D NULL", __func__)); > + KASSERT(uap !=3D NULL, ("%s: uap =3D=3D NULL", __func__)); The asserts are useless and must be removed. > + > + if (uap->from =3D=3D uap->to) > + return EINVAL; Style(9) recommends to brace the values of return operator. > + > + if (uap->flags & ~O_CLOEXEC) > + return EINVAL; > + > + const int dupflags =3D (uap->flags =3D=3D O_CLOEXEC) ? > DUP_FIXED|DUP_CLOEXEC : DUP_FIXED; There are too many style violations to enumerate them all, please do not consider the list below exhaustive: - the variable is declared in the executive part of the function body; - line too long; - no spaces around binary '|'. Not stule comments: there is no use in declaring dupflags const; it is better to test the presence of O_CLOEXEC with & instead of comparing with =3D=3D, to allow for ease introduction of future dup3 flags, if any. > + > + return (do_dup(td, dupflags, (int)uap->from, (int)uap->to, > + td->td_retval)); Why casting arguments to int ? > + return (0); Isn't this line never executed ? > +} > + > +/* > * Duplicate a file descriptor to a particular value. > * > * Note: keep in mind that a potential race condition exists when closing > @@ -912,6 +945,9 @@ > fdp->fd_lastfile =3D new; > *retval =3D new; >=20 > + if (flags & DUP_CLOEXEC) > + fdp->fd_ofileflags[new] |=3D UF_EXCLOSE; > + It is better to handle UF_EXCLOSE at the time of assignment to fdp->fd_ofileflags[new] just above, instead of clearing UF_EXCLOSE and then setting it. > /* > * If we dup'd over a valid file, we now own the reference to it > * and must dispose of it using closef() semantics (as if a > Index: sys/kern/syscalls.master > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/kern/syscalls.master (revision 229830) > +++ sys/kern/syscalls.master (working copy) > @@ -951,5 +951,6 @@ > off_t offset, off_t len); } > 531 AUE_NULL STD { int posix_fadvise(int fd, off_t offset, \ > off_t len, int advice); } > +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } > ; Please copy any additions and changes to the following compatability t= ables: > ; sys/compat/freebsd32/syscalls.master > Index: sys/compat/freebsd32/syscalls.master > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/compat/freebsd32/syscalls.master (revision 229830) > +++ sys/compat/freebsd32/syscalls.master (working copy) > @@ -997,3 +997,4 @@ > uint32_t offset1, uint32_t offset2,\ > uint32_t len1, uint32_t len2, \ > int advice); } > +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } And again, this part of patch makes me think that you never compiled it. That said, I am not sure that we shall copy the O_CLOEXEC crusade from Linux until it is standartized. And, if copying, I think we shall copy all bits of the new API, like SOCK_CLOEXEC etc, and not just dup3. --+hILXQfXzEY/zLuK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8OsSgACgkQC3+MBN1Mb4g06ACfd6w3dAda842SWf73Bqnq3Ajj zDkAn1Wh2RDtBjBjB4flOzlGNw5sZYDQ =VUKQ -----END PGP SIGNATURE----- --+hILXQfXzEY/zLuK-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 10:11:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 805F9106566C; Thu, 12 Jan 2012 10:11:40 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 3FEED8FC15; Thu, 12 Jan 2012 10:11:40 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id A3D222A28CEC; Thu, 12 Jan 2012 11:11:39 +0100 (CET) Date: Thu, 12 Jan 2012 11:11:39 +0100 From: Ed Schouten To: Eitan Adler Message-ID: <20120112101139.GE5300@hoeg.nl> References: <20120112095656.GD5300@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mjUDp/cLGeqUhYyE" Content-Disposition: inline In-Reply-To: <20120112095656.GD5300@hoeg.nl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:11:40 -0000 --mjUDp/cLGeqUhYyE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten , 20120112 10:56: > I suspect that not long after we add dup3(), some random person asks us > to implement F_DUP3FD. Any chance you can implement this without using a > system call, but through fcntl()? Never mind. This seems to be non-trivial, as fcntl() just takes a single parameter and dup3() requires the newfd and the flags. --=20 Ed Schouten WWW: http://80386.nl/ --mjUDp/cLGeqUhYyE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJPDrHbAAoJEG5e2P40kaK7xMgP/jyRYgPl97fnbSz4COGdXNG8 Nzb9VKzVGi+Q9PJDRjkmpLk/y1CK+PzBgomS5rjHvE8/kl/ai164eKT+wKaCUzIa DSJGE1rC0NpJaVqQlL8WrrMloK27w162Z1jyDLWR2vtsDp6lgBCpgAk5NEapq3li wtnkjgB3Xu/Hm89mHxpLgSXQsUvGV2F7Alk9wSYupZhqL6XHsTBbA60PhRFbgL3+ P3IrIvt/58IUJ6FiBwjfNEDqeiFDuJC7E7pDTspqa8l89pbC30yPoBgvS9N2zqSO AXnVA6Q6DHDBw0yDHkjgYgetC8g3Wr0JnXqbbEiPb9wk+lXjiYzgXehPgTfa1oIA 70i44f9vW9GTNdnLtse9OBXAo0mRR7bjMnOar7bHdVjh3wSyEiTG8sn9+jxQRhsn CHMU4k3w9OekuD3DS/sLPbv65MYurNJUjuakU6VQObCzAuWWR/Q6ufR6Hce4Gr8C 66f7KGtFb2rxk8iLGzeRhxtgxOneVlx6BssNHbCPacqL0UD1eKYuMPQv2gaJVnAK sSZsr5yzugwmcHTNkQ8Y4QVG5bml7zJ/S/ws8PC19MTabn9cvJnfLhJGSSWci40p M9SEz8fcvErGfNeBfOjjO0Ts+C7+mz70k4xw6pA77djkUuwkrTuLtF91wO0cHU82 djHT84UnSFAkov7qpjRu =wjkw -----END PGP SIGNATURE----- --mjUDp/cLGeqUhYyE-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 10:23:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09042106566B; Thu, 12 Jan 2012 10:23:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 41A628FC0C; Thu, 12 Jan 2012 10:23:39 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0CAN9Na018944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 12:23:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0CAN6ik073543; Thu, 12 Jan 2012 12:23:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0CAN6ls073542; Thu, 12 Jan 2012 12:23:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 12 Jan 2012 12:23:06 +0200 From: Kostik Belousov To: Eitan Adler Message-ID: <20120112102306.GW31224@deviant.kiev.zoral.com.ua> References: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gaVk6OYrcNQmNLCV" Content-Disposition: inline In-Reply-To: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:23:40 -0000 --gaVk6OYrcNQmNLCV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2012 at 12:08:40PM +0200, Kostik Belousov wrote: > On Thu, Jan 12, 2012 at 12:01:29AM -0500, Eitan Adler wrote: > > This is an implementation of dup3 for FreeBSD: > > man page here (with a FreeBSD patch coming soon): > > https://www.kernel.org/doc/man-pages/online/pages/man2/dup.2.html > >=20 > > Is this implementation correct? If so any objection to adding this as > > a supported syscall? > >=20 > >=20 > > Index: sys/kern/kern_descrip.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/kern/kern_descrip.c (revision 229830) > > +++ sys/kern/kern_descrip.c (working copy) > > @@ -110,6 +110,7 @@ > > /* Flags for do_dup() */ > > #define DUP_FIXED 0x1 /* Force fixed allocation */ > > #define DUP_FCNTL 0x2 /* fcntl()-style errors */ > > +#define DUP_CLOEXEC 0x4 /* Enable O_CLOEXEC on the new fs */ > >=20 > > static int do_dup(struct thread *td, int flags, int old, int new, > > register_t *retval); > > @@ -307,7 +308,39 @@ > > return (0); > > } > >=20 > > +#ifndef _SYS_SYSPROTO_H_ > > +struct dup3_args { > > + u_int from; > > + u_int to; > > + int flags; > > +}; > > +#endif > > + > The _SYS_SYSPROTO_H_ should have been obsoleted and removed long time ago. > I see no reasons to continue its agony for new syscalls. >=20 > > /* > > + * Duplicate a file descriptor and allow for O_CLOEXEC > > + */ > > + > > +/* ARGSUSED */ > ARGUSED is from the same category as SYS_SYSPROTO_H. >=20 > > +int > > +sys_dup3(struct thread * const td, struct dup3_args * const uap) { > The td and uap are not constant in the prototypes generated by > makesyscalls.sh. This makes me seriosly wonder was the patch compiled at > all. >=20 > > + > > + KASSERT(td !=3D NULL, ("%s: td =3D=3D NULL", __func__)); > > + KASSERT(uap !=3D NULL, ("%s: uap =3D=3D NULL", __func__)); > The asserts are useless and must be removed. >=20 > > + > > + if (uap->from =3D=3D uap->to) > > + return EINVAL; > Style(9) recommends to brace the values of return operator. >=20 > > + > > + if (uap->flags & ~O_CLOEXEC) > > + return EINVAL; > > + > > + const int dupflags =3D (uap->flags =3D=3D O_CLOEXEC) ? > > DUP_FIXED|DUP_CLOEXEC : DUP_FIXED; > There are too many style violations to enumerate them all, please do not > consider the list below exhaustive: > - the variable is declared in the executive part of the function body; > - line too long; > - no spaces around binary '|'. >=20 > Not stule comments: there is no use in declaring dupflags const; > it is better to test the presence of O_CLOEXEC with & instead of comparing > with =3D=3D, to allow for ease introduction of future dup3 flags, if any. >=20 > > + > > + return (do_dup(td, dupflags, (int)uap->from, (int)uap->to, > > + td->td_retval)); > Why casting arguments to int ? > > + return (0); > Isn't this line never executed ? > > +} > > + > > +/* > > * Duplicate a file descriptor to a particular value. > > * > > * Note: keep in mind that a potential race condition exists when clos= ing > > @@ -912,6 +945,9 @@ > > fdp->fd_lastfile =3D new; > > *retval =3D new; > >=20 > > + if (flags & DUP_CLOEXEC) > > + fdp->fd_ofileflags[new] |=3D UF_EXCLOSE; > > + > It is better to handle UF_EXCLOSE at the time of assignment to > fdp->fd_ofileflags[new] just above, instead of clearing UF_EXCLOSE > and then setting it. >=20 > > /* > > * If we dup'd over a valid file, we now own the reference to it > > * and must dispose of it using closef() semantics (as if a > > Index: sys/kern/syscalls.master > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/kern/syscalls.master (revision 229830) > > +++ sys/kern/syscalls.master (working copy) > > @@ -951,5 +951,6 @@ > > off_t offset, off_t len); } > > 531 AUE_NULL STD { int posix_fadvise(int fd, off_t offset, \ > > off_t len, int advice); } > > +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } > > ; Please copy any additions and changes to the following compatability= tables: > > ; sys/compat/freebsd32/syscalls.master > > Index: sys/compat/freebsd32/syscalls.master > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/compat/freebsd32/syscalls.master (revision 229830) > > +++ sys/compat/freebsd32/syscalls.master (working copy) > > @@ -997,3 +997,4 @@ > > uint32_t offset1, uint32_t offset2,\ > > uint32_t len1, uint32_t len2, \ > > int advice); } > > +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } > And again, this part of patch makes me think that you never compiled it. Oh, and it misses the versioning for the new syscall symbols in libc. The symbols not listed in the Symbol.maps are made local during the final linkage. --gaVk6OYrcNQmNLCV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8OtIoACgkQC3+MBN1Mb4htvQCglv77VlHDkghe4Lr7HtDdt2IN WiIAoNo77zMGmpzG/ncvfK30kNxXdbPj =MMik -----END PGP SIGNATURE----- --gaVk6OYrcNQmNLCV-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 10:38:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BFEC1065678; Thu, 12 Jan 2012 10:38:52 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6688FC27; Thu, 12 Jan 2012 10:38:52 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 7E9F62A28CC6; Thu, 12 Jan 2012 11:38:51 +0100 (CET) Date: Thu, 12 Jan 2012 11:38:51 +0100 From: Ed Schouten To: Kostik Belousov Message-ID: <20120112103851.GF5300@hoeg.nl> References: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2XUWoe1nmt7t49kG" Content-Disposition: inline In-Reply-To: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: jilles@freebsd.org, Eitan Adler , Colin Percival , FreeBSD Hackers Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 10:38:52 -0000 --2XUWoe1nmt7t49kG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Kostik, * Kostik Belousov , 20120112 11:08: > > +int > > +sys_dup3(struct thread * const td, struct dup3_args * const uap) { > The td and uap are not constant in the prototypes generated by > makesyscalls.sh. This makes me seriosly wonder was the patch compiled at > all. This is because the parameters itself are const -- not the objects they point to. e.g: int foo(int); int foo(const int i) { /* code here */ } --=20 Ed Schouten WWW: http://80386.nl/ --2XUWoe1nmt7t49kG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJPDrg7AAoJEG5e2P40kaK7dSwQAIbXS2yRIFsxLAMWF24SaMd1 61Q2pkoFcyW5r4NRoz9jgCs+xdyqBGaeL+pkTNc4DxWxbJjjX9fODsqSXFz+Dn+A Bzybm2FtXyzdCgXH93rLISB0zNd3/BUcIPffiH9twphLEFSNQ0ikLLuhL+uDPppX pwtwRUEx9nlFiYLdRds2TqWOqnvgF04RXIzY5bo7Ltuzu4hicFuUtP9YzRLPmp7n D2l/U7bXCnhtT0/dgRv04WYpdjSDGF/ibltUsTh27lqdwkCAEuiRtJJ/s+SM8YfL AUVp8brSAJJwSgv3vrEAz0tNtzHixzMmzZfi1XaEIfu57PV2VWUDFn83N6Ys3DT5 wImgI8PdRu14PKfKpRdFf+tqtGIjjwKX3WpLu24rWMQTg+8jwcvyVDzXUXR2YR4+ 2nUmBbtGR6hzVPWL0z+eU0s+E3VyVphjvVxz/+QvfQuGdECySxaKu7+LcidXrfE/ bfwYgVu+tuB7/Y5vFRTBF9LvsMwDw9eEi28QMhL8P+9wVjY1OyRWzQ3YpmPwtg1k EzFd8zZgzRuslxQQlxoJy8LRBLWybZ5YqiYoDLZ2ardnFnBGAzodPCG12H44gUTq 56ImFnBuUKlpZK8GS5QYLxjF8tNigqChd2N/3dMwI2DODuoB2G09NSZB9+YcJ1jx +olLCtOamANfsfFuQ1O0 =BNjK -----END PGP SIGNATURE----- --2XUWoe1nmt7t49kG-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 12:52:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67851106566B; Thu, 12 Jan 2012 12:52:01 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1808FC17; Thu, 12 Jan 2012 12:52:00 +0000 (UTC) Received: by lahd3 with SMTP id d3so1256998lah.13 for ; Thu, 12 Jan 2012 04:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Vg5tXhtcSWKSqyukNofkg6XEgJfAL18lfJoZqiI4YEc=; b=OU2nkrNKGWbOhKamlUwUCya2CefzCkJ6QCNdWvDcUsxA0p/CwnkJ91u3LoaezdLNOF gfPy0Urmsto8JVdU9pRuzNZbtzRKCjeMg5oVj98NsZVDNbn4wep+8sHlaEaUXQtvKFeF E3H0mKbpG2JYnQ/DkrnScvxsiy9yUpGi2OJtc= Received: by 10.112.25.35 with SMTP id z3mr772582lbf.52.1326372719170; Thu, 12 Jan 2012 04:51:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.129.8 with HTTP; Thu, 12 Jan 2012 04:51:28 -0800 (PST) In-Reply-To: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> References: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> From: Eitan Adler Date: Thu, 12 Jan 2012 07:51:28 -0500 Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:52:01 -0000 Thank you for your comments. I will hopefully have version 2 of the diff tonight. On Thu, Jan 12, 2012 at 4:56 AM, Ed Schouten wrote: > I suspect that not long after we add dup3(), some random person asks us > to implement F_DUP3FD. Any chance you can implement this without using a > system call, but through fcntl()? The goal is to be atomic with the duplication. On Thu, Jan 12, 2012 at 5:08 AM, Kostik Belousov wrot= e: > makesyscalls.sh. This makes me seriosly wonder was the patch compiled at > all. It was compiled and tested in a virtual machine. I did however generate this diff differently than the one I tested (I applied my git diff against svn and used the svn diff here) so I may have missed something when doing that. >> + >> + =C2=A0 =C2=A0 return (do_dup(td, dupflags, (int)uap->from, (int)uap->t= o, >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 td->td_retval)= ); > Why casting arguments to int ? I stole this line from sys_dup2. >> + =C2=A0 =C2=A0 return (0); > Isn't this line never executed ? Yes, this was leftover of some previous version. >> +} >> + >> +/* >> =C2=A0 * Duplicate a file descriptor to a particular value. >> =C2=A0 * >> =C2=A0 * Note: keep in mind that a potential race condition exists when = closing >> @@ -912,6 +945,9 @@ >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fdp->fd_lastfile =3D ne= w; >> =C2=A0 =C2=A0 =C2=A0 *retval =3D new; >> >> + =C2=A0 =C2=A0 if (flags & DUP_CLOEXEC) >> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 fdp->fd_ofileflags[new] |=3D= UF_EXCLOSE; >> + > It is better to handle UF_EXCLOSE at the time of assignment to > fdp->fd_ofileflags[new] just above, instead of clearing UF_EXCLOSE > and then setting it. > > That said, I am not sure that we shall copy the O_CLOEXEC crusade from > Linux until it is standartized. And, if copying, I think we shall copy > all bits of the new API, like SOCK_CLOEXEC etc, and not just dup3. If it is standardized I can't see how it will have semantics that differ from the current Linux version and IMHO this is a worthwhile thing to add. > Oh, and it misses the versioning for the new syscall symbols in libc. > The symbols not listed in the Symbol.maps are made local during the > final linkage. Cut me a bit slack, this is my first attempt at adding a syscall ;) --=20 Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 12 14:04:45 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E9F51065670; Thu, 12 Jan 2012 14:04:45 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F5FF8FC17; Thu, 12 Jan 2012 14:04:41 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id q0CE4JQ9066103; Thu, 12 Jan 2012 15:04:34 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id q0CE4ItN066102; Thu, 12 Jan 2012 15:04:18 +0100 (CET) (envelope-from olli) Date: Thu, 12 Jan 2012 15:04:18 +0100 (CET) Message-Id: <201201121404.q0CE4ItN066102@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, Oliver Fromme , freebsd-net@FreeBSD.ORG, "Paul A. Procacci" In-Reply-To: X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.9.6-20101126 ("Burnside") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (lurza.secnetix.de [127.0.0.1]); Thu, 12 Jan 2012 15:04:35 +0100 (CET) Cc: Subject: Re: Processes' FIBs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 14:04:45 -0000 Bjoern A. Zeeb wrote: > On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: > > I'm currently looking at the source code of ps, but adding > > a field for the FIB isn't as trivial as I thought because > > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > > which doesn't contain the FIB. procstat does the same. > > > > I'm currently trying to write a patch that copies p_fibnum > > from struct proc to struct kinfo_proc (just like p_nice, > > for example). Does that make sense? If so, does the patch > > below look reasonable? (I've made it on a stable/8 system, > > but it should apply to 9 and 10, too.) > > I am not sure it makes too much sense in ps. It might make sense in > sockstat maybe? Well, every process has a default FIB number (p_fibnum in struct proc). It is a property of the process, just like the nice value for example. So I think it makes sense for ps to be able to display it if the user asks for it. This is the piece of information that I need. On the other hand, sockstat displays open sockets only. Of course, an internet socket has a FIB number associated with it, too, so sockstat could display it. But that would be a completely different piece of information, and it wouldn't solve the actual problem that I'm currently facing. Best regards Oliver --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 @@ -83,7 +83,7 @@ * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and * function kvm_proclist in lib/libkvm/kvm_proc.c . */ -#define KI_NSPARE_INT 9 +#define KI_NSPARE_INT 8 #define KI_NSPARE_LONG 12 #define KI_NSPARE_PTR 6 @@ -177,6 +177,7 @@ */ char ki_sparestrings[68]; /* spare string space */ int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ + int ki_fibnum; /* Default FIB number */ u_int ki_cr_flags; /* Credential flags */ int ki_jid; /* Process jail ID */ int ki_numthreads; /* XXXKSE number of threads in total */ --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 @@ -775,6 +775,7 @@ kp->ki_swtime = (ticks - p->p_swtick) / hz; kp->ki_pid = p->p_pid; kp->ki_nice = p->p_nice; + kp->ki_fibnum = p->p_fibnum; PROC_SLOCK(p); rufetch(p, &kp->ki_rusage); kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime); --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 @@ -90,6 +90,7 @@ NULL, 0}, {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0}, {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 03:08:31 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45BBA106566C; Fri, 13 Jan 2012 03:08:31 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 62DC68FC13; Fri, 13 Jan 2012 03:08:30 +0000 (UTC) Received: by lahd3 with SMTP id d3so48012lah.13 for ; Thu, 12 Jan 2012 19:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JfNgc/L/G6kDfjN9JmLyuJTfnlNZ0GNwNmsYfFow9A4=; b=bvjObFl3nkYixT7QAMdAWffxyT3X7dzKqMqQ6Ac0xJneqRiYkkjogdCXvWF0kMk8wq rmWQZPMAgsaBylLR19ry0SajSMohjrosL7bvU801oWexslNSJLoomZ8SnP25VZcbPDVx WOFTEbYPs7oZfvbuf/UpSn+kOU8wRob9AcUSg= Received: by 10.112.83.197 with SMTP id s5mr132891lby.9.1326424109130; Thu, 12 Jan 2012 19:08:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.17.163 with HTTP; Thu, 12 Jan 2012 19:07:58 -0800 (PST) In-Reply-To: References: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> From: Eitan Adler Date: Thu, 12 Jan 2012 22:07:58 -0500 Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=UTF-8 Cc: jilles@freebsd.org, FreeBSD Hackers , Colin Percival Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 03:08:31 -0000 Okay - here is version 2 (compile and run tested) Index: sys/kern/kern_descrip.c =================================================================== --- sys/kern/kern_descrip.c (revision 229830) +++ sys/kern/kern_descrip.c (working copy) @@ -110,6 +110,7 @@ /* Flags for do_dup() */ #define DUP_FIXED 0x1 /* Force fixed allocation */ #define DUP_FCNTL 0x2 /* fcntl()-style errors */ +#define DUP_CLOEXEC 0x4 /* Enable O_CLOEXEC on the new fs */ static int do_dup(struct thread *td, int flags, int old, int new, register_t *retval); @@ -307,7 +308,36 @@ return (0); } +struct dup3_args { + u_int from; + u_int to; + int flags; +}; + /* + * Duplicate a file descriptor and allow for O_CLOEXEC + */ + +int +sys_dup3(struct thread * td, struct dup3_args * uap) { + int dupflags; + + if (uap->from == uap->to) + return (EINVAL); + + if (uap->flags & ~O_CLOEXEC) + return (EINVAL); + + dupflags = DUP_FIXED; + if (uap->flags & O_CLOEXEC) + dupflags |= DUP_CLOEXEC; + + return (do_dup(td, dupflags, (int)uap->from, (int)uap->to, + td->td_retval)); + return (0); +} + +/* * Duplicate a file descriptor to a particular value. * * Note: keep in mind that a potential race condition exists when closing @@ -912,6 +942,9 @@ fdp->fd_lastfile = new; *retval = new; + if (flags & DUP_CLOEXEC) + fdp->fd_ofileflags[new] |= UF_EXCLOSE; + /* * If we dup'd over a valid file, we now own the reference to it * and must dispose of it using closef() semantics (as if a Index: sys/kern/syscalls.master =================================================================== --- sys/kern/syscalls.master (revision 229830) +++ sys/kern/syscalls.master (working copy) @@ -951,5 +951,6 @@ off_t offset, off_t len); } 531 AUE_NULL STD { int posix_fadvise(int fd, off_t offset, \ off_t len, int advice); } +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } ; Please copy any additions and changes to the following compatability tables: ; sys/compat/freebsd32/syscalls.master Index: sys/compat/freebsd32/syscalls.master =================================================================== --- sys/compat/freebsd32/syscalls.master (revision 229830) +++ sys/compat/freebsd32/syscalls.master (working copy) @@ -997,3 +997,4 @@ uint32_t offset1, uint32_t offset2,\ uint32_t len1, uint32_t len2, \ int advice); } +532 AUE_NULL STD { int dup3(u_int from, u_int to, int flags); } Index: lib/libc/sys/Symbol.map =================================================================== --- lib/libc/sys/Symbol.map (revision 229830) +++ lib/libc/sys/Symbol.map (working copy) @@ -383,6 +383,7 @@ FBSD_1.3 { posix_fadvise; + dup3; }; FBSDprivate_1.0 { -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 06:43:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54FEE106566B; Fri, 13 Jan 2012 06:43:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1FEEB8FC0A; Fri, 13 Jan 2012 06:43:54 +0000 (UTC) Received: from julian-mac.elischer.org ([12.42.66.130]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q0D6hmCg048734 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 22:43:50 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F0FD2E3.1060607@freebsd.org> Date: Thu, 12 Jan 2012 22:44:51 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.25) Gecko/20111213 Thunderbird/3.1.17 MIME-Version: 1.0 To: Oliver Fromme References: <201201121404.q0CE4ItN066102@lurza.secnetix.de> In-Reply-To: <201201121404.q0CE4ItN066102@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "Paul A. Procacci" , Oliver Fromme , freebsd-net@freebsd.org Subject: Re: Processes' FIBs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:43:55 -0000 On 1/12/12 6:04 AM, Oliver Fromme wrote: > Bjoern A. Zeeb wrote: > > On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: > > > I'm currently looking at the source code of ps, but adding > > > a field for the FIB isn't as trivial as I thought because > > > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > > > which doesn't contain the FIB. procstat does the same. > > > > > > I'm currently trying to write a patch that copies p_fibnum > > > from struct proc to struct kinfo_proc (just like p_nice, > > > for example). Does that make sense? If so, does the patch > > > below look reasonable? (I've made it on a stable/8 system, > > > but it should apply to 9 and 10, too.) > > > > I am not sure it makes too much sense in ps. It might make sense in > > sockstat maybe? > > Well, every process has a default FIB number (p_fibnum in > struct proc). It is a property of the process, just like > the nice value for example. So I think it makes sense for > ps to be able to display it if the user asks for it. This > is the piece of information that I need. > > On the other hand, sockstat displays open sockets only. > Of course, an internet socket has a FIB number associated > with it, too, so sockstat could display it. But that > would be a completely different piece of information, > and it wouldn't solve the actual problem that I'm currently > facing. > I hadn't considered that a process would want to see the fib of another. but of course it makes sense. I see no problem the the attached patch except that it doesn't fix the man page for ps and setfib(2) or setfib(8) (or is it 1?) etc. if there are no objections, I can add this when it has been polished.. > Best regards > Oliver > > --- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 > +++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 > @@ -83,7 +83,7 @@ > * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c and > * function kvm_proclist in lib/libkvm/kvm_proc.c . > */ > -#define KI_NSPARE_INT 9 > +#define KI_NSPARE_INT 8 > #define KI_NSPARE_LONG 12 > #define KI_NSPARE_PTR 6 > > @@ -177,6 +177,7 @@ > */ > char ki_sparestrings[68]; /* spare string space */ > int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ > + int ki_fibnum; /* Default FIB number */ > u_int ki_cr_flags; /* Credential flags */ > int ki_jid; /* Process jail ID */ > int ki_numthreads; /* XXXKSE number of threads in total */ > --- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 > +++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 > @@ -775,6 +775,7 @@ > kp->ki_swtime = (ticks - p->p_swtick) / hz; > kp->ki_pid = p->p_pid; > kp->ki_nice = p->p_nice; > + kp->ki_fibnum = p->p_fibnum; > PROC_SLOCK(p); > rufetch(p,&kp->ki_rusage); > kp->ki_runtime = cputick2usec(p->p_rux.rux_runtime); > --- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 > +++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 > @@ -90,6 +90,7 @@ > NULL, 0}, > {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL, 0}, > {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, > + {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, > {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 07:28:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 277C61065670 for ; Fri, 13 Jan 2012 07:28:54 +0000 (UTC) (envelope-from v.haisman@sh.cvut.cz) Received: from service1.sh.cvut.cz (ns2.sh.cvut.cz [IPv6:2001:718:2::241]) by mx1.freebsd.org (Postfix) with ESMTP id 9E37C8FC0C for ; Fri, 13 Jan 2012 07:28:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by service1.sh.cvut.cz (Postfix) with ESMTP id 8BBBE24267; Fri, 13 Jan 2012 08:28:51 +0100 (CET) X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-255 required=5 tests=[BAYES_00=-1.9, RCVD_IN_RP_RNBL=1.31, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from service1.sh.cvut.cz ([127.0.0.1]) by localhost (service1.sh.cvut.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6Q+-GFlLKgs; Fri, 13 Jan 2012 08:28:51 +0100 (CET) Received: from shell.sh.cvut.cz (shell.sh.cvut.cz [147.32.127.212]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by service1.sh.cvut.cz (Postfix) with ESMTPS id 28CC0240B8; Fri, 13 Jan 2012 08:28:51 +0100 (CET) Received: by shell.sh.cvut.cz (Postfix, from userid 50017) id B7638DE0F; Fri, 13 Jan 2012 08:28:51 +0100 (CET) To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 13 Jan 2012 08:28:51 +0100 From: =?UTF-8?Q?V=C3=A1clav_Zeman?= In-Reply-To: References: <20120112100840.GV31224@deviant.kiev.zoral.com.ua> Message-ID: <7e876d727968c783478caf9dcab62488@shell.sh.cvut.cz> X-Sender: v.haisman@sh.cvut.cz User-Agent: Roundcube Webmail/0.5.4 Subject: Re: dup3 syscall - atomic set O_CLOEXEC with dup2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 07:28:54 -0000 On Thu, 12 Jan 2012 22:07:58 -0500, Eitan Adler wrote: > Okay - here is version 2 (compile and run tested) > > Index: sys/kern/kern_descrip.c > =================================================================== > --- sys/kern/kern_descrip.c (revision 229830) > +++ sys/kern/kern_descrip.c (working copy) > @@ -110,6 +110,7 @@ > /* Flags for do_dup() */ > #define DUP_FIXED 0x1 /* Force fixed allocation */ > #define DUP_FCNTL 0x2 /* fcntl()-style errors */ > +#define DUP_CLOEXEC 0x4 /* Enable O_CLOEXEC on the new fs */ s/fs/fd/? -----------------------------------------------------^^ -- VZ From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 09:59:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4932B106566B for ; Fri, 13 Jan 2012 09:59:24 +0000 (UTC) (envelope-from dgre090@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BDE258FC16 for ; Fri, 13 Jan 2012 09:59:23 +0000 (UTC) Received: by lahd3 with SMTP id d3so249627lah.13 for ; Fri, 13 Jan 2012 01:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=7XqwTGyM0FOMgtC4EcA34iDMilEfojY/9etGUL4uTxw=; b=EQldix1rh7JBsWCP4OQ0hf/wo1cwp/+BfPF4qlLog7y8t+oyevjlE+HHSr58jwJprV pVhBENjpjjWj3AAxNsOAWcAPDnE7bDpq7SjPxaQnQZVPlszDMLMU7231cJg81fSQ430I yCnIZ+yWAjHKNJp/n0Jxlm7CmZb20XUQboa5s= MIME-Version: 1.0 Received: by 10.152.105.113 with SMTP id gl17mr698458lab.25.1326446958360; Fri, 13 Jan 2012 01:29:18 -0800 (PST) Received: by 10.152.3.166 with HTTP; Fri, 13 Jan 2012 01:29:18 -0800 (PST) Date: Fri, 13 Jan 2012 10:29:18 +0100 Message-ID: From: Daniel Grech To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: USB Zero length packet X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 09:59:24 -0000 Hi, does anybody know what the procedure for sending a zero length packet through libusb on FreeBSD is ? Thanks in advance, Regards, Daniel From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 12:28:04 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C775106568A for ; Fri, 13 Jan 2012 12:28:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id F2B588FC1A for ; Fri, 13 Jan 2012 12:28:03 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0DCRpEx098358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 14:27:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0DCRp0i091394; Fri, 13 Jan 2012 14:27:51 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0DCRnHi091393; Fri, 13 Jan 2012 14:27:49 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 13 Jan 2012 14:27:49 +0200 From: Kostik Belousov To: Julian Elischer Message-ID: <20120113122749.GG31224@deviant.kiev.zoral.com.ua> References: <201201121404.q0CE4ItN066102@lurza.secnetix.de> <4F0FD2E3.1060607@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l7ZAGG5ZGPl0OWqn" Content-Disposition: inline In-Reply-To: <4F0FD2E3.1060607@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-hackers@freebsd.org, "Paul A. Procacci" , Oliver Fromme , Oliver Fromme , freebsd-net@freebsd.org Subject: Re: Processes' FIBs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:28:04 -0000 --l7ZAGG5ZGPl0OWqn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2012 at 10:44:51PM -0800, Julian Elischer wrote: > On 1/12/12 6:04 AM, Oliver Fromme wrote: > >Bjoern A. Zeeb wrote: > > > On 11. Jan 2012, at 15:06 , Oliver Fromme wrote: > > > > I'm currently looking at the source code of ps, but adding > > > > a field for the FIB isn't as trivial as I thought because > > > > ps only sees struct kinfo_proc (via sysctl kern.proc.*) > > > > which doesn't contain the FIB. procstat does the same. > > > > > > > > I'm currently trying to write a patch that copies p_fibnum > > > > from struct proc to struct kinfo_proc (just like p_nice, > > > > for example). Does that make sense? If so, does the patch > > > > below look reasonable? (I've made it on a stable/8 system, > > > > but it should apply to 9 and 10, too.) > > > > > > I am not sure it makes too much sense in ps. It might make sense in > > > sockstat maybe? > > > >Well, every process has a default FIB number (p_fibnum in > >struct proc). It is a property of the process, just like > >the nice value for example. So I think it makes sense for > >ps to be able to display it if the user asks for it. This > >is the piece of information that I need. > > > >On the other hand, sockstat displays open sockets only. > >Of course, an internet socket has a FIB number associated > >with it, too, so sockstat could display it. But that > >would be a completely different piece of information, > >and it wouldn't solve the actual problem that I'm currently > >facing. > > >=20 > I hadn't considered that a process would want to see the fib of another. > but of course it makes sense. > I see no problem the the attached patch except that it doesn't fix the=20 > man page for ps and setfib(2) or setfib(8) (or is it 1?) >=20 > etc. > if there are no objections, I can add this when it has been polished.. The patch misses compat32 bits and breaks compat32 ps/top. >=20 > >Best regards > > Oliver > > > >--- ./sys/sys/user.h.orig 2011-07-12 14:23:54.000000000 +0200 > >+++ ./sys/sys/user.h 2012-01-11 15:35:50.000000000 +0100 > >@@ -83,7 +83,7 @@ > > * it in two places: function fill_kinfo_proc in sys/kern/kern_proc.c = and > > * function kvm_proclist in lib/libkvm/kvm_proc.c . > > */ > >-#define KI_NSPARE_INT 9 > >+#define KI_NSPARE_INT 8 > > #define KI_NSPARE_LONG 12 > > #define KI_NSPARE_PTR 6 > > > >@@ -177,6 +177,7 @@ > > */ > > char ki_sparestrings[68]; /* spare string space */ > > int ki_spareints[KI_NSPARE_INT]; /* spare room for growth */ > >+ int ki_fibnum; /* Default FIB number */ > > u_int ki_cr_flags; /* Credential flags */ > > int ki_jid; /* Process jail ID */ > > int ki_numthreads; /* XXXKSE number of threads in total=20 > > */ > >--- ./sys/kern/kern_proc.c.orig 2011-07-12 14:19:26.000000000 +0200 > >+++ ./sys/kern/kern_proc.c 2012-01-11 15:36:22.000000000 +0100 > >@@ -775,6 +775,7 @@ > > kp->ki_swtime =3D (ticks - p->p_swtick) / hz; > > kp->ki_pid =3D p->p_pid; > > kp->ki_nice =3D p->p_nice; > >+ kp->ki_fibnum =3D p->p_fibnum; > > PROC_SLOCK(p); > > rufetch(p,&kp->ki_rusage); > > kp->ki_runtime =3D cputick2usec(p->p_rux.rux_runtime); > >--- ./bin/ps/keyword.c.orig 2011-07-12 13:42:48.000000000 +0200 > >+++ ./bin/ps/keyword.c 2012-01-11 15:44:27.000000000 +0100 > >@@ -90,6 +90,7 @@ > > NULL, 0}, > > {"etime", "ELAPSED", NULL, USER, elapsed, NULL, 12, 0, CHAR, NULL,=20 > > 0}, > > {"f", "F", NULL, 0, kvar, NULL, 8, KOFF(ki_flag), INT, "x", 0}, > >+ {"fib", "FIB", NULL, 0, kvar, NULL, 2, KOFF(ki_fibnum), INT, "d", 0}, > > {"flags", "", "f", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > > {"ignored", "", "sigignore", 0, NULL, NULL, 0, 0, CHAR, NULL, 0}, > > {"inblk", "INBLK", NULL, USER, rvar, NULL, 4, ROFF(ru_inblock), LONG, > >_______________________________________________ > >freebsd-hackers@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.or= g" > > >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --l7ZAGG5ZGPl0OWqn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8QI0UACgkQC3+MBN1Mb4iZIQCeJMmMRc1xlEKG9AqVZ5Z3g7b2 htsAn1sIrSGYbjpROJhvpknVM7mUoiEx =uZA+ -----END PGP SIGNATURE----- --l7ZAGG5ZGPl0OWqn-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 12:21:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C330106564A for ; Fri, 13 Jan 2012 12:21:20 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 3454B8FC13 for ; Fri, 13 Jan 2012 12:21:18 +0000 (UTC) Received: (qmail 47368 invoked by uid 907); 13 Jan 2012 12:21:16 -0000 Received: from b13FC.static.pacific.net.au (HELO [192.168.1.155]) (202.7.88.252) (smtp-auth username janm, mechanism plain) by midgard.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Fri, 13 Jan 2012 23:21:16 +1100 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Jan Mikkelsen In-Reply-To: Date: Fri, 13 Jan 2012 23:21:38 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201201110806.30620.jhb@freebsd.org> To: Garrett Cooper X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Fri, 13 Jan 2012 12:28:42 +0000 Cc: freebsd-hackers@freebsd.org, Xin LI , Ivan Voras , davidxu@freebsd.org Subject: Re: sem(4) lockup in python? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:21:20 -0000 On 12/01/2012, at 3:47 AM, Garrett Cooper wrote: > Glad to see that iXsystems isn't the only one ([1] -- please add a "me > too" to the PR). > [ =85 ] > 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dports/163489 Also reported in: ports/163467 ports/160717 Jan. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 13 20:58:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56146106577C for ; Fri, 13 Jan 2012 20:58:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id DB5558FC13 for ; Fri, 13 Jan 2012 20:58:00 +0000 (UTC) X-T2-Spam-Status: No, hits=0.5 required=5.0 tests=ALL_TRUSTED, BAYES_60 Received: from [188.126.198.129] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.2) with ESMTPA id 226531286; Fri, 13 Jan 2012 21:57:59 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 13 Jan 2012 21:55:45 +0100 User-Agent: KMail/1.13.5 (FreeBSD/8.2-STABLE; KDE/4.4.5; amd64; ; ) References: In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201201132155.45324.hselasky@c2i.net> Cc: Daniel Grech Subject: Re: USB Zero length packet X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:58:01 -0000 On Friday 13 January 2012 10:29:18 Daniel Grech wrote: > Hi, > > does anybody know what the procedure for sending a zero length packet > through libusb on FreeBSD is ? > > Thanks in advance, > > Regards, > > Daniel By writing zero bytes, you send a zero length packet. With the libusb20 API you can set a flag to optimise this case in the kernel instead. --HPS From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 14 07:00:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2997106564A for ; Sat, 14 Jan 2012 07:00:01 +0000 (UTC) (envelope-from janm-freebsd-hackers@transactionware.com) Received: from midgard.transactionware.com (mail2.transactionware.com [203.14.245.36]) by mx1.freebsd.org (Postfix) with SMTP id 26B6C8FC13 for ; Sat, 14 Jan 2012 07:00:00 +0000 (UTC) Received: (qmail 12469 invoked by uid 907); 14 Jan 2012 06:59:58 -0000 Received: from b13FC.static.pacific.net.au (HELO [192.168.1.155]) (202.7.88.252) (smtp-auth username janm, mechanism plain) by midgard.transactionware.com (qpsmtpd/0.84) with (AES128-SHA encrypted) ESMTPSA; Sat, 14 Jan 2012 17:59:58 +1100 From: Jan Mikkelsen Date: Sat, 14 Jan 2012 18:00:25 +1100 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Hardware supported by ng_frame_relay? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 07:00:01 -0000 Hi, I'm looking to upgrade a system running frame relay over a Sangoma A101 = card and WANPIPE. Sangoma do not support FreeBSD anymore, so I'm looking for alternatives. What hardware does ng_frame_relay support now that ar(4) and sr(4) are = not in FreeBSD 9? Specifically, will ng_frame_relay work with a Digium TE121 and = ports/dahdi-kmod? Any suggestions welcome, G.703, X.21 or V.35 interfaces OK. Thanks, Jan Mikkelsen= From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 14 13:01:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFAB1065673 for ; Sat, 14 Jan 2012 13:01:28 +0000 (UTC) (envelope-from matt.hauglustaine@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F8CA8FC14 for ; Sat, 14 Jan 2012 13:01:28 +0000 (UTC) Received: by vcbfl17 with SMTP id fl17so257818vcb.13 for ; Sat, 14 Jan 2012 05:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=MsDtJW5+ptWr4fGbjhGHXv+wdKCFnZCEnxZnyARGmsE=; b=Xygv3Ye/v0CbTLsYzKNRu5/Nye30QMTJ/0E/tmeNbZF25kv/2+GUrLh9SRLghc9xsh gQ7he8v1q1MEDMFG1wZgiUnf34jWIFJVl70el2xligydj8dzh07i0ecBAQvTU9/EtAQR d0gTm4xzUCYpEl1QrIJaIG8+DKNKLS/WYNuuM= Received: by 10.52.173.39 with SMTP id bh7mr2349171vdc.47.1326544744228; Sat, 14 Jan 2012 04:39:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.21.80 with HTTP; Sat, 14 Jan 2012 04:38:23 -0800 (PST) From: Matthieu Hauglustaine Date: Sat, 14 Jan 2012 13:38:23 +0100 Message-ID: To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: 2 years student project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 13:01:28 -0000 Dear all, We are a group of french CS students at Epitech, currently in 3rd year. As part of our formation we have to start working on our end of scholarship project. We will have 2 years to complete this project, and the only obligation we have is to be "innovative". The first step is to submit our subject for validation, and this must be done for the end of the month, We would really like to take this opportunity to contribute to the FreeBSD project. Our formation is focused exclusively on the "learn by doing it yourself" philosophy and we have many projects in different domains behind us (mainly in c and c++). We've spent some time looking around the ideas presented on this page: http://wiki.freebsd.org/IdeasPage. Lots of these projects are extremely interesting and, among others, "porting HFS+" and "Space Communication Protocol Standards" are on our list of potential projects. Maybe their are other unlisted ideas that would be nice student projects while still useful to the community? However, what should be the first move here? Who should we contact? Would someone with more experience in FeeBSD development take the role of "mentor"? We are hoping for some guidance so we could be as effective as possible. Regards, Matthieu Hauglustaine From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 14 16:35:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 504FD106566C for ; Sat, 14 Jan 2012 16:35:16 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB3A8FC0C for ; Sat, 14 Jan 2012 16:35:16 +0000 (UTC) Received: by iaae16 with SMTP id e16so7708392iaa.17 for ; Sat, 14 Jan 2012 08:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KXezEy7O6rcEsVJJrOe5ziHTROZGXMO9bQ6tIEL1uMo=; b=IAYlrULmuQZf1R8flsJloh9MZZisClCjKHAvtSx1NXEiYPFHMQL9Cz7DX2Ui3xnzK3 PuNmSA9pocL7VwxBfCGntlGCe+Y2Trz8EI1LBogjWOgoGXXfflpcns1Orl66dAqjFt+v d3G08406dKxMumhcOnUg6RB2BO6OXy3UfIjwE= MIME-Version: 1.0 Received: by 10.50.195.129 with SMTP id ie1mr5414096igc.29.1326557409047; Sat, 14 Jan 2012 08:10:09 -0800 (PST) Received: by 10.42.133.9 with HTTP; Sat, 14 Jan 2012 08:10:09 -0800 (PST) In-Reply-To: References: Date: Sat, 14 Jan 2012 17:10:09 +0100 Message-ID: From: Kip Macy To: Matthieu Hauglustaine Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: 2 years student project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 16:35:16 -0000 Many of the ideas on that page are stale. I believe that the most promising approach would be to figure out what area of the system you're most interested in, e.g. networking, file systems, virtual memory, scheduling etc., make an honest appraisal of your development abilities (the rate at which you can come up to speed working with a large body of code and your ability to read technical documentation), and then contact the mentor for one of the "Ideas" in your area of interest to discuss how to proceed further. In order to have any likelihood of success you'll need to find someone who is willing to take the time to discuss things with you on a regular basis. I hope this helps. Cheers On Sat, Jan 14, 2012 at 1:38 PM, Matthieu Hauglustaine wrote: > Dear all, > > We are a group of french CS students at Epitech, currently in 3rd year. > As part of our formation we have to start working on our end of > scholarship project. We will have 2 years to complete this project, > and the only obligation we have is to be "innovative". > The first step is to submit our subject for validation, and this must > be done for the end of the month, > > We would really like to take this opportunity to contribute to the > FreeBSD project. > Our formation is focused exclusively on the "learn by doing it > yourself" philosophy and we have many projects in different domains > behind us (mainly in c and c++). > > We've spent some time looking around the ideas presented on this page: > http://wiki.freebsd.org/IdeasPage. > Lots of these projects are extremely interesting and, among others, > "porting HFS+" and "Space Communication Protocol Standards" are on our > list of potential projects. > Maybe their are other unlisted ideas that would be nice student > projects while still useful to the community? > > However, what should be the first move here? Who should we contact? > Would someone with more experience in FeeBSD development take the role > of "mentor"? > > We are hoping for some guidance so we could be as effective as possible. > > Regards, > > Matthieu Hauglustaine > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 14 18:26:41 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B1BC1065782 for ; Sat, 14 Jan 2012 18:26:41 +0000 (UTC) (envelope-from benlaurie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C33DF8FC1B for ; Sat, 14 Jan 2012 18:26:40 +0000 (UTC) Received: by vbbfp1 with SMTP id fp1so3205539vbb.13 for ; Sat, 14 Jan 2012 10:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hMivuFaSt/z4zQ4+yfbaFx2NQOpeEzE/0HVts4lJcXQ=; b=LAA/ebVCCDeasuZGEyPcXbOKR5CImb8VNHPrE/i5LnWprQQWSu7fM3HRCLZzxO1kle oy/y+cRpSluoIqnRRzYwZ//RNKiYpkaKUxkqied5tTUT0nw9s7tKdFsSK2eXZyq6BqY5 20dANfWpf6JGjFxk3ISOqhWtjfKpeI7V8CtZY= MIME-Version: 1.0 Received: by 10.52.92.144 with SMTP id cm16mr2752065vdb.90.1326563775512; Sat, 14 Jan 2012 09:56:15 -0800 (PST) Sender: benlaurie@gmail.com Received: by 10.52.28.171 with HTTP; Sat, 14 Jan 2012 09:56:15 -0800 (PST) In-Reply-To: References: Date: Sat, 14 Jan 2012 17:56:15 +0000 X-Google-Sender-Auth: wQTcFw5fv6U3BUaBbkRSAnFhFtE Message-ID: From: Ben Laurie To: Matthieu Hauglustaine Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: 2 years student project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 18:26:41 -0000 On Sat, Jan 14, 2012 at 12:38 PM, Matthieu Hauglustaine wrote: > Dear all, > > We are a group of french CS students at Epitech, currently in 3rd year. > As part of our formation we have to start working on our end of > scholarship project. We will have 2 years to complete this project, > and the only obligation we have is to be "innovative". > The first step is to submit our subject for validation, and this must > be done for the end of the month, > > We would really like to take this opportunity to contribute to the > FreeBSD project. > Our formation is focused exclusively on the "learn by doing it > yourself" philosophy and we have many projects in different domains > behind us (mainly in c and c++). > > We've spent some time looking around the ideas presented on this page: > http://wiki.freebsd.org/IdeasPage. > Lots of these projects are extremely interesting and, among others, > "porting HFS+" and "Space Communication Protocol Standards" are on our > list of potential projects. > Maybe their are other unlisted ideas that would be nice student > projects while still useful to the community? Porting userland to the Capsicum framework! (https://lists.cam.ac.uk/mailman/listinfo/cl-capsicum-discuss) > > However, what should be the first move here? Who should we contact? > Would someone with more experience in FeeBSD development take the role > of "mentor"? > > We are hoping for some guidance so we could be as effective as possible. > > Regards, > > Matthieu Hauglustaine > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 14 22:33:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2D5E106567E for ; Sat, 14 Jan 2012 22:33:21 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0C2258FC16 for ; Sat, 14 Jan 2012 22:33:20 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so753052wgb.31 for ; Sat, 14 Jan 2012 14:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=k4CGe9LsUka0HUltcrX4RWGFdQEWeBkia58wMaL3TSM=; b=BBjjM1cJgW3vOU+vR6SlGnphc5C2H4N/vHRqEdovX1ijnVzNBugMGa6Dwbii9AdrCj Hx6rHRt+BLnTD6u7vjxu1k54uZOcGzOnmg+ThcPgHIZE4CHpsMN92y50qf1O3IdC828I kcvEH2WirwK3LuWOkcXCNCN/gJhQPhdviLMgg= MIME-Version: 1.0 Received: by 10.180.97.73 with SMTP id dy9mr10506967wib.11.1326580399933; Sat, 14 Jan 2012 14:33:19 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.216.234.194 with HTTP; Sat, 14 Jan 2012 14:33:19 -0800 (PST) In-Reply-To: References: Date: Sat, 14 Jan 2012 23:33:19 +0100 X-Google-Sender-Auth: PdRa-vgq_fxNTvksdufrVp-u_RA Message-ID: From: Attilio Rao To: Kip Macy Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Matthieu Hauglustaine Subject: Re: 2 years student project X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 22:33:21 -0000 2012/1/14 Kip Macy : > Many of the ideas on that page are stale. I believe that the most > promising approach would be to figure out what area of the system > you're most interested in, e.g. networking, file systems, virtual > memory, scheduling etc., make an honest appraisal of your development > abilities (the rate at which you can come up to speed working with a > large body of code and your ability to read technical documentation), > and then contact the mentor for one of the "Ideas" in your area of > interest to discuss how to proceed further. In order to have any > likelihood of success you'll need to find someone who is willing to > take the time to discuss things with you on a regular basis. In addition to what Kip suggests, there are also a lot of other ideas that are really very subsystem-specific and are not listed in the "Ideas" page, thus if you figure out the kernel areas where you want to work (and, as Kip says, the rate of your learning) we can provide you a list of people to contact for any area which can provide several degrees of mentorship too. Attilio -- Peace can only be achieved by understanding - A. Einstein