From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 19:42:26 2011 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 C4A5B1065673 for ; Sun, 23 Oct 2011 19:42:26 +0000 (UTC) (envelope-from strontium90@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 561848FC17 for ; Sun, 23 Oct 2011 19:42:25 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so9441513bkb.13 for ; Sun, 23 Oct 2011 12:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:content-type; bh=XcVSXvrv8NHzUaSI+6IJwtaK5U5D8jzaIe5zHDqIORE=; b=Kwk6RBrr7KVT+Mt2dioA4qXafqSJ/8ntVXVtl0zQeZuAtdZPeot3r2lUyhYq4S/LgY EsaSH6fHwXUofCpP0iaTqJ0VU6HjtFvCt1/V5hAGFNsc2AbKhZBMIlEI8c0T/yWwqDSs M1KFB4pobIVts3XWrWkJxqdLcBJwvnIvvHHwc= Received: by 10.223.75.15 with SMTP id w15mr7413985faj.9.1319398945045; Sun, 23 Oct 2011 12:42:25 -0700 (PDT) Received: from crow.localnet (ip-81.net-82-216-178.lyon5.rev.numericable.fr. [82.216.178.81]) by mx.google.com with ESMTPS id y8sm37779150faj.10.2011.10.23.12.42.23 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 12:42:23 -0700 (PDT) From: Razmig K To: freebsd-hackers@freebsd.org Date: Sun, 23 Oct 2011 21:42:16 +0200 Message-ID: <8739679.u2caBOoV7X@crow> User-Agent: KMail/4.7.2 (Linux/3.0.0-12-generic; KDE/4.7.1; x86_64; ; ) In-Reply-To: <20111021155557.GC93709@dan.emsphone.com> References: <4EA0610B.90206@gmail.com> <4EA1471E.9050501@gmail.com> <20111021155557.GC93709@dan.emsphone.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: Measuring memory footprint in C/C++ code on FreeBSD 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, 23 Oct 2011 19:42:26 -0000 Hello Thanks to everyone for tips and insight you gave me on this discussion. ~Razmig From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 23 22:11:59 2011 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 2C9121065673 for ; Sun, 23 Oct 2011 22:11:59 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id D89498FC13 for ; Sun, 23 Oct 2011 22:11:58 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id D20D6281E5 for ; Sun, 23 Oct 2011 21:52:43 +0000 (UTC) Received: by cruwe.de (Postfix, from userid 65534) id B403B281E3; Sun, 23 Oct 2011 21:52:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED, MIME_QP_LONG_LINE autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37A239.dip.t-dialin.net [91.55.162.57]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id 7E1E8281DF for ; Sun, 23 Oct 2011 21:52:41 +0000 (UTC) Date: Sun, 23 Oct 2011 23:52:31 +0200 From: "Christopher J. Ruwe" To: Message-ID: <20111023235231.71f73ea3@dijkstra> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/bPMhCG8I9AM9ThsjFZaDu71"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Subject: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? 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, 23 Oct 2011 22:11:59 -0000 --Sig_/bPMhCG8I9AM9ThsjFZaDu71 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I need to get the maximum size of an pwd-entry to determine the correct buffersize for calling getpwnam_r("uname",&pwd, buf, bufsize, &pwdp). I would like to use sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which unfornutately fails (returns -1). Currently, I used 16384, which seems to be too much, bit works for the time being. =46rom recent mails I get that _SC_GETPW_R_SIZE_MAX is not available on FreeB= SD, e.g., http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2009-Septem= ber/173081.html and http://www.redhat.com/archives/libvir-list/2011-May/msg= 01013.html. This assertion seems to be backed by /usr/srclib/libc/gen/sysco= nf.c, line 374. =46rom Stevens & Rago, Adavanced Programming in the UNIX Environment, I can g= et that FreeBSD supports all possible members in the passwd structure, but = where can I determine the maximum size of these so that I can calculate the= ax size of the pwd struct therefrom? Does anybody know or know where to lo= ok what maximum size a pwd-entry can have?=20 Knowing the maximum size a pwd structure can have, it seems like to be an i= dea to define the correct value in sysconf.c. As that is not done though su= ggested in the code, are there any obstacles in defining that value so nobo= dy has done that so far? Thanks for any help, cheers,=20 --=20 Christopher J. Ruwe TZ GMT + 2 --Sig_/bPMhCG8I9AM9ThsjFZaDu71 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJOpIymAAoJEJTIKW/o3iwUwHsP/A7EMfLFaT57uxIrF2aQ9QQC cmNsRnIOtisvAyMDsLZP4uepjX7gK0H2y7jOa8R3XpoxrCVri2MLAgKhaLosMB/X u1jbLzdaSeFW8hsUej9Jcm56fdA9aKGSaasVQt0H5fQuoFqjakijQ75Ao3pQvUbr 8VpiwBTUNDFN/HLssgkylXrbrIyzij2V1SUhp4eUmwOWeovfQgO4j2DZos19fxh+ 8OJxMz9W52z60O+TPhywLlH1Urx5dulAg2DM0uLqFOzYdjnuqXqQsLB+NmDUCJLb tqD15nc62jWI7CGcmlRJJhwk9xt8JHw/N6AfDKzG1pD2hQhOsHRt22InDdJj90S6 ip6ScxrgH0cobYFrFsmwnjm6zcTX6Kggr1H17W3UWp90vMT3tGphT6vydJBLHfuO 7nIbpQTs4CawcGD3hfaC64fvmpkp0MDAJbUnUfLSV2BSXj1NjZJXLVSx0FUYZEBJ ymRgy6NDuU+H7yi9iMPxhAQ5JBmB35TESAMY3QbPir0ARJ03McNN0IGaeHdDXU/9 GOHY9kNOQRDfpt0+iMvI/LH8StG/Cm/fhI7oFSKJ47gyP2AgwrJfvyYhJvr7T78p EsoIG8ocXO6cCtIN9JRCEBcO8f+EYdFpI2U9csP05+srrt/vpAfg7CZ4vqtIuHdO FtTqn9JG68195QkxtcG0 =6mH+ -----END PGP SIGNATURE----- --Sig_/bPMhCG8I9AM9ThsjFZaDu71-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 00:10:39 2011 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 183E6106564A for ; Mon, 24 Oct 2011 00:10:39 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 90F508FC15 for ; Mon, 24 Oct 2011 00:10:38 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p9O0AZXG055258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Oct 2011 19:10:35 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id p9O0AY6P079535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Oct 2011 19:10:34 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p9O0AYul079534; Sun, 23 Oct 2011 19:10:34 -0500 (CDT) (envelope-from dan) Date: Sun, 23 Oct 2011 19:10:34 -0500 From: Dan Nelson To: "Christopher J. Ruwe" Message-ID: <20111024001034.GE93709@dan.emsphone.com> References: <20111023235231.71f73ea3@dijkstra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111023235231.71f73ea3@dijkstra> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Sun, 23 Oct 2011 19:10:35 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-hackers@freebsd.org Subject: Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? 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, 24 Oct 2011 00:10:39 -0000 In the last episode (Oct 23), Christopher J. Ruwe said: > I need to get the maximum size of an pwd-entry to determine the correct > buffersize for calling getpwnam_r("uname",&pwd, buf, bufsize, &pwdp). I > would like to use sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, > which unfornutately fails (returns -1). Currently, I used 16384, which > seems to be too much, bit works for the time being. > > From recent mails I get that _SC_GETPW_R_SIZE_MAX is not available on > FreeBSD, e.g., > http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2009-September/173081.html > and http://www.redhat.com/archives/libvir-list/2011-May/msg01013.html. > This assertion seems to be backed by /usr/srclib/libc/gen/sysconf.c, line > 374. > > From Stevens & Rago, Adavanced Programming in the UNIX Environment, I can > get that FreeBSD supports all possible members in the passwd structure, > but where can I determine the maximum size of these so that I can > calculate the ax size of the pwd struct therefrom? Does anybody know or > know where to look what maximum size a pwd-entry can have? > > Knowing the maximum size a pwd structure can have, it seems like to be an > idea to define the correct value in sysconf.c. As that is not done though > suggested in the code, are there any obstacles in defining that value so > nobody has done that so far? >From looking at the libc/gen/getpwent.c file, it looks like a maximum size might be 1MB. The wrapper functions that convert getpw*_r functions into ones that simply return a pointer to malloced data all use the getpw() helper function, which starts with a 1k buffer and keeps doubling its size until the data fits or it hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX is only checked within that getpw() function, though, so it's possible that an nss library might return an even longer string to a get*_r call. It's up to you to decide what your own limit is :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 18:26:50 2011 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 0933A1065673 for ; Mon, 24 Oct 2011 18:26:50 +0000 (UTC) (envelope-from bnyec@yahoo.com) Received: from nm23-vm0.bullet.mail.bf1.yahoo.com (nm23-vm0.bullet.mail.bf1.yahoo.com [98.139.212.191]) by mx1.freebsd.org (Postfix) with SMTP id 9BDBB8FC17 for ; Mon, 24 Oct 2011 18:26:49 +0000 (UTC) Received: from [98.139.212.145] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 24 Oct 2011 18:14:37 -0000 Received: from [98.139.212.229] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 24 Oct 2011 18:14:36 -0000 Received: from [127.0.0.1] by omp1038.mail.bf1.yahoo.com with NNFMP; 24 Oct 2011 18:14:36 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 988071.68982.bm@omp1038.mail.bf1.yahoo.com Received: (qmail 47423 invoked by uid 60001); 24 Oct 2011 18:14:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1319480076; bh=2jG7QfuW+yiNPcAxK7+zI0bQzd7D3pUH5fw8vU+0TH4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=0gpHpahSGxM0W3LWj4r5XFuuov2AaN7SvU8FyX5SUdg3WU8vPiMz5Jo8PMgud2POZ5Bs0OkGctb4haqMzsSXmWWJGxlWV1ac6IfFzuXToQjbXkC02P5LAMchtzcPaVuDsTCKoAA5zeMupya7rDk2256rGlflQAInWGmkzkMLvgY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=5P3tJnoQpFPab8c0QQSv3Fd8yOnRjjqulQh2pwTIKejn8959BdBythnzmooUXSkQa79O/bygsAK4HvZZIZxnksAWvQLk75bSOUyff2+1IqUs5I9XdalPrq6jpwVj2NZ1dy+9GBViUptI7uuM9kkDxASprnruyK8TtcU6KYkrQR0=; X-YMail-OSG: IvnD9Q0VM1lvXoNSRtYAJ.mnK3v_5rlzCuYgu0AtB634aOV G3JjsUOhkLHA.YPnJKPXgolsX5.3hOoxtHaTC.v2BSUwYv5bDDci6yYYRdyI UzDj6hJg895mcGWuHfExT6GIIIddzWhcZHuWdl8R76KLmb.V9kxLMytJoij8 H8zRHwl.tSIvR_bcu1HSIJYFEeA4eV1Piq4mx1IFQiRTy7tf42sEHTOiJgbl rDUL2qIEfB00n.9SjQpUyUT2.m4oZchb59hFm8..vIAYMZA8rdAQWl_ZYVpG 4JtuzuFags2rtEygY04qrolrqyBjdnGIHh7Fq0FEdfrY6Xem3np.WSiS3BR7 G2Q67CgP9eWyXLScH33Da81602Xcl8rA_xFeiG1FZSzNRdKytOmu__FVxTHZ pOJkQT4_dZP32d4XFtVcXCrbEt80KjieE5uwNDSdOlzDR2Vb04fLsHYg3FTA X0jumHUu54bK_4eLqoe7uLWkDmRrGahkJPIfK.cvmAmltYYAOGa3a1gdZvbW R5yia Received: from [173.192.118.68] by web161501.mail.bf1.yahoo.com via HTTP; Mon, 24 Oct 2011 11:14:36 PDT X-Mailer: YahooMailClassic/14.0.10 YahooMailWebService/0.8.114.317681 Message-ID: <1319480076.47008.YahooMailClassic@web161501.mail.bf1.yahoo.com> Date: Mon, 24 Oct 2011 11:14:36 -0700 (PDT) From: "b. nyec" To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: igb drivers and 8.1-RELEASE-p2 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bnyec@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 18:26:50 -0000 Hi, I hope this is the proper place to ask this question, if not i do apologize. a little background, I have a few systems running 8.1-RELEASE-p2 with an Intel 82575EB Gigabit Card installed. I had a couple of the systems go down with a panic: page fault... (igb0 taskq).. I've done some searching and i haven't found a solid solution, Doing a PR search for "igb" i was unable to find a solution/patches (http://www.freebsd.org/cgi/query-pr.cgi). No, unfortunately i do not have a stack trace/core dump as the systems have not been configured to generate the necessary dump information. (yeah, i have considered setting the machines properly to generate dumps, and know how, I've considered upgrade etc.., call me lazy. heh, i'll save that for a later date as this isn't mission critical right now ;) ) I also have 8.2-RELEASE-p2 systems with the same NIC installed that have not had any problems. So, my question, Is it easily possible to use the igb drivers from 8.2-RELEASE on 8.1-RELEASE and load them as a module? If so what would be the best way to accomplish this ? This is more just a kind of exploration for myself rather than a "real" fix. Thanks for any help. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 18:30:26 2011 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 51D491065688 for ; Mon, 24 Oct 2011 18:30:26 +0000 (UTC) (envelope-from cattelan@thebarn.com) Received: from x.digitalelves.com (x.digitalelves.com [209.98.77.55]) by mx1.freebsd.org (Postfix) with ESMTP id 1B2368FC14 for ; Mon, 24 Oct 2011 18:30:25 +0000 (UTC) Received: from macpro00.x.thebarn.com (c-66-41-26-220.hsd1.mn.comcast.net [66.41.26.220]) (authenticated bits=0) by x.digitalelves.com (8.14.5/8.14.4) with ESMTP id p9OHt283059602 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 24 Oct 2011 12:55:04 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <4EA5A676.5040500@thebarn.com> Date: Mon, 24 Oct 2011 12:55:02 -0500 From: Russell Cattelan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4DFA4C47.8060503@digitalelves.com> In-Reply-To: <4DFA4C47.8060503@digitalelves.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: kexec or similar for FreeBSD 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, 24 Oct 2011 18:30:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So it has been a while and a lot of hair pulling but kload is sorta alive and kicking. It can now load the kernel from userspace, copy it over the running kernel and jump the the kernel entry point. I'm still having problems getting through the boot process due to interrupts arriving for unconfigured handlers. Fatal Trap (30) If anybody has some experience with acpi and interrupt configuration in general and is willing to help please let me know. - -Russell On 6/16/11 1:32 PM, Russell Cattelan wrote: > I have been contacted about possibly implementing a fast reboot > mechanism for FreeBSD similar to kexec on Linux. > > I have just started looking into how this accomplished so I figured > a note to freebsd hackers would also be a good place to ask for > comments. > > Has anybody looked at doing something like kexec? > > Is it the right thing to do for FreeBSD. I'm concerned that the > way FreeBSD handles early kernel modules (loaded via the boot > loader) vs linux which does everything via initrd is going to be a > problem. > > Thanks for any help on this. > > -Russell Cattelan > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6lpnYACgkQNRmM+OaGhBgPHwCfd3hVJh3FTjFYlG9Jl1f9LkMD 7h8Ani6zJbix9UGooippNKhyEapDPRoQ =r5Sm -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 19:31:55 2011 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 48F7F1065673 for ; Mon, 24 Oct 2011 19:31:55 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCE98FC1B for ; Mon, 24 Oct 2011 19:31:54 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 2E1D828BA2 for ; Mon, 24 Oct 2011 19:31:53 +0000 (UTC) Received: by cruwe.de (Postfix, from userid 65534) id 0720B28BA1; Mon, 24 Oct 2011 19:31:52 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37B849.dip.t-dialin.net [91.55.184.73]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id 4F43428B9B for ; Mon, 24 Oct 2011 19:31:50 +0000 (UTC) Date: Mon, 24 Oct 2011 21:31:40 +0200 From: "Christopher J. Ruwe" To: freebsd-hackers@freebsd.org Message-ID: <20111024213140.491467d9@dijkstra> In-Reply-To: <20111024001034.GE93709@dan.emsphone.com> References: <20111023235231.71f73ea3@dijkstra> <20111024001034.GE93709@dan.emsphone.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/P5vaMaWNyyCijVwDjLdeATL"; protocol="application/pgp-signature" X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Subject: Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? 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, 24 Oct 2011 19:31:55 -0000 --Sig_/P5vaMaWNyyCijVwDjLdeATL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 23 Oct 2011 19:10:34 -0500 Dan Nelson wrote: > In the last episode (Oct 23), Christopher J. Ruwe said: > > I need to get the maximum size of an pwd-entry to determine the > > correct buffersize for calling getpwnam_r("uname",&pwd, buf, > > bufsize, &pwdp). I would like to use sysconf(_SC_GETPW_R_SIZE_MAX) > > to determine bufsize, which unfornutately fails (returns -1). > > Currently, I used 16384, which seems to be too much, bit works for > > the time being. > >=20 > > From recent mails I get that _SC_GETPW_R_SIZE_MAX is not available > > on FreeBSD, e.g., > > http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2009-September/17= 3081.html > > and > > http://www.redhat.com/archives/libvir-list/2011-May/msg01013.html. > > This assertion seems to be backed > > by /usr/srclib/libc/gen/sysconf.c, line 374. > >=20 > > From Stevens & Rago, Adavanced Programming in the UNIX Environment, > > I can get that FreeBSD supports all possible members in the passwd > > structure, but where can I determine the maximum size of these so > > that I can calculate the ax size of the pwd struct therefrom? Does > > anybody know or know where to look what maximum size a pwd-entry > > can have? > >=20 > > Knowing the maximum size a pwd structure can have, it seems like to > > be an idea to define the correct value in sysconf.c. As that is > > not done though suggested in the code, are there any obstacles in > > defining that value so nobody has done that so far? >=20 > >From looking at the libc/gen/getpwent.c file, it looks like a > >maximum size > might be 1MB. The wrapper functions that convert getpw*_r functions > into ones that simply return a pointer to malloced data all use the > getpw() helper function, which starts with a 1k buffer and keeps > doubling its size until the data fits or it hits PWD_STORAGE_MAX > (1MB). PWD_STORAGE_MAX is only checked within that getpw() function, > though, so it's possible that an nss library might return an even > longer string to a get*_r call. It's up to you to decide what your > own limit is :) >=20 Uh ... it's just that I hoped I had not to decide ;-) However, 1M seems to be rather large to me. Let's see (pwd.h): 116 struct passwd { 117 char *pw_name; /* user name */ 118 char *pw_passwd; /* encrypted password */ 119 uid_t pw_uid; /* user uid */ 120 gid_t pw_gid; /* user gid */ 121 time_t pw_change; /* password change time */ 122 char *pw_class; /* user access class */ 123 char *pw_gecos; /* Honeywell login info */ 124 char *pw_dir; /* home directory */ 125 char *pw_shell; /* default shell */ 126 time_t pw_expire; /* account expiration */ 127 int pw_fields; /* internal: fields filled in */ 128 }; So pw_name -> MAXLOGNAME (from param.h) =3D 17. pw_passwd -> http://www.fre= ebsd.org/doc/handbook/one-time-passwords.html =3D 129. pw_uid & pw_gid each= sizeof(__uint32_t) ?=3D 32b. time_t -> sizeof(__int64_t) ?=3D 64b. At some point, I would just sum it up and reach some size which might be ma= chine dependant, but should be somewhere (guessing/estimating now) between = 4k and 16k. I am short on time just now, am I on the right track or am I mi= ssing something which should be obvious to someone with experience, but is = not to me (lacking experience)? Thanks and regards, --=20 Christopher J. Ruwe TZ GMT + 2 --Sig_/P5vaMaWNyyCijVwDjLdeATL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iQIcBAEBAgAGBQJOpb0jAAoJEJTIKW/o3iwUa6sP/0yAryZNwL/gT0WGAXjkm7Th hjxhJnD27nlTPl1GCCVvbvLHlS0+hRoZnGK/Ud9ftTcAzMKaVk3MHTKM+U8JUUmZ xWwBnw1sIGJFyf2yKxyaRJV0EYIk1q7+p0gfvDbnKEmV3lIPjsy+yeVQB1B73TXK w2wF27tzvngOK8STPlxh/kRfiw7UYRiD5tAbf6EoE8iUr+5xKMTRfmGtK/s5wWpW 2OTX2bz4yx2rzvpV5tuTllsIavmVa8mZM03+9km8lG6XwRAWc8FK4HdpN2CYpFnP U6OFvq+smFSFYlGAthErXJ/K6UfJLPYjAUeWLojUiiCqGil6lEKPeUDTDjk/PuvB +stFLKAYxMEUIksk9hgRJmtMQzFWAGvQSpgxn2TFxK1RV/dgLGMjUOI0KuHElzr1 3otzDwZRJpDvN4svAYpfnAF17X4qAJLaFGVLg/0bq2xUZvRjooqub/FAl7cneAFV dXlqnRaRMppvOLxvohfQtambnweKaAcZyTdfM9MI3hy2L+bHALHWdHNocDOuILW/ c+bp/bx6bBbuXvagw5Uwf573nLZbiKYDXz5MkY/4X9/Z/MLALjNLTbYhX7N9bHZ4 E2MWojnurWjiEDXrsxiJsg+x6dxaNEX7zH0qwSUgOoEF1wyyppa2Coq+m3cCAtxk 5aMFPi//89XLMdmjhghi =i4ql -----END PGP SIGNATURE----- --Sig_/P5vaMaWNyyCijVwDjLdeATL-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 20:42:11 2011 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 AEF7D1065674 for ; Mon, 24 Oct 2011 20:42:11 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 810CA8FC08 for ; Mon, 24 Oct 2011 20:42:11 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p9OKgAUR071417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Oct 2011 15:42:10 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id p9OKgAhF067148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Oct 2011 15:42:10 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p9OKgA4q067139; Mon, 24 Oct 2011 15:42:10 -0500 (CDT) (envelope-from dan) Date: Mon, 24 Oct 2011 15:42:10 -0500 From: Dan Nelson To: "Christopher J. Ruwe" Message-ID: <20111024204209.GF93709@dan.emsphone.com> References: <20111023235231.71f73ea3@dijkstra> <20111024001034.GE93709@dan.emsphone.com> <20111024213140.491467d9@dijkstra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111024213140.491467d9@dijkstra> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Mon, 24 Oct 2011 15:42:10 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-hackers@freebsd.org Subject: Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? 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, 24 Oct 2011 20:42:11 -0000 In the last episode (Oct 24), Christopher J. Ruwe said: > On Sun, 23 Oct 2011 19:10:34 -0500 > Dan Nelson wrote: > > In the last episode (Oct 23), Christopher J. Ruwe said: > > > I need to get the maximum size of an pwd-entry to determine the > > > correct buffersize for calling getpwnam_r("uname",&pwd, buf, bufsize, > > > &pwdp). I would like to use sysconf(_SC_GETPW_R_SIZE_MAX) to > > > determine bufsize, which unfornutately fails (returns -1). Currently, > > > I used 16384, which seems to be too much, bit works for the time > > > being. [..] > > From looking at the libc/gen/getpwent.c file, it looks like a maximum > > size might be 1MB. The wrapper functions that convert getpw*_r > > functions into ones that simply return a pointer to malloced data all > > use the getpw() helper function, which starts with a 1k buffer and keeps > > doubling its size until the data fits or it hits PWD_STORAGE_MAX (1MB). > > PWD_STORAGE_MAX is only checked within that getpw() function, though, so > > it's possible that an nss library might return an even longer string to > > a get*_r call. It's up to you to decide what your own limit is :) > > Uh ... it's just that I hoped I had not to decide ;-) > > However, 1M seems to be rather large to me. Let's see (pwd.h): > > 116 struct passwd { > 117 char *pw_name; /* user name */ > 118 char *pw_passwd; /* encrypted password */ > 119 uid_t pw_uid; /* user uid */ > 120 gid_t pw_gid; /* user gid */ > 121 time_t pw_change; /* password change time */ > 122 char *pw_class; /* user access class */ > 123 char *pw_gecos; /* Honeywell login info */ > 124 char *pw_dir; /* home directory */ > 125 char *pw_shell; /* default shell */ > 126 time_t pw_expire; /* account expiration */ > 127 int pw_fields; /* internal: fields filled in */ > 128 }; > > So pw_name -> MAXLOGNAME (from param.h) = 17. pw_passwd -> > http://www.freebsd.org/doc/handbook/one-time-passwords.html = 129. pw_uid > & pw_gid each sizeof(__uint32_t) ?= 32b. time_t -> sizeof(__int64_t) ?= > 64b. > > At some point, I would just sum it up and reach some size which might be > machine dependant, but should be somewhere (guessing/estimating now) > between 4k and 16k. I am short on time just now, am I on the right track > or am I missing something which should be obvious to someone with > experience, but is not to me (lacking experience)? The getpwnam_r function needs enough space to store the "struct passwd" itself (which has a constant size) plus the strings pointed to by pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. If you have enough control over your environment that you can guarantee that the sum of those strings won't be larger than 4k, then you can just used a fixed buffer of that size. Even 1k is probably large enough for 99.999% of all systems. That's a really long home directory or shell path :) On the other hand, the GECOS field is theoretially free-form and could contain a lot of data. I've never see it hold more than an office number myself, though. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 21:13:19 2011 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 3CC7510656B4; Mon, 24 Oct 2011 21:13:19 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC6E8FC13; Mon, 24 Oct 2011 21:13:18 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so11207461bkb.13 for ; Mon, 24 Oct 2011 14:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=i5V8f6ZXrymankJ2JlCQbGLREwRgHJ0rXXFBz5p6W9E=; b=XtSzzSaHp4vjaWsMgpB+llqgB2WI8lx0SKkzAgqcqyGkoapERs4a/HqgmqqFLy14oV IMutWt2XO72dXfb90bcosCqufDy/VPonYdyuLRgV0EJYtMEgy4hAa8GKPnqLi+YsZi2J /DpfxWhRx7HujqwjnD9ITDEs1t04yMosB624c= Received: by 10.204.145.15 with SMTP id b15mr19028348bkv.52.1319490797063; Mon, 24 Oct 2011 14:13:17 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id j9sm25208969bkd.2.2011.10.24.14.13.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Oct 2011 14:13:13 -0700 (PDT) From: Mikolaj Golub To: Kostik Belousov References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Sender: Mikolaj Golub Date: Tue, 25 Oct 2011 00:13:10 +0300 In-Reply-To: <20111016171005.GB50300@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Sun, 16 Oct 2011 20:10:05 +0300") Message-ID: <86aa8qozyx.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: "ps -e" without procfs(5) 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, 24 Oct 2011 21:13:19 -0000 On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote: KB> In my opinion, the way to implement the feature is to (re)use KB> linprocfs_doargv() and provide another kern.proc sysctl to retrieve the KB> argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as KB> procfs and linprocfs inside the kernel. Thanks! I am testing a patch (without auxv vector so far) and have some questions. Original ps -e returns environment only for user owned processes (the access is restricted by the permissions of /proc/pid/mem file). My kern.proc.env sysctl does not have such a restriction. I suppose I should add it? What function I could use for this? BTW, linprocfs allows to read other user's environment. KB> While you are at the code, it would be useful to also export the auxv vector, KB> which is immediately before env. It looks I can find the location of auxv but what about the size? Or do you propose to extend struct ps_strings to store location and size of auxv? I could do this way... -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 21:15:10 2011 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 3C6D31065689 for ; Mon, 24 Oct 2011 21:15:10 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D38698FC14 for ; Mon, 24 Oct 2011 21:15:09 +0000 (UTC) Received: by faar19 with SMTP id r19so121654faa.13 for ; Mon, 24 Oct 2011 14:15:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.17.3 with SMTP id q3mr45848683faa.28.1319489535524; Mon, 24 Oct 2011 13:52:15 -0700 (PDT) Received: by 10.223.96.133 with HTTP; Mon, 24 Oct 2011 13:52:15 -0700 (PDT) X-Originating-IP: [216.223.13.144] Date: Mon, 24 Oct 2011 16:52:15 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Apache Corefile issues 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, 24 Oct 2011 21:15:10 -0000 Hackers I have a strange apache issue , and I wonder if anyone has seen this before. I am running Apache 1.3.34 on freeBSD 7.3-RELEASE amd64 . At some point in the day apache's children segfault and die. No core files are generated. I am not running mod_php either. 1. I have setup the following sysctls #Debug options kern.sugid_coredump=1 kern.corefile="/var/coredumps/%U-%N-%P.core" 2. The httpd.conf is set with CoreDumpDirectory /var/coredumps/ 3. The dir /var/coredumps/ is set 1777 4. A ktrace of the parrent apache process shows the core file tries to create 84954 libhttpd.ep RET kill 0 84954 libhttpd.ep CALL sigreturn(0x7ffffffeb030) 84954 libhttpd.ep RET sigreturn JUSTRETURN 84954 libhttpd.ep PSIG SIGSEGV SIG_DFL 84954 libhttpd.ep NAMI ""/var/coredumps/65534-libhttpd.ep-84954.core"" 34924 libhttpd.ep RET select 0 34924 libhttpd.ep CALL gettimeofday(0x7fffffffe890,0) 34924 libhttpd.ep RET gettimeofday 0 34924 libhttpd.ep CALL fork 5. I have proc mounted and I can't gcore -s $PID either I have no cores and I am stumped . -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 21:59:46 2011 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 C264D106566B for ; Mon, 24 Oct 2011 21:59:46 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3942B8FC14 for ; Mon, 24 Oct 2011 21:59:45 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p9OLQeNL076513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Oct 2011 23:26:41 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p9OLQatI007984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2011 23:26:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id p9OLQa1K035992; Mon, 24 Oct 2011 23:26:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p9OLQai0035991; Mon, 24 Oct 2011 23:26:36 +0200 (CEST) (envelope-from ticso) Date: Mon, 24 Oct 2011 23:26:36 +0200 From: Bernd Walter To: Mark Saad Message-ID: <20111024212636.GS55289@cicely7.cicely.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org Subject: Re: Apache Corefile issues X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:59:46 -0000 On Mon, Oct 24, 2011 at 04:52:15PM -0400, Mark Saad wrote: > Hackers > I have a strange apache issue , and I wonder if anyone has seen this before. > I am running Apache 1.3.34 on freeBSD 7.3-RELEASE amd64 . At some > point in the day apache's children segfault and die. No core files are > generated. I am > not running mod_php either. Apache 1.x isn't really advised since many many years, but I assume you have very special reasons to stay with it? > 1. I have setup the following sysctls > > #Debug options > kern.sugid_coredump=1 > kern.corefile="/var/coredumps/%U-%N-%P.core" Don't use quotes here. > 2. The httpd.conf is set with CoreDumpDirectory /var/coredumps/ > > 3. The dir /var/coredumps/ is set 1777 > > 4. A ktrace of the parrent apache process shows the core file tries to create > > > 84954 libhttpd.ep RET kill 0 > 84954 libhttpd.ep CALL sigreturn(0x7ffffffeb030) > 84954 libhttpd.ep RET sigreturn JUSTRETURN > 84954 libhttpd.ep PSIG SIGSEGV SIG_DFL > 84954 libhttpd.ep NAMI ""/var/coredumps/65534-libhttpd.ep-84954.core"" It's double quoted here - one to frame the filename and one as part of the filename itself. I guess your / directory don't contain a subdirectory named ". > 34924 libhttpd.ep RET select 0 > 34924 libhttpd.ep CALL gettimeofday(0x7fffffffe890,0) > 34924 libhttpd.ep RET gettimeofday 0 > 34924 libhttpd.ep CALL fork > > 5. I have proc mounted and I can't gcore -s $PID either > > I have no cores and I am stumped . > > > -- > mark saad | nonesuch@longcount.org > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 24 22:51:30 2011 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 023BB1065701 for ; Mon, 24 Oct 2011 22:51:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 81E7E8FC17 for ; Mon, 24 Oct 2011 22:51:29 +0000 (UTC) Received: by wyi40 with SMTP id 40so8689298wyi.13 for ; Mon, 24 Oct 2011 15:51:28 -0700 (PDT) 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=YUvA925Q3aHMGmews2Sg2s7enMX64c8+sIsaAuSV1d0=; b=lGVhM2J1B4tDsk7de00hRF/LF55tsOHFhLFHNeollIIPLIzIupbhf3tWVzsLNzTPTR VH40b7JA5YhFxvE8HXT++kC5+apLy5TqPR9WrBqFIreYY6JVDhCVKbCbBWG0WAGyj3GZ OVCaD8r/JTWQzr4Z0PkLqsJT8lTWv+UG5Oi74= MIME-Version: 1.0 Received: by 10.216.136.168 with SMTP id w40mr3881486wei.27.1319494972465; Mon, 24 Oct 2011 15:22:52 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.216.182.3 with HTTP; Mon, 24 Oct 2011 15:22:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 00:22:52 +0200 X-Google-Sender-Auth: pmwOgvbb9ZmpY4axeUfGRtuwH1Y Message-ID: From: Attilio Rao To: Haozhong Zhang Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org Subject: Re: question about the exchanges of td->td_lock and mtx in sched_switch() of sched_ule 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, 24 Oct 2011 22:51:30 -0000 2011/10/13 Haozhong Zhang : > Hi, > > I'm recently reading the code of sched_ule in freebsd 8.2.0 and have two > questions. > > 1. sched_switch() (in sched_ule.c) invokes cpu_switch() (at line 1852) and > thread_unblock_switch() (at line 1867). These two functions exchange > td->td_lock and mtx. What are the purposes of these exchanges? > > 2. Can the exchange in cpu_switch() (in amd64/amd64/cpu_switch.S, at line > 134) be done before calling cpu_switch()? I mean, does this reorder of > exchange and other operations in cpu_switch() cause side-effects to other > code? This thread should have the details you need: http://lists.freebsd.org/pipermail/svn-src-all/2010-January/019345.html Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 00:49:00 2011 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 5911F1065676 for ; Tue, 25 Oct 2011 00:49:00 +0000 (UTC) (envelope-from ctuffli@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 20F948FC08 for ; Tue, 25 Oct 2011 00:48:59 +0000 (UTC) Received: by yxt33 with SMTP id 33so3244648yxt.13 for ; Mon, 24 Oct 2011 17:48:59 -0700 (PDT) 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=1fBVj2oXrP77piaSTl9qu/KtAx0UimmYyfW+0v4ox8U=; b=l1CBuAP7f3qHHo8uKzr2NmspxHYD0RPfHMeiwq+2MzoYMFqzpP+FmbqValbc47J6v8 eiBZWXRkwx57o8cVjtSah3W6yOSM/uYrLXW0uTavcHI70AgmGHAvv8+3FsZUCmXIEBVB 5RkEUpHXbM961ni432eo7XOa2cXH1Aq8Tsg/w= MIME-Version: 1.0 Received: by 10.182.45.3 with SMTP id i3mr3806287obm.62.1319502068469; Mon, 24 Oct 2011 17:21:08 -0700 (PDT) Received: by 10.182.53.9 with HTTP; Mon, 24 Oct 2011 17:21:08 -0700 (PDT) Date: Mon, 24 Oct 2011 17:21:08 -0700 Message-ID: From: Chuck Tuffli To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: determining bus_dma memory usage by 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, 25 Oct 2011 00:49:00 -0000 Is there an easy way to determine the amount of bus_dma memory allocated by a driver? Something similar to vmstat -m TIA ---chuck From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 00:55:58 2011 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 A0EDC106566B for ; Tue, 25 Oct 2011 00:55:58 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA498FC08 for ; Tue, 25 Oct 2011 00:55:57 +0000 (UTC) Received: from mart.js.berklix.net (p5DCBEADF.dip.t-dialin.net [93.203.234.223]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p9P0QPhO063860 for ; Tue, 25 Oct 2011 00:26:27 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id p9P0QB9s054918 for ; Tue, 25 Oct 2011 02:26:14 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p9P0Q5UP055046 for ; Tue, 25 Oct 2011 00:26:11 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201110250026.p9P0Q5UP055046@fire.js.berklix.net> To: freebsd-hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Linux Unix Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com/~jhs/cv/ Date: Tue, 25 Oct 2011 02:26:05 +0200 Sender: jhs@berklix.com Subject: Shrinking 4 parititions on a new HP laptop 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, 25 Oct 2011 00:55:58 -0000 Hi hackers@ A new purchased HP laptop (pavilion entertainment PC dm3 http://reviews.shopping.hp.com/8843/dm3t_series/hp-pavilion-dm3t-customizable-notebook-pc-reviews/reviews.htm had all 4 partitions occupied with Windows 7 Home Prem OA. (Maybe the shop did that) I want just 1 of the 4 fdisk partitions with an MS slice (for h/w test mainly), & the other 3 with FreeBSD slices (2 boots of different release & a large common UFS as usual. I've done that often before, not asking for help on that, but normally the PC just uses a single fdisk partition so it just a case of shrinking it & allocating the other 3. This is a bit trickier, I need to figure what all the other partitons are for, & how to merge/ remove them down to one. So first I shrank the main NTFS from 223 G to 65G (for now) & rebooted MS & it still boots MS, Next I need to copy data from spare Fdisk F1, F3, F4 partitions to main F2, leaving the others free for FreeBSD (& also I'll need to tell Fdisk precisely how big my new shrunken F2 NTFS is). Maybe one of you has insight what the partitions might be for at present ? It has a 200M F1 active, then F2 is the main MS FS of most of disk. I wonder why they do that ? For recovery or repair ? Or to later allow an encrypted F2 OS booting from another smaller F1 OS first ? I wonder if I can safely merge F1 & F2 ? Then on F3, HP used 12.6 of 15G for their own software as hardware manufacturer. (Stuff I'll want to move to F2, cos I need partitions for BSD) Not sure how I'll move that tree (tar I guess as I dont know modern MS or trust any MS) (maybe insert a join command if MS still have that (opposite of mount, effectively) to keep the HP seperate yet have paths under MS working. Then F4 is taken too, Backup stuff maybe, or suspend ? My notes chronologically as I worked: -------------- MS My Computer says Local Disk (C:) 176 Gig Free of 218 GB RECOVERY (D:) 2.39 GB Free of 14.5 GB HP_TOOLS (E:) 92.5 MB Free of 99.1 MB Boot a USB image fdisk /dev/ad4 Partition 1 Sysid 7,NTFS etc 199 M Active start 2048 size 407552 Partition 2 Sysid 7,NTFS etc 223305 M start 409600 size 457328640 Partition 3 Sysid=7,NTFS etc 14866 M start 457738240 size 30445568 Partition 4 Sysid 12,DOS/Win-95 32 bit FAT 103 M start 488183808 size 211312 The numbers above add up OK dc: 2048 407552 + p 409600 457328640 + p 457738240 30445568 + p 488183808 211312 + p 488395120 dmesg announced number of sector for USB da0 but not for ad4. dmesg | grep ad4 # 238475 MB WDC WD2500BEKT UDMA100 SATA 3Gb/s cd /dist/sbin kldload /dist/boot/kernel/ntfs.ko mount_ntfs /dev/ad4s1 /lap/1 ; du -s -k /lap/1 # 25 M mount_ntfs /dev/ad4s2 /lap/2 ; du -s -k /lap/2 # 48.098 M mount_ntfs /dev/ad4s3 /lap/3 ; du -s -k /lap/3 # 12,641 M mount_msdosfs /dev/ad4s4 /lap/4 ; du -s -k /lap/4 # 6.7 M of 101 M df 1Kblocks Used Avail Capacity s1 203775 28815 174960 14% s2 228664319 43896379 184767940 19% # s3 15222783 12708523 2514260 83% # ./hp/ s4 101562 6762 94800 7% # ./$RECYCLE.BIN # ./Hewlett-Packard Analysis with dc shows F1,F2,F3 fdisk partition entries each 2x512 bytes more than df shows as size, but with F4, The DOS FS within the fdisk partiton is considerably smaller: 203775 2 * p 407550 # fdisk shows 407552 228664319 2 * p 457328638 # fdisk shows 457328640 15222783 2 * p 30445566 # fdisk shows 30445568 101562 2 * p 203124 # fdisk shows 211312 umount /dev/ad4s2 /dist/usr/local/sbin/ntfsresize -n -s 65G -v /dev/ad4s2 /libexec/ld-elf.so.1: Shared object "libublio.so.1" not found Discovered make.conf CFLAGS += -static insufficient for sysutils/ntfsprog On cross compile host: file /usr/local/sbin/ntfsresize /usr/local/sbin/ntfsresize: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2, stripped cd /usr/ports/sysutils/ntfsprogs unsetenv NOCLEANDEPENDS make clean grep -i static /etc/make.conf CFLAGS += -static make xs make install package ===> ntfsprogs-2.0.0_1 depends on shared library: ublio.1 - found file /usr/local/sbin/ntfsresize /usr/local/sbin/ntfsresize: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.2, stripped cd /usr/ports/devel/libublio make package cd /usr/ports/packages/All ls -l libublio-20070103.tbz ntfsprogs-2.0.0_1.tbz Copy across on another ISB stick & install... /dist/usr/local/sbin/ntfsresize -s 65G -v /dev/ad4s2 adjusted bm_size: 1983648->1984000 # maybe that give a clue for new fdisk size. reboot, usb sticks out MS chkdsk runs automatically ------------------------------------------- Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Software Freedom Day, Muenchen: 22 Okt http://berklix.org/sfd/ From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 03:55:51 2011 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 46F84106566B for ; Tue, 25 Oct 2011 03:55:51 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 055968FC0A for ; Tue, 25 Oct 2011 03:55:50 +0000 (UTC) Received: from [192.168.135.109] (c-24-7-47-62.hsd1.ca.comcast.net [24.7.47.62]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p9P3cWQr077509 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 24 Oct 2011 20:38:33 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4EA62F32.6010305@feral.com> Date: Mon, 24 Oct 2011 20:38:26 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Mon, 24 Oct 2011 20:38:33 -0700 (PDT) Subject: Re: determining bus_dma memory usage by driver X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 03:55:51 -0000 On 10/24/2011 5:21 PM, Chuck Tuffli wrote: > Is there an easy way to determine the amount of bus_dma memory > allocated by a driver? Something similar to vmstat -m > bus_dma memory allocations are platform specific. Looking at least amd64 you can see that the memory is carved out M_DEVBUF. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 04:25:13 2011 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 18EEA1065670 for ; Tue, 25 Oct 2011 04:25:13 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id CF5278FC14 for ; Tue, 25 Oct 2011 04:25:12 +0000 (UTC) Received: by gyd8 with SMTP id 8so132844gyd.13 for ; Mon, 24 Oct 2011 21:25:12 -0700 (PDT) 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=VdqyoRdoOrsZUNTomb1HxuU917zN4vfEoDhAO15d+ME=; b=CMmiN56D9IuUP3TZRB8bESjAzrKLTagdjAP5M7FCKmXziEHYhLKvU621bjKtU1T14B SOusTsraLTY4JiUQR4UE9KtgSSQIK5tEec5lQXMIdROxc9yiILyo0YipOghhWVS5P587 E/BDftWsfeA/FIy6RS6ADdsYgdLaAFjeVe3Fc= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr9977396yhn.7.1319514968056; Mon, 24 Oct 2011 20:56:08 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.103.175 with HTTP; Mon, 24 Oct 2011 20:56:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Oct 2011 20:56:08 -0700 X-Google-Sender-Auth: ADgjdlI6uGFihYl4dw79tbG2Dvs Message-ID: From: Artem Belevich To: Chuck Tuffli Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: determining bus_dma memory usage by 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, 25 Oct 2011 04:25:13 -0000 On Mon, Oct 24, 2011 at 5:21 PM, Chuck Tuffli wrote: > Is there an easy way to determine the amount of bus_dma memory > allocated by a driver? Something similar to vmstat -m > Would "devinfo -r" do? --Artem From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 08:25:07 2011 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 72C401065674; Tue, 25 Oct 2011 08:25:07 +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 C0B028FC15; Tue, 25 Oct 2011 08:25:06 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9P8OqNf057020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Oct 2011 11:24:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9P8Opkm092429; Tue, 25 Oct 2011 11:24:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9P8OpQk092428; Tue, 25 Oct 2011 11:24:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Oct 2011 11:24:51 +0300 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20111025082451.GO50300@deviant.kiev.zoral.com.ua> References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7gzJCi2wfhUHVacz" Content-Disposition: inline In-Reply-To: <86aa8qozyx.fsf@kopusha.home.net> 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.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no 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, Robert Watson Subject: Re: "ps -e" without procfs(5) 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, 25 Oct 2011 08:25:07 -0000 --7gzJCi2wfhUHVacz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote: >=20 > On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote: >=20 > KB> In my opinion, the way to implement the feature is to (re)use > KB> linprocfs_doargv() and provide another kern.proc sysctl to retrieve = the > KB> argv and env vectors. Then, ps(1) and procstat(1) can use it, as wel= l as > KB> procfs and linprocfs inside the kernel. >=20 > Thanks! I am testing a patch (without auxv vector so far) and have some > questions. >=20 > Original ps -e returns environment only for user owned processes (the acc= ess is > restricted by the permissions of /proc/pid/mem file). My kern.proc.env sy= sctl > does not have such a restriction. I suppose I should add it? What functio= n I > could use for this? >=20 > BTW, linprocfs allows to read other user's environment. linprocfs uses p_cansee() to check the permissions. There are sysctls security.bsd.see_other_{ug}ids that control the behaviour. I believe that the new sysctl shall use the same check. >=20 > KB> While you are at the code, it would be useful to also export the aux= v vector, > KB> which is immediately before env. >=20 > It looks I can find the location of auxv but what about the size? Or do y= ou > propose to extend struct ps_strings to store location and size of auxv? I > could do this way... No, extending ps_strings is not needed and it is too radical change. The auxv vector must end by the AT_NULL aux entry. You can also artificially limit the amount of read aux vectors to, say, 256, which is much more then it is currently defined. --7gzJCi2wfhUHVacz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6mclMACgkQC3+MBN1Mb4jRxgCgwjXXtNzpDxyeSGSYnSdW+9gD fB8AoK3noTKoVjj+w6FdHsciqmQwsqs3 =PDhD -----END PGP SIGNATURE----- --7gzJCi2wfhUHVacz-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 08:40:37 2011 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 18CDD106566B; Tue, 25 Oct 2011 08:40:37 +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 E78C68FC1B; Tue, 25 Oct 2011 08:40:36 +0000 (UTC) Received: from [192.168.2.115] (host86-161-235-163.range86-161.btcentralplus.com [86.161.235.163]) by cyrus.watson.org (Postfix) with ESMTPSA id 1579A46B0D; Tue, 25 Oct 2011 04:40:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20111025082451.GO50300@deviant.kiev.zoral.com.ua> Date: Tue, 25 Oct 2011 09:40:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7292FA7A-60A4-4D29-87B5-894AF0ED9C0E@freebsd.org> References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1084) Cc: Mikolaj Golub , freebsd-hackers@freebsd.org Subject: Re: "ps -e" without procfs(5) 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, 25 Oct 2011 08:40:37 -0000 On 25 Oct 2011, at 09:24, Kostik Belousov wrote: > On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote: >>=20 >> On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote: >>=20 >> KB> In my opinion, the way to implement the feature is to (re)use >> KB> linprocfs_doargv() and provide another kern.proc sysctl to = retrieve the >> KB> argv and env vectors. Then, ps(1) and procstat(1) can use it, as = well as >> KB> procfs and linprocfs inside the kernel. >>=20 >> Thanks! I am testing a patch (without auxv vector so far) and have = some >> questions. >>=20 >> Original ps -e returns environment only for user owned processes (the = access is >> restricted by the permissions of /proc/pid/mem file). My = kern.proc.env sysctl >> does not have such a restriction. I suppose I should add it? What = function I >> could use for this? >>=20 >> BTW, linprocfs allows to read other user's environment. > linprocfs uses p_cansee() to check the permissions. There are sysctls > security.bsd.see_other_{ug}ids that control the behaviour. >=20 > I believe that the new sysctl shall use the same check. To be honest, I'd be far more comfortable if the environment check used = p_candebug(). Environmental variables sometimes contain passwords, etc, = that shouldn't be visible to other users on the system. Even showing = command lines is a bit dubious, but widely accepted, whereas seeing the = contents of environmental variables is not widely known in user = communities. Robert= From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 09:28:00 2011 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 2CBF11065677; Tue, 25 Oct 2011 09:28:00 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE1F8FC16; Tue, 25 Oct 2011 09:27:59 +0000 (UTC) Received: by eyd10 with SMTP id 10so225488eyd.13 for ; Tue, 25 Oct 2011 02:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=XTMmFTlWN5M+vnWBvU8NIybdjz6cK4OhtcMEVJYZwZQ=; b=Z3VEaAO9o1eYW4efTssDb1z+Yzq5RZGborUVRJzH0E5HM51AQRGm0vzIau/3LbuqT9 Lh9qrrWGscryp1lSxxbwzMSBGzLuW5i+sGSSyr2ayjK8q/4xqKU+zXdmSIzgAETMwqcv MR2P1yOfqAFhI2b0X62Odovqv4I1A6QxyQJ7U= Received: by 10.14.2.93 with SMTP id 69mr3309807eee.62.1319534878374; Tue, 25 Oct 2011 02:27:58 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id q28sm29932420eea.6.2011.10.25.02.27.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Oct 2011 02:27:56 -0700 (PDT) From: Mikolaj Golub To: Kostik Belousov Organization: TOA Ukraine References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> Sender: Mikolaj Golub Date: Tue, 25 Oct 2011 12:27:52 +0300 In-Reply-To: <20111025082451.GO50300@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue, 25 Oct 2011 11:24:51 +0300") Message-ID: <86aa8p1kvb.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: "ps -e" without procfs(5) 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, 25 Oct 2011 09:28:00 -0000 On Tue, 25 Oct 2011 11:24:51 +0300 Kostik Belousov wrote: KB> On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote: >> >> On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote: >> >> KB> In my opinion, the way to implement the feature is to (re)use >> KB> linprocfs_doargv() and provide another kern.proc sysctl to retrieve the >> KB> argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as >> KB> procfs and linprocfs inside the kernel. >> >> Thanks! I am testing a patch (without auxv vector so far) and have some >> questions. >> >> Original ps -e returns environment only for user owned processes (the access is >> restricted by the permissions of /proc/pid/mem file). My kern.proc.env sysctl >> does not have such a restriction. I suppose I should add it? What function I >> could use for this? >> >> BTW, linprocfs allows to read other user's environment. KB> linprocfs uses p_cansee() to check the permissions. There are sysctls KB> security.bsd.see_other_{ug}ids that control the behaviour. KB> I believe that the new sysctl shall use the same check. This looks reasonable for me. But I just wanted to be sure that this would be ok for other people, as my patch changes the system behavior: currently with security.bsd.see_other_{ug}ids and procfs (not linprocfs) mounted a user can see other users args but not env; after the change a user will see both args and env (until security.bsd.see_other_{ug}ids is off). >> >> KB> While you are at the code, it would be useful to also export the auxv vector, >> KB> which is immediately before env. >> >> It looks I can find the location of auxv but what about the size? Or do you >> propose to extend struct ps_strings to store location and size of auxv? I >> could do this way... KB> No, extending ps_strings is not needed and it is too radical change. KB> The auxv vector must end by the AT_NULL aux entry. You can also artificially KB> limit the amount of read aux vectors to, say, 256, which is much more then KB> it is currently defined. Thanks. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 15:24:02 2011 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 27670106566B for ; Tue, 25 Oct 2011 15:24:02 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id BBE7D8FC14 for ; Tue, 25 Oct 2011 15:24:01 +0000 (UTC) Received: by faar19 with SMTP id r19so904591faa.13 for ; Tue, 25 Oct 2011 08:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.91.143 with SMTP id n15mr46536946fam.23.1319556239616; Tue, 25 Oct 2011 08:23:59 -0700 (PDT) Received: by 10.223.96.133 with HTTP; Tue, 25 Oct 2011 08:23:59 -0700 (PDT) X-Originating-IP: [216.223.13.144] In-Reply-To: <20111024212636.GS55289@cicely7.cicely.de> References: <20111024212636.GS55289@cicely7.cicely.de> Date: Tue, 25 Oct 2011 11:23:59 -0400 Message-ID: From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Apache Corefile issues 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, 25 Oct 2011 15:24:02 -0000 On Mon, Oct 24, 2011 at 5:26 PM, Bernd Walter wro= te: > On Mon, Oct 24, 2011 at 04:52:15PM -0400, Mark Saad wrote: >> Hackers >> I have a strange apache issue , and I wonder if anyone has seen this bef= ore. >> I am running Apache 1.3.34 on freeBSD 7.3-RELEASE amd64 . At some >> point in the day apache's children segfault and die. No core files are >> generated. =C2=A0I am >> not running mod_php either. > > Apache 1.x isn't really advised since many many years, but I assume you > have very special reasons to stay with it? we are moving away from this to nginx > >> 1. I have setup the following sysctls >> >> =C2=A0#Debug options >> =C2=A0kern.sugid_coredump=3D1 >> =C2=A0kern.corefile=3D"/var/coredumps/%U-%N-%P.core" > > Don't use quotes here. Stupid me , why is this sysctl using no quotes as its convention ? > >> 2. The httpd.conf is set with CoreDumpDirectory /var/coredumps/ >> >> 3. The dir =C2=A0/var/coredumps/ is set 1777 >> >> 4. A ktrace of the parrent apache process shows the core file tries to c= reate >> >> >> =C2=A084954 libhttpd.ep RET =C2=A0 kill 0 >> =C2=A084954 libhttpd.ep CALL =C2=A0sigreturn(0x7ffffffeb030) >> =C2=A084954 libhttpd.ep RET =C2=A0 sigreturn JUSTRETURN >> =C2=A084954 libhttpd.ep PSIG =C2=A0SIGSEGV SIG_DFL >> =C2=A084954 libhttpd.ep NAMI =C2=A0""/var/coredumps/65534-libhttpd.ep-84= 954.core"" > > It's double quoted here - one to frame the filename and one as part of th= e > filename itself. > I guess your / directory don't contain a subdirectory named ". This worked with out the quotes on the sysctl > >> =C2=A034924 libhttpd.ep RET =C2=A0 select 0 >> =C2=A034924 libhttpd.ep CALL =C2=A0gettimeofday(0x7fffffffe890,0) >> =C2=A034924 libhttpd.ep RET =C2=A0 gettimeofday 0 >> =C2=A034924 libhttpd.ep CALL =C2=A0fork >> >> 5. I =C2=A0have proc mounted and I can't =C2=A0gcore -s $PID either >> >> I have no cores and I am stumped . >> >> >> -- >> mark saad | nonesuch@longcount.org >> _______________________________________________ >> 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" > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > --=20 mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 16:27:26 2011 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 33232106566B for ; Tue, 25 Oct 2011 16:27:26 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 86E8A8FC08 for ; Tue, 25 Oct 2011 16:27:25 +0000 (UTC) Received: by faar19 with SMTP id r19so1004089faa.13 for ; Tue, 25 Oct 2011 09:27:24 -0700 (PDT) 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=b9C0Aymx0fEbgsuOf33i85DBQm7bHt8mHka5vf0Bwn4=; b=oc9nojC/WNeCLX67Y+woV/k6U62lNtQb4Yaiq2NXzvRD1+PwglRqnXKYx0/+9edqfI kEmMqs/uj+1nsDhZUf601s4xQ2g7i+FbYm/RUQvs8cAheCLYR9doa8HZlj1sgSO4q41N /0xdkAsSRYduiODya+cpn/rjKsF2mU294EWIg= MIME-Version: 1.0 Received: by 10.182.212.33 with SMTP id nh1mr4443325obc.72.1319560044199; Tue, 25 Oct 2011 09:27:24 -0700 (PDT) Received: by 10.182.53.9 with HTTP; Tue, 25 Oct 2011 09:27:24 -0700 (PDT) In-Reply-To: <4EA62F32.6010305@feral.com> References: <4EA62F32.6010305@feral.com> Date: Tue, 25 Oct 2011 09:27:24 -0700 Message-ID: From: Chuck Tuffli To: mj@feral.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: determining bus_dma memory usage by 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, 25 Oct 2011 16:27:26 -0000 On Mon, Oct 24, 2011 at 8:38 PM, Matthew Jacob wrote: > > On 10/24/2011 5:21 PM, Chuck Tuffli wrote: >> >> Is there an easy way to determine the amount of bus_dma memory >> allocated by a driver? Something similar to vmstat -m >> > > bus_dma memory allocations are platform specific. Looking at least amd64 you can see that the memory is carved out M_DEVBUF. OK, so do a diff of vmstat -m | grep devbuf before and after driver load would get me the right number? Does this double count any memory reported by the MALLOC_DEFINE()? ---chuck From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 18:27:58 2011 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 117E4106566C for ; Tue, 25 Oct 2011 18:27:58 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id 93DE28FC14 for ; Tue, 25 Oct 2011 18:27:57 +0000 (UTC) Received: from mart.js.berklix.net (pD9FBECF9.dip.t-dialin.net [217.251.236.249]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id p9PIRtii079830 for ; Tue, 25 Oct 2011 18:27:56 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id p9PIRjZJ070361 for ; Tue, 25 Oct 2011 20:27:45 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.4/8.14.4) with ESMTP id p9PIRc9U058492 for ; Tue, 25 Oct 2011 18:27:44 GMT (envelope-from jhs@fire.js.berklix.net) Message-Id: <201110251827.p9PIRc9U058492@fire.js.berklix.net> cc: freebsd-hackers@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 25 Oct 2011 02:26:05 +0200." <201110250026.p9P0Q5UP055046@fire.js.berklix.net> Date: Tue, 25 Oct 2011 20:27:38 +0200 Sender: jhs@berklix.com Subject: Re: Shrinking 4 parititions on a new HP laptop 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, 25 Oct 2011 18:27:58 -0000 "Julian H. Stacey" wrote: > A new purchased HP laptop (pavilion entertainment PC dm3 ... As no answer so far, I reformulated posting, added info & reposted to sysinstall@ Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with "> "; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 19:55:35 2011 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 36D3E106564A for ; Tue, 25 Oct 2011 19:55:35 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7EA8FC0C for ; Tue, 25 Oct 2011 19:55:34 +0000 (UTC) Received: by faar19 with SMTP id r19so1280413faa.13 for ; Tue, 25 Oct 2011 12:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=tBeqXMscKtjJh2oiJZ8egiqP614rNnGGkdCDhgw3UK0=; b=wX3Y1HuZTqv6sh0DEt2APhTU/DDCngwjAeBH6hvco4b+A/VoLKiLrxDXZRf6AtgMCz E9N+sB5ofhDWpPuTJemJ7TAVrTIogIUPDCx/OqB7zVByLWpnu/2kEZkEAp8W6URQ7OxJ NbTp3YnVX2cQTF4Q7FxElz/S2WPAvPDNdV+EY= Received: by 10.223.77.6 with SMTP id e6mr53127630fak.32.1319572533516; Tue, 25 Oct 2011 12:55:33 -0700 (PDT) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id c13sm50945585fai.3.2011.10.25.12.55.30 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 12:55:32 -0700 (PDT) Message-ID: <20111025.195527.950.1@DOMY-PC> From: rank1seeker@gmail.com To: "Julian H. Stacey" , hackers@freebsd.org Date: Tue, 25 Oct 2011 21:55:27 +0200 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <201110250026.p9P0Q5UP055046@fire.js.berklix.net> References: <201110250026.p9P0Q5UP055046@fire.js.berklix.net> X-Mailer: POP Peeper (3.8.0.0) Cc: Subject: Re: Shrinking 4 parititions on a new HP laptop 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, 25 Oct 2011 19:55:35 -0000 When Win comes with machine, you don't use it at all.=0D=0AYOU install Win, = set it up and THEN use it.=0D=0A=0D=0AYou must have bootable USB stick, = which you have already setup-ed (Must be able to compile/install BSD = itself and in it, you have your BSD confs).=0D=0AStick it and enter boot = menu on laptop and choose USB.=0D=0AWhen BSD boots, at this step, you = will ONLY SLICE HDD:=0D=0A=0D=0A# dd if=3D/dev/zero of=3D/dev/ada0 = bs=3D8m=0D=0A Nuke HDD and pRe-installed $oft Win=0D=0A=0D=0A# gpart = create -s MBR ada0=0D=0A You wana dual boot right?=0D=0A# gpart = bootcode -b /boot/mbr ada0=0D=0A=0D=0AYou said 1 slice, but I say 2 = slices (which will preserve ntfs data, if win is nuked)=0D=0AUse max 35 = Gb for win install slice and choose yourself how much Gb you wana for = slice 2=0D=0A# gpart add -s 30g -t ntfs ada0=0D=0A# gpart add -s 50g -t = \!15 ada0=0D=0A Append slice 2, of type 'Extended DOS (LBA)' -> holds = all oher added letters (D:, E:, ...)=0D=0A=0D=0A... Here you can add max = 2 slices for FreeBSD and something else ...=0D=0A=0D=0AReboot, as we ONLY = SLICED HDD.=0D=0A=0D=0ANow install Win7 (it reads MBR and replaces it = with it's own MBR) and set it up.=0D=0AAfter Win7 has been = installed:=0D=0ABoot USB stick and:=0D=0A# boot0cfg -B ada0=0D=0A# = boot0cfg -m 0x5 ada0=0D=0A # In boot options, show only slices 1 (Win7) = and 3 (FreeBSD)=0D=0A=0D=0AHere you would mount slice 3 and install = FreeBSD into it ... (about which I'll not chatter = ...)=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6=0D=0A From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 20:07:33 2011 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 C52FF1065674 for ; Tue, 25 Oct 2011 20:07:33 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2551A8FC08 for ; Tue, 25 Oct 2011 20:07:33 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 662802855E for ; Tue, 25 Oct 2011 20:07:31 +0000 (UTC) Received: by cruwe.de (Postfix, from userid 65534) id 4CEE82855B; Tue, 25 Oct 2011 20:07:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37B6CE.dip.t-dialin.net [91.55.182.206]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id 4F6362854A; Tue, 25 Oct 2011 20:07:28 +0000 (UTC) Date: Tue, 25 Oct 2011 22:07:25 +0200 From: "Christopher J. Ruwe" To: Dan Nelson Message-ID: <20111025220725.7327fd57@dijkstra> In-Reply-To: <20111024204209.GF93709@dan.emsphone.com> References: <20111023235231.71f73ea3@dijkstra> <20111024001034.GE93709@dan.emsphone.com> <20111024213140.491467d9@dijkstra> <20111024204209.GF93709@dan.emsphone.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Cc: freebsd-hackers@freebsd.org Subject: Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? 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, 25 Oct 2011 20:07:33 -0000 On Mon, 24 Oct 2011 15:42:10 -0500 Dan Nelson wrote: > In the last episode (Oct 24), Christopher J. Ruwe said: > > On Sun, 23 Oct 2011 19:10:34 -0500 > > Dan Nelson wrote: > > > In the last episode (Oct 23), Christopher J. Ruwe said: > > > > I need to get the maximum size of an pwd-entry to determine the > > > > correct buffersize for calling getpwnam_r("uname",&pwd, buf, > > > > bufsize, &pwdp). I would like to use > > > > sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which > > > > unfornutately fails (returns -1). Currently, I used 16384, > > > > which seems to be too much, bit works for the time being. > [..] > > > From looking at the libc/gen/getpwent.c file, it looks like a > > > maximum size might be 1MB. The wrapper functions that convert > > > getpw*_r functions into ones that simply return a pointer to > > > malloced data all use the getpw() helper function, which starts > > > with a 1k buffer and keeps doubling its size until the data fits > > > or it hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX is only checked > > > within that getpw() function, though, so it's possible that an > > > nss library might return an even longer string to a get*_r call. > > > It's up to you to decide what your own limit is :) > > > > Uh ... it's just that I hoped I had not to decide ;-) > > > > However, 1M seems to be rather large to me. Let's see (pwd.h): > > > > 116 struct passwd { > > 117 char *pw_name; /* user name */ > > 118 char *pw_passwd; /* encrypted > > password */ 119 uid_t pw_uid; /* user > > uid */ 120 gid_t pw_gid; /* user gid > > */ 121 time_t pw_change; /* password change > > time */ 122 char *pw_class; /* user access > > class */ 123 char *pw_gecos; /* Honeywell > > login info */ 124 char *pw_dir; /* home > > directory */ 125 char *pw_shell; /* default > > shell */ 126 time_t pw_expire; /* account > > expiration */ 127 int pw_fields; /* internal: > > fields filled in */ 128 }; > > > > So pw_name -> MAXLOGNAME (from param.h) = 17. pw_passwd -> > > http://www.freebsd.org/doc/handbook/one-time-passwords.html = 129. > > pw_uid & pw_gid each sizeof(__uint32_t) ?= 32b. time_t -> > > sizeof(__int64_t) ?= 64b. > > > > At some point, I would just sum it up and reach some size which > > might be machine dependant, but should be somewhere > > (guessing/estimating now) between 4k and 16k. I am short on time > > just now, am I on the right track or am I missing something which > > should be obvious to someone with experience, but is not to me > > (lacking experience)? > > The getpwnam_r function needs enough space to store the "struct > passwd" itself (which has a constant size) plus the strings pointed > to by pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. If you have > enough control over your environment that you can guarantee that the > sum of those strings won't be larger than 4k, then you can just used > a fixed buffer of that size. Even 1k is probably large enough for > 99.999% of all systems. That's a really long home directory or shell > path :) On the other hand, the GECOS field is theoretially free-form > and could contain a lot of data. I've never see it hold more than an > office number myself, though. > Thanks for your help so far. Just assuming (I am not sufficiently clear about myself and my own intents) I want to be precise and am afraid of guessing: Can I assume that the gecos field is an entry in /etc/passwd and can therefore never exceed LINE_MAX, i.e., 2048B (limits.h, line 72)? Or, more precisely, ( 2048B - sum( lenght(all fields except passwd) ) )? Would that be an acceptable limit to set the getpwnam_r( ... ) buffer to and/or would that be an acceptable value to replace the following bit from sysconf.c? 372 #if _POSIX_THREAD_SAFE_FUNCTIONS > -1 373 case _SC_GETGR_R_SIZE_MAX: 374 case _SC_GETPW_R_SIZE_MAX: 375 #error "somebody needs to implement this" 376 #endif Thanks again, cheers, -- Christopher J. Ruwe TZ GMT + 2 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 20:34:42 2011 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 0DBE1106564A for ; Tue, 25 Oct 2011 20:34:42 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id CE8C98FC1C for ; Tue, 25 Oct 2011 20:34:41 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id A16F3108AC9 for ; Tue, 25 Oct 2011 22:34:40 +0200 (CEST) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Oct 2011 22:34:39 +0200 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: iotop (dtrace?) 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, 25 Oct 2011 20:34:42 -0000 I've got two systems with a constantly high rate of disk I/O that = sometimes seems to be overwhelmed from it. Before trying to decide if a = hardware upgrade will help, I'd like to figure out which processes = generate the load. I've found a couple scripts named iotop which appear to produce what I = would be interested in, but they appear to require Solaris or Linux.=20 Has someone ported over one of them, or would have a suggestion how to = go about writing a custom dtrace script to gather this kind of = information? I can successfully run a couple of sample dtrace scripts on these = 8-stable amd64 boxes. Thanks, Stefan Solaris dtrace-based iotop: = http://prefetch.net/articles/solaris.dtracetopten.html Linux /proc-based Python script: http://guichaz.free.fr/iotop/=09 --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 20:50:58 2011 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 6D3AC106566B for ; Tue, 25 Oct 2011 20:50:58 +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 56F888FC0A; Tue, 25 Oct 2011 20:50:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9PKowtp052188; Tue, 25 Oct 2011 20:50:58 GMT (envelope-from bapt@FreeBSD.org) Received: (from bapt@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9PKovBe052102; Tue, 25 Oct 2011 20:50:57 GMT (envelope-from bapt@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: bapt set sender to bapt@FreeBSD.org using -f Date: Tue, 25 Oct 2011 22:50:54 +0200 From: Baptiste Daroussin To: Stefan Bethke Message-ID: <20111025205054.GB86420@azathoth.lan> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org Subject: Re: iotop (dtrace?) 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, 25 Oct 2011 20:50:58 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 25, 2011 at 10:34:39PM +0200, Stefan Bethke wrote: > I've got two systems with a constantly high rate of disk I/O that sometim= es seems to be overwhelmed from it. Before trying to decide if a hardware = upgrade will help, I'd like to figure out which processes generate the load. >=20 > I've found a couple scripts named iotop which appear to produce what I wo= uld be interested in, but they appear to require Solaris or Linux.=20 >=20 > Has someone ported over one of them, or would have a suggestion how to go= about writing a custom dtrace script to gather this kind of information? >=20 > I can successfully run a couple of sample dtrace scripts on these 8-stabl= e amd64 boxes. >=20 Can't 'top -mio' do the job? regards, Bapt --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6nIS4ACgkQ8kTtMUmk6EzKAQCgrj1h2iSg1OLKc5opyxNbTALT h7AAnRFLRm0ThK0C2kyvSIb0+rlRTQxJ =m2f7 -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 20:52:46 2011 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 C18FD1065676; Tue, 25 Oct 2011 20:52:46 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 8B62D8FC1F; Tue, 25 Oct 2011 20:52:46 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id CC304CF1D8; Tue, 25 Oct 2011 22:52:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <20111025205054.GB86420@azathoth.lan> Date: Tue, 25 Oct 2011 22:52:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2B3AA9F7-641A-4F84-B55F-E29732B0568A@lassitu.de> References: <20111025205054.GB86420@azathoth.lan> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-hackers@FreeBSD.org Subject: Re: iotop (dtrace?) 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, 25 Oct 2011 20:52:46 -0000 Am 25.10.2011 um 22:50 schrieb Baptiste Daroussin: > On Tue, Oct 25, 2011 at 10:34:39PM +0200, Stefan Bethke wrote: >> I've got two systems with a constantly high rate of disk I/O that = sometimes seems to be overwhelmed from it. Before trying to decide if a = hardware upgrade will help, I'd like to figure out which processes = generate the load. >>=20 >> I've found a couple scripts named iotop which appear to produce what = I would be interested in, but they appear to require Solaris or Linux.=20= >>=20 >> Has someone ported over one of them, or would have a suggestion how = to go about writing a custom dtrace script to gather this kind of = information? >>=20 >> I can successfully run a couple of sample dtrace scripts on these = 8-stable amd64 boxes. >>=20 >=20 > Can't 'top -mio' do the job? D'oh! Thanks! Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 20:56:17 2011 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 DA8021065680 for ; Tue, 25 Oct 2011 20:56:17 +0000 (UTC) (envelope-from prvs=1279b086c0=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 652758FC13 for ; Tue, 25 Oct 2011 20:56:17 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 25 Oct 2011 21:46:05 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 25 Oct 2011 21:46:05 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50015827311.msg for ; Tue, 25 Oct 2011 21:46:05 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1279b086c0=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-hackers@freebsd.org Message-ID: From: "Steven Hartland" To: "Stefan Bethke" , References: Date: Tue, 25 Oct 2011 21:46:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Subject: Re: iotop (dtrace?) 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, 25 Oct 2011 20:56:17 -0000 top and then use the IO mode, will give you an idea where the issue is. Regards Steve ----- Original Message ----- From: "Stefan Bethke" To: Sent: Tuesday, October 25, 2011 9:34 PM Subject: iotop (dtrace?) I've got two systems with a constantly high rate of disk I/O that sometimes seems to be overwhelmed from it. Before trying to decide if a hardware upgrade will help, I'd like to figure out which processes generate the load. I've found a couple scripts named iotop which appear to produce what I would be interested in, but they appear to require Solaris or Linux. Has someone ported over one of them, or would have a suggestion how to go about writing a custom dtrace script to gather this kind of information? I can successfully run a couple of sample dtrace scripts on these 8-stable amd64 boxes. Thanks, Stefan Solaris dtrace-based iotop: http://prefetch.net/articles/solaris.dtracetopten.html Linux /proc-based Python script: http://guichaz.free.fr/iotop/ -- Stefan Bethke Fon +49 151 14070811 _______________________________________________ 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" ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 21:27:41 2011 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 4E68C1065674 for ; Tue, 25 Oct 2011 21:27:41 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 1E4FE8FC0A for ; Tue, 25 Oct 2011 21:27:40 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p9PLRcX8011236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Oct 2011 16:27:38 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id p9PLRc3E049084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Oct 2011 16:27:38 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p9PLRc6v049083; Tue, 25 Oct 2011 16:27:38 -0500 (CDT) (envelope-from dan) Date: Tue, 25 Oct 2011 16:27:38 -0500 From: Dan Nelson To: "Christopher J. Ruwe" Message-ID: <20111025212738.GJ93709@dan.emsphone.com> References: <20111023235231.71f73ea3@dijkstra> <20111024001034.GE93709@dan.emsphone.com> <20111024213140.491467d9@dijkstra> <20111024204209.GF93709@dan.emsphone.com> <20111025220725.7327fd57@dijkstra> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111025220725.7327fd57@dijkstra> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Tue, 25 Oct 2011 16:27:38 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: freebsd-hackers@freebsd.org Subject: Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? 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, 25 Oct 2011 21:27:41 -0000 In the last episode (Oct 25), Christopher J. Ruwe said: > On Mon, 24 Oct 2011 15:42:10 -0500 > Dan Nelson wrote: > > In the last episode (Oct 24), Christopher J. Ruwe said: > > > On Sun, 23 Oct 2011 19:10:34 -0500 > > > Dan Nelson wrote: > > > > In the last episode (Oct 23), Christopher J. Ruwe said: > > > > > I need to get the maximum size of an pwd-entry to determine the > > > > > correct buffersize for calling getpwnam_r("uname",&pwd, buf, > > > > > bufsize, &pwdp). I would like to use > > > > > sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which > > > > > unfornutately fails (returns -1). Currently, I used 16384, > > > > > which seems to be too much, bit works for the time being. > > [..] > > > > From looking at the libc/gen/getpwent.c file, it looks like a > > > > maximum size might be 1MB. The wrapper functions that convert > > > > getpw*_r functions into ones that simply return a pointer to > > > > malloced data all use the getpw() helper function, which starts with > > > > a 1k buffer and keeps doubling its size until the data fits or it > > > > hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX is only checked within > > > > that getpw() function, though, so it's possible that an nss library > > > > might return an even longer string to a get*_r call. It's up to you > > > > to decide what your own limit is :) > > > > > > Uh ... it's just that I hoped I had not to decide ;-) > > > > The getpwnam_r function needs enough space to store the "struct passwd" > > itself (which has a constant size) plus the strings pointed to by > > pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. If you have enough > > control over your environment that you can guarantee that the sum of > > those strings won't be larger than 4k, then you can just used a fixed > > buffer of that size. Even 1k is probably large enough for 99.999% of > > all systems. That's a really long home directory or shell path :) On > > the other hand, the GECOS field is theoretially free-form and could > > contain a lot of data. I've never see it hold more than an office > > number myself, though. > > > > Thanks for your help so far. Just assuming (I am not sufficiently clear > about myself and my own intents) I want to be precise and am afraid of > guessing: Can I assume that the gecos field is an entry in /etc/passwd and > can therefore never exceed LINE_MAX, i.e., 2048B (limits.h, line 72)? Or, > more precisely, ( 2048B - sum( lenght(all fields except passwd) ) )? > Would that be an acceptable limit to set the getpwnam_r( ... ) buffer to > and/or would that be an acceptable value to replace the following bit from > sysconf.c? > > 372 #if _POSIX_THREAD_SAFE_FUNCTIONS > -1 > 373 case _SC_GETGR_R_SIZE_MAX: > 374 case _SC_GETPW_R_SIZE_MAX: > 375 #error "somebody needs to implement this" > 376 #endif If your nsswitch.conf has "passwd: files" in it, then yes, you can assume that the 2048-byte limit applies. However, if you are using nss_ldap, nss_mysql, nss_winbind, or some other nsswitch module that provides user info, that backend user system may be capable of returning longer strings. If you want to be able to handle any struct passwd that might be thrown at you, you should implement a "retry with doubling" loop similar to the one in libc/gen/getpwent.c:getpw() . -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 25 23:35:36 2011 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 248FE106564A; Tue, 25 Oct 2011 23:35:36 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id DD3048FC1B; Tue, 25 Oct 2011 23:35:35 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 20CCE290ACB; Tue, 25 Oct 2011 18:35:35 -0500 (CDT) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 1319029088B; Tue, 25 Oct 2011 18:35:35 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id quFep8pQQpEl; Tue, 25 Oct 2011 18:35:34 -0500 (CDT) Received: from [10.74.20.46] (staff-74-dun20-046.rice.edu [10.74.20.46]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id C666A2907E1; Tue, 25 Oct 2011 18:35:32 -0500 (CDT) Message-ID: <4EA747B5.9040304@rice.edu> Date: Tue, 25 Oct 2011 18:35:17 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Wojciech Puchar References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> <4E8FF4B8.7010300@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 26 Oct 2011 01:01:25 +0000 Cc: alc@freebsd.org, Kostik Belousov , hackers@freebsd.org, Grzegorz Kulewski Subject: Re: mmap performance and memory use 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, 25 Oct 2011 23:35:36 -0000 On 10/10/2011 4:28 PM, Wojciech Puchar wrote: >> >> Notice that vm.pmap.pde.promotions increased by 31. This means that >> 31 superpage mappings were created by promotion from small page >> mappings. > > thank you. i looked at .mappings as it seemed logical for me that is > shows total. > >> In contrast, vm.pmap.pde.mappings counts superpage mappings that are >> created directly and not by promotion from small page mappings. For >> example, if a large executable, such as gcc, is resident in memory, >> the text segment will be pre-mapped using superpage mappings, >> avoiding soft fault and promotion overhead. Similarly, mmap(..., >> MAP_PREFAULT_READ) on a large, memory resident file may pre-map the >> file using superpage mappings. > > your options are not described in mmap manpage nor madvise > (MAP_PREFAULT_READ). > > when can i find the up to date manpage or description? > A few minutes ago, I merged the changes to support and document MAP_PREFAULT_READ into 8-STABLE. So, now it exists in HEAD, 9.0, and 8-STABLE. Alan From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 11:51:08 2011 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 5990B1065673; Wed, 26 Oct 2011 11:51:08 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B74E88FC1B; Wed, 26 Oct 2011 11:51:07 +0000 (UTC) Received: by qyg14 with SMTP id 14so1985268qyg.13 for ; Wed, 26 Oct 2011 04:51:07 -0700 (PDT) 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=ANadpLbs4LBX7B4cdOgBYgDP27hyA0GzojyzknwT40o=; b=p+HvCY9LQiZFkCz5u1aK+rsjd+wO00H/129sO93Pr2VcYuiDlkTHRN0UZjBFV6+7Rf vc0WcgAKqup4eiqiJdHMbU9e0Hc6Y73bVTmiT/mN3YkFPXUp5ep2+dXTj2OXaD56KpM/ GBhIF7vy1PiGaf2GphMxuQnw8EmFw/VCiDYNc= MIME-Version: 1.0 Received: by 10.68.29.137 with SMTP id k9mr54097221pbh.54.1319628189711; Wed, 26 Oct 2011 04:23:09 -0700 (PDT) Received: by 10.142.131.21 with HTTP; Wed, 26 Oct 2011 04:23:09 -0700 (PDT) In-Reply-To: <4EA747B5.9040304@rice.edu> References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> <4E8FF4B8.7010300@rice.edu> <4EA747B5.9040304@rice.edu> Date: Wed, 26 Oct 2011 13:23:09 +0200 Message-ID: From: Svatopluk Kraus To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, Wojciech Puchar , Kostik Belousov , hackers@freebsd.org, Grzegorz Kulewski Subject: Re: mmap performance and memory use 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, 26 Oct 2011 11:51:08 -0000 Hi, well, I'm working on new port (arm11 mpcore) and pmap_enter_object() is what I'm debugging rigth now. And I did not find any way in userland how to force kernel to call pmap_enter_object() which makes SUPERPAGE mapping without promotion. I tried to call mmap() with MAP_PREFAULT_READ without success. I tried to call madvise() with MADV_WILLNEED without success too. To make SUPERPAGE mapping, it's obvious that all physical pages under SUPERPAGE must be allocated in vm_object. And SUPERPAGE mapping must be done before first access to them, otherwise a promotion is on the way. MAP_PREFAULT_READ does nothing with it. If madvice() is used, vm_object_madvise() is called but only cached pages are allocated in advance. Of coarse, an allocation of all physical memory behind virtual address space in advance is not preferred in most situations. For example, I want to do some computation on 4M memory space (I know that each byte will be accessed) and want to utilize SUPERPAGE mapping without promotion, so save 4K page table (i386 machine). However, malloc() leads to promotion, mmap() with MAP_PREFAULT_READ doesn't do nothing so SUPERPAGE mapping is promoted, and madvice() with MADV_WILLNEED calls vm_object_madvise() but because the pages are not cached (how can be on anonymous memory), it is not work without promotion too. So, SUPERPAGE mapping without promotions is fine, but it can be done only if physical memory being mapped is already allocated. Is it really possible to force that in userland? Moreover, the SUPERPAGE mapping is made readonly firstly. So, even if I have SUPERPAGE mapping without promotion, the mapping is demoted after first write, and promoted again after all underlying pages are accessed by write. There is 4K page table saving no longer. Svata On Wed, Oct 26, 2011 at 1:35 AM, Alan Cox wrote: > On 10/10/2011 4:28 PM, Wojciech Puchar wrote: >>> >>> Notice that vm.pmap.pde.promotions increased by 31. =A0This means that = 31 >>> superpage mappings were created by promotion from small page mappings. >> >> thank you. i looked at .mappings as it seemed logical for me that is sho= ws >> total. >> >>> In contrast, vm.pmap.pde.mappings counts superpage mappings that are >>> created directly and not by promotion from small page mappings. =A0For >>> example, if a large executable, such as gcc, is resident in memory, the= text >>> segment will be pre-mapped using superpage mappings, avoiding soft faul= t and >>> promotion overhead. =A0Similarly, mmap(..., MAP_PREFAULT_READ) on a lar= ge, >>> memory resident file may pre-map the file using superpage mappings. >> >> your options are not described in mmap manpage nor madvise >> (MAP_PREFAULT_READ). >> >> when can i find the up to date manpage or description? >> > > A few minutes ago, I merged the changes to support and document > MAP_PREFAULT_READ into 8-STABLE. =A0So, now it exists in HEAD, 9.0, and > 8-STABLE. > > Alan > > > > _______________________________________________ > 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 Oct 26 13:12:10 2011 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 B0B33106564A for ; Wed, 26 Oct 2011 13:12:10 +0000 (UTC) (envelope-from timon@timon.net.nz) Received: from frost.plasmahost.ru (plasmahost.ru [178.63.60.242]) by mx1.freebsd.org (Postfix) with ESMTP id 039698FC16 for ; Wed, 26 Oct 2011 13:12:09 +0000 (UTC) Received: from pc121.office.masterhost.ru ([87.242.97.5]) (AUTH: PLAIN timon@timon.net.nz, SSL: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by frost.plasmahost.ru with ESMTPSA; Wed, 26 Oct 2011 12:58:50 +0000 id 0001268A.000000004EA8040A.0001341F Message-ID: <4EA804C8.2030900@timon.net.nz> Date: Wed, 26 Oct 2011 17:02:00 +0400 From: Alexandr Matveev User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110818 Thunderbird/5.0 MIME-Version: 1.0 To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: sigprocmask and fork 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, 26 Oct 2011 13:12:10 -0000 Hi, We are using FreeBSD 8.2 on our servers for high load projects. When I was preparing system for production I saw strange (as I think) behavior, that leads to increased load on servers. If I made truss on httpd (apache22) process, I saw too much sigprocmask syscalls: 24822: sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) 24822: sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) 24822: sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) 24822: sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) 24822: sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) ... too many lines ... and 24822: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|S IGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 24822: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 24822: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|S IGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 24822: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 24822: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|S IGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 24822: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) ... too many lines ... but apache, and modules loaded from it do not call this directly. I was trying to use DTRACE for getting information about syscalls, and I got same result. I wrote a tiny sample code: $ cat sigproc_test.c #include main() { fork(); } I ran it on FreeBSD with different compilers: $ cc sigproc_test.c -o sigproc_test $ truss ./sigproc_test 2>&1 | grep sigprocmask | wc -l 8 $ g++ sigproc_test.c -o sigproc_test $ truss ./sigproc_test 2>&1 | grep sigprocmask | wc -l 20 Is it normal to make so many sigprocmask syscalls for such simple program? For example, there is no sigprocmask syscalls when I run it on Debian Linux. Another sample. Here we have sigprocmask syscalls on Linux too, but FreeBSD makes this syscall significantly more often: $ cat test.c #include main() { int i; sleep(2); for (i = 0; i<3; i++) { int pid = fork(); if (!pid) { sleep(0.5); return 0; } sleep(2); } } FreeBSD 8.2: # truss -f ./test ... SKIPPED ... 48666: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 48666: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48666: __sysctl(0xbfbfe6a4,0x2,0x28192700,0xbfbfe6ac,0x0,0x0) = 0 (0x0) 48666: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 48666: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48666: nanosleep({2.000000000 }) = 0 (0x0) 48666: fork() = 48667 (0xbe1b) 48667: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48667: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 48667: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48667: process exit, rval = 0 48666: nanosleep({2.000000000 }) = 0 (0x0) 48666: fork() = 48669 (0xbe1d) 48669: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 48669: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48669: process exit, rval = 0 48666: nanosleep({2.000000000 }) = 0 (0x0) 48666: fork() = 48674 (0xbe22) 48674: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48674: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 48674: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48674: process exit, rval = 0 48666: nanosleep({2.000000000 }) = 0 (0x0) 48666: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 48666: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48666: sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) 48666: sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) 48666: process exit, rval = 0 Linux: # strace ./test ... SKIPPED ... rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({2, 0}, 0x7fff0e6b7050) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb553b0d9d0) = 24310 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- nanosleep({2, 0}, 0x7fff0e6b7050) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb553b0d9d0) = 24311 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- nanosleep({2, 0}, 0x7fff0e6b7050) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb553b0d9d0) = 24312 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- nanosleep({2, 0}, 0x7fff0e6b7050) = 0 exit_group(0) = ? -- Alexander Matveev .masterhost From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 17:19:46 2011 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 56D89106564A for ; Wed, 26 Oct 2011 17:19:46 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id DE46F8FC08 for ; Wed, 26 Oct 2011 17:19:45 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 5F5AD28C18 for ; Wed, 26 Oct 2011 17:19:44 +0000 (UTC) Received: by cruwe.de (Postfix, from userid 65534) id 40B9E28C17; Wed, 26 Oct 2011 17:19:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37B3C0.dip.t-dialin.net [91.55.179.192]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id 11E1828C14 for ; Wed, 26 Oct 2011 17:19:41 +0000 (UTC) Date: Wed, 26 Oct 2011 19:19:41 +0200 From: "Christopher J. Ruwe" To: freebsd-hackers@freebsd.org Message-ID: <20111026191941.004d5889@dijkstra> In-Reply-To: <20111025212738.GJ93709@dan.emsphone.com> References: <20111023235231.71f73ea3@dijkstra> <20111024001034.GE93709@dan.emsphone.com> <20111024213140.491467d9@dijkstra> <20111024204209.GF93709@dan.emsphone.com> <20111025220725.7327fd57@dijkstra> <20111025212738.GJ93709@dan.emsphone.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Subject: Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? 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, 26 Oct 2011 17:19:46 -0000 On Tue, 25 Oct 2011 16:27:38 -0500 Dan Nelson wrote: > In the last episode (Oct 25), Christopher J. Ruwe said: > > On Mon, 24 Oct 2011 15:42:10 -0500 > > Dan Nelson wrote: > > > In the last episode (Oct 24), Christopher J. Ruwe said: > > > > On Sun, 23 Oct 2011 19:10:34 -0500 > > > > Dan Nelson wrote: > > > > > In the last episode (Oct 23), Christopher J. Ruwe said: > > > > > > I need to get the maximum size of an pwd-entry to determine > > > > > > the correct buffersize for calling getpwnam_r("uname",&pwd, > > > > > > buf, bufsize, &pwdp). I would like to use > > > > > > sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which > > > > > > unfornutately fails (returns -1). Currently, I used 16384, > > > > > > which seems to be too much, bit works for the time being. > > > [..] > > > > > From looking at the libc/gen/getpwent.c file, it looks like a > > > > > maximum size might be 1MB. The wrapper functions that convert > > > > > getpw*_r functions into ones that simply return a pointer to > > > > > malloced data all use the getpw() helper function, which > > > > > starts with a 1k buffer and keeps doubling its size until the > > > > > data fits or it hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX > > > > > is only checked within that getpw() function, though, so it's > > > > > possible that an nss library might return an even longer > > > > > string to a get*_r call. It's up to you to decide what your > > > > > own limit is :) > > > > > > > > Uh ... it's just that I hoped I had not to decide ;-) > > > > > > The getpwnam_r function needs enough space to store the "struct > > > passwd" itself (which has a constant size) plus the strings > > > pointed to by pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. > > > If you have enough control over your environment that you can > > > guarantee that the sum of those strings won't be larger than 4k, > > > then you can just used a fixed buffer of that size. Even 1k is > > > probably large enough for 99.999% of all systems. That's a > > > really long home directory or shell path :) On the other hand, > > > the GECOS field is theoretially free-form and could contain a lot > > > of data. I've never see it hold more than an office number > > > myself, though. > > > > > > > Thanks for your help so far. Just assuming (I am not sufficiently > > clear about myself and my own intents) I want to be precise and am > > afraid of guessing: Can I assume that the gecos field is an entry > > in /etc/passwd and can therefore never exceed LINE_MAX, i.e., 2048B > > (limits.h, line 72)? Or, more precisely, ( 2048B - sum( lenght(all > > fields except passwd) ) )? Would that be an acceptable limit to set > > the getpwnam_r( ... ) buffer to and/or would that be an acceptable > > value to replace the following bit from sysconf.c? > > > > 372 #if _POSIX_THREAD_SAFE_FUNCTIONS > -1 > > 373 case _SC_GETGR_R_SIZE_MAX: > > 374 case _SC_GETPW_R_SIZE_MAX: > > 375 #error "somebody needs to implement this" > > 376 #endif > > If your nsswitch.conf has "passwd: files" in it, then yes, you can > assume that the 2048-byte limit applies. However, if you are using > nss_ldap, nss_mysql, nss_winbind, or some other nsswitch module that > provides user info, that backend user system may be capable of > returning longer strings. If you want to be able to handle any struct > passwd that might be thrown at you, you should implement a "retry > with doubling" loop similar to the one in > libc/gen/getpwent.c:getpw() . This method has been suggested at some other sites as well ... I just had hopes it would be able to implement that in a more elegant and more concise manner. Anyways, thank you for your kind help, cheers, -- Christopher J. Ruwe TZ GMT + 2 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 20:26:00 2011 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 B46501065674 for ; Wed, 26 Oct 2011 20:26:00 +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 1EC748FC15 for ; Wed, 26 Oct 2011 20:25:59 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9QKPjSC033779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 23:25:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9QKPj05099520; Wed, 26 Oct 2011 23:25:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9QKPhLk099519; Wed, 26 Oct 2011 23:25:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Oct 2011 23:25:43 +0300 From: Kostik Belousov To: Alexandr Matveev Message-ID: <20111026202542.GG50300@deviant.kiev.zoral.com.ua> References: <4EA804C8.2030900@timon.net.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8yqj9JR9W5krfwRp" Content-Disposition: inline In-Reply-To: <4EA804C8.2030900@timon.net.nz> 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.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: hackers@freebsd.org Subject: Re: sigprocmask and fork 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, 26 Oct 2011 20:26:00 -0000 --8yqj9JR9W5krfwRp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 26, 2011 at 05:02:00PM +0400, Alexandr Matveev wrote: > Hi, >=20 > We are using FreeBSD 8.2 on our servers for high load projects. > When I was preparing system for production I saw strange (as I think)=20 > behavior, > that leads to increased load on servers. >=20 > If I made truss on httpd (apache22) process, I saw too much sigprocmask= =20 > syscalls: >=20 > 24822: sigprocmask(SIG_BLOCK,0x0,0x0) =3D 0 (0x0) > 24822: sigprocmask(SIG_BLOCK,0x0,0x0) =3D 0 (0x0) > 24822: sigprocmask(SIG_BLOCK,0x0,0x0) =3D 0 (0x0) > 24822: sigprocmask(SIG_BLOCK,0x0,0x0) =3D 0 (0x0) > 24822: sigprocmask(SIG_BLOCK,0x0,0x0) =3D 0 (0x0) > ... too many lines ... >=20 > and >=20 > 24822: > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|S=20 >=20 > IGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) > 24822: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 24822: > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|S=20 >=20 > IGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) > 24822: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 24822: > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|S=20 >=20 > IGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) =3D 0 (0x0) > 24822: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > ... too many lines ... >=20 >=20 > but apache, and modules loaded from it do not call this directly. > I was trying to use DTRACE for getting information about syscalls, and I > got same result. >=20 > I wrote a tiny sample >=20 > code: > $ cat sigproc_test.c > #include >=20 > main() > { > fork(); > } > I ran it on FreeBSD with different compilers: > $ cc sigproc_test.c -o sigproc_test > $ truss ./sigproc_test 2>&1 | grep sigprocmask | wc -l > 8 > $ g++ sigproc_test.c -o sigproc_test > $ truss ./sigproc_test 2>&1 | grep sigprocmask | wc -l > 20 >=20 > Is it normal to make so many sigprocmask syscalls for such simple program? > For example, there is no sigprocmask syscalls when I run it on Debian=20 > Linux. Yes, it is normal. I do not quite understand the relation between "simple program" and "so many sigprocmask syscalls" claim, but alas. The calls to sigprocmask originate from the rtld, which needs to guarantee async-signal safety of the lazy binding process. The rtld locks, besides other things, block signals. Also, due to an additional requirement that rtld is functional after the fork, it has to acquire the internal locks around fork in multithreaded programs. All lock acquisions in the program which does only one fork(2) call in main(), as well as in the program that does nothing in main at all, come from the rtld initialization before main, and shared library finalizations after. For empty main(), there are 4 locks acquisions after return from main, so you get total 12 for forked version. In essence, the trivial program makes the same amount of locking in the startup/exit path, as non-trivial (the cost is proportional to the number of shared libraries loaded). The typical cause for the rtld locks acquisitions during the program execution, besides the dlopen(3) activity, is the lazy resolution of the PLT entries. LD_BIND_NOW=3D1 moves the load to the program startup. >=20 > Another sample. Here we have sigprocmask syscalls on Linux too, but=20 > FreeBSD makes this syscall significantly more often: > $ cat test.c > #include >=20 > main() > { > int i; > sleep(2); > for (i =3D 0; i<3; i++) { > int pid =3D fork(); > if (!pid) { > sleep(0.5); > return 0; > } > sleep(2); > } > } >=20 > FreeBSD 8.2: > # truss -f ./test > ... SKIPPED ... > 48666:=20 > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)=20 > =3D 0 (0x0) > 48666: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48666: __sysctl(0xbfbfe6a4,0x2,0x28192700,0xbfbfe6ac,0x0,0x0) =3D 0 (0x0) > 48666:=20 > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)=20 > =3D 0 (0x0) > 48666: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48666: nanosleep({2.000000000 }) =3D 0 (0x0) > 48666: fork() =3D 48667 (0xbe1b) > 48667: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48667:=20 > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)=20 > =3D 0 (0x0) > 48667: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48667: process exit, rval =3D 0 > 48666: nanosleep({2.000000000 }) =3D 0 (0x0) > 48666: fork() =3D 48669 (0xbe1d) > 48669:=20 > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)=20 > =3D 0 (0x0) > 48669: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48669: process exit, rval =3D 0 > 48666: nanosleep({2.000000000 }) =3D 0 (0x0) > 48666: fork() =3D 48674 (0xbe22) > 48674: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48674:=20 > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)=20 > =3D 0 (0x0) > 48674: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48674: process exit, rval =3D 0 > 48666: nanosleep({2.000000000 }) =3D 0 (0x0) > 48666:=20 > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)=20 > =3D 0 (0x0) > 48666: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48666:=20 > sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE= RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIG= XFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)=20 > =3D 0 (0x0) > 48666: sigprocmask(SIG_SETMASK,0x0,0x0) =3D 0 (0x0) > 48666: process exit, rval =3D 0 >=20 > Linux: > # strace ./test > ... SKIPPED ... > rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0 > rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0 > nanosleep({2, 0}, 0x7fff0e6b7050) =3D 0 > clone(child_stack=3D0,=20 > flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,=20 > child_tidptr=3D0x7fb553b0d9d0) =3D 24310 > rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0 > rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0 > --- SIGCHLD (Child exited) @ 0 (0) --- > nanosleep({2, 0}, 0x7fff0e6b7050) =3D 0 > clone(child_stack=3D0,=20 > flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,=20 > child_tidptr=3D0x7fb553b0d9d0) =3D 24311 > rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0 > rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0 > --- SIGCHLD (Child exited) @ 0 (0) --- > nanosleep({2, 0}, 0x7fff0e6b7050) =3D 0 > clone(child_stack=3D0,=20 > flags=3DCLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,=20 > child_tidptr=3D0x7fb553b0d9d0) =3D 24312 > rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) =3D 0 > rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) =3D 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =3D 0 > --- SIGCHLD (Child exited) @ 0 (0) --- > nanosleep({2, 0}, 0x7fff0e6b7050) =3D 0 > exit_group(0) =3D ? >=20 > --=20 > Alexander Matveev > .masterhost >=20 >=20 > _______________________________________________ > 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" --8yqj9JR9W5krfwRp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6obMYACgkQC3+MBN1Mb4jt2QCg5Dvbl2nqUA/byNcicOzwwbuZ +3kAoKfcHTYn7saxEK4111GSxUx1zV36 =qfbX -----END PGP SIGNATURE----- --8yqj9JR9W5krfwRp-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 09:02:47 2011 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 89A3B106566B for ; Thu, 27 Oct 2011 09:02:47 +0000 (UTC) (envelope-from dgre090@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1AD0D8FC16 for ; Thu, 27 Oct 2011 09:02:46 +0000 (UTC) Received: by faar19 with SMTP id r19so3375598faa.13 for ; Thu, 27 Oct 2011 02:02:46 -0700 (PDT) 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=cCOQycGtz/F46Kno0WeHz62K1LY2y+5CALDPH9WgjoM=; b=JXPSKKsiRzJ5ziRUZV17OtQxU/n96Q/cTBEtns7sKjvjv2JFB4rs0NkNLdv5bKITlO mvT/cI+JwVC+CMH8vbq6mI7s0P5l/1xJGPSZvw5LOumlcgUgggn1J7FbiAi7tk2LAfsz w99/EBdBYsNjj3xcgX9u6YbqYJSpUukHAzNQU= MIME-Version: 1.0 Received: by 10.223.36.193 with SMTP id u1mr14514702fad.27.1319704303265; Thu, 27 Oct 2011 01:31:43 -0700 (PDT) Received: by 10.152.24.198 with HTTP; Thu, 27 Oct 2011 01:31:43 -0700 (PDT) Date: Thu, 27 Oct 2011 10:31:43 +0200 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: Kernel Space Memory Allocation 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, 27 Oct 2011 09:02:47 -0000 Hi, I am allocating memory from a device driver in the kernel and passing it on to another driver. In the other driver it is neccessary for me to determine whether the address passed is from user space or kernel space as this driver can also be called from user space. I am currently using the following check to determine if the address is in kernel space or userspace : if ( ( (char *) VM_MIN_KERNEL_ADDRESS <= address) && (address <= (char *) VM_MAX_KERNEL_ADDRESS) ) { KERNEL SPACE } else { USER SPACE } However, this does not always work. Sometimes although I allocate memory in the kernel using the malloc macro, this returns an address which is not in the above range. Is there any workaround for this problem? Thanks in advance for your help. Daniel From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 09:20:55 2011 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 5D33E106566B for ; Thu, 27 Oct 2011 09:20:55 +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 CABA88FC1B for ; Thu, 27 Oct 2011 09:20:54 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p9R9KmoJ017723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 12:20:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id p9R9KmUT001923; Thu, 27 Oct 2011 12:20:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id p9R9KmVM001922; Thu, 27 Oct 2011 12:20:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Oct 2011 12:20:48 +0300 From: Kostik Belousov To: Daniel Grech Message-ID: <20111027092048.GK50300@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="te1vED83xZIPpfwV" 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.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no 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 Subject: Re: Kernel Space Memory Allocation 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, 27 Oct 2011 09:20:55 -0000 --te1vED83xZIPpfwV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2011 at 10:31:43AM +0200, Daniel Grech wrote: > Hi, >=20 > I am allocating memory from a device driver in the kernel and passing it = on > to another driver. In the other driver it is neccessary for me to determi= ne > whether the address passed is from user space or kernel space as this dri= ver > can also be called from user space. I am currently using the following ch= eck > to determine if the address is in kernel space or userspace : >=20 > if ( ( (char *) VM_MIN_KERNEL_ADDRESS <=3D address) && (address <=3D (ch= ar *) > VM_MAX_KERNEL_ADDRESS) ) > { > KERNEL SPACE > } > else > { > USER SPACE > } >=20 > However, this does not always work. Sometimes although I allocate memory = in > the kernel using the malloc macro, this returns an address which is not in > the above range. Is there any workaround for this problem? >=20 > Thanks in advance for your help. Generally, you cannot determine the ownership of the address by its value. There are architectures that use separate kernel/user address spaces, e.g. Even for i386, there were a patch that switched page tables on the kernel entry, allowing the kernel to use whole 4GB of the address space. The proper way to do what you want is to supply explicit indicator of the address space referenced by the address. Read uio(9), in particular, look at the uio_seg. --te1vED83xZIPpfwV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6pInAACgkQC3+MBN1Mb4jVpACg0yW/xfdT/fqc4rIZ6ESf5W32 4jkAoKwHoqoJdUuAJdXJS0XXN/Uu+e+g =FcZZ -----END PGP SIGNATURE----- --te1vED83xZIPpfwV-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 27 13:20:09 2011 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 9241A1065672 for ; Thu, 27 Oct 2011 13:20:09 +0000 (UTC) (envelope-from marktinguely@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 587CD8FC1C for ; Thu, 27 Oct 2011 13:20:09 +0000 (UTC) Received: by iaky10 with SMTP id y10so4478308iak.13 for ; Thu, 27 Oct 2011 06:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8NEZ/gEniMSSLogxOYKKBiffU779IOCrlMRRNZKaBMY=; b=opDJG906tvFrHxXSPwZa/pGJ3jP5Q0k01ilHEjEpjrOt6q5pbB3u0spr3DAS0Go8UD 3NRcQMDdxJU+O2UYqnAMCuJ+CCcRiSu9zF6bkAZlswjj/w38egJG1FNK7tdd4Tu204Zz tkJx/EKEIx6lRqGhw6/RAluP8Yl88iu5PVfUs= Received: by 10.42.197.73 with SMTP id ej9mr59411265icb.2.1319720126283; Thu, 27 Oct 2011 05:55:26 -0700 (PDT) Received: from [192.168.1.100] ([216.129.185.155]) by mx.google.com with ESMTPS id en6sm1725651igb.0.2011.10.27.05.55.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Oct 2011 05:55:25 -0700 (PDT) Message-ID: <4EA954B7.7070205@gmail.com> Date: Thu, 27 Oct 2011 07:55:19 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Daniel Grech References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Kernel Space Memory Allocation 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, 27 Oct 2011 13:20:09 -0000 On 10/27/2011 3:31 AM, Daniel Grech wrote: > Hi, > > I am allocating memory from a device driver in the kernel and passing it on > to another driver. In the other driver it is neccessary for me to determine > whether the address passed is from user space or kernel space as this driver > can also be called from user space. I am currently using the following check > to determine if the address is in kernel space or userspace : > > if ( ( (char *) VM_MIN_KERNEL_ADDRESS<= address)&& (address<= (char *) > VM_MAX_KERNEL_ADDRESS) ) > { > KERNEL SPACE > } > else > { > USER SPACE > } > > However, this does not always work. Sometimes although I allocate memory in > the kernel using the malloc macro, this returns an address which is not in > the above range. Is there any workaround for this problem? > > Thanks in advance for your help. > > Daniel > _______________________________________________ > 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" > Be careful if using user virtual addresses in DMA POST commands, because the interrupt handler may not have the the same address space as the caller. For example: BUS_DMASYNC_POSTREAD copying a bounce buffer to a user VA. --Mark Tinguely From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 07:12:07 2011 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 3F792106566B; Fri, 28 Oct 2011 07:12:07 +0000 (UTC) (envelope-from hosting@syscare.sk) Received: from services.syscare.sk (services.syscare.sk [188.40.39.36]) by mx1.freebsd.org (Postfix) with ESMTP id EA7728FC12; Fri, 28 Oct 2011 07:12:06 +0000 (UTC) Received: from services.syscare.sk (services [188.40.39.36]) by services.syscare.sk (Postfix) with ESMTP id 9475A73E19; Fri, 28 Oct 2011 08:54:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at rulez.sk Received: from services.syscare.sk ([188.40.39.36]) by services.syscare.sk (services.rulez.sk [188.40.39.36]) (amavisd-new, port 10024) with ESMTP id dkFoj2B2NBlV; Fri, 28 Oct 2011 08:54:54 +0200 (CEST) Received: from hosting.syscare.sk (hosting [188.40.39.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by services.syscare.sk (Postfix) with ESMTPS id C8FBA73E0E; Fri, 28 Oct 2011 08:54:54 +0200 (CEST) Received: (from www@localhost) by hosting.syscare.sk (8.14.4/8.14.4/Submit) id p9S6ssHs029110; Fri, 28 Oct 2011 08:54:54 +0200 (CEST) (envelope-from hosting@syscare.sk) X-Authentication-Warning: hosting.syscare.sk: www set sender to hosting@syscare.sk using -f To: , X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 28 Oct 2011 07:54:54 +0100 From: Daniel Gerzo Organization: The FreeBSD Project In-Reply-To: <4E99FF0B.6080101@FreeBSD.org> References: <4E99FF0B.6080101@FreeBSD.org> Message-ID: <49dbd71d83b7b63f57dfb10c690535dc@rulez.sk> X-Sender: danger@FreeBSD.org User-Agent: Roundcube Webmail/0.5.4 Cc: Subject: Re: HEADSUP: Call for FreeBSD Status Reports - 3Q/2011 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, 28 Oct 2011 07:12:07 -0000 On Sat, 15 Oct 2011 23:45:47 +0200, Daniel Gerzo wrote: > Dear all, > > I would like to remind you that the next round of status reports > covering the third quarter of 2011 were due on October 15th, 2011. As > this initiative is very popular among our users, I would like to > ask you to submit your status reports as soon as possible, so that we > can compile the report in a timely fashion. I had a few requests to extend the deadline. If you have anything to submit for the upcoming status report (which would be very welcome!), please do so until Oct. 30th. Thank you. -- Kind regards Daniel From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 11:11:29 2011 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 DF491106564A for ; Fri, 28 Oct 2011 11:11:29 +0000 (UTC) (envelope-from dcherednik@masterhost.ru) Received: from mail.corp.masterhost.ru (wincas02.mail.corp.masterhost.ru [90.156.219.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5AB108FC13 for ; Fri, 28 Oct 2011 11:11:29 +0000 (UTC) Received: from kzholnay-pc.masterhost.ru (87.242.97.5) by mail.corp.masterhost.ru (90.156.219.210) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 28 Oct 2011 15:00:29 +0400 Message-ID: <4EAA8B4B.2090002@masterhost.ru> Date: Fri, 28 Oct 2011 15:00:27 +0400 From: Daniil Cherednik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [87.242.97.5] Cc: Subject: performance of fork() syscalls 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, 28 Oct 2011 11:11:30 -0000 Hello. I have some questions about performance fork syscall. The simple test: int main(){ int i; int pid; char *test; signal(SIGCHLD, SIG_IGN); for (i = 0; i <10000; i++) { pid = fork(); if (!pid) return 0; } } Result in FreeBSD (8.2, amd62): real 0m2.010s user 0m0.053s sys 0m1.946s Result in Linux (2.6.32-5-amd64): real 0m1.210s user 0m0.008s sys 0m1.200s Of course the machines for test is same. CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0xf41 Family = f Model = 4 Stepping = 1 Features=0xbfebfbff Features2=0x641d AMD Features=0x20000800 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4113141760 (3922 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 Does this mean performance of fork() in Linux is better? And can you explain why? -- С уважением, Daniil Cherednik .masterhost From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 05:38:07 2011 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 2B963106564A; Fri, 28 Oct 2011 05:38:07 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id E2E2D8FC08; Fri, 28 Oct 2011 05:38:06 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 083BE2916F7; Fri, 28 Oct 2011 00:38:06 -0500 (CDT) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id E5D17297603; Fri, 28 Oct 2011 00:38:05 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id RzI8rQSDDtMy; Fri, 28 Oct 2011 00:38:05 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 307F82916F7; Fri, 28 Oct 2011 00:38:05 -0500 (CDT) Message-ID: <4EAA3FBC.3090907@rice.edu> Date: Fri, 28 Oct 2011 00:38:04 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Svatopluk Kraus References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> <4E8FF4B8.7010300@rice.edu> <4EA747B5.9040304@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 28 Oct 2011 11:17:04 +0000 Cc: alc@freebsd.org, Wojciech Puchar , Kostik Belousov , hackers@freebsd.org, Grzegorz Kulewski Subject: Re: mmap performance and memory use 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, 28 Oct 2011 05:38:07 -0000 On 10/26/2011 06:23, Svatopluk Kraus wrote: > Hi, > > well, I'm working on new port (arm11 mpcore) and pmap_enter_object() > is what I'm debugging rigth now. And I did not find any way in > userland how to force kernel to call pmap_enter_object() which makes > SUPERPAGE mapping without promotion. I tried to call mmap() with > MAP_PREFAULT_READ without success. I tried to call madvise() with > MADV_WILLNEED without success too. > mmap() should call pmap_enter_object() if MAP_PREFAULT_READ was specified. I'm surprised to hear that it's not happening for you. > To make SUPERPAGE mapping, it's obvious that all physical pages under > SUPERPAGE must be allocated in vm_object. And SUPERPAGE mapping must > be done before first access to them, otherwise a promotion is on the > way. MAP_PREFAULT_READ does nothing with it. If madvice() is used, > vm_object_madvise() is called but only cached pages are allocated in > advance. Of coarse, an allocation of all physical memory behind > virtual address space in advance is not preferred in most situations. > > For example, I want to do some computation on 4M memory space (I know > that each byte will be accessed) and want to utilize SUPERPAGE mapping > without promotion, so save 4K page table (i386 machine). However, > malloc() leads to promotion, mmap() with MAP_PREFAULT_READ doesn't do > nothing so SUPERPAGE mapping is promoted, and madvice() with > MADV_WILLNEED calls vm_object_madvise() but because the pages are not > cached (how can be on anonymous memory), it is not work without > promotion too. > > So, SUPERPAGE mapping without promotions is fine, but it can be done > only if physical memory being mapped is already allocated. Is it > really possible to force that in userland? > To force the allocation of the physical memory? Right now, the only way is for your program to touch the pages. > Moreover, the SUPERPAGE mapping is made readonly firstly. So, even if > I have SUPERPAGE mapping without promotion, the mapping is demoted > after first write, and promoted again after all underlying pages are > accessed by write. There is 4K page table saving no longer. > Yes, that is all true. It is possible to change things so that the page table pages are reclaimed after a time, and not kept around indefinitely. However, this not high on my personal priority list. Before that, it is more likely that I will add an option to avoid the demotion on write, if we don't have to copy the entire superpage to do so. Alan From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 10:32:47 2011 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 C4CD5106564A; Sat, 29 Oct 2011 10:32:47 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 109948FC08; Sat, 29 Oct 2011 10:32:46 +0000 (UTC) Received: by bkbzs2 with SMTP id zs2so1858849bkb.13 for ; Sat, 29 Oct 2011 03:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:message-id :user-agent:mime-version:content-type; bh=3yEAmVyoJR5D2ly3/nKK89wHjMKBbNhKL1MXzBBll7U=; b=UEhH7Tfr5sphbtJkbuyRANxfoK5fFNQG57DFBdp9r29TRdAgxTL0FE9lR0kHyfbk37 ggatbBOajTYPXSUukvnA3lBhxvWGXQvmV4ph2rJJ9a6K9Hw1LzX13X1/rw+mmL2FEfIT sfGaEnf5ts8qZNfC7XxAN/jKIBvTK3RPDhZwI= Received: by 10.204.13.68 with SMTP id b4mr5022043bka.96.1319884365782; Sat, 29 Oct 2011 03:32:45 -0700 (PDT) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id j9sm10262067bkd.2.2011.10.29.03.32.41 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Oct 2011 03:32:42 -0700 (PDT) From: Mikolaj Golub To: Kostik Belousov References: <86y5wkeuw9.fsf@kopusha.home.net> <20111016171005.GB50300@deviant.kiev.zoral.com.ua> <86aa8qozyx.fsf@kopusha.home.net> <20111025082451.GO50300@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Sender: Mikolaj Golub Date: Sat, 29 Oct 2011 13:32:39 +0300 Message-ID: <86aa8k2im0.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: "ps -e" without procfs(5) 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, 29 Oct 2011 10:32:47 -0000 --=-=-= On Tue, 25 Oct 2011 11:24:51 +0300 Kostik Belousov wrote: KB> On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote: >> >> On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote: >> >> KB> In my opinion, the way to implement the feature is to (re)use >> KB> linprocfs_doargv() and provide another kern.proc sysctl to retrieve the >> KB> argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as >> KB> procfs and linprocfs inside the kernel. >> >> Thanks! I am testing a patch (without auxv vector so far) and have some >> questions. >> >> Original ps -e returns environment only for user owned processes (the access is >> restricted by the permissions of /proc/pid/mem file). My kern.proc.env sysctl >> does not have such a restriction. I suppose I should add it? What function I >> could use for this? >> >> BTW, linprocfs allows to read other user's environment. KB> linprocfs uses p_cansee() to check the permissions. There are sysctls KB> security.bsd.see_other_{ug}ids that control the behaviour. KB> I believe that the new sysctl shall use the same check. >> >> KB> While you are at the code, it would be useful to also export the auxv vector, >> KB> which is immediately before env. >> >> It looks I can find the location of auxv but what about the size? Or do you >> propose to extend struct ps_strings to store location and size of auxv? I >> could do this way... KB> No, extending ps_strings is not needed and it is too radical change. KB> The auxv vector must end by the AT_NULL aux entry. You can also artificially KB> limit the amount of read aux vectors to, say, 256, which is much more then KB> it is currently defined. What do you think about the attached patch? This is a kernel part. COMPAT_FREEBSD32 has not been tested after the last update (just checked that it compiles): it looks I will not have access to amd64 box for testing during the weekend. I will test it after the weekend. Both kernel and userland parts are available here: http://people.freebsd.org/~trociny/env.sys.patch http://people.freebsd.org/~trociny/env.user.patch Currently there is an issue with procstat -x: if one tried to run it on 64 bit for a 32 bit process it would not detect this so would output a garbage. Could somebody recommend a way how to get this info about a process from userlend? -- Mikolaj Golub --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=env.sys.patch diff --git a/sys/sys/proc.h b/sys/sys/proc.h index fb97913..4949f98 100644 --- a/sys/sys/proc.h +++ b/sys/sys/proc.h @@ -168,6 +168,7 @@ struct p_sched; struct proc; struct procdesc; struct racct; +struct sbuf; struct sleepqueue; struct td_sched; struct thread; @@ -843,6 +844,10 @@ int p_canwait(struct thread *td, struct proc *p); struct pargs *pargs_alloc(int len); void pargs_drop(struct pargs *pa); void pargs_hold(struct pargs *pa); +int proc_getargv(struct thread *td, struct proc *p, struct sbuf *sb, + size_t nchr); +int proc_getenvv(struct thread *td, struct proc *p, struct sbuf *sb, + size_t nchr); void procinit(void); void proc_linkup0(struct proc *p, struct thread *td); void proc_linkup(struct proc *p, struct thread *td); diff --git a/sys/sys/sysctl.h b/sys/sys/sysctl.h index 1e879f5..99ea342 100644 --- a/sys/sys/sysctl.h +++ b/sys/sys/sysctl.h @@ -559,6 +559,8 @@ SYSCTL_ALLOWED_TYPES(UINT64, uint64_t *a; unsigned long long *b; ); #define KERN_PROC_VMMAP 32 /* VM map entries for process */ #define KERN_PROC_FILEDESC 33 /* File descriptors for process */ #define KERN_PROC_GROUPS 34 /* process groups */ +#define KERN_PROC_ENV 35 /* get environment */ +#define KERN_PROC_AUXV 36 /* get ELF auxiliary vector */ /* * KERN_IPC identifiers diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c index 998e7ca..ef4055a 100644 --- a/sys/kern/kern_proc.c +++ b/sys/kern/kern_proc.c @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -49,6 +50,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -66,6 +68,8 @@ __FBSDID("$FreeBSD$"); #include #include +#include + #ifdef DDB #include #endif @@ -1356,6 +1360,218 @@ pargs_drop(struct pargs *pa) pargs_free(pa); } +static int +proc_read_mem(struct thread *td, struct proc *p, vm_offset_t offset, void* buf, + size_t len) +{ + struct iovec iov; + struct uio uio; + + iov.iov_base = (caddr_t)buf; + iov.iov_len = len; + uio.uio_iov = &iov; + uio.uio_iovcnt = 1; + uio.uio_offset = offset; + uio.uio_resid = (ssize_t)len; + uio.uio_segflg = UIO_SYSSPACE; + uio.uio_rw = UIO_READ; + uio.uio_td = td; + + return (proc_rwmem(p, &uio)); +} + +#define PROC_AUXV_MAX 256 /* Limit on auxv size. */ + +enum proc_vector_type { + PROC_ARG, + PROC_ENV, + PROC_AUX, +}; + +#ifdef COMPAT_FREEBSD32 +static int +get_proc_vector32(struct thread *td, struct proc *p, char ***proc_vectorp, + size_t *vsizep, enum proc_vector_type type) +{ + struct freebsd32_ps_strings pss; + Elf32_Auxinfo aux; + vm_offset_t vptr, ptr; + uint32_t *proc_vector32; + char **proc_vector; + size_t vsize, size; + int i, error; + + error = proc_read_mem(td, p, (vm_offset_t)(p->p_sysent->sv_psstrings), + &pss, sizeof(pss)); + if (error != 0) + return (error); + switch (type) { + case PROC_ARG: + vptr = (vm_offset_t)PTRIN(pss.ps_argvstr); + vsize = pss.ps_nargvstr; + size = vsize * sizeof(int32_t); + break; + case PROC_ENV: + vptr = (vm_offset_t)PTRIN(pss.ps_envstr); + vsize = pss.ps_nenvstr; + size = vsize * sizeof(int32_t); + break; + case PROC_AUX: + vptr = ptr = (vm_offset_t)PTRIN(pss.ps_envstr) + + (pss.ps_nenvstr + 1) * sizeof(int32_t); + for (i = 0; i < PROC_AUXV_MAX; i++) { + error = proc_read_mem(td, p, ptr, &aux, sizeof(aux)); + if (error != 0) + return (error); + if (aux.a_type == AT_NULL) + break; + ptr += sizeof(aux); + } + if (aux.a_type != AT_NULL) { + *proc_vectorp = NULL; + *vsizep = 0; + return (0); + } + vsize = i + 1; + size = vsize * sizeof(aux); + break; + default: + KASSERT(0, ("Wrong proc vector type: %d", type)); + } + proc_vector32 = malloc(size, M_TEMP, M_WAITOK); + error = proc_read_mem(td, p, vptr, proc_vector32, size); + if (error != 0) + goto done; + if (type == PROC_AUX) { + *proc_vectorp = (char **)proc_vector32; + *vsizep = vsize; + return (0); + } + proc_vector = malloc(vsize * sizeof(char *), M_TEMP, M_WAITOK); + for (i = 0; i < (int)vsize; i++) + proc_vector[i] = PTRIN(proc_vector32[i]); + *proc_vectorp = proc_vector; + *vsizep = vsize; +done: + free(proc_vector32, M_TEMP); + return (error); +} +#endif + +static int +get_proc_vector(struct thread *td, struct proc *p, char ***proc_vectorp, + size_t *vsizep, enum proc_vector_type type) +{ + struct ps_strings pss; + Elf_Auxinfo aux; + vm_offset_t vptr, ptr; + char **proc_vector; + size_t vsize, size; + int error, i; + +#ifdef COMPAT_FREEBSD32 + if (SV_PROC_FLAG(p, SV_ILP32) != 0) + return (get_proc_vector32(td, p, proc_vectorp, vsizep, type)); +#endif + error = proc_read_mem(td, p, (vm_offset_t)(p->p_sysent->sv_psstrings), + &pss, sizeof(pss)); + if (error != 0) + return (error); + switch (type) { + case PROC_ARG: + vptr = (vm_offset_t)pss.ps_argvstr; + vsize = pss.ps_nargvstr; + size = vsize * sizeof(char *); + break; + case PROC_ENV: + vptr = (vm_offset_t)pss.ps_envstr; + vsize = pss.ps_nenvstr; + size = vsize * sizeof(char *); + break; + case PROC_AUX: + vptr = ptr = (vm_offset_t)pss.ps_envstr + (pss.ps_nenvstr + 1) + * sizeof(char *); + for (i = 0; i < PROC_AUXV_MAX; i++) { + error = proc_read_mem(td, p, ptr, &aux, sizeof(aux)); + if (error != 0) + return (error); + if (aux.a_type == AT_NULL) + break; + ptr += sizeof(aux); + } + if (aux.a_type != AT_NULL) { + *proc_vectorp = NULL; + *vsizep = 0; + return (0); + } + vsize = i + 1; + size = vsize * sizeof(aux); + break; + default: + KASSERT(0, ("Wrong proc vector type: %d", type)); + } + proc_vector = malloc(size, M_TEMP, M_WAITOK); + error = proc_read_mem(td, p, vptr, proc_vector, size); + if (error != 0) { + free(proc_vector, M_TEMP); + return (error); + } + *proc_vectorp = proc_vector; + *vsizep = vsize; + + return (0); +} + +#define GET_PS_STRINGS_CHUNK_SZ 256 /* Chunk size (bytes) for ps_strings operations. */ + +static int +get_ps_strings(struct thread *td, struct proc *p, struct sbuf *sb, + enum proc_vector_type type, size_t nchr) +{ + vm_offset_t offset; + size_t done, len, vsize; + int error, i; + char **proc_vector; + char pss_string[GET_PS_STRINGS_CHUNK_SZ]; + + error = get_proc_vector(td, p, &proc_vector, &vsize, type); + if (error != 0) + return (error); + for (done = 0, i = 0; i < (int)vsize && done < nchr; i++) { + for (offset = (vm_offset_t)proc_vector[i]; ; + offset += GET_PS_STRINGS_CHUNK_SZ) { + error = proc_read_mem(td, p, offset, pss_string, + sizeof(pss_string)); + if (error != 0) + goto done; + len = strnlen(pss_string, GET_PS_STRINGS_CHUNK_SZ); + if (done + len >= nchr) + len = nchr - done - 1; + sbuf_bcat(sb, pss_string, len); + if (len != GET_PS_STRINGS_CHUNK_SZ) + break; + done += GET_PS_STRINGS_CHUNK_SZ; + } + sbuf_bcat(sb, "", 1); + done += len + 1; + } +done: + free(proc_vector, M_TEMP); + return (error); +} + +int +proc_getargv(struct thread *td, struct proc *p, struct sbuf *sb, size_t nchr) +{ + return (get_ps_strings(curthread, p, sb, PROC_ARG, nchr)); +} + +int +proc_getenvv(struct thread *td, struct proc *p, struct sbuf *sb, size_t nchr) +{ + return (get_ps_strings(curthread, p, sb, PROC_ENV, nchr)); +} + /* * This sysctl allows a process to retrieve the argument list or process * title for another process without groping around in the address space @@ -1369,7 +1585,8 @@ sysctl_kern_proc_args(SYSCTL_HANDLER_ARGS) u_int namelen = arg2; struct pargs *newpa, *pa; struct proc *p; - int error = 0; + struct sbuf sb; + int error = 0, error2; if (namelen != 1) return (EINVAL); @@ -1389,11 +1606,24 @@ sysctl_kern_proc_args(SYSCTL_HANDLER_ARGS) } pa = p->p_args; - pargs_hold(pa); - PROC_UNLOCK(p); - if (pa != NULL) + if (pa != NULL) { + pargs_hold(pa); + PROC_UNLOCK(p); error = SYSCTL_OUT(req, pa->ar_args, pa->ar_length); - pargs_drop(pa); + pargs_drop(pa); + } else if ((p->p_flag & (P_WEXIT | P_SYSTEM)) == 0) { + _PHOLD(p); + PROC_UNLOCK(p); + sbuf_new_for_sysctl(&sb, NULL, GET_PS_STRINGS_CHUNK_SZ, req); + error = proc_getargv(curthread, p, &sb, req->oldlen); + error2 = sbuf_finish(&sb); + PRELE(p); + sbuf_delete(&sb); + if (error == 0 && error2 != 0) + error = error2; + } else { + PROC_UNLOCK(p); + } if (error != 0 || req->newptr == NULL) return (error); @@ -1414,6 +1644,95 @@ sysctl_kern_proc_args(SYSCTL_HANDLER_ARGS) } /* + * This sysctl allows a process to retrieve environment of another process. + */ +static int +sysctl_kern_proc_env(SYSCTL_HANDLER_ARGS) +{ + int *name = (int*) arg1; + u_int namelen = arg2; + struct proc *p; + struct sbuf sb; + int error, error2; + + if (namelen != 1) + return (EINVAL); + + p = pfind((pid_t)name[0]); + if (p == NULL) + return (ESRCH); + if (p->p_flag & P_WEXIT) { + PROC_UNLOCK(p); + return (ESRCH); + } + if ((error = p_candebug(curthread, p)) != 0) { + PROC_UNLOCK(p); + return (error); + } + if (p->p_flag & P_SYSTEM) { + PROC_UNLOCK(p); + return (0); + } + _PHOLD(p); + PROC_UNLOCK(p); + sbuf_new_for_sysctl(&sb, NULL, GET_PS_STRINGS_CHUNK_SZ, req); + error = proc_getenvv(curthread, p, &sb, req->oldlen); + error2 = sbuf_finish(&sb); + PRELE(p); + sbuf_delete(&sb); + return (error != 0 ? error : error2); +} + +/* + * This sysctl allows a process to retrieve ELF auxiliary vector of + * another process. + */ +static int +sysctl_kern_proc_auxv(SYSCTL_HANDLER_ARGS) +{ + int *name = (int*) arg1; + u_int namelen = arg2; + struct proc *p; + size_t vsize; + char **auxv; + int error; + + if (namelen != 1) + return (EINVAL); + + p = pfind((pid_t)name[0]); + if (p == NULL) + return (ESRCH); + if (p->p_flag & P_WEXIT) { + PROC_UNLOCK(p); + return (ESRCH); + } + if ((error = p_cansee(curthread, p)) != 0) { + PROC_UNLOCK(p); + return (error); + } + if (p->p_flag & P_SYSTEM) { + PROC_UNLOCK(p); + return (0); + } + _PHOLD(p); + PROC_UNLOCK(p); + error = get_proc_vector(curthread, p, &auxv, &vsize, PROC_AUX); + PRELE(p); + if (error == 0) { +#ifdef COMPAT_FREEBSD32 + if (SV_PROC_FLAG(p, SV_ILP32) != 0) + error = SYSCTL_OUT(req, auxv, vsize * + sizeof(Elf32_Auxinfo)); + else +#endif + error = SYSCTL_OUT(req, auxv, vsize * sizeof(Elf_Auxinfo)); + free(auxv, M_TEMP); + } + return (error); +} + +/* * This sysctl allows a process to retrieve the path of the executable for * itself or another process. */ @@ -2026,6 +2345,14 @@ static SYSCTL_NODE(_kern_proc, KERN_PROC_ARGS, args, CTLFLAG_RW | CTLFLAG_ANYBODY | CTLFLAG_MPSAFE, sysctl_kern_proc_args, "Process argument list"); +static SYSCTL_NODE(_kern_proc, KERN_PROC_ENV, env, + CTLFLAG_RW | CTLFLAG_ANYBODY | CTLFLAG_MPSAFE, + sysctl_kern_proc_env, "Process environment"); + +static SYSCTL_NODE(_kern_proc, KERN_PROC_AUXV, auxv, + CTLFLAG_RW | CTLFLAG_ANYBODY | CTLFLAG_MPSAFE, + sysctl_kern_proc_auxv, "Process ELF auxiliary vector"); + static SYSCTL_NODE(_kern_proc, KERN_PROC_PATHNAME, pathname, CTLFLAG_RD | CTLFLAG_MPSAFE, sysctl_kern_proc_pathname, "Process executable path"); diff --git a/sys/compat/linprocfs/linprocfs.c b/sys/compat/linprocfs/linprocfs.c index 8832d3d..2f8ec1a 100644 --- a/sys/compat/linprocfs/linprocfs.c +++ b/sys/compat/linprocfs/linprocfs.c @@ -919,150 +919,6 @@ linprocfs_doprocroot(PFS_FILL_ARGS) return (0); } -#define MAX_ARGV_STR 512 /* Max number of argv-like strings */ -#define UIO_CHUNK_SZ 256 /* Max chunk size (bytes) for uiomove */ - -static int -linprocfs_doargv(struct thread *td, struct proc *p, struct sbuf *sb, - void (*resolver)(const struct ps_strings, u_long *, int *)) -{ - struct iovec iov; - struct uio tmp_uio; - struct ps_strings pss; - int ret, i, n_elements, elm_len; - u_long addr, pbegin; - char **env_vector, *envp; - char env_string[UIO_CHUNK_SZ]; -#ifdef COMPAT_FREEBSD32 - struct freebsd32_ps_strings pss32; - uint32_t *env_vector32; -#endif - -#define UIO_HELPER(uio, iov, base, len, cnt, offset, sz, flg, rw, td) \ -do { \ - iov.iov_base = (caddr_t)(base); \ - iov.iov_len = (len); \ - uio.uio_iov = &(iov); \ - uio.uio_iovcnt = (cnt); \ - uio.uio_offset = (off_t)(offset); \ - uio.uio_resid = (sz); \ - uio.uio_segflg = (flg); \ - uio.uio_rw = (rw); \ - uio.uio_td = (td); \ -} while (0) - - env_vector = malloc(sizeof(char *) * MAX_ARGV_STR, M_TEMP, M_WAITOK); - -#ifdef COMPAT_FREEBSD32 - env_vector32 = NULL; - if (SV_PROC_FLAG(p, SV_ILP32) != 0) { - env_vector32 = malloc(sizeof(*env_vector32) * MAX_ARGV_STR, - M_TEMP, M_WAITOK); - elm_len = sizeof(int32_t); - envp = (char *)env_vector32; - - UIO_HELPER(tmp_uio, iov, &pss32, sizeof(pss32), 1, - (off_t)(p->p_sysent->sv_psstrings), - sizeof(pss32), UIO_SYSSPACE, UIO_READ, td); - ret = proc_rwmem(p, &tmp_uio); - if (ret != 0) - goto done; - pss.ps_argvstr = PTRIN(pss32.ps_argvstr); - pss.ps_nargvstr = pss32.ps_nargvstr; - pss.ps_envstr = PTRIN(pss32.ps_envstr); - pss.ps_nenvstr = pss32.ps_nenvstr; - } else { -#endif - elm_len = sizeof(char *); - envp = (char *)env_vector; - - UIO_HELPER(tmp_uio, iov, &pss, sizeof(pss), 1, - (off_t)(p->p_sysent->sv_psstrings), - sizeof(pss), UIO_SYSSPACE, UIO_READ, td); - ret = proc_rwmem(p, &tmp_uio); - if (ret != 0) - goto done; -#ifdef COMPAT_FREEBSD32 - } -#endif - - /* Get the array address and the number of elements */ - resolver(pss, &addr, &n_elements); - - /* Consistent with lib/libkvm/kvm_proc.c */ - if (n_elements > MAX_ARGV_STR) { - ret = E2BIG; - goto done; - } - - UIO_HELPER(tmp_uio, iov, envp, n_elements * elm_len, 1, - (vm_offset_t)(addr), iov.iov_len, UIO_SYSSPACE, UIO_READ, td); - ret = proc_rwmem(p, &tmp_uio); - if (ret != 0) - goto done; -#ifdef COMPAT_FREEBSD32 - if (env_vector32 != NULL) { - for (i = 0; i < n_elements; i++) - env_vector[i] = PTRIN(env_vector32[i]); - } -#endif - - /* Now we can iterate through the list of strings */ - for (i = 0; i < n_elements; i++) { - pbegin = (vm_offset_t)env_vector[i]; - for (;;) { - UIO_HELPER(tmp_uio, iov, env_string, sizeof(env_string), - 1, pbegin, iov.iov_len, UIO_SYSSPACE, UIO_READ, td); - ret = proc_rwmem(p, &tmp_uio); - if (ret != 0) - goto done; - - if (!strvalid(env_string, UIO_CHUNK_SZ)) { - /* - * We didn't find the end of the string. - * Add the string to the buffer and move - * the pointer. But do not allow strings - * of unlimited length. - */ - sbuf_bcat(sb, env_string, UIO_CHUNK_SZ); - if (sbuf_len(sb) >= ARG_MAX) { - ret = E2BIG; - goto done; - } - pbegin += UIO_CHUNK_SZ; - } else { - sbuf_cat(sb, env_string); - break; - } - } - sbuf_bcat(sb, "", 1); - } -#undef UIO_HELPER - -done: - free(env_vector, M_TEMP); -#ifdef COMPAT_FREEBSD32 - free(env_vector32, M_TEMP); -#endif - return (ret); -} - -static void -ps_string_argv(const struct ps_strings ps, u_long *addr, int *n) -{ - - *addr = (u_long) ps.ps_argvstr; - *n = ps.ps_nargvstr; -} - -static void -ps_string_env(const struct ps_strings ps, u_long *addr, int *n) -{ - - *addr = (u_long) ps.ps_envstr; - *n = ps.ps_nenvstr; -} - /* * Filler function for proc/pid/cmdline */ @@ -1090,9 +946,15 @@ linprocfs_doproccmdline(PFS_FILL_ARGS) PROC_UNLOCK(p); return (0); } + + if ((p->p_flag & (P_WEXIT | P_SYSTEM)) != 0) { + PROC_UNLOCK(p); + return (0); + } + PROC_UNLOCK(p); - ret = linprocfs_doargv(td, p, sb, ps_string_argv); + ret = proc_getargv(td, p, sb, ARG_MAX); return (ret); } @@ -1118,9 +980,15 @@ linprocfs_doprocenviron(PFS_FILL_ARGS) PROC_UNLOCK(p); return (0); } + + if ((p->p_flag & (P_WEXIT | P_SYSTEM)) != 0) { + PROC_UNLOCK(p); + return (0); + } + PROC_UNLOCK(p); - ret = linprocfs_doargv(td, p, sb, ps_string_env); + ret = proc_getenvv(td, p, sb, ARG_MAX); return (ret); } --=-=-=-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 06:14:41 2011 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 A614E106567B for ; Sat, 29 Oct 2011 06:14:41 +0000 (UTC) (envelope-from bfalk@brandonfa.lk) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 67A9E8FC19 for ; Sat, 29 Oct 2011 06:14:41 +0000 (UTC) Received: by qyg14 with SMTP id 14so6074352qyg.13 for ; Fri, 28 Oct 2011 23:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brandonfa.lk; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=o1QgiOIN9xDuKuFDMdh8dWkpCd1ySIFlzjM5AsIB9LY=; b=qPo7pAlQtreNFg7VO6GYEUN9TK3iOAhKMdZBqQCpZIMoK3RVw702q7QJZseHaJvU2G hKzuDm0ShurhVL5K+y6XOw0Arnk0Mwvt+sDbrZn9R8E5XZjLM/tJ2eOxFu4Ce+mLAxu7 P6zAC6WYfi4fASjo5l7MZ6VGUQzTAT+4S3n+U= MIME-Version: 1.0 Received: by 10.229.61.73 with SMTP id s9mr1378484qch.230.1319867467727; Fri, 28 Oct 2011 22:51:07 -0700 (PDT) Received: by 10.229.11.19 with HTTP; Fri, 28 Oct 2011 22:51:07 -0700 (PDT) X-Originating-IP: [71.126.180.69] Date: Sat, 29 Oct 2011 01:51:07 -0400 Message-ID: From: Brandon Falk To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Sat, 29 Oct 2011 11:22:13 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Issue building pango on FreeBSD 10.0 amd64 (r226893) 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: Sat, 29 Oct 2011 06:14:41 -0000 I'm currently getting this issue building pango (everything, including world and kernel, have been built with clang): /usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:762: syntax error, unexpected identifier in ' guint16 name_offset;' at 'guint16' /usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:768: syntax error, unexpected identifier, expecting ',' or ';' in 'static const ColorEntry color_entries[] = {' at 'color_entries' /usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-language-sample-table.h:52: syntax error, unexpected identifier in 'LANGUAGE(' at 'LANGUAGE' CCLD libpangoxft-1.0.la CCLD libpangocairo-1.0.la /usr/bin/ld: /usr/local/lib/libXft.a(xftdpy.o): relocation R_X86_64_32 against `_XftDisplayInfo' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libXft.a: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) gmake[4]: *** [libpangoxft-1.0.la] Error 1 gmake[4]: *** Waiting for unfinished jobs.... g-ir-scanner: Pango: warning: 57 warnings suppressed (use --warn-all to see them) gmake[4]: Leaving directory `/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/x11-toolkits/pango/work/pango-1.28.4' gmake: *** [all] Error 2 *** Error code 1 Any ideas? Perhaps it's just some crazy temporary issue? I'll look into it tomorrow, but I gotta catch some sleep. Thanks in advance, Brandon Falk From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 29 16:45:58 2011 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 8E4481065687 for ; Sat, 29 Oct 2011 16:45:58 +0000 (UTC) (envelope-from falkman@gamozo.org) Received: from fireblade.netcore2k.net (fireblade.netcore2k.net [92.48.127.72]) by mx1.freebsd.org (Postfix) with ESMTP id 10B528FC08 for ; Sat, 29 Oct 2011 16:45:57 +0000 (UTC) Received: by fireblade.netcore2k.net with ESMTP id p9TGW5hM029335 ; Sat, 29 Oct 2011 17:32:07 +0100 Message-ID: <4EAC2A84.7070805@gamozo.org> Date: Sat, 29 Oct 2011 12:32:04 -0400 From: Brandon Falk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Brandon Falk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Issue building pango on FreeBSD 10.0 amd64 (r226893) 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: Sat, 29 Oct 2011 16:45:58 -0000 On 10/29/2011 1:51 AM, Brandon Falk wrote: > I'm currently getting this issue building pango (everything, including world > and kernel, have been built with clang): > > /usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:762: > syntax error, unexpected identifier in ' guint16 name_offset;' at > 'guint16' > /usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-color-table.h:768: > syntax error, unexpected identifier, expecting ',' or ';' in 'static const > ColorEntry color_entries[] = {' at 'color_entries' > /usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango/pango-language-sample-table.h:52: > syntax error, unexpected identifier in 'LANGUAGE(' at 'LANGUAGE' > CCLD libpangoxft-1.0.la > CCLD libpangocairo-1.0.la > /usr/bin/ld: /usr/local/lib/libXft.a(xftdpy.o): relocation R_X86_64_32 > against `_XftDisplayInfo' can not be used when making a shared object; > recompile with -fPIC > /usr/local/lib/libXft.a: could not read symbols: Bad value > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > gmake[4]: *** [libpangoxft-1.0.la] Error 1 > gmake[4]: *** Waiting for unfinished jobs.... > g-ir-scanner: Pango: warning: 57 warnings suppressed (use --warn-all to see > them) > gmake[4]: Leaving directory > `/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango' > gmake[3]: *** [all-recursive] Error 1 > gmake[3]: Leaving directory > `/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango' > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory > `/usr/ports/x11-toolkits/pango/work/pango-1.28.4/pango' > gmake[1]: *** [all-recursive] Error 1 > gmake[1]: Leaving directory > `/usr/ports/x11-toolkits/pango/work/pango-1.28.4' > gmake: *** [all] Error 2 > *** Error code 1 > > > Any ideas? Perhaps it's just some crazy temporary issue? I'll look into it > tomorrow, but I gotta catch some sleep. > > Thanks in advance, > Brandon Falk > _______________________________________________ > 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" (I'm the original poster... just on a different email) I went to bed, and woke up, and the port(s) were fixed and the issues went away. [NOTE: This was not a clang issue, gcc acted the same way] To continue with my build (of vim which has now succeeded), I had to deinstall and reinstall the following ports (due to getting the same errors on these ports): x11-fonts/libXft x11/libXi x11/libXrandr x11/libXcursor x11/libXcomposite x11/libXdamage Perhaps I'll have the same issue on other ports, and I'll have to reinstall them. But I doubt anyone has really experienced this issue, as it seems like it was a small window in ports where this error occurred? Or perhaps it's a 10.0 issue that's been ongoing and discussed elsewhere. Anyways... this is FIXED. Regards, Brandon Falk