From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 00:13:58 2009 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 17188106566B for ; Sun, 11 Jan 2009 00:13:58 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id CC9DE8FC08 for ; Sun, 11 Jan 2009 00:13:57 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n0B0Dv6P026813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 10 Jan 2009 16:13:57 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n0B0DvTO026812; Sat, 10 Jan 2009 16:13:57 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA02896; Sat, 10 Jan 09 16:08:32 PST Date: Sat, 10 Jan 2009 16:10:42 -0800 From: perryh@pluto.rain.com To: uspoerlein@gmail.com Message-Id: <49693902.0x2OQspLPLnuQLwg%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090110185135.GB83079@roadrunner.spoerlein.net> In-Reply-To: <20090110185135.GB83079@roadrunner.spoerlein.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present 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, 11 Jan 2009 00:13:58 -0000 Ulrich Spoerlein wrote: > I cannot really comment on the devfs(4) design issues, > and quite frankly it hasn't bothered my thus far. It evidently inconvenienced the OP. > Just another little quirk you get to remember. If we followed that line of reasoning to its logical conclusion we would eliminate POLA entirely. > > IMO it violates POLA, if not POSIX, for open(2) to succeed when > > applied to a name which, according to readdir(2), does not > > exist; and it is suboptimal to have "stealth" drivers whose > > availability for use cannot be discovered by examining /dev. > > You forgot directories with --x permissions. You can open many > files inside them, but readdir(2) will get you nowhere. So this > is a poor standard by which to judge devfs(4) device cloning. There are at least two problems with that analysis: * /dev does not ordinarily have --x permissions. Even if I amended the principle to allow for that case, it would not affect its application to this case. * readdir works for root, even in directories with --x permissions. For example: $ mkdir test $ touch test/file $ ls -la test total 4 drwxr-xr-x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh 0 Jan 10 15:39 file $ chmod 111 test $ ls -ld test d--x--x--x 2 perryh perryh 512 Jan 10 15:39 test $ ls -la test total 0 ls: test: Permission denied # ls -la test total 4 d--x--x--x 2 perryh perryh 512 Jan 10 15:39 . drwxr-xr-x 3 perryh perryh 512 Jan 10 15:39 .. -rw-r--r-- 1 perryh perryh 0 Jan 10 15:39 file From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 02:37:00 2009 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 E9520106564A for ; Sun, 11 Jan 2009 02:37:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 53CCB8FC12 for ; Sun, 11 Jan 2009 02:37:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3410004fgb.35 for ; Sat, 10 Jan 2009 18:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xGpG68czKsDPm38k7o+d5KLL6az4ShVGSZaEj2gx6bM=; b=pReTAi+wKCfs81rLYTzUWXjudhzqKhhYw3KNGOrM+iYjgnInU8LuMnHhZumUEJX1D9 DJGRJxkw3REDiD7v76+NWnEaCX3aHo7KXECF86FaybPtAqqwUZxVcK9P1o6a5Aksb0vr p5Lb5EdJdzk5dBvzoIr3StfgckAcb4I2XSc5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MnXFOK5kOSrGLd1Fmxwg5jLjJixRHgjjNlmhMWKWdja7QX+6JEcQFEls+hc8ho+2h5 PNzvujSG9+phN9I3SeqoHqXj8SAh8/k1FCfZxq/j5Yv+5kwT+Ui4jW3kHHkdtXcAAEp5 /5aj8sY6PIiUNbglapSKm1F5smok2iUNAO7AQ= Received: by 10.86.79.4 with SMTP id c4mr1179183fgb.7.1231641419477; Sat, 10 Jan 2009 18:36:59 -0800 (PST) Received: by 10.86.72.19 with HTTP; Sat, 10 Jan 2009 18:36:59 -0800 (PST) Message-ID: Date: Sun, 11 Jan 2009 05:36:59 +0300 From: pluknet To: "Tim Kientzle" In-Reply-To: <49692659.2030306@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49692659.2030306@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: extattr problems? 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, 11 Jan 2009 02:37:01 -0000 2009/1/11 Tim Kientzle : > FreeBSD 6.3: > > fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777); > n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); > > After this, fd=3, n is non-zero, errno = 9 (EBADF) > > Huh? I would have expected EOPNOTSUPP if > extended attributes weren't supported on this > filesystem. The file descriptor is clearly > valid. Simple guess. Don't hit me if I'm wrong. :) You call open() with (O_CREAT | O_EXCL) on an already existing file. If such then open() returns -1 with EEXIST and subsequent extattr_set_fd() call with fd (-1) returns EBADF from getvnode() on failed (td->td_proc->p_fd == NULL) or (fp = fdp->fd_ofiles[fd]) == NULL) checks. > > Tim -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 03:48:55 2009 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 288CB106564A for ; Sun, 11 Jan 2009 03:48:55 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 00E098FC16 for ; Sun, 11 Jan 2009 03:48:54 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0B3msC1001968; Sat, 10 Jan 2009 19:48:54 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <49696C24.8010601@freebsd.org> Date: Sat, 10 Jan 2009 19:48:52 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pluknet References: <49692659.2030306@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: extattr problems? 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, 11 Jan 2009 03:48:55 -0000 pluknet wrote: > 2009/1/11 Tim Kientzle : > >>FreeBSD 6.3: >> >>fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777); >>n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); >> >>After this, fd=3, n is non-zero, errno = 9 (EBADF) >> >>Huh? I would have expected EOPNOTSUPP if >>extended attributes weren't supported on this >>filesystem. The file descriptor is clearly >>valid. > > Simple guess. > Don't hit me if I'm wrong. :) > > You call open() with (O_CREAT | O_EXCL) on an already existing file. Nope. As you can see from my earlier summary, fd=3 immediately after this, so the open did succeed normally. Oh, but that gives me an idea ... ... darn. Still no joy. I tried changing the open to open("test", O_RDWR | O_CREATE, 0777) and it still fails in exactly the same way. The open still succeeds and the extattr_set_fd() still fails with a nonsensical errno value. Time to dig through kernel sources.... Tim From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 03:50:57 2009 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 39E90106566C for ; Sun, 11 Jan 2009 03:50:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by mx1.freebsd.org (Postfix) with ESMTP id 030E88FC08 for ; Sun, 11 Jan 2009 03:50:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so11617975rvf.43 for ; Sat, 10 Jan 2009 19:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QLaoKT2AXf0loDUnNoKKRzHvSkccJ9X7+GtFxQZk1jc=; b=E4cseevD32XtTeiFwiRuKrCtbCbFWnLf2KjtZqiNpFi6G4KKxumXkR3zsjzkplityX pF76jZ3z8va4t/PSFcRu6hINyfHcx+J8GLim38qPWpbvJHLYRkkWV7Fyw/REID5In51s 27OBjd3s9I1cfIKHAWH+h5nRihRM9F3iynzEA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=tXcAgoQuk4SfoXaRDXEzhQ2kw+amswx2A/zffpc/378j4sMAC5YllieBAJTIdfM+7f 1RKqbTKzfbabtl6Zx7Is9pVWsHY4iTYMiyH/rOsX5GULY1yqOqA4hxk0HgjLwNOxOTsG FU0cvPtvTlqM4iueBPp9U16RkcJSv1Ky1m9d4= Received: by 10.140.173.10 with SMTP id v10mr420717rve.199.1231644171791; Sat, 10 Jan 2009 19:22:51 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id g14sm1422688rvb.0.2009.01.10.19.22.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Jan 2009 19:22:50 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.14.3/8.14.3) with ESMTP id n0B3Mi0Y043047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 12:22:44 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.14.3/8.14.3/Submit) id n0B3MhC7043046; Sun, 11 Jan 2009 12:22:43 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sun, 11 Jan 2009 12:22:43 +0900 From: Pyun YongHyeon To: "Aryeh M. Friedman" Message-ID: <20090111032243.GC42714@cdnetworks.co.kr> References: <4967FE4C.2050301@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4967FE4C.2050301@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: support for i45 (ich10) chipsets X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 03:50:57 -0000 On Fri, Jan 09, 2009 at 08:47:56PM -0500, Aryeh M. Friedman wrote: > I just got a i45 based motherboard and everything works except for the > following pci: > > none2@pci0:1:0:0: class=0x020000 card=0x83671043 chip=0x816810ec > rev=0x02 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > does -current support it or should I stay with 7.1-RELEASE ? (i386) If re(4) didn't serve the controller, re(4) might have printed some informational messages to console. So would you show me the dmesg output? BTW, I think stable@ would be appropriate list for this kind of issue. -- Regards, Pyun YongHyeon From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 05:05:23 2009 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 CB676106564A for ; Sun, 11 Jan 2009 05:05:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3D08FC0A for ; Sun, 11 Jan 2009 05:05:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0B532l3034526; Sat, 10 Jan 2009 22:03:02 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 10 Jan 2009 22:03:22 -0700 (MST) Message-Id: <20090110.220322.2008390173.imp@bsdimp.com> To: peterjeremy@optushome.com.au From: "M. Warner Losh" In-Reply-To: <20090111041710.GB5661@server.vk2pj.dyndns.org> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: hackers@FreeBSD.org Subject: Re: 3x read to write ratio on dump/restore 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, 11 Jan 2009 05:05:24 -0000 In message: <20090111041710.GB5661@server.vk2pj.dyndns.org> Peter Jeremy writes: : On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" wrote: : >The read kBps was 3x the write kBps. : ... : >Any ideas what gives? I observed this with 16MB cache and with 32MB : >cache, fwiw. : : I've seen this as well. AFAIK, this is a side-effect of dump's caching. : : My top-of-head explanation is that each dump process has its own cache : but actual I/O is round-robined on a (roughly) block scale so a large : contiguous file will wind up in each 'slave' process's cache. : : The most obvious (and easiest) fixes are to either implement a shared : cache (though this means another level of inter-process communication) : or only use a single 'slave' process when caching is enabled. I'll have to look into this... Most of the files I was backing up were large contiguous files (26 10GiB .dv files from my camera). : The cache algorithm could probably be enhanced as well - apart from : inode blocks, any block will only be accessed once so once a block has : been accessed, it can be purged from the cache (which is completely : opposite to a "normal" cache). Yes, read everything, purge once it is touched. Warner From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 07:12:21 2009 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 2F2131065672 for ; Sun, 11 Jan 2009 07:12:21 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4CF8FC18 for ; Sun, 11 Jan 2009 07:12:20 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0B4HLIV008151 for ; Sun, 11 Jan 2009 15:17:21 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0B4HBXs002862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 15:17:12 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n0B4HAaK006274; Sun, 11 Jan 2009 15:17:10 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n0B4HAqW006273; Sun, 11 Jan 2009 15:17:10 +1100 (EST) (envelope-from peter) Date: Sun, 11 Jan 2009 15:17:10 +1100 From: Peter Jeremy To: "M. Warner Losh" Message-ID: <20090111041710.GB5661@server.vk2pj.dyndns.org> References: <20090109.095027.-1672857892.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <20090109.095027.-1672857892.imp@bsdimp.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: hackers@freebsd.org Subject: Re: 3x read to write ratio on dump/restore 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, 11 Jan 2009 07:12:21 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" wrote: >The read kBps was 3x the write kBps. =2E.. >Any ideas what gives? I observed this with 16MB cache and with 32MB >cache, fwiw. I've seen this as well. AFAIK, this is a side-effect of dump's caching. My top-of-head explanation is that each dump process has its own cache but actual I/O is round-robined on a (roughly) block scale so a large contiguous file will wind up in each 'slave' process's cache. The most obvious (and easiest) fixes are to either implement a shared cache (though this means another level of inter-process communication) or only use a single 'slave' process when caching is enabled. The cache algorithm could probably be enhanced as well - apart from inode blocks, any block will only be accessed once so once a block has been accessed, it can be purged from the cache (which is completely opposite to a "normal" cache). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklpcsYACgkQ/opHv/APuIf68wCgq8Tr6rXQur5nEVBgVn4gPSLl O1AAnjf2Nn3jqnii5ZHq9BycVa6hFXe8 =C38A -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 08:04:46 2009 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 DD15E1065670; Sun, 11 Jan 2009 08:04:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 408EB8FC25; Sun, 11 Jan 2009 08:04:46 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3442728fgb.35 for ; Sun, 11 Jan 2009 00:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=kEP+OVGUjrba3M6xBCo4OrLrlkOaZ7kZr2R+ibkkhuc=; b=GjIOgCT+ZE41bfFZnvHH5/mLhCmfktq9Sv/mC5H+3I06jagcDuiZTxLTpF4k4vnukH 1DNbPucN/mnQVm4VcgFiMj/ssEEobw57kftCK6dUtur2Ybo7T4A/TvUTUBEwDCrRd/BS cW+nag+xLxCAFr/Si0m24Rja+idfAaZFkVXyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=op3v7WLYqA9Ty/hSw5XAu0uvZn/yzf/tinBcyVD9kr0/vYfPQh/IkjRyHtRz3tcmoQ lTRKp8jpncIKUH6gjNmqf9YQUPm+VxT5u9Vg0tVjYXbGs0zShCr/5MVuXIisqcwCnfPf h7ScSycNqW6AeR/CuFhWg+uFirt/ScDlpgB6s= Received: by 10.86.82.6 with SMTP id f6mr10441629fgb.42.1231661085167; Sun, 11 Jan 2009 00:04:45 -0800 (PST) Received: by 10.86.72.19 with HTTP; Sun, 11 Jan 2009 00:04:45 -0800 (PST) Message-ID: Date: Sun, 11 Jan 2009 11:04:45 +0300 From: pluknet To: "Tim Kientzle" In-Reply-To: <49696C24.8010601@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: extattr problems? 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, 11 Jan 2009 08:04:47 -0000 2009/1/11 Tim Kientzle : > pluknet wrote: >> >> 2009/1/11 Tim Kientzle : >> >>> FreeBSD 6.3: >>> >>> fd = open("test", O_WRONLY | O_CREAT | O_EXCL, 0777); >>> n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); >>> >>> After this, fd=3, n is non-zero, errno = 9 (EBADF) >>> >>> Huh? I would have expected EOPNOTSUPP if >>> extended attributes weren't supported on this >>> filesystem. The file descriptor is clearly >>> valid. >> >> Simple guess. >> Don't hit me if I'm wrong. :) >> >> You call open() with (O_CREAT | O_EXCL) on an already existing file. > > Nope. As you can see from my earlier summary, > fd=3 immediately after this, so the open did > succeed normally. Ah, I'm sorry. My inadvertency. > > Oh, but that gives me an idea ... > ... darn. Still no joy. I tried changing the open to > open("test", O_RDWR | O_CREATE, 0777) and it still > fails in exactly the same way. The open still succeeds > and the extattr_set_fd() still fails with a nonsensical > errno value. It's strange.. FreeBSD jaw.ripn.net 6.3-RELEASE-p5. works for me (tm), extattr_set_fd() returns 4 as expected. Also works on 7.1 at home. > > Time to dig through kernel sources.... > > Tim > -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 08:33:03 2009 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 B5DA51065670; Sun, 11 Jan 2009 08:33:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id 483EE8FC12; Sun, 11 Jan 2009 08:33:03 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0B8X1HO027655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 19:33:01 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n0B8X0nW007399; Sun, 11 Jan 2009 19:33:00 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n0B8X0mE007395; Sun, 11 Jan 2009 19:33:00 +1100 (EST) (envelope-from peter) Date: Sun, 11 Jan 2009 19:33:00 +1100 From: Peter Jeremy To: Kamlesh Patel Message-ID: <20090111083300.GC7054@server.vk2pj.dyndns.org> References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yVhtmJPUSI46BTXb" Content-Disposition: inline In-Reply-To: <468090.72533.qm@web45413.mail.sp1.yahoo.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: kernel panic 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, 11 Jan 2009 08:33:04 -0000 --yVhtmJPUSI46BTXb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jan-09 00:05:47 -0800, Kamlesh Patel wrote: >How do i recover the system from this error. I can't reload the loader.old If you press any key during the first spinner, you should get a prompt similar to the following: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: You can then enter the name of the program you wish to run - eg /boot/loader.old (or directly load /boot/kernel/kernel) See the following for a more complete description: http://www.freebsd.org/cgi/man.cgi?query=3Dboot&apropos=3D0&sektion=3D0&man= path=3DFreeBSD+7.1-RELEASE&format=3Dhtml --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --yVhtmJPUSI46BTXb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklprrwACgkQ/opHv/APuIfTrACgvDIfkZzzdTJkznYWKfqeVj4R JzgAn1B05lz+K8r+NtxrA/3bXfHHt3/V =HVuo -----END PGP SIGNATURE----- --yVhtmJPUSI46BTXb-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 15:59:05 2009 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 960D5106564A for ; Sun, 11 Jan 2009 15:59:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id A5B5C8FC14 for ; Sun, 11 Jan 2009 15:59:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LM2iM-000Jg6-J6; Sun, 11 Jan 2009 17:59:02 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0BFwt4J087794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 17:58:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0BFwtUw064427; Sun, 11 Jan 2009 17:58:55 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0BFwtlP064426; Sun, 11 Jan 2009 17:58:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 11 Jan 2009 17:58:55 +0200 From: Kostik Belousov To: Omer Faruk Sen Message-ID: <20090111155854.GS93900@deviant.kiev.zoral.com.ua> References: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="173oMW6+eDUtB8Ng" Content-Disposition: inline In-Reply-To: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LM2iM-000Jg6-J6 7d7b656bfcb6ddfb13f1b58dae3703b0 X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: kernel dump with 7.1-RELEASE 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, 11 Jan 2009 15:59:05 -0000 --173oMW6+eDUtB8Ng Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote: > Hi, >=20 > I am having kernel dump with FreeBSD 7.1: >=20 > Here is crashinfo output of it (Actually i don't know the state of > crashinfo in Fbsd 7.1) >=20 > 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >=20 >=20 >=20 > panic: semexit - semid not allocated >=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > Physical memory: 8173 MB > Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 > 214 198 182 166 150 134 118 102 86 70 54 38 22 6 >=20 > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:195 > #1 0x0000000000000004 in ?? () > #2 0xffffffff804b4ce9 in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff804b50f2 in panic (fmt=3D0x104
) > at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff804f846d in semexit_myhook (arg=3DVariable "arg" is not ava= ilable. > ) > at /usr/src/sys/kern/sysv_sem.c:1328 > #5 0xffffffff80490dbc in exit1 (td=3D0xffffff000995f370, rv=3D0) > at /usr/src/sys/kern/kern_exit.c:244 > #6 0xffffffff8049239e in sys_exit (td=3DVariable "td" is not available. > ) at /usr/src/sys/kern/kern_exit.c:109 > #7 0xffffffff8078a7c7 in syscall (frame=3D0xffffffffb0d4ac80) > at /usr/src/sys/amd64/amd64/trap.c:907 > #8 0xffffffff8077088b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:330 > #9 0x0000000800a2a30c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) It seems that there are at least two issues with IPC_RMID operation on SysV semaphores. 1. The squeeze of the semaphore array in the kern_semctl() modifies sem_base for the semaphores, as well as the values of the semaphores, without locking their mutex. This can lead to (killable) hangs or unexpected behaviour of the processes performing any sem operations while other process does IPC_RMID. 2. The semexit_myhook() eventhandler does not lock SEMUNDO_LOCK() while accessing *suptr. I think that this allows for IPC_RMID to be performed in parallel with the sem id referenced by the current undo structure. Patch below is the backport of the patch I developed and lightly tested on CURRENT, that shuffle locking to solve the listed issues. Testing consisted of running several instances of tools/regression/sysvsem. diff --git a/sys/kern/sysv_sem.c b/sys/kern/sysv_sem.c index 80d07ba..6bc4cce 100644 --- a/sys/kern/sysv_sem.c +++ b/sys/kern/sysv_sem.c @@ -88,7 +88,7 @@ int semop(struct thread *td, struct semop_args *uap); =20 static struct sem_undo *semu_alloc(struct thread *td); static int semundo_adjust(struct thread *td, struct sem_undo **supptr, - int semid, int semnum, int adjval); + int semid, int semseq, int semnum, int adjval); static void semundo_clear(int semid, int semnum); =20 /* XXX casting to (sy_call_t *) is bogus, as usual. */ @@ -98,15 +98,17 @@ static sy_call_t *semcalls[] =3D { }; =20 static struct mtx sem_mtx; /* semaphore global lock */ +static struct mtx sem_undo_mtx; static int semtot =3D 0; static struct semid_kernel *sema; /* semaphore id pool */ static struct mtx *sema_mtx; /* semaphore id pool mutexes*/ static struct sem *sem; /* semaphore pool */ -SLIST_HEAD(, sem_undo) semu_list; /* list of active undo structures */ +LIST_HEAD(, sem_undo) semu_list; /* list of active undo structures */ +LIST_HEAD(, sem_undo) semu_free_list; /* list of free undo structures */ static int *semu; /* undo structure pool */ static eventhandler_tag semexit_tag; =20 -#define SEMUNDO_MTX sem_mtx +#define SEMUNDO_MTX sem_undo_mtx #define SEMUNDO_LOCK() mtx_lock(&SEMUNDO_MTX); #define SEMUNDO_UNLOCK() mtx_unlock(&SEMUNDO_MTX); #define SEMUNDO_LOCKASSERT(how) mtx_assert(&SEMUNDO_MTX, (how)); @@ -122,13 +124,15 @@ struct sem { * Undo structure (one per process) */ struct sem_undo { - SLIST_ENTRY(sem_undo) un_next; /* ptr to next active undo structure */ + LIST_ENTRY(sem_undo) un_next; /* ptr to next active undo structure */ struct proc *un_proc; /* owner of this structure */ short un_cnt; /* # of active entries */ struct undo { short un_adjval; /* adjust on exit values */ short un_num; /* semaphore # */ int un_id; /* semid */ + unsigned short un_seq; + } un_ent[1]; /* undo entries */ }; =20 @@ -250,12 +254,15 @@ seminit(void) } for (i =3D 0; i < seminfo.semmni; i++) mtx_init(&sema_mtx[i], "semid", NULL, MTX_DEF); + LIST_INIT(&semu_free_list); for (i =3D 0; i < seminfo.semmnu; i++) { struct sem_undo *suptr =3D SEMU(i); suptr->un_proc =3D NULL; + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); } - SLIST_INIT(&semu_list); + LIST_INIT(&semu_list); mtx_init(&sem_mtx, "sem", NULL, MTX_DEF); + mtx_init(&sem_undo_mtx, "semu", NULL, MTX_DEF); semexit_tag =3D EVENTHANDLER_REGISTER(process_exit, semexit_myhook, NULL, EVENTHANDLER_PRI_ANY); } @@ -265,6 +272,7 @@ semunload(void) { int i; =20 + /* XXXKIB */ if (semtot !=3D 0) return (EBUSY); =20 @@ -279,6 +287,7 @@ semunload(void) for (i =3D 0; i < seminfo.semmni; i++) mtx_destroy(&sema_mtx[i]); mtx_destroy(&sem_mtx); + mtx_destroy(&sem_undo_mtx); return (0); } =20 @@ -350,69 +359,31 @@ semsys(td, uap) */ =20 static struct sem_undo * -semu_alloc(td) - struct thread *td; +semu_alloc(struct thread *td) { - int i; struct sem_undo *suptr; - struct sem_undo **supptr; - int attempt; =20 SEMUNDO_LOCKASSERT(MA_OWNED); - /* - * Try twice to allocate something. - * (we'll purge an empty structure after the first pass so - * two passes are always enough) - */ - - for (attempt =3D 0; attempt < 2; attempt++) { - /* - * Look for a free structure. - * Fill it in and return it if we find one. - */ - - for (i =3D 0; i < seminfo.semmnu; i++) { - suptr =3D SEMU(i); - if (suptr->un_proc =3D=3D NULL) { - SLIST_INSERT_HEAD(&semu_list, suptr, un_next); - suptr->un_cnt =3D 0; - suptr->un_proc =3D td->td_proc; - return(suptr); - } - } - - /* - * We didn't find a free one, if this is the first attempt - * then try to free a structure. - */ + if ((suptr =3D LIST_FIRST(&semu_free_list)) =3D=3D NULL) + return (NULL); + LIST_REMOVE(suptr, un_next); + LIST_INSERT_HEAD(&semu_list, suptr, un_next); + suptr->un_cnt =3D 0; + suptr->un_proc =3D td->td_proc; + return (suptr); +} =20 - if (attempt =3D=3D 0) { - /* All the structures are in use - try to free one */ - int did_something =3D 0; +static int +semu_try_free(struct sem_undo *suptr) +{ =20 - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, - un_next) { - if (suptr->un_cnt =3D=3D 0) { - suptr->un_proc =3D NULL; - did_something =3D 1; - *supptr =3D SLIST_NEXT(suptr, un_next); - break; - } - } + SEMUNDO_LOCKASSERT(MA_OWNED); =20 - /* If we didn't free anything then just give-up */ - if (!did_something) - return(NULL); - } else { - /* - * The second pass failed even though we freed - * something after the first pass! - * This is IMPOSSIBLE! - */ - panic("semu_alloc - second attempt failed"); - } - } - return (NULL); + if (suptr->un_cnt !=3D 0) + return (0); + LIST_REMOVE(suptr, un_next); + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); + return (1); } =20 /* @@ -420,11 +391,8 @@ semu_alloc(td) */ =20 static int -semundo_adjust(td, supptr, semid, semnum, adjval) - struct thread *td; - struct sem_undo **supptr; - int semid, semnum; - int adjval; +semundo_adjust(struct thread *td, struct sem_undo **supptr, int semid, + int semseq, int semnum, int adjval) { struct proc *p =3D td->td_proc; struct sem_undo *suptr; @@ -437,7 +405,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) =20 suptr =3D *supptr; if (suptr =3D=3D NULL) { - SLIST_FOREACH(suptr, &semu_list, un_next) { + LIST_FOREACH(suptr, &semu_list, un_next) { if (suptr->un_proc =3D=3D p) { *supptr =3D suptr; break; @@ -448,7 +416,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) return(0); suptr =3D semu_alloc(td); if (suptr =3D=3D NULL) - return(ENOSPC); + return (ENOSPC); *supptr =3D suptr; } } @@ -472,58 +440,59 @@ semundo_adjust(td, supptr, semid, semnum, adjval) if (i < suptr->un_cnt) suptr->un_ent[i] =3D suptr->un_ent[suptr->un_cnt]; + if (suptr->un_cnt =3D=3D 0) + semu_try_free(suptr); } - return(0); + return (0); } =20 /* Didn't find the right entry - create it */ if (adjval =3D=3D 0) - return(0); + return (0); if (adjval > seminfo.semaem || adjval < -seminfo.semaem) return (ERANGE); if (suptr->un_cnt !=3D seminfo.semume) { sunptr =3D &suptr->un_ent[suptr->un_cnt]; suptr->un_cnt++; sunptr->un_adjval =3D adjval; - sunptr->un_id =3D semid; sunptr->un_num =3D semnum; + sunptr->un_id =3D semid; + sunptr->un_num =3D semnum; + sunptr->un_seq =3D semseq; } else - return(EINVAL); - return(0); + return (EINVAL); + return (0); } =20 static void -semundo_clear(semid, semnum) - int semid, semnum; +semundo_clear(int semid, int semnum) { - struct sem_undo *suptr; + struct sem_undo *suptr, *suptr1; + struct undo *sunptr; + int i; =20 SEMUNDO_LOCKASSERT(MA_OWNED); - SLIST_FOREACH(suptr, &semu_list, un_next) { - struct undo *sunptr =3D &suptr->un_ent[0]; - int i =3D 0; - - while (i < suptr->un_cnt) { - if (sunptr->un_id =3D=3D semid) { - if (semnum =3D=3D -1 || sunptr->un_num =3D=3D semnum) { - suptr->un_cnt--; - if (i < suptr->un_cnt) { - suptr->un_ent[i] =3D - suptr->un_ent[suptr->un_cnt]; - continue; - } + LIST_FOREACH_SAFE(suptr, &semu_list, un_next, suptr1) { + sunptr =3D &suptr->un_ent[0]; + for (i =3D 0; i < suptr->un_cnt; i++, sunptr++) { + if (sunptr->un_id !=3D semid) + continue; + if (semnum =3D=3D -1 || sunptr->un_num =3D=3D semnum) { + suptr->un_cnt--; + if (i < suptr->un_cnt) { + suptr->un_ent[i] =3D + suptr->un_ent[suptr->un_cnt]; + continue; } - if (semnum !=3D -1) - break; + semu_try_free(suptr); } - i++, sunptr++; + if (semnum !=3D -1) + break; } } } =20 static int -semvalid(semid, semakptr) - int semid; - struct semid_kernel *semakptr; +semvalid(int semid, struct semid_kernel *semakptr) { =20 return ((semakptr->u.sem_perm.mode & SEM_ALLOC) =3D=3D 0 || @@ -542,9 +511,7 @@ struct __semctl_args { }; #endif int -__semctl(td, uap) - struct thread *td; - struct __semctl_args *uap; +__semctl(struct thread *td, struct __semctl_args *uap) { struct semid_ds dsbuf; union semun arg, semun; @@ -655,6 +622,8 @@ kern_semctl(struct thread *td, int semid, int semnum, i= nt cmd, =20 semakptr =3D &sema[semidx]; sema_mtxp =3D &sema_mtx[semidx]; + if (cmd =3D=3D IPC_RMID) + mtx_lock(&sem_mtx); mtx_lock(sema_mtxp); #ifdef MAC error =3D mac_check_sysv_sem_semctl(cred, semakptr, cmd); @@ -673,22 +642,29 @@ kern_semctl(struct thread *td, int semid, int semnum,= int cmd, goto done2; semakptr->u.sem_perm.cuid =3D cred->cr_uid; semakptr->u.sem_perm.uid =3D cred->cr_uid; - semtot -=3D semakptr->u.sem_nsems; + semakptr->u.sem_perm.mode =3D 0; + SEMUNDO_LOCK(); + semundo_clear(semidx, -1); + SEMUNDO_UNLOCK(); +#ifdef MAC + mac_cleanup_sysv_sem(semakptr); +#endif + wakeup(semakptr); + for (i =3D 0; i < seminfo.semmni; i++) { + if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && + sema[i].u.sem_base > semakptr->u.sem_base) + mtx_lock(&sema_mtx[i]); + } for (i =3D semakptr->u.sem_base - sem; i < semtot; i++) sem[i] =3D sem[i + semakptr->u.sem_nsems]; for (i =3D 0; i < seminfo.semmni; i++) { if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && - sema[i].u.sem_base > semakptr->u.sem_base) + sema[i].u.sem_base > semakptr->u.sem_base) { sema[i].u.sem_base -=3D semakptr->u.sem_nsems; + mtx_unlock(&sema_mtx[i]); + } } - semakptr->u.sem_perm.mode =3D 0; -#ifdef MAC - mac_cleanup_sysv_sem(semakptr); -#endif - SEMUNDO_LOCK(); - semundo_clear(semidx, -1); - SEMUNDO_UNLOCK(); - wakeup(semakptr); + semtot -=3D semakptr->u.sem_nsems; break; =20 case IPC_SET: @@ -855,6 +831,8 @@ kern_semctl(struct thread *td, int semid, int semnum, i= nt cmd, =20 done2: mtx_unlock(sema_mtxp); + if (cmd =3D=3D IPC_RMID) + mtx_unlock(&sem_mtx); if (array !=3D NULL) free(array, M_TEMP); return(error); @@ -868,21 +846,23 @@ struct semget_args { }; #endif int -semget(td, uap) - struct thread *td; - struct semget_args *uap; +semget(struct thread *td, struct semget_args *uap) { int semid, error =3D 0; int key =3D uap->key; int nsems =3D uap->nsems; int semflg =3D uap->semflg; struct ucred *cred =3D td->td_ucred; + register_t ret; +#ifdef MAC + int sem_found; +#endif =20 DPRINTF(("semget(0x%x, %d, 0%o)\n", key, nsems, semflg)); if (!jail_sysvipc_allowed && jailed(td->td_ucred)) return (ENOSYS); =20 - mtx_lock(&Giant); + mtx_lock(&sem_mtx); if (key !=3D IPC_PRIVATE) { for (semid =3D 0; semid < seminfo.semmni; semid++) { if ((sema[semid].u.sem_perm.mode & SEM_ALLOC) && @@ -905,15 +885,12 @@ semget(td, uap) error =3D EEXIST; goto done2; } -#ifdef MAC - error =3D mac_check_sysv_semget(cred, &sema[semid]); - if (error !=3D 0) - goto done2; -#endif + sem_found =3D 1; goto found; } } =20 + sem_found =3D 0; DPRINTF(("need to allocate the semid_kernel\n")); if (key =3D=3D IPC_PRIVATE || (semflg & IPC_CREAT)) { if (nsems <=3D 0 || nsems > seminfo.semmsl) { @@ -955,7 +932,6 @@ semget(td, uap) bzero(sema[semid].u.sem_base, sizeof(sema[semid].u.sem_base[0])*nsems); #ifdef MAC - mac_create_sysv_sem(cred, &sema[semid]); #endif DPRINTF(("sembase =3D %p, next =3D %p\n", sema[semid].u.sem_base, &sem[semtot])); @@ -966,9 +942,19 @@ semget(td, uap) } =20 found: - td->td_retval[0] =3D IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); + ret =3D IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); + mtx_unlock(&sem_mtx); +#ifdef MAC + if (error =3D=3D 0) { + if (sem_found) + error =3D mac_check_sysv_semget(cred, &sema[semid]); + else + mac_create_sysv_sem(cred, &sema[semid]); + } + if (error =3D=3D 0) +#endif + td->td_retval[0] =3D ret; done2: - mtx_unlock(&Giant); return (error); } =20 @@ -980,9 +966,7 @@ struct semop_args { }; #endif int -semop(td, uap) - struct thread *td; - struct semop_args *uap; +semop(struct thread *td, struct semop_args *uap) { #define SMALL_SOPS 8 struct sembuf small_sops[SMALL_SOPS]; @@ -997,6 +981,7 @@ semop(td, uap) size_t i, j, k; int error; int do_wakeup, do_undos; + unsigned short seq; =20 #ifdef SEM_DEBUG sops =3D NULL; @@ -1036,7 +1021,8 @@ semop(td, uap) error =3D EINVAL; goto done2; } - if (semakptr->u.sem_perm.seq !=3D IPCID_TO_SEQ(uap->semid)) { + seq =3D semakptr->u.sem_perm.seq; + if (seq !=3D IPCID_TO_SEQ(uap->semid)) { error =3D EINVAL; goto done2; } @@ -1160,8 +1146,9 @@ semop(td, uap) /* * Make sure that the semaphore still exists */ + seq =3D semakptr->u.sem_perm.seq; if ((semakptr->u.sem_perm.mode & SEM_ALLOC) =3D=3D 0 || - semakptr->u.sem_perm.seq !=3D IPCID_TO_SEQ(uap->semid)) { + seq !=3D IPCID_TO_SEQ(uap->semid)) { error =3D EIDRM; goto done2; } @@ -1213,7 +1200,7 @@ done: adjval =3D sops[i].sem_op; if (adjval =3D=3D 0) continue; - error =3D semundo_adjust(td, &suptr, semid, + error =3D semundo_adjust(td, &suptr, semid, seq, sops[i].sem_num, -adjval); if (error =3D=3D 0) continue; @@ -1234,7 +1221,7 @@ done: adjval =3D sops[k].sem_op; if (adjval =3D=3D 0) continue; - if (semundo_adjust(td, &suptr, semid, + if (semundo_adjust(td, &suptr, semid, seq, sops[k].sem_num, adjval) !=3D 0) panic("semop - can't undo undos"); } @@ -1281,28 +1268,28 @@ done2: * semaphores. */ static void -semexit_myhook(arg, p) - void *arg; - struct proc *p; +semexit_myhook(void *arg, struct proc *p) { struct sem_undo *suptr; - struct sem_undo **supptr; + struct semid_kernel *semakptr; + struct mtx *sema_mtxp; + int semid, semnum, adjval, ix; + unsigned short seq; =20 /* * Go through the chain of undo vectors looking for one * associated with this process. */ SEMUNDO_LOCK(); - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, un_next) { - if (suptr->un_proc =3D=3D p) { - *supptr =3D SLIST_NEXT(suptr, un_next); + LIST_FOREACH(suptr, &semu_list, un_next) { + if (suptr->un_proc =3D=3D p) break; - } } - SEMUNDO_UNLOCK(); - - if (suptr =3D=3D NULL) + if (suptr =3D=3D NULL) { + SEMUNDO_UNLOCK(); return; + } + LIST_REMOVE(suptr, un_next); =20 DPRINTF(("proc @%p has undo structure with %d entries\n", p, suptr->un_cnt)); @@ -1311,21 +1298,21 @@ semexit_myhook(arg, p) * If there are any active undo elements then process them. */ if (suptr->un_cnt > 0) { - int ix; - + SEMUNDO_UNLOCK(); for (ix =3D 0; ix < suptr->un_cnt; ix++) { - int semid =3D suptr->un_ent[ix].un_id; - int semnum =3D suptr->un_ent[ix].un_num; - int adjval =3D suptr->un_ent[ix].un_adjval; - struct semid_kernel *semakptr; - struct mtx *sema_mtxp; - + semid =3D suptr->un_ent[ix].un_id; + semnum =3D suptr->un_ent[ix].un_num; + adjval =3D suptr->un_ent[ix].un_adjval; + seq =3D suptr->un_ent[ix].un_seq; semakptr =3D &sema[semid]; sema_mtxp =3D &sema_mtx[semid]; + mtx_lock(sema_mtxp); - SEMUNDO_LOCK(); - if ((semakptr->u.sem_perm.mode & SEM_ALLOC) =3D=3D 0) - panic("semexit - semid not allocated"); + if ((semakptr->u.sem_perm.mode & SEM_ALLOC) =3D=3D 0 || + (semakptr->u.sem_perm.seq !=3D seq)) { + mtx_unlock(sema_mtxp); + continue; + } if (semnum >=3D semakptr->u.sem_nsems) panic("semexit - semnum out of range"); =20 @@ -1336,29 +1323,26 @@ semexit_myhook(arg, p) suptr->un_ent[ix].un_adjval, semakptr->u.sem_base[semnum].semval)); =20 - if (adjval < 0) { - if (semakptr->u.sem_base[semnum].semval < - -adjval) - semakptr->u.sem_base[semnum].semval =3D 0; - else - semakptr->u.sem_base[semnum].semval +=3D - adjval; - } else + if (adjval < 0 && semakptr->u.sem_base[semnum].semval < + -adjval) + semakptr->u.sem_base[semnum].semval =3D 0; + else semakptr->u.sem_base[semnum].semval +=3D adjval; =20 wakeup(semakptr); DPRINTF(("semexit: back from wakeup\n")); mtx_unlock(sema_mtxp); - SEMUNDO_UNLOCK(); } + SEMUNDO_LOCK(); } =20 /* * Deallocate the undo vector. */ DPRINTF(("removing vector\n")); - SEMUNDO_LOCK(); suptr->un_proc =3D NULL; + suptr->un_cnt =3D 0; + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); SEMUNDO_UNLOCK(); } =20 --173oMW6+eDUtB8Ng Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklqFz4ACgkQC3+MBN1Mb4iPEwCgvwSjiY/ShUPbowsrm8xRLl3g qHwAoJEIpCv93ff7M1cv1rIiyxOc7IAS =w1Ti -----END PGP SIGNATURE----- --173oMW6+eDUtB8Ng-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 16:01:40 2009 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 8A00B1065670 for ; Sun, 11 Jan 2009 16:01:40 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 3BE078FC0C for ; Sun, 11 Jan 2009 16:01:39 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 2888 invoked by uid 2001); 11 Jan 2009 16:01:38 -0000 Date: Sun, 11 Jan 2009 10:01:38 -0600 From: "Rick C. Petty" To: perryh@pluto.rain.com Message-ID: <20090111160138.GA2386@keira.kiwi-computer.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jan 2009 16:01:40 -0000 On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh@pluto.rain.com wrote: > "Rick C. Petty" wrote: > > > > That's not how devfs works. It's actually a feature > > that devfs doesn't list everything ever possible > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg Funny. But this isn't a bug disguised as a feature. It's a feature that you believe is a bug. > > I'd rather be able to list to see things that are in use, although > > at first glance I didn't like devfs hidden nodes. Otherwise you'd > > be stuck printing tunXXX through infinity instead of this: > > > > % ls /dev/tun* > > /dev/tun0 /dev/tun115 /dev/tun194 > > In any other part of the directory tree we expect ls to provide > a list of names that are available to be opened (subject to > permissions). Why should /dev be any different? Because it's a special filesystem. > Since you aren't supposed to open (say) /dev/tun85, but only > /dev/tun0, correspondence between readdir and open would not demand What? Why aren't you supposed to open tun85? I use this behavior all the time and have for years. It helps keep track of things. Otherwise I would have to keep my natd configuration, firewall rules, and openvpn configuration all in sync. Please provide a reference describing you're not "supposed to" open any arbitrary tunnelling device. > that readdir return the (large, if not infinite) list of potential > instances. It would however seem reasonable for that ls command to > show /dev/tun0 if its driver is loaded, even if the device has not > been instantiated because the node has never been opened. I don't buy that argument at all. If anything it should show "/dev/tun", but why create device nodes when they aren't necessary, as you have to clone the nodes (or create new ones) when an actual open(2) occurs? > > This is not a bug, it is designed behavior. It was intentionally > > written to dynamically create device nodes when needed. > > That the code faithfully adheres to the design does not guarantee > that the design is flawless. IMO it violates POLA, if not POSIX, Please provide the reference where it violates POSIX. > for open(2) to succeed when applied to a name which, according to > readdir(2), does not exist; What? This can happen already-- there is no atomicity between a readdir and an open. And what about msdosfs and case-insensitivity? You can certainly open files that weren't a part of your readdir. Also no one in their right mind would be coding a readdir/open solution against a filesystem known to be completely dynamic and especially against devfs. You would want to tie in directly to devctl, sysctl, or syscall. > and it is suboptimal to have "stealth" > drivers whose availability for use cannot be discovered by examining > /dev. Why is it suboptimal? I think you have that backwards-- it's more optimal not to have to create superfluous device nodes when they are not needed, at least from the kernel efficiency perspective. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 19:04:12 2009 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 B4B7E106564A for ; Sun, 11 Jan 2009 19:04:12 +0000 (UTC) (envelope-from omerfsen@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0DD8FC0A for ; Sun, 11 Jan 2009 19:04:11 +0000 (UTC) (envelope-from omerfsen@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so1858360nfh.33 for ; Sun, 11 Jan 2009 11:04:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=ShFoB1dG0iG6Dp2N98xeR/6cbiVLPfE8SDpppKRZACU=; b=UPQUAKlJr8f2anhSrbXkz2j0ShQbvoTM4b03jEdv9xsqNqJHr6Ast4odqQzXHRlG9M ouYQfkaAEOLN8vG2OCKUZZOcHX/D2nM4JlkpEbnufIbgXS3mo3iAZdabj4tRAHuVA3uc UubitN74Ws0xTfsFdpfqqcuEPYqthRuH7N0Es= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=FQyL/J/cqAsHrMtzqJOcMHpclEEEAeP4EFynTD1KE7QxSvA6y16RokieZydojBKWUW 2EFwXzVpithOj/NTLS0Z+QK7heT/hIv8S5cQKYUNR8c2i0r8GTAk77RC1P0dLO61s7BO NfFeNvIZf2vGNKQPzPrisdC69rRflCwdjxIB0= Received: by 10.66.222.6 with SMTP id u6mr793797ugg.19.1231700650382; Sun, 11 Jan 2009 11:04:10 -0800 (PST) Received: by 10.67.99.13 with HTTP; Sun, 11 Jan 2009 11:04:10 -0800 (PST) Message-ID: <75a268720901111104m6297614jae11f5d1ea4f85df@mail.gmail.com> Date: Sun, 11 Jan 2009 21:04:10 +0200 From: "Omer Faruk Sen" To: "Kostik Belousov" In-Reply-To: <20090111155854.GS93900@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 References: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> <20090111155854.GS93900@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: kernel dump with 7.1-RELEASE 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, 11 Jan 2009 19:04:13 -0000 Hi Kostik, I will try that patch and will return to -hackers if that solves semid not allocated problem. Thanks for prompt action. Best Regards. On Sun, Jan 11, 2009 at 5:58 PM, Kostik Belousov wrote: > On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote: > > Hi, > > > > I am having kernel dump with FreeBSD 7.1: > > > > Here is crashinfo output of it (Actually i don't know the state of > > crashinfo in Fbsd 7.1) > > > > 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 > > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > > > > > > panic: semexit - semid not allocated > > > > GNU gdb 6.1.1 [FreeBSD] > > Copyright 2004 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, and you > are > > welcome to change it and/or distribute copies of it under certain > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > details. > > This GDB was configured as "amd64-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > Physical memory: 8173 MB > > Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 > > 214 198 182 166 150 134 118 102 86 70 54 38 22 6 > > > > #0 doadump () at pcpu.h:195 > > 195 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) #0 doadump () at pcpu.h:195 > > #1 0x0000000000000004 in ?? () > > #2 0xffffffff804b4ce9 in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:418 > > #3 0xffffffff804b50f2 in panic (fmt=0x104
) > > at /usr/src/sys/kern/kern_shutdown.c:574 > > #4 0xffffffff804f846d in semexit_myhook (arg=Variable "arg" is not > available. > > ) > > at /usr/src/sys/kern/sysv_sem.c:1328 > > #5 0xffffffff80490dbc in exit1 (td=0xffffff000995f370, rv=0) > > at /usr/src/sys/kern/kern_exit.c:244 > > #6 0xffffffff8049239e in sys_exit (td=Variable "td" is not available. > > ) at /usr/src/sys/kern/kern_exit.c:109 > > #7 0xffffffff8078a7c7 in syscall (frame=0xffffffffb0d4ac80) > > at /usr/src/sys/amd64/amd64/trap.c:907 > > #8 0xffffffff8077088b in Xfast_syscall () > > at /usr/src/sys/amd64/amd64/exception.S:330 > > #9 0x0000000800a2a30c in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > It seems that there are at least two issues with IPC_RMID operation > on SysV semaphores. > 1. The squeeze of the semaphore array in the kern_semctl() modifies > sem_base for the semaphores, as well as the values of the > semaphores, without locking their mutex. This can lead to > (killable) hangs or unexpected behaviour of the processes > performing any sem operations while other process does IPC_RMID. > 2. The semexit_myhook() eventhandler does not lock SEMUNDO_LOCK() > while accessing *suptr. I think that this allows for IPC_RMID > to be performed in parallel with the sem id referenced by the > current undo structure. > > Patch below is the backport of the patch I developed and lightly > tested on CURRENT, that shuffle locking to solve the listed issues. > Testing consisted of running several instances of > tools/regression/sysvsem. > > diff --git a/sys/kern/sysv_sem.c b/sys/kern/sysv_sem.c > index 80d07ba..6bc4cce 100644 > --- a/sys/kern/sysv_sem.c > +++ b/sys/kern/sysv_sem.c > @@ -88,7 +88,7 @@ int semop(struct thread *td, struct semop_args *uap); > > static struct sem_undo *semu_alloc(struct thread *td); > static int semundo_adjust(struct thread *td, struct sem_undo **supptr, > - int semid, int semnum, int adjval); > + int semid, int semseq, int semnum, int adjval); > static void semundo_clear(int semid, int semnum); > > /* XXX casting to (sy_call_t *) is bogus, as usual. */ > @@ -98,15 +98,17 @@ static sy_call_t *semcalls[] = { > }; > > static struct mtx sem_mtx; /* semaphore global lock */ > +static struct mtx sem_undo_mtx; > static int semtot = 0; > static struct semid_kernel *sema; /* semaphore id pool */ > static struct mtx *sema_mtx; /* semaphore id pool mutexes*/ > static struct sem *sem; /* semaphore pool */ > -SLIST_HEAD(, sem_undo) semu_list; /* list of active undo structures > */ > +LIST_HEAD(, sem_undo) semu_list; /* list of active undo structures > */ > +LIST_HEAD(, sem_undo) semu_free_list; /* list of free undo structures */ > static int *semu; /* undo structure pool */ > static eventhandler_tag semexit_tag; > > -#define SEMUNDO_MTX sem_mtx > +#define SEMUNDO_MTX sem_undo_mtx > #define SEMUNDO_LOCK() mtx_lock(&SEMUNDO_MTX); > #define SEMUNDO_UNLOCK() mtx_unlock(&SEMUNDO_MTX); > #define SEMUNDO_LOCKASSERT(how) mtx_assert(&SEMUNDO_MTX, (how)); > @@ -122,13 +124,15 @@ struct sem { > * Undo structure (one per process) > */ > struct sem_undo { > - SLIST_ENTRY(sem_undo) un_next; /* ptr to next active undo > structure */ > + LIST_ENTRY(sem_undo) un_next; /* ptr to next active undo > structure */ > struct proc *un_proc; /* owner of this structure */ > short un_cnt; /* # of active entries */ > struct undo { > short un_adjval; /* adjust on exit values */ > short un_num; /* semaphore # */ > int un_id; /* semid */ > + unsigned short un_seq; > + > } un_ent[1]; /* undo entries */ > }; > > @@ -250,12 +254,15 @@ seminit(void) > } > for (i = 0; i < seminfo.semmni; i++) > mtx_init(&sema_mtx[i], "semid", NULL, MTX_DEF); > + LIST_INIT(&semu_free_list); > for (i = 0; i < seminfo.semmnu; i++) { > struct sem_undo *suptr = SEMU(i); > suptr->un_proc = NULL; > + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); > } > - SLIST_INIT(&semu_list); > + LIST_INIT(&semu_list); > mtx_init(&sem_mtx, "sem", NULL, MTX_DEF); > + mtx_init(&sem_undo_mtx, "semu", NULL, MTX_DEF); > semexit_tag = EVENTHANDLER_REGISTER(process_exit, semexit_myhook, > NULL, > EVENTHANDLER_PRI_ANY); > } > @@ -265,6 +272,7 @@ semunload(void) > { > int i; > > + /* XXXKIB */ > if (semtot != 0) > return (EBUSY); > > @@ -279,6 +287,7 @@ semunload(void) > for (i = 0; i < seminfo.semmni; i++) > mtx_destroy(&sema_mtx[i]); > mtx_destroy(&sem_mtx); > + mtx_destroy(&sem_undo_mtx); > return (0); > } > > @@ -350,69 +359,31 @@ semsys(td, uap) > */ > > static struct sem_undo * > -semu_alloc(td) > - struct thread *td; > +semu_alloc(struct thread *td) > { > - int i; > struct sem_undo *suptr; > - struct sem_undo **supptr; > - int attempt; > > SEMUNDO_LOCKASSERT(MA_OWNED); > - /* > - * Try twice to allocate something. > - * (we'll purge an empty structure after the first pass so > - * two passes are always enough) > - */ > - > - for (attempt = 0; attempt < 2; attempt++) { > - /* > - * Look for a free structure. > - * Fill it in and return it if we find one. > - */ > - > - for (i = 0; i < seminfo.semmnu; i++) { > - suptr = SEMU(i); > - if (suptr->un_proc == NULL) { > - SLIST_INSERT_HEAD(&semu_list, suptr, > un_next); > - suptr->un_cnt = 0; > - suptr->un_proc = td->td_proc; > - return(suptr); > - } > - } > - > - /* > - * We didn't find a free one, if this is the first attempt > - * then try to free a structure. > - */ > + if ((suptr = LIST_FIRST(&semu_free_list)) == NULL) > + return (NULL); > + LIST_REMOVE(suptr, un_next); > + LIST_INSERT_HEAD(&semu_list, suptr, un_next); > + suptr->un_cnt = 0; > + suptr->un_proc = td->td_proc; > + return (suptr); > +} > > - if (attempt == 0) { > - /* All the structures are in use - try to free one > */ > - int did_something = 0; > +static int > +semu_try_free(struct sem_undo *suptr) > +{ > > - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, > - un_next) { > - if (suptr->un_cnt == 0) { > - suptr->un_proc = NULL; > - did_something = 1; > - *supptr = SLIST_NEXT(suptr, > un_next); > - break; > - } > - } > + SEMUNDO_LOCKASSERT(MA_OWNED); > > - /* If we didn't free anything then just give-up */ > - if (!did_something) > - return(NULL); > - } else { > - /* > - * The second pass failed even though we freed > - * something after the first pass! > - * This is IMPOSSIBLE! > - */ > - panic("semu_alloc - second attempt failed"); > - } > - } > - return (NULL); > + if (suptr->un_cnt != 0) > + return (0); > + LIST_REMOVE(suptr, un_next); > + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); > + return (1); > } > > /* > @@ -420,11 +391,8 @@ semu_alloc(td) > */ > > static int > -semundo_adjust(td, supptr, semid, semnum, adjval) > - struct thread *td; > - struct sem_undo **supptr; > - int semid, semnum; > - int adjval; > +semundo_adjust(struct thread *td, struct sem_undo **supptr, int semid, > + int semseq, int semnum, int adjval) > { > struct proc *p = td->td_proc; > struct sem_undo *suptr; > @@ -437,7 +405,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) > > suptr = *supptr; > if (suptr == NULL) { > - SLIST_FOREACH(suptr, &semu_list, un_next) { > + LIST_FOREACH(suptr, &semu_list, un_next) { > if (suptr->un_proc == p) { > *supptr = suptr; > break; > @@ -448,7 +416,7 @@ semundo_adjust(td, supptr, semid, semnum, adjval) > return(0); > suptr = semu_alloc(td); > if (suptr == NULL) > - return(ENOSPC); > + return (ENOSPC); > *supptr = suptr; > } > } > @@ -472,58 +440,59 @@ semundo_adjust(td, supptr, semid, semnum, adjval) > if (i < suptr->un_cnt) > suptr->un_ent[i] = > suptr->un_ent[suptr->un_cnt]; > + if (suptr->un_cnt == 0) > + semu_try_free(suptr); > } > - return(0); > + return (0); > } > > /* Didn't find the right entry - create it */ > if (adjval == 0) > - return(0); > + return (0); > if (adjval > seminfo.semaem || adjval < -seminfo.semaem) > return (ERANGE); > if (suptr->un_cnt != seminfo.semume) { > sunptr = &suptr->un_ent[suptr->un_cnt]; > suptr->un_cnt++; > sunptr->un_adjval = adjval; > - sunptr->un_id = semid; sunptr->un_num = semnum; > + sunptr->un_id = semid; > + sunptr->un_num = semnum; > + sunptr->un_seq = semseq; > } else > - return(EINVAL); > - return(0); > + return (EINVAL); > + return (0); > } > > static void > -semundo_clear(semid, semnum) > - int semid, semnum; > +semundo_clear(int semid, int semnum) > { > - struct sem_undo *suptr; > + struct sem_undo *suptr, *suptr1; > + struct undo *sunptr; > + int i; > > SEMUNDO_LOCKASSERT(MA_OWNED); > - SLIST_FOREACH(suptr, &semu_list, un_next) { > - struct undo *sunptr = &suptr->un_ent[0]; > - int i = 0; > - > - while (i < suptr->un_cnt) { > - if (sunptr->un_id == semid) { > - if (semnum == -1 || sunptr->un_num == > semnum) { > - suptr->un_cnt--; > - if (i < suptr->un_cnt) { > - suptr->un_ent[i] = > - > suptr->un_ent[suptr->un_cnt]; > - continue; > - } > + LIST_FOREACH_SAFE(suptr, &semu_list, un_next, suptr1) { > + sunptr = &suptr->un_ent[0]; > + for (i = 0; i < suptr->un_cnt; i++, sunptr++) { > + if (sunptr->un_id != semid) > + continue; > + if (semnum == -1 || sunptr->un_num == semnum) { > + suptr->un_cnt--; > + if (i < suptr->un_cnt) { > + suptr->un_ent[i] = > + suptr->un_ent[suptr->un_cnt]; > + continue; > } > - if (semnum != -1) > - break; > + semu_try_free(suptr); > } > - i++, sunptr++; > + if (semnum != -1) > + break; > } > } > } > > static int > -semvalid(semid, semakptr) > - int semid; > - struct semid_kernel *semakptr; > +semvalid(int semid, struct semid_kernel *semakptr) > { > > return ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || > @@ -542,9 +511,7 @@ struct __semctl_args { > }; > #endif > int > -__semctl(td, uap) > - struct thread *td; > - struct __semctl_args *uap; > +__semctl(struct thread *td, struct __semctl_args *uap) > { > struct semid_ds dsbuf; > union semun arg, semun; > @@ -655,6 +622,8 @@ kern_semctl(struct thread *td, int semid, int semnum, > int cmd, > > semakptr = &sema[semidx]; > sema_mtxp = &sema_mtx[semidx]; > + if (cmd == IPC_RMID) > + mtx_lock(&sem_mtx); > mtx_lock(sema_mtxp); > #ifdef MAC > error = mac_check_sysv_sem_semctl(cred, semakptr, cmd); > @@ -673,22 +642,29 @@ kern_semctl(struct thread *td, int semid, int semnum, > int cmd, > goto done2; > semakptr->u.sem_perm.cuid = cred->cr_uid; > semakptr->u.sem_perm.uid = cred->cr_uid; > - semtot -= semakptr->u.sem_nsems; > + semakptr->u.sem_perm.mode = 0; > + SEMUNDO_LOCK(); > + semundo_clear(semidx, -1); > + SEMUNDO_UNLOCK(); > +#ifdef MAC > + mac_cleanup_sysv_sem(semakptr); > +#endif > + wakeup(semakptr); > + for (i = 0; i < seminfo.semmni; i++) { > + if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && > + sema[i].u.sem_base > semakptr->u.sem_base) > + mtx_lock(&sema_mtx[i]); > + } > for (i = semakptr->u.sem_base - sem; i < semtot; i++) > sem[i] = sem[i + semakptr->u.sem_nsems]; > for (i = 0; i < seminfo.semmni; i++) { > if ((sema[i].u.sem_perm.mode & SEM_ALLOC) && > - sema[i].u.sem_base > semakptr->u.sem_base) > + sema[i].u.sem_base > semakptr->u.sem_base) { > sema[i].u.sem_base -= semakptr->u.sem_nsems; > + mtx_unlock(&sema_mtx[i]); > + } > } > - semakptr->u.sem_perm.mode = 0; > -#ifdef MAC > - mac_cleanup_sysv_sem(semakptr); > -#endif > - SEMUNDO_LOCK(); > - semundo_clear(semidx, -1); > - SEMUNDO_UNLOCK(); > - wakeup(semakptr); > + semtot -= semakptr->u.sem_nsems; > break; > > case IPC_SET: > @@ -855,6 +831,8 @@ kern_semctl(struct thread *td, int semid, int semnum, > int cmd, > > done2: > mtx_unlock(sema_mtxp); > + if (cmd == IPC_RMID) > + mtx_unlock(&sem_mtx); > if (array != NULL) > free(array, M_TEMP); > return(error); > @@ -868,21 +846,23 @@ struct semget_args { > }; > #endif > int > -semget(td, uap) > - struct thread *td; > - struct semget_args *uap; > +semget(struct thread *td, struct semget_args *uap) > { > int semid, error = 0; > int key = uap->key; > int nsems = uap->nsems; > int semflg = uap->semflg; > struct ucred *cred = td->td_ucred; > + register_t ret; > +#ifdef MAC > + int sem_found; > +#endif > > DPRINTF(("semget(0x%x, %d, 0%o)\n", key, nsems, semflg)); > if (!jail_sysvipc_allowed && jailed(td->td_ucred)) > return (ENOSYS); > > - mtx_lock(&Giant); > + mtx_lock(&sem_mtx); > if (key != IPC_PRIVATE) { > for (semid = 0; semid < seminfo.semmni; semid++) { > if ((sema[semid].u.sem_perm.mode & SEM_ALLOC) && > @@ -905,15 +885,12 @@ semget(td, uap) > error = EEXIST; > goto done2; > } > -#ifdef MAC > - error = mac_check_sysv_semget(cred, &sema[semid]); > - if (error != 0) > - goto done2; > -#endif > + sem_found = 1; > goto found; > } > } > > + sem_found = 0; > DPRINTF(("need to allocate the semid_kernel\n")); > if (key == IPC_PRIVATE || (semflg & IPC_CREAT)) { > if (nsems <= 0 || nsems > seminfo.semmsl) { > @@ -955,7 +932,6 @@ semget(td, uap) > bzero(sema[semid].u.sem_base, > sizeof(sema[semid].u.sem_base[0])*nsems); > #ifdef MAC > - mac_create_sysv_sem(cred, &sema[semid]); > #endif > DPRINTF(("sembase = %p, next = %p\n", > sema[semid].u.sem_base, &sem[semtot])); > @@ -966,9 +942,19 @@ semget(td, uap) > } > > found: > - td->td_retval[0] = IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); > + ret = IXSEQ_TO_IPCID(semid, sema[semid].u.sem_perm); > + mtx_unlock(&sem_mtx); > +#ifdef MAC > + if (error == 0) { > + if (sem_found) > + error = mac_check_sysv_semget(cred, &sema[semid]); > + else > + mac_create_sysv_sem(cred, &sema[semid]); > + } > + if (error == 0) > +#endif > + td->td_retval[0] = ret; > done2: > - mtx_unlock(&Giant); > return (error); > } > > @@ -980,9 +966,7 @@ struct semop_args { > }; > #endif > int > -semop(td, uap) > - struct thread *td; > - struct semop_args *uap; > +semop(struct thread *td, struct semop_args *uap) > { > #define SMALL_SOPS 8 > struct sembuf small_sops[SMALL_SOPS]; > @@ -997,6 +981,7 @@ semop(td, uap) > size_t i, j, k; > int error; > int do_wakeup, do_undos; > + unsigned short seq; > > #ifdef SEM_DEBUG > sops = NULL; > @@ -1036,7 +1021,8 @@ semop(td, uap) > error = EINVAL; > goto done2; > } > - if (semakptr->u.sem_perm.seq != IPCID_TO_SEQ(uap->semid)) { > + seq = semakptr->u.sem_perm.seq; > + if (seq != IPCID_TO_SEQ(uap->semid)) { > error = EINVAL; > goto done2; > } > @@ -1160,8 +1146,9 @@ semop(td, uap) > /* > * Make sure that the semaphore still exists > */ > + seq = semakptr->u.sem_perm.seq; > if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || > - semakptr->u.sem_perm.seq != IPCID_TO_SEQ(uap->semid)) { > + seq != IPCID_TO_SEQ(uap->semid)) { > error = EIDRM; > goto done2; > } > @@ -1213,7 +1200,7 @@ done: > adjval = sops[i].sem_op; > if (adjval == 0) > continue; > - error = semundo_adjust(td, &suptr, semid, > + error = semundo_adjust(td, &suptr, semid, seq, > sops[i].sem_num, -adjval); > if (error == 0) > continue; > @@ -1234,7 +1221,7 @@ done: > adjval = sops[k].sem_op; > if (adjval == 0) > continue; > - if (semundo_adjust(td, &suptr, semid, > + if (semundo_adjust(td, &suptr, semid, seq, > sops[k].sem_num, adjval) != 0) > panic("semop - can't undo undos"); > } > @@ -1281,28 +1268,28 @@ done2: > * semaphores. > */ > static void > -semexit_myhook(arg, p) > - void *arg; > - struct proc *p; > +semexit_myhook(void *arg, struct proc *p) > { > struct sem_undo *suptr; > - struct sem_undo **supptr; > + struct semid_kernel *semakptr; > + struct mtx *sema_mtxp; > + int semid, semnum, adjval, ix; > + unsigned short seq; > > /* > * Go through the chain of undo vectors looking for one > * associated with this process. > */ > SEMUNDO_LOCK(); > - SLIST_FOREACH_PREVPTR(suptr, supptr, &semu_list, un_next) { > - if (suptr->un_proc == p) { > - *supptr = SLIST_NEXT(suptr, un_next); > + LIST_FOREACH(suptr, &semu_list, un_next) { > + if (suptr->un_proc == p) > break; > - } > } > - SEMUNDO_UNLOCK(); > - > - if (suptr == NULL) > + if (suptr == NULL) { > + SEMUNDO_UNLOCK(); > return; > + } > + LIST_REMOVE(suptr, un_next); > > DPRINTF(("proc @%p has undo structure with %d entries\n", p, > suptr->un_cnt)); > @@ -1311,21 +1298,21 @@ semexit_myhook(arg, p) > * If there are any active undo elements then process them. > */ > if (suptr->un_cnt > 0) { > - int ix; > - > + SEMUNDO_UNLOCK(); > for (ix = 0; ix < suptr->un_cnt; ix++) { > - int semid = suptr->un_ent[ix].un_id; > - int semnum = suptr->un_ent[ix].un_num; > - int adjval = suptr->un_ent[ix].un_adjval; > - struct semid_kernel *semakptr; > - struct mtx *sema_mtxp; > - > + semid = suptr->un_ent[ix].un_id; > + semnum = suptr->un_ent[ix].un_num; > + adjval = suptr->un_ent[ix].un_adjval; > + seq = suptr->un_ent[ix].un_seq; > semakptr = &sema[semid]; > sema_mtxp = &sema_mtx[semid]; > + > mtx_lock(sema_mtxp); > - SEMUNDO_LOCK(); > - if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0) > - panic("semexit - semid not allocated"); > + if ((semakptr->u.sem_perm.mode & SEM_ALLOC) == 0 || > + (semakptr->u.sem_perm.seq != seq)) { > + mtx_unlock(sema_mtxp); > + continue; > + } > if (semnum >= semakptr->u.sem_nsems) > panic("semexit - semnum out of range"); > > @@ -1336,29 +1323,26 @@ semexit_myhook(arg, p) > suptr->un_ent[ix].un_adjval, > semakptr->u.sem_base[semnum].semval)); > > - if (adjval < 0) { > - if (semakptr->u.sem_base[semnum].semval < > - -adjval) > - semakptr->u.sem_base[semnum].semval > = 0; > - else > - semakptr->u.sem_base[semnum].semval > += > - adjval; > - } else > + if (adjval < 0 && > semakptr->u.sem_base[semnum].semval < > + -adjval) > + semakptr->u.sem_base[semnum].semval = 0; > + else > semakptr->u.sem_base[semnum].semval += > adjval; > > wakeup(semakptr); > DPRINTF(("semexit: back from wakeup\n")); > mtx_unlock(sema_mtxp); > - SEMUNDO_UNLOCK(); > } > + SEMUNDO_LOCK(); > } > > /* > * Deallocate the undo vector. > */ > DPRINTF(("removing vector\n")); > - SEMUNDO_LOCK(); > suptr->un_proc = NULL; > + suptr->un_cnt = 0; > + LIST_INSERT_HEAD(&semu_free_list, suptr, un_next); > SEMUNDO_UNLOCK(); > } > > From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 23:10:52 2009 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 0B82D1065670 for ; Sun, 11 Jan 2009 23:10:52 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by mx1.freebsd.org (Postfix) with ESMTP id BFEB08FC1A for ; Sun, 11 Jan 2009 23:10:51 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n0BM4UEF003380; Sun, 11 Jan 2009 17:04:30 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20090109015106.3614a378@mbook.local> References: <20090107125759.GA1462@roadrunner.spoerlein.net> <20090107154854.GC1462@roadrunner.spoerlein.net> <20090109015106.3614a378@mbook.local> Date: Sun, 11 Jan 2009 17:04:29 -0500 To: Mike Meyer , "Sheldon Givens" From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 20.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227 Cc: freebsd-hackers@FreeBSD.org Subject: Re: Small change to 'ps' 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, 11 Jan 2009 23:10:52 -0000 At 1:51 AM -0500 1/9/09, Mike Meyer wrote: >On Wed, 7 Jan 2009 "Sheldon Givens" wrote: > > And I guess I just feel like running a second command to do what should be >> possible to do with the first command (and is, on many platforms. ps >> --no-headers on linux for example) is a problem and presents opportunity for >> continued refinement of the utility. > >I agree. However, [...] > >So `--no-headers' is ok. However, `-n' has lots of different meanings >in different commands. How about borrowing from existing commands that >already implement this functionality (zfs and zpool) and using `-H', >which is relatively rarely used elsewhere? I recommend against adding any single-letter option to the `ps' command. This command is already an absolute minefield of headaches when it comes to portability across operating systems (and POSIX). Trying to sneak in some single-letter option is bound to give us headaches in the long run. Adding something like '--no-headers' is pretty safe, although that opens up a different set of arguments (heh) when it comes to `ps' on freebsd. Namely, we don't have any long-options in our `ps'. Yet another tactic might be to add another accepted keyword to '-o', since it already uses words as its acceptable values. We'd be bending the definition of `-o' a bit to do that, but we could at least do that in a way which would be very unlikely to conflict with an option in any other version of `ps'. -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 11 23:37:08 2009 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 D1C731065674 for ; Sun, 11 Jan 2009 23:37:08 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 3EB778FC37 for ; Sun, 11 Jan 2009 23:37:08 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 11 Jan 2009 23:37:06 -0000 Received: from p54A3FBCD.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.251.205] by mail.gmx.net (mp015) with SMTP; 12 Jan 2009 00:37:06 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19blDYXaXxbkEc9hDooXPeQEDEPIAeV3KBhyB5JcN c2CDG5pEL8yOfz Message-ID: <496A82A2.9010509@gmx.de> Date: Mon, 12 Jan 2009 00:37:06 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: uwe@grohnwaldt.eu, miwi@freebsd.org Subject: Question about panic in brelse() 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, 11 Jan 2009 23:37:09 -0000 Hi, I observe a failed assertion in the VFS regarding a buffer. I investigated a bit and now I want to present my findings and I have a question: Assume I have a buffer with b_iocmd = BIO_WRITE b_ioflags = BIO_ERROR b_error = EIO b_flags = B_NOCACHE passed to brelse() in kern/vfs_bio.c[0]. - This particular combination of values (line 1144) causes BIO_ERROR to be cleared (line 1152) and B_DELWRI is set in bdirty() (line 1031, called in line 1153). - Because of B_NOCACHE (line 1343) this buffer gets moved to QUEUE_CLEAN (line 1349). Also B_INVAL gets set here (line 1345). - A few lines down (line 1375) bundirty() gets called because of B_INVAL and B_DELWRI. - bundirty() instantly panics because the buffer is not in QUEUE_NONE (line 1075). My question is: Is this a bug in brelse() or was the combination of flag B_NOCACHE with a failed write attempt (BIO_WRITE, BIO_ERROR, EIO) invalid when the buffer was passed to brelse()? Below is a dump of the buffer right when the assertion is triggered. If you want any further information about this issue, please tell me. Hopefully somebody can shed some light on this Christoph { b_bufobj = 0xffffff0030005e00, b_bcount = 16384, b_caller1 = 0x0, b_data = 0xfffffffea2c57000 "", b_error = 5, (EIO) b_iocmd = 2 '\002', (BIO_WRITE) b_ioflags = 2 '\002', (BIO_DONE) b_iooffset = 98304, b_resid = 16384, b_iodone = 0, b_blkno = 192, b_offset = 98304, b_bobufs = { tqe_next = 0x0, tqe_prev = 0xffffff0030005e40}, b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = { tqe_next = 0xfffffffe92d747c8, tqe_prev = 0xffffffff80d340f0 }, b_qindex = 1, (QUEUE_CLEAN) b_flags = 41092, (B_NOCACHE | b_INVAL | B_DELWRI | B_ASYNC) b_xflags = 33 '!', b_lock = { lock_object = { lo_name = 0xffffffff808d01b6 "bufwait", lo_flags = 91947008, lo_data = 0, lo_witness = 0xfffffffe40206180 }, lk_lock = 18446744073709551608, lk_timo = 0, lk_pri = 80 }, b_bufsize = 16384, b_runningbufspace = 0, b_kvabase = 0xfffffffea2c57000 "", b_kvasize = 16384, b_lblkno = 192, b_vp = 0xffffff0030005ce8, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xfffffffea2c57000, b_pager = {pg_reqpage = 0}, b_cluster = { cluster_head = { tqh_first = 0xfffffffe92d747c8, tqh_last = 0xfffffffe92d73ad0 }, cluster_entry = { tqe_next = 0xfffffffe92d747c8, tqe_prev = 0xfffffffe92d73ad0 } }, b_pages = { 0xffffff00de3ce5a0, 0xffffff00de3ce610, 0xffffff00de3ce680, 0xffffff00de3ce6f0, $0x0 }, b_npages = 4, b_dep = { lh_first = 0x0 }, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0 } [0] r183754 in head/, which is the latest version of kern/vfs_bio.c. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 02:12:40 2009 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 29782106566B for ; Mon, 12 Jan 2009 02:12:40 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id DED7D8FC17 for ; Mon, 12 Jan 2009 02:12:39 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0C2CdC1008377; Sun, 11 Jan 2009 18:12:39 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <496AA714.1090904@freebsd.org> Date: Sun, 11 Jan 2009 18:12:36 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pluknet References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: extattr problems? 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, 12 Jan 2009 02:12:40 -0000 pluknet wrote: > > It's strange.. > FreeBSD jaw.ripn.net 6.3-RELEASE-p5. > works for me (tm), extattr_set_fd() returns 4 as expected. Thank you! *That* was my mistake; I thought extattr_set_fd() returned 0 on success, non-zero on error. I re-read the man page and now everything makes sense. Thank you again! Tim From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 03:48:45 2009 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 540371065691; Mon, 12 Jan 2009 03:48:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 29CEC8FC1F; Mon, 12 Jan 2009 03:48:45 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0C3miC1008840; Sun, 11 Jan 2009 19:48:44 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <496ABD9A.8080006@freebsd.org> Date: Sun, 11 Jan 2009 19:48:42 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Kientzle References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> <496AA714.1090904@freebsd.org> In-Reply-To: <496AA714.1090904@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, pluknet Subject: Re: extattr problems? 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, 12 Jan 2009 03:48:45 -0000 I think this one is a bug. It appears that extattr_set_fd() obeys the permissions on the file, not the permissions of the descriptor. In particular, I see this on FreeBSD 6.3: [tim@dark /tmp]$ ./extattr_test fd=3 extattr_set_fd() = -1 errno = 13 (Permission denied) [tim@dark /tmp]$ cat extattr_test.c #include #include #include #include #include int main(int argc, char **argv) { int n, fd; fd = open("/tmp/test12345", O_RDWR | O_CREAT | O_EXCL, 0000); printf("fd=%d\n", fd); n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, "testattr", "1234", 4); printf("extattr_set_fd() = %d\n", n); if (n != 0) printf("errno = %d (%s)\n", errno, strerror(errno)); exit(0); } From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 05:24:56 2009 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 46B621065670 for ; Mon, 12 Jan 2009 05:24:56 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id 176A58FC19 for ; Mon, 12 Jan 2009 05:24:55 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n0C5Orqn038014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 11 Jan 2009 21:24:55 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n0C5OrWk038013; Sun, 11 Jan 2009 21:24:53 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA06962; Sun, 11 Jan 09 21:12:45 PST Date: Sun, 11 Jan 2009 21:14:53 -0800 From: perryh@pluto.rain.com To: rick-freebsd2008@kiwi-computer.com Message-Id: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090111160138.GA2386@keira.kiwi-computer.com> In-Reply-To: <20090111160138.GA2386@keira.kiwi-computer.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present 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, 12 Jan 2009 05:24:56 -0000 "Rick C. Petty" wrote: > On Sat, Jan 10, 2009 at 04:20:58AM -0800, perryh@pluto.rain.com wrote: > > "Rick C. Petty" wrote: > > > > > > That's not how devfs works. It's actually a feature > > > that devfs doesn't list everything ever possible > > > > http://storage9.myopera.com/freejerk/files/bug-feature.jpg > > Funny. But this isn't a bug disguised as a feature. > It's a feature that you believe is a bug. I would call it a bug that you believe is a feature. > > > I'd rather be able to list to see things that are in use, > > > although at first glance I didn't like devfs hidden nodes. > > > Otherwise you'd be stuck printing tunXXX through infinity > > > instead of this: > > > > > > % ls /dev/tun* > > > /dev/tun0 /dev/tun115 /dev/tun194 > > > > In any other part of the directory tree we expect ls to provide > > a list of names that are available to be opened (subject to > > permissions). Why should /dev be any different? > > Because it's a special filesystem. I think that constitutes an admission that it violates POLA, and it's not much of a justification IMO. > > Since you aren't supposed to open (say) /dev/tun85, but only > > /dev/tun0, correspondence between readdir and open would not > > demand > > What? Why aren't you supposed to open tun85? I use this behavior > all the time and have for years. It helps keep track of things. > Otherwise I would have to keep my natd configuration, firewall > rules, and openvpn configuration all in sync. Please provide a > reference describing you're not "supposed to" open any arbitrary > tunnelling device. The manpage for tun(4) says: tun does for network interfaces what the pty(4) driver does for terminals ... The network interfaces are named ``tun0'', ``tun1'', etc., one for each control device that has been opened ... The tun interface permits opens on the special control device /dev/tun. When this device is opened, tun will return a handle for the **lowest** unused tun device ... (emphasis added). The whole point of cloning devices is to avoid the need for the application to loop through a sequence of possible names to find one that is not in use; it simply opens the generic name and gets a (pseudo) device. BTW I was slightly off -- it is /dev/tun rather than /dev/tun0 that's supposed to be opened -- but if anything this strengthens my point (see below). > > that readdir return the (large, if not infinite) list of > > potential instances. It would however seem reasonable for > > that ls command to show /dev/tun0 if its driver is loaded, > > even if the device has not been instantiated because the > > node has never been opened. > > I don't buy that argument at all. If anything it should show > "/dev/tun", Agreed it should be /dev/tun -- see above. > but why create device nodes when they aren't necessary, as you > have to clone the nodes (or create new ones) when an actual > open(2) occurs? As I stated earlier in this thread: * It doesn't necessarily need to actually create them, but the * results from readdir(2) should be as if they had been created. > > > This is not a bug, it is designed behavior. It was > > > intentionally written to dynamically create device > > > nodes when needed. > > > > That the code faithfully adheres to the design does not > > guarantee that the design is flawless. IMO it violates > > POLA, if not POSIX, > > Please provide the reference where it violates POSIX. I am not familiar with POSIX in detail, which is why I only suggest that it *may* violate POSIX. You're welcome to research the matter. I would *expect* that research to find that there is supposed to be a correspondence between what readdir reports as the contents of a directory, and the results of attempting to open a filename in the directory whose contents were read; if not, what would be the point of having readdir in the first place? > > for open(2) to succeed when applied to a name which, according > > to readdir(2), does not exist; > > What? This can happen already-- there is no atomicity between > a readdir and an open. Of course not, but we are not dealing here with a case in which process A reads the directory, then process B creates a file in it, and thus that file becomes visible to process A. Instead we have a magical side-effect, wherein process A opens a file which (per readdir) does not exist, and thereby calls into existence a new file, while the name that process A opened *still* does not exist. > And what about msdosfs and case-insensitivity? You can > certainly open files that weren't a part of your readdir. The semantics of msdosfs are driven by the need to maintain compatibility with a certain other operating system -- the one which defined that filesystem representation in the first place. I hardly think it should be considered a good precedent. > Also no one in their right mind would be coding a readdir/open > solution against a filesystem known to be completely dynamic and > especially against devfs. You would want to tie in directly to > devctl, sysctl, or syscall. Programmatically, yes. But long-standing historical precedent, going back at least as far as the AT&T sixth research edition, would have an administrator or knowledgeable user believe that the contents of /dev are related to the collection of drivers that the system supports. The aspect of devfs that prevents the existence of orphan nodes in /dev is an excellent improvement which strengthens that precedent -- now I can find out from /dev not merely that the system supports a particular device in principle but also whether it actually has that device attached. Why would we want to trash that concept by allowing the existence of phantom drivers, which have no presence in /dev unless/until they have been opened? > > and it is suboptimal to have "stealth" drivers whose > > availability for use cannot be discovered by examining /dev. > > Why is it suboptimal? As in the case of the OP, it is suboptimal from the standpoint of a human who wants to know what devices and drivers exist in the system -- AFAIK the output of ls(1) is intended primarily for human consumption. Of course, for ls(1) to do its job, readdir(2) has to provide the data. > I think you have that backwards-- it's more optimal not to have to > create superfluous device nodes when they are not needed, at least > from the kernel efficiency perspective. If /dev/tun does not exist, how does an open on it succeed? Either there is special-case code that somehow scans the list of installed drivers in addition to examining the contents of /dev, or the node actually exists but readdir avoids reporting its existence. Either way, the kernel is having to do extra work to maintain the disagreement between the contents of the directory as reported by readdir and the list of names that are known to open. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 08:02:28 2009 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 76702106566B for ; Mon, 12 Jan 2009 08:02:28 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 1470A8FC0A for ; Mon, 12 Jan 2009 08:02:27 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 9006 invoked by uid 2001); 12 Jan 2009 08:02:27 -0000 Date: Mon, 12 Jan 2009 02:02:27 -0600 From: "Rick C. Petty" To: perryh@pluto.rain.com Message-ID: <20090112080227.GA8590@keira.kiwi-computer.com> References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090111160138.GA2386@keira.kiwi-computer.com> <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 08:02:28 -0000 On Sun, Jan 11, 2009 at 09:14:53PM -0800, perryh@pluto.rain.com wrote: > > > Funny. But this isn't a bug disguised as a feature. > > It's a feature that you believe is a bug. > > I would call it a bug that you believe is a feature. Not just me, but freebsd developers including those who wrote devfs. > > > In any other part of the directory tree we expect ls to provide > > > a list of names that are available to be opened (subject to > > > permissions). Why should /dev be any different? > > > > Because it's a special filesystem. > > I think that constitutes an admission that it violates POLA, > and it's not much of a justification IMO. Only you and a small group of people seem to be astonished by this, something that's been in FreeBSD since 4.0. Glad you're voicing your opinion now, before it's too late. > The manpage for tun(4) says: > > tun does for network interfaces what the pty(4) driver does for > terminals ... The network interfaces are named ``tun0'', ``tun1'', > etc., one for each control device that has been opened ... The tun > interface permits opens on the special control device /dev/tun. > When this device is opened, tun will return a handle for the > **lowest** unused tun device ... > > (emphasis added). The whole point of cloning devices is to avoid > the need for the application to loop through a sequence of possible > names to find one that is not in use; it simply opens the generic > name and gets a (pseudo) device. Yes, when using /dev/tun, you get the lowest. That's expected behavior. But it doesn't say not to use your own numbering. I'll stand by my previous statements. > > but why create device nodes when they aren't necessary, as you > > have to clone the nodes (or create new ones) when an actual > > open(2) occurs? > > As I stated earlier in this thread: > > * It doesn't necessarily need to actually create them, but the > * results from readdir(2) should be as if they had been created. I think you may find this is not as trivial as you make it sound. > > Please provide the reference where it violates POSIX. > > I am not familiar with POSIX in detail, which is why I only suggest > that it *may* violate POSIX. That much is obvious. > You're welcome to research the matter. No thanks, I've read it back to front. But you seem to imply that you're the expert, so I was hoping for you to point out how I've misread it. > I would *expect* that research to find that there is supposed to be > a correspondence between what readdir reports as the contents of a > directory, and the results of attempting to open a filename in the > directory whose contents were read; if not, what would be the point > of having readdir in the first place? Good point. We should probably rewrite syscalls to use vnode references instead of names. That would solve all ambiguity problems as well. > Of course not, but we are not dealing here with a case in which > process A reads the directory, then process B creates a file in > it, and thus that file becomes visible to process A. Instead we > have a magical side-effect, wherein process A opens a file which > (per readdir) does not exist, and thereby calls into existence a > new file, while the name that process A opened *still* does not > exist. There is nothing magical about it, nor did this just happen overnight. Perhaps it's not well-documented but it is well-known. > > And what about msdosfs and case-insensitivity? You can > > certainly open files that weren't a part of your readdir. > > The semantics of msdosfs are driven by the need to maintain > compatibility with a certain other operating system -- the one > which defined that filesystem representation in the first place. Just like devfs, which defined the filesystem representation that there are invisible nodes and pseudo-nodes. > I hardly think it should be considered a good precedent. Obviously kernel developers disagreed with you. > > Also no one in their right mind would be coding a readdir/open > > solution against a filesystem known to be completely dynamic and > > especially against devfs. You would want to tie in directly to > > devctl, sysctl, or syscall. > > Programmatically, yes. But long-standing historical precedent, > going back at least as far as the AT&T sixth research edition, > would have an administrator or knowledgeable user believe that the > contents of /dev are related to the collection of drivers that the > system supports. So we should go back to the precedent and make all dev entries static once again? You can't argue for progress in the same case that you argue for precedence. > actually has that device attached. Why would we want to trash that > concept by allowing the existence of phantom drivers, which have no > presence in /dev unless/until they have been opened? The drivers aren't phantom-- their instances are. > > Why is it suboptimal? > > As in the case of the OP, it is suboptimal from the standpoint of > a human who wants to know what devices and drivers exist in the > system You mean a human who does not understand enough about devfs to know its design quirks? This same human who does not care to look in /var/run/dmesg.boot? This same human who expects FreeBSD to behave as any other OS when it comes to device drivers and doesn't know to check /dev/sndstat? That's not what I think about when I hear the word "suboptimal". I think you're trying to argue that certain devfs semantics are confusing to beginners. I would call that perhaps "confusing" or perhaps "misleading" (which is a stretch). > -- AFAIK the output of ls(1) is intended primarily for human > consumption. Of course, for ls(1) to do its job, readdir(2) has to > provide the data. ls(1) is doing its job. Perhaps your argument for having one non-phantom device node appear for each driver is useful, but don't discount the utility and flexibility of phantom nodes in other cases. I agree that better documentation would also help. So I look forward to your patches for either of these areas. > > I think you have that backwards-- it's more optimal not to have to > > create superfluous device nodes when they are not needed, at least > > from the kernel efficiency perspective. > > If /dev/tun does not exist, how does an open on it succeed? Who says it doesn't exist? The open succeeds so it apparently does exist. In unix, there's never been a guarantee that after you readdir that an open will succeed, nor that a subsequent readdir will show the file you've opened. > Either there is special-case code that somehow scans the list of > installed drivers in addition to examining the contents of /dev, or > the node actually exists but readdir avoids reporting its existence. I don't think you understand how devices work (specifically, pseudo devices). You may wish to look at make_dev(9) and maybe source code for a device driver. > Either way, the kernel is having to do extra work to maintain the > disagreement between the contents of the directory as reported by > readdir and the list of names that are known to open. No, I believe it's less work this way, but I'm no expert here. I did not design devfs nor did I like it myself initially, but after time I grew to prefer it and its behavior. This issue about invisible device nodes has come up numerous times in the past and I believe its proponents and opponents have argued it to death which is why no one else is speaking up now. I encourage you to submit patches. Either you will find it more difficult your way or you may have a difficult time convincing others of its necessity. Just disagreeing with me will not change anything. -- Rick C. Petty From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 10:25:13 2009 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 BE22E106566C for ; Mon, 12 Jan 2009 10:25:13 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9151E8FC18 for ; Mon, 12 Jan 2009 10:25:13 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-20-240-125.phil.east.verizon.net [70.20.240.125]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 83F905FEC1; Mon, 12 Jan 2009 19:07:11 +0900 (JST) Date: Mon, 12 Jan 2009 05:05:37 -0500 From: Yoshihiro Ota To: Peter Jeremy Message-Id: <20090112050537.f423215c.ota@j.email.ne.jp> In-Reply-To: <20090111041710.GB5661@server.vk2pj.dyndns.org> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: hackers@freebsd.org Subject: Re: 3x read to write ratio on dump/restore 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, 12 Jan 2009 10:25:14 -0000 Jermey, I tought you wrote this, http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.html. Try GEOM Cache(gcache). It will be like, $ gcache create temp -s /dev/XXYsZ $ dump /dev/cache/temp <...> It's been 9 months since I tested so I don't remember about the detail numbers. However, I think it reduced user-time with dump to a half. I only wish gcache creates devices with .cache suffix like /dev/XXYsZ.cache. The cache cannot be shared among other providers anyway, it looks suffix style is more appropriate. Regards, Hiro On Sun, 11 Jan 2009 15:17:10 +1100 Peter Jeremy wrote: > On 2009-Jan-09 09:50:27 -0700, "M. Warner Losh" wrote: > >The read kBps was 3x the write kBps. > ... > >Any ideas what gives? I observed this with 16MB cache and with 32MB > >cache, fwiw. > > I've seen this as well. AFAIK, this is a side-effect of dump's caching. > > My top-of-head explanation is that each dump process has its own cache > but actual I/O is round-robined on a (roughly) block scale so a large > contiguous file will wind up in each 'slave' process's cache. > > The most obvious (and easiest) fixes are to either implement a shared > cache (though this means another level of inter-process communication) > or only use a single 'slave' process when caching is enabled. > > The cache algorithm could probably be enhanced as well - apart from > inode blocks, any block will only be accessed once so once a block has > been accessed, it can be purged from the cache (which is completely > opposite to a "normal" cache). > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 11:07:54 2009 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 C1B941065780 for ; Mon, 12 Jan 2009 11:07:54 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 0E1588FC1D for ; Mon, 12 Jan 2009 11:07:53 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 12 Jan 2009 10:41:12 -0000 Received: from p54A3E57E.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.229.126] by mail.gmx.net (mp060) with SMTP; 12 Jan 2009 11:41:12 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18lS2oYx3AlA0JaqzgjW2x/eN2RmYsGA649zszJKN VgmEjxqx68SW5P Message-ID: <496B1E47.1030403@gmx.de> Date: Mon, 12 Jan 2009 11:41:11 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Yoshihiro Ota References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> In-Reply-To: <20090112050537.f423215c.ota@j.email.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.75 Cc: hackers@freebsd.org Subject: gcache [was: Re: 3x read to write ratio on dump/restore] 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, 12 Jan 2009 11:07:57 -0000 Yoshihiro Ota schrieb: > Try GEOM Cache(gcache). Just a side note: gcache does not seem to have any documentation. "man gcache" is unsuccessful, geom(8) does not mention it (geom and gcache are the same hardlinked binary). Is there information about it somewhere? From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 11:20:48 2009 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 7857710658DB for ; Mon, 12 Jan 2009 11:20:48 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.freenix.fr (keltia.freenix.org [IPv6:2001:660:330f:f820:213:72ff:fe15:f44]) by mx1.freebsd.org (Postfix) with ESMTP id 1CD588FC2C for ; Mon, 12 Jan 2009 11:20:48 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from localhost (localhost [127.0.0.1]) by keltia.freenix.fr (Postfix/TLS) with ESMTP id 241DF3B9A5 for ; Mon, 12 Jan 2009 12:20:47 +0100 (CET) X-Virus-Scanned: amavisd-new at keltia.freenix.fr Received: from keltia.freenix.fr ([127.0.0.1]) by localhost (keltia.freenix.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YikJ6ySg2idm for ; Mon, 12 Jan 2009 12:20:46 +0100 (CET) Received: by keltia.freenix.fr (Postfix/TLS, from userid 101) id CA0413B9A4; Mon, 12 Jan 2009 12:20:46 +0100 (CET) Date: Mon, 12 Jan 2009 12:20:46 +0100 From: Ollivier Robert To: freebsd-hackers@freebsd.org Message-ID: <20090112112046.GA52776@keltia.freenix.fr> References: <20090109.095027.-1672857892.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090109.095027.-1672857892.imp@bsdimp.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7 / Dell D820 SMP User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: 3x read to write ratio on dump/restore 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, 12 Jan 2009 11:20:57 -0000 According to M. Warner Losh: > The read kBps was 3x the write kBps. While the dump is going through > the raw device, and the restore is going through the file system, I > can't imagine why we'd have such a huge difference that would be utter > consistent for the whole 15 hour run. dump launches several processes to read the raw device and use a buffer between them whereas restore is single process. When copying from disk to disk, I often use team (sysutils/team) to stream. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Dons / donation Ondine : http://ondine.keltia.net/ From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 11:51:41 2009 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 EFD0A1065670 for ; Mon, 12 Jan 2009 11:51:41 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A10DE8FC0A for ; Mon, 12 Jan 2009 11:51:41 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LMLKT-0004er-De for freebsd-hackers@freebsd.org; Mon, 12 Jan 2009 11:51:37 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Jan 2009 11:51:37 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Jan 2009 11:51:37 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Mon, 12 Jan 2009 12:51:18 +0100 Lines: 33 Message-ID: References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig562445D843A40CC0E1018502" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.18 (X11/20081125) In-Reply-To: <496B1E47.1030403@gmx.de> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: gcache [was: Re: 3x read to write ratio on dump/restore] 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, 12 Jan 2009 11:51:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig562445D843A40CC0E1018502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christoph Mallon wrote: > Yoshihiro Ota schrieb: >> Try GEOM Cache(gcache). >=20 > Just a side note: gcache does not seem to have any documentation. "man > gcache" is unsuccessful, geom(8) does not mention it (geom and gcache > are the same hardlinked binary). Is there information about it somewher= e? AFAIK it's very experimental, might not be there in this form in the futu= re. --------------enig562445D843A40CC0E1018502 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJay62ldnAQVacBcgRAuYqAJ9MpTIKekEgT3aokPkhaXlQdN8Z/QCg+SS7 xr+1p6u9tpNYPRLI3MJvIjc= =krsi -----END PGP SIGNATURE----- --------------enig562445D843A40CC0E1018502-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 12:01:00 2009 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 28C48106570D; Mon, 12 Jan 2009 12:01:00 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id C40D78FC2D; Mon, 12 Jan 2009 12:00:59 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KDC00IRTVZM49D0@mta-1.ms.rz.RWTH-Aachen.de>; Mon, 12 Jan 2009 12:30:58 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.37,252,1231110000"; d="scan'208";a="96255649" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Mon, 12 Jan 2009 12:30:58 +0100 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n0CBUwhk002544; Mon, 12 Jan 2009 12:30:58 +0100 (CET) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LML0U-0007qk-8Q; Mon, 12 Jan 2009 12:30:58 +0100 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 026B73F41B; Mon, 12 Jan 2009 12:30:57 +0100 (CET) Date: Mon, 12 Jan 2009 12:30:57 +0100 From: Christian Brueffer To: Christoph Mallon Message-id: <20090112113057.GA1277@haakonia.hitnet.RWTH-Aachen.DE> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=9jxsPFA5p3P2qPhR Content-disposition: inline In-reply-to: <496B1E47.1030403@gmx.de> X-Operating-System: FreeBSD 6.4-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.11 Cc: trhodes@freebsd.org, hackers@freebsd.org Subject: Re: gcache [was: Re: 3x read to write ratio on dump/restore] 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, 12 Jan 2009 12:01:03 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 12, 2009 at 11:41:11AM +0100, Christoph Mallon wrote: > Yoshihiro Ota schrieb: > >Try GEOM Cache(gcache). >=20 > Just a side note: gcache does not seem to have any documentation. "man=20 > gcache" is unsuccessful, geom(8) does not mention it (geom and gcache=20 > are the same hardlinked binary). Is there information about it somewhere? > _______________________________________________ A manpage for gcache is currently under review. Hopefully it will be committed in the next couple of days. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFJaynxbHYXjKDtmC0RAvunAJ9BH/9U73UINwBukUxt4D4025irQgCg+278 geTgou5Ajx5FlgeBDokU7yE= =M3dK -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 12:15:42 2009 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 100821065670 for ; Mon, 12 Jan 2009 12:15:42 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4A48FC1D for ; Mon, 12 Jan 2009 12:15:41 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by bwz13 with SMTP id 13so6042045bwz.19 for ; Mon, 12 Jan 2009 04:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=HJKQ8EBuGHVYdRYRq/N/Or05V+VU6rja3eDiPNGFh1o=; b=POq4xTr8u1Bi2AYv9LX6KOz4vTmdV5jbTOtUkVYfv+qm/ofphkst5TOkLHaZggPwLd tSqVJd7jNaWG5fST2EmHKoz3AR62Nl2/XVQdrggDbSXu1yPmgqHyrb5CunQVeWgwnMNK FplmZnRbvAr9xbdLdVSwTe53bHtGPWXyrsTGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=MpCZXVhgBMAqmHCGKnsX+W2+kZoDMQeceWs+vix2Z3AHbLTbpUGK8uVzVjNzEPjtN1 YnNECWwks7mJKFivk0i7LHdfF8BEZZdiyrjmkZLUkvToKl1Wn64dp7l0+KBl+FgEQqgb PhG1PZQsRGQHFBFNvssE/3d5uvn9PqlISyEfA= Received: by 10.223.115.16 with SMTP id g16mr20964234faq.93.1231761311405; Mon, 12 Jan 2009 03:55:11 -0800 (PST) Received: by 10.223.110.209 with HTTP; Mon, 12 Jan 2009 03:55:11 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2009 11:55:11 +0000 From: "Andrew Brampton" To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Mon, 12 Jan 2009 12:28:05 +0000 Cc: Subject: Determine if a kernel is built with a specific option? 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, 12 Jan 2009 12:15:42 -0000 Hi, I was wondering how a autoconf configure script can determine if the kernel is built with a particular option. In this case the code I have can make use of the FreeBSD polling driver, which by default isn't built into a kernel. So I want my configure script to determine if the kernel supports it, if so sets a #define, otherwise doesn't. In the past I have basically hacked my way though these configure scripts by looking at other examples. One such example I found was for Linux, which does something like this: AC_CACHE_CHECK(for device polling kernel extension, ac_cv_linux_poll_extension, [if grep polling `find_linuxpath include/linux/netdevice.h` >/dev/null 2>&1; then ac_cv_linux_poll_extension=yes else ac_cv_linux_poll_extension=no; fi]) if test $ac_cv_linux_poll_extension = yes; then AC_DEFINE(HAVE_LINUX_POLLING) fi So I simply want to figure out an equalavant check I can do on FreeBSD. thanks Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 12:31:07 2009 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 CFA8D106566B; Mon, 12 Jan 2009 12:31:07 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3576C8FC24; Mon, 12 Jan 2009 12:31:06 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from lack-of-gravitas.thebunker.net (gateway.ash.thebunker.net [213.129.64.4]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.3/8.14.3) with ESMTP id n0CCUsU7050867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 12:31:01 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.7.2 smtp.infracaninophile.co.uk n0CCUsU7050867 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1231763461; bh=RYFsEgLVSS28N0 ozZ6/b2o/eADSv5InVkoubHLP5pbY=; h=Message-ID:Date:From:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<496B37FD.7 040209@infracaninophile.co.uk>|Date:=20Mon,=2012=20Jan=202009=2012: 30:53=20+0000|From:=20Matthew=20Seaman=20|Organization:=20Infracaninophile|User-Agent:=20Thunderbird= 202.0.0.19=20(X11/20090103)|MIME-Version:=201.0|To:=20Christian=20B rueffer=20|CC:=20Christoph=20Mallon=20,=20trhodes@freebsd.org,=20=0D=0A=20hackers@freeb sd.org|Subject:=20Re:=20gcache=20[was:=20Re:=203x=20read=20to=20wri te=20ratio=20on=20dump/restore]|References:=20<20090109.095027.-167 2857892.imp@bsdimp.com>=09<20090111041710.GB5661@server.vk2pj.dyndn s.org>=09<20090112050537.f423215c.ota@j.email.ne.jp>=20<496B1E47.10 30403@gmx.de>=20<20090112113057.GA1277@haakonia.hitnet.RWTH-Aachen. DE>|In-Reply-To:=20<20090112113057.GA1277@haakonia.hitnet.RWTH-Aach en.DE>|X-Enigmail-Version:=200.95.6|Content-Type:=20text/plain=3B=2 0charset=3DUTF-8=3B=20format=3Dflowed|Content-Transfer-Encoding:=20 7bit; b=Qf5kgjcNIXIifY0RRzwq+4t0GvV8OGxF5m0rXx5j+BCHU9pSNTQMy8aPl4t Oip/ySJ4XcYTQxFz40A6THoIWNloj19Z/DF1Wvder0srXdjsJzyTpHY7k6+4v0XYkHG JQ0xdWZfDffdig4OT0ELjdxWXWiiCKjN0EXpqcXdeNxyM= Message-ID: <496B37FD.7040209@infracaninophile.co.uk> Date: Mon, 12 Jan 2009 12:30:53 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Christian Brueffer References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> <20090112113057.GA1277@haakonia.hitnet.RWTH-Aachen.DE> In-Reply-To: <20090112113057.GA1277@haakonia.hitnet.RWTH-Aachen.DE> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (smtp.infracaninophile.co.uk [81.187.76.162]); Mon, 12 Jan 2009 12:31:01 +0000 (GMT) X-Virus-Scanned: ClamAV 0.94.2/8853/Mon Jan 12 00:26:44 2009 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,SPF_FAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: hackers@freebsd.org, trhodes@freebsd.org, Christoph Mallon Subject: Re: gcache [was: Re: 3x read to write ratio on dump/restore] 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, 12 Jan 2009 12:31:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Christian Brueffer wrote: | On Mon, Jan 12, 2009 at 11:41:11AM +0100, Christoph Mallon wrote: |> Yoshihiro Ota schrieb: |>> Try GEOM Cache(gcache). |> Just a side note: gcache does not seem to have any documentation. "man |> gcache" is unsuccessful, geom(8) does not mention it (geom and gcache |> are the same hardlinked binary). Is there information about it somewhere? |> _______________________________________________ | | A manpage for gcache is currently under review. Hopefully it will be | committed in the next couple of days. Unfortunate name clash with apache13-ssl's gcache though. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. Flat 3 ~ 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate ~ Kent, CT11 9PW, UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAklrN/0ACgkQ8Mjk52CukIxRcwCfQYWp6FHjrsFn0u3MBofWlhNg mhgAnRz2zNyW4WSe8W8Lc+0XK49LVPud =trWs -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 13:00:30 2009 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 98B5510656FA for ; Mon, 12 Jan 2009 13:00:30 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 927F78FC18 for ; Mon, 12 Jan 2009 13:00:29 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3672783fgb.35 for ; Mon, 12 Jan 2009 05:00:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=VKtK+CF8CEwODsm8A+/mfreraJf2lfOrxAdTWFeQMlU=; b=lpqm1lZY3r2YH7PHalYoqeb+tQz+RQcsgcC1SgiHiGTryr7GkHk6pUXsTLWNvbfIIN JNA8mp+1q1n+5HmsbIFJVC6UL7MHT3Om9jKaqYjQb7JjKyY/JlIla7vgDVXnSp74vPO0 8EjOLNAv03X8WoiP9MjFbm2FXH2N5R+A3V/SU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wbpT8ML78P6/Bb8V/r1zrEJBR60jQWcXQeVZ3iN4qBza86MA7vUo4ADSi5jr6nWcRh 7e965AALRXtY838riioTDDY65V/KfBN6QGdcEMdxr1u/Wp711aqX72EVLBfOo7RSFhFh BpU1LS8UFmHVipegs8JmNA9kmxx4D+JJiCqnw= Received: by 10.86.51.10 with SMTP id y10mr16730310fgy.51.1231765228453; Mon, 12 Jan 2009 05:00:28 -0800 (PST) Received: by 10.86.72.19 with HTTP; Mon, 12 Jan 2009 05:00:28 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2009 16:00:28 +0300 From: pluknet To: "Andrew Brampton" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: hackers@freebsd.org Subject: Re: Determine if a kernel is built with a specific option? 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, 12 Jan 2009 13:00:31 -0000 2009/1/12 Andrew Brampton : > Hi, > I was wondering how a autoconf configure script can determine if the > kernel is built with a particular option. In this case the code I have > can make use of the FreeBSD polling driver, which by default isn't > built into a kernel. So I want my configure script to determine if the > kernel supports it, if so sets a #define, otherwise doesn't. > > In the past I have basically hacked my way though these configure > scripts by looking at other examples. One such example I found was for > Linux, which does something like this: > > AC_CACHE_CHECK(for device polling kernel extension, ac_cv_linux_poll_extension, > [if grep polling `find_linuxpath include/linux/netdevice.h` >/dev/null > 2>&1; then > ac_cv_linux_poll_extension=yes > else ac_cv_linux_poll_extension=no; fi]) > if test $ac_cv_linux_poll_extension = yes; then > AC_DEFINE(HAVE_LINUX_POLLING) > fi > > So I simply want to figure out an equalavant check I can do on FreeBSD. > Hi. You may look at sysctl kern.polling presence. -- wbr, pluknet From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 13:47:59 2009 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 E39E3106566B for ; Mon, 12 Jan 2009 13:47:59 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 6F38A8FC1F for ; Mon, 12 Jan 2009 13:47:59 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by fg-out-1718.google.com with SMTP id l26so3684919fgb.35 for ; Mon, 12 Jan 2009 05:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:reply-to:mail-followup-to:mime-version:content-type :content-disposition:user-agent; bh=eng03phmK/tRqJcEddTTPRBtZjQN0yodh+4eAJ8sxK8=; b=q9hAv+JFztoW0RIdGHSxvmwRZDW80Rq5zeSDYuZETDSOPk2EO4jb1xV/yN4t/aqTkN xWJoRiyXVzt6PxZRzNDxrtlfjAGkVXwlG65ObjTZmtE6iO1+gCWjTUy4vnZDMjO4ifar RFdo0oz0lBqkjIX7rA8gQSchoVxoAqUSZ/LX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:mail-followup-to :mime-version:content-type:content-disposition:user-agent; b=CFdIXZX0kxNllP2JGc/2AVz+r3aoAb0q5tYYh9MPuD0faaE8LJGpbzNNenSPxU0T35 fFRLlQhLkwVkvVzy4apyv8pNzcjyC6PFLvOgaFcYzcnvYx1rGYrA0pULZLYmxGulUwnG 2U5DD5Nq7h29aRpYGjRyx5OrNHM2Vjmb6lijg= Received: by 10.86.59.2 with SMTP id h2mr12373503fga.73.1231768078513; Mon, 12 Jan 2009 05:47:58 -0800 (PST) Received: from localhost (BAJ0a25.baj.pppool.de [77.137.10.37]) by mx.google.com with ESMTPS id 4sm43170469fgg.24.2009.01.12.05.47.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 05:47:57 -0800 (PST) Date: Mon, 12 Jan 2009 14:47:26 +0100 From: Alexej Sokolov To: freebsd-hackers@freebsd.org Message-ID: <20090112134726.GA2988@debian.samsung.router> Mail-Followup-To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: panic by unlocking of mutex in KLD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexej Sokolov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 13:48:00 -0000 Hello, by unloading of folowing module I have kernel panic. I would like to get any explanation about my mistake. #include #include #include #include #include #include #include #include #include #include #include struct mtx my_mtx; /* Load handler */ static int load(struct module *mod, int cmd, void *arg) { int error = 0; switch(cmd) { case MOD_LOAD: printf("Start! Addres of mutex = 0x%X \n", &my_mtx); mtx_init(&my_mtx, "My mutex name", "My mutex type", MTX_DEF); mtx_lock(&my_mtx); break; case MOD_UNLOAD: printf("Stop! Addres of mutex = 0x%X \n", &my_mtx); mtx_unlock(&my_mtx); break; default: error = EOPNOTSUPP; break; } return (error); } /* Module structure */ static moduledata_t mod_data = { "mymod", load, NULL }; MODULE_VERSION (kld, 1); DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); Thanx -- Alexej Sokolov From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 14:10:31 2009 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 C64DD1065675 for ; Mon, 12 Jan 2009 14:10:31 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 518958FC17 for ; Mon, 12 Jan 2009 14:10:30 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3690518fgb.35 for ; Mon, 12 Jan 2009 06:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=INpZ7Ad0T7DwtLQqINwdSdLXxhz4rYJ+CdOkf6nSLLI=; b=QqV49TvifOxqmAtF4WC9r1fYX/paMT3vg/H/zb1DSKlTSVgix2ww3BbQ/OxNp+0zWm Wc03KQHWuJRj6P8g8mzWOfHkyNT2RWb5ESr+H9yAdtoxjWj27M4ECDRj+nD1HGlweNzl PhmhfcjTC04IldQgIaHFaZUC6ud++GTFmi1cI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=QgsYKxN3L1rkIfsEY6w+WV+jDF8miDsUNCZtSYAGaXDP9zW9UMSTGS1ZksGXrcpWGl V3zmlJVVPFyZ94js8t2Z1RUykgsdLHJi8PW68a65yyUHtfk8q2WL7sVjOIQFfS3+rMn6 RQjquYX4BXIj5pScsoA4fe8rWxj7GJvLyx1+4= Received: by 10.86.54.3 with SMTP id c3mr15345153fga.75.1231769430178; Mon, 12 Jan 2009 06:10:30 -0800 (PST) Received: from gmail.com (sdferwer192.net.autocom.pl [77.236.1.49]) by mx.google.com with ESMTPS id d6sm9155459fga.20.2009.01.12.06.10.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 06:10:29 -0800 (PST) Date: Mon, 12 Jan 2009 15:10:29 +0100 From: Mateusz Guzik To: Alexej Sokolov Message-ID: <20090112141029.GA31108@skucha> References: <20090112134726.GA2988@debian.samsung.router> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20090112134726.GA2988@debian.samsung.router> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 14:10:32 -0000 On Mon, Jan 12, 2009 at 02:47:26PM +0100, Alexej Sokolov wrote: > Hello, > > by unloading of folowing module I have kernel panic. > > I would like to get any explanation about my mistake. > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > > struct mtx my_mtx; > > > /* Load handler */ > static int > load(struct module *mod, int cmd, void *arg) > { > int error = 0; > switch(cmd) { > case MOD_LOAD: > printf("Start! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_init(&my_mtx, "My mutex name", "My mutex > type", MTX_DEF); > > mtx_lock(&my_mtx); > break; > case MOD_UNLOAD: > printf("Stop! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_unlock(&my_mtx); > break; > default: > error = EOPNOTSUPP; > break; > } > > return (error); > } > > /* Module structure */ > static moduledata_t mod_data = { > "mymod", > load, > NULL > }; > MODULE_VERSION (kld, 1); > DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > > Acutally it panics even on loading. :) Mutexes have owners. It panics on loading because processes cannot return to userland with locks held. It panics on unloading (in your case) because curproc != my_mtx's owner. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 14:39:22 2009 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 97DF6106564A; Mon, 12 Jan 2009 14:39:22 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 57DBD8FC0A; Mon, 12 Jan 2009 14:39:22 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 4BFE96D43F; Mon, 12 Jan 2009 14:39:21 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 34F1E844A7; Mon, 12 Jan 2009 15:39:21 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Eitan Shefi" References: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> Date: Mon, 12 Jan 2009 15:39:21 +0100 In-Reply-To: <5D49E7A8952DC44FB38C38FA0D758EAD0164F6D6@mtlexch01.mtl.com> (Eitan Shefi's message of "Wed, 7 Jan 2009 13:30:20 +0200") Message-ID: <86hc447fmu.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: "/var/log/messages" logs appear in the output of "sysctl -a" 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, 12 Jan 2009 14:39:23 -0000 "Eitan Shefi" writes: > I run "sysctl -a | less" why? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 14:45:10 2009 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 C9BD4106564A for ; Mon, 12 Jan 2009 14:45:10 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8620E8FC19 for ; Mon, 12 Jan 2009 14:45:10 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id C4EDA6D43F; Mon, 12 Jan 2009 14:45:09 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A8C96844ED; Mon, 12 Jan 2009 15:45:09 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: perryh@pluto.rain.com References: <20090107181032.GA2808@rebelion.Sisis.de> <1231398405.2842.1.camel@daemon2.partygaming.local> <20090108080708.GE1462@roadrunner.spoerlein.net> <4966e5b7.sTBBp+JY+DDMKG47%perryh@pluto.rain.com> <20090109204014.GA83381@keira.kiwi-computer.com> <496892aa.n9QVqyhWypsSmeIU%perryh@pluto.rain.com> <20090111160138.GA2386@keira.kiwi-computer.com> <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> Date: Mon, 12 Jan 2009 15:45:09 +0100 In-Reply-To: <496ad1cd.5X8ZKwS/WWhYNQ61%perryh@pluto.rain.com> (perryh@pluto.rain.com's message of "Sun, 11 Jan 2009 21:14:53 -0800") Message-ID: <86d4es7fd6.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: rick-freebsd2008@kiwi-computer.com, freebsd-hackers@freebsd.org Subject: Re: /dev/dsp* & /dev/audio* devices not present 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, 12 Jan 2009 14:45:11 -0000 perryh@pluto.rain.com writes: > "Rick C. Petty" writes: > > Funny. But this isn't a bug disguised as a feature. > > It's a feature that you believe is a bug. > I would call it a bug that you believe is a feature. It is *by definition* a feature. The code works as intended. If it didn't, that would be a bug. The fact that you wish the code worked differently doesn't make it a bug. Anyway, you can complain until you're blue in the face, but it's not going to change, for a number of very good reasons (which have mostly been listed in other posts in this thread). DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 14:50:56 2009 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 CC63F106564A; Mon, 12 Jan 2009 14:50:56 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 8C3208FC1C; Mon, 12 Jan 2009 14:50:56 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id A980E6D44C; Mon, 12 Jan 2009 14:50:55 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 8EFEC844ED; Mon, 12 Jan 2009 15:50:55 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Peter Jeremy References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> <20090111083300.GC7054@server.vk2pj.dyndns.org> Date: Mon, 12 Jan 2009 15:50:55 +0100 In-Reply-To: <20090111083300.GC7054@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Sun, 11 Jan 2009 19:33:00 +1100") Message-ID: <868wpg7f3k.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kamlesh Patel , hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: kernel panic 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, 12 Jan 2009 14:50:57 -0000 Peter Jeremy writes: > Kamlesh Patel writes: > > How do i recover the system from this error. I can't reload the > > loader.old > > If you press any key during the first spinner [...] You can then > enter the name of the program you wish to run - eg /boot/loader.old That won't work - he changed the forth code, not the compiled code. > (or directly load /boot/kernel/kernel) That will work. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 14:56:23 2009 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 CC2B2106566C for ; Mon, 12 Jan 2009 14:56:23 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 24EC08FC24 for ; Mon, 12 Jan 2009 14:56:22 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by bwz13 with SMTP id 13so6346517bwz.19 for ; Mon, 12 Jan 2009 06:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xpo1JsABI/SOGuB2Fj1ySmvuwtRdYOTTirRtHlBVE7E=; b=GiTe5MrDJpArGKvhJiG7qO9qt8Pn71MLylEjWtPVAomr0UAYGPUeqpMj9sGQthE2EM jhLHvo/noqNd79Hwgk6sU8JhNnhGwf1P7tAM+tzj4/Z2R7TH69KZMdDQxtfL+HtgL4Mj joQJaqB3bW5WAZe5IEC3O98nvGOgkuMnEMIxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=P9l9HRCpWQvdxQqbe8qus4zmxCEuRsyzn0FS1szE7ccywHX//mfjoBoa44Sb+JIOa2 KddvHVcCqdSaCY9a7mIZTByRx1CNVzWLjRQKVf+/H0v46MIhmv0Ge7HTQaqvpxxg04UV h546orxmptIyNGEnBXIf+/nP1ixgOAhGJ+64c= Received: by 10.223.114.2 with SMTP id c2mr21281659faq.85.1231772181764; Mon, 12 Jan 2009 06:56:21 -0800 (PST) Received: by 10.223.110.209 with HTTP; Mon, 12 Jan 2009 06:56:21 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2009 14:56:21 +0000 From: "Andrew Brampton" Sender: brampton@gmail.com To: "Eugene Grosbein" In-Reply-To: <20090112145131.GA4375@svzserv.kemerovo.su> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090112145131.GA4375@svzserv.kemerovo.su> X-Google-Sender-Auth: d606bc5103930637 Cc: hackers@freebsd.org Subject: Re: Determine if a kernel is built with a specific option? 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, 12 Jan 2009 14:56:24 -0000 2009/1/12 Eugene Grosbein : >> I was wondering how a autoconf configure script can determine if the >> kernel is built with a particular option. In this case the code I have >> can make use of the FreeBSD polling driver, which by default isn't >> built into a kernel. So I want my configure script to determine if the >> kernel supports it, if so sets a #define, otherwise doesn't. > > You should not assume that compiled code does not need polling support > just because _buildbox_ doesn't have it enabled in time of build. > If the code builds here, it does not mean it will run here. > > Eugene Grosbein > Thanks for your comments Eugene. I know that is a bad assumption to make, but I'm basically updating someone else's software which already had that assumption for Linux. If you were going to do this, would you make it a configure flag... ie --enable-polling... That way it doesn't matter if the build box is different? thanks Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 14:58:07 2009 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 A202A106568B for ; Mon, 12 Jan 2009 14:58:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 39A868FC16 for ; Mon, 12 Jan 2009 14:58:06 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=A61yHLuv1KAA:10 a=nklthdr5v5AUSfVrlghuJA==:17 a=OqVvdz0Z2B-PgFpi5JkA:9 a=PmvdemeyjeGrU5oe2RcA:7 a=pTnRiqneiQoNfUxOZOVBSMkRs7gA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1178393361; Mon, 12 Jan 2009 14:58:04 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org, Alexej Sokolov Date: Mon, 12 Jan 2009 15:00:20 +0100 User-Agent: KMail/1.9.7 References: <20090112134726.GA2988@debian.samsung.router> In-Reply-To: <20090112134726.GA2988@debian.samsung.router> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901121500.21657.hselasky@c2i.net> Cc: Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 14:58:08 -0000 On Monday 12 January 2009, Alexej Sokolov wrote: > Hello, > > by unloading of folowing module I have kernel panic. > > I would like to get any explanation about my mistake. > > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > > struct mtx my_mtx; > > > /* Load handler */ > static int > load(struct module *mod, int cmd, void *arg) > { > int error = 0; > switch(cmd) { > case MOD_LOAD: > printf("Start! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_init(&my_mtx, "My mutex name", "My mutex > type", MTX_DEF); > > mtx_lock(&my_mtx); > break; > case MOD_UNLOAD: > printf("Stop! Addres of mutex = 0x%X \n", > &my_mtx); > mtx_unlock(&my_mtx); > break; > default: > error = EOPNOTSUPP; > break; > } > > return (error); > } > > /* Module structure */ > static moduledata_t mod_data = { > "mymod", > load, > NULL > }; > MODULE_VERSION (kld, 1); > DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > > > Thanx Hi, You cannot do like this. Remember, two different threads are doing the load/unload. The mutex is associated with a thread. Print out "curthread" aswell and you will see. The mutex can only be unlocked by the same thread that locked it. --HPS From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 14:51:34 2009 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 78E5B10656C2 for ; Mon, 12 Jan 2009 14:51:34 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id D2FB18FC20 for ; Mon, 12 Jan 2009 14:51:33 +0000 (UTC) (envelope-from eugen@kuzbass.ru) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id n0CEpV5k004581; Mon, 12 Jan 2009 21:51:31 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id n0CEpVlp004580; Mon, 12 Jan 2009 21:51:31 +0700 (KRAT) (envelope-from eugen) Date: Mon, 12 Jan 2009 21:51:31 +0700 From: Eugene Grosbein To: Andrew Brampton , hackers@freebsd.org Message-ID: <20090112145131.GA4375@svzserv.kemerovo.su> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Mon, 12 Jan 2009 15:17:00 +0000 Cc: Subject: Re: Determine if a kernel is built with a specific option? 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, 12 Jan 2009 14:51:34 -0000 > I was wondering how a autoconf configure script can determine if the > kernel is built with a particular option. In this case the code I have > can make use of the FreeBSD polling driver, which by default isn't > built into a kernel. So I want my configure script to determine if the > kernel supports it, if so sets a #define, otherwise doesn't. You should not assume that compiled code does not need polling support just because _buildbox_ doesn't have it enabled in time of build. If the code builds here, it does not mean it will run here. Eugene Grosbein From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 15:45:44 2009 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 F11C51065674; Mon, 12 Jan 2009 15:45:44 +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 CAA8B8FC0A; Mon, 12 Jan 2009 15:45:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6B33246B17; Mon, 12 Jan 2009 10:45:44 -0500 (EST) Date: Mon, 12 Jan 2009 15:45:44 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tim Kientzle In-Reply-To: <496ABD9A.8080006@freebsd.org> Message-ID: References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> <496AA714.1090904@freebsd.org> <496ABD9A.8080006@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, pluknet Subject: Re: extattr problems? 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, 12 Jan 2009 15:45:45 -0000 On Sun, 11 Jan 2009, Tim Kientzle wrote: > I think this one is a bug. It appears that extattr_set_fd() obeys the > permissions on the file, not the permissions of the descriptor. In > particular, I see this on FreeBSD 6.3: Hmm. Not clear. EAs live in a slightly hazy world between data and meta-data. Normally you can perform operations like fchmod(2), which are strictly meta-data operations, regardless of the flags of the file descriptor they are performed on, subject to ownership/permissions. With NFSv4 ACLs, where the right to change ACLs can be delegated, this only becomes more true. I've chosen to generally treat EAs as meta-data in this regard, where the file descriptor simply names the object rather than as an access method as occurs with write(), etc. How do other systems handle this -- for example, Linux, with its notion of user vs. system namespaces? Robert N M Watson Computer Laboratory University of Cambridge > > [tim@dark /tmp]$ ./extattr_test > fd=3 > extattr_set_fd() = -1 > errno = 13 (Permission denied) > [tim@dark /tmp]$ cat extattr_test.c > #include > #include > #include > #include > #include > > int > main(int argc, char **argv) > { > int n, fd; > > fd = open("/tmp/test12345", O_RDWR | O_CREAT | O_EXCL, 0000); > printf("fd=%d\n", fd); > n = extattr_set_fd(fd, EXTATTR_NAMESPACE_USER, > "testattr", "1234", 4); > printf("extattr_set_fd() = %d\n", n); > if (n != 0) > printf("errno = %d (%s)\n", > errno, strerror(errno)); > exit(0); > } > _______________________________________________ > 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 Mon Jan 12 16:03:07 2009 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 3DF7C106566C for ; Mon, 12 Jan 2009 16:03:07 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id EEC768FC1B for ; Mon, 12 Jan 2009 16:03:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 8ACC9FEF5; Tue, 13 Jan 2009 04:36:24 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC8U++Knddg0; Tue, 13 Jan 2009 04:36:20 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 13 Jan 2009 04:36:20 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 503841142B; Tue, 13 Jan 2009 04:36:20 +1300 (NZDT) Date: Mon, 12 Jan 2009 07:36:20 -0800 From: Andrew Thompson To: Andrew Brampton Message-ID: <20090112153620.GA76347@citylink.fud.org.nz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: hackers@freebsd.org Subject: Re: Determine if a kernel is built with a specific option? 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, 12 Jan 2009 16:03:07 -0000 On Mon, Jan 12, 2009 at 11:55:11AM +0000, Andrew Brampton wrote: > Hi, > I was wondering how a autoconf configure script can determine if the > kernel is built with a particular option. In this case the code I have > can make use of the FreeBSD polling driver, which by default isn't > built into a kernel. So I want my configure script to determine if the > kernel supports it, if so sets a #define, otherwise doesn't. > > In the past I have basically hacked my way though these configure > scripts by looking at other examples. One such example I found was for > Linux, which does something like this: > > AC_CACHE_CHECK(for device polling kernel extension, ac_cv_linux_poll_extension, > [if grep polling `find_linuxpath include/linux/netdevice.h` >/dev/null > 2>&1; then > ac_cv_linux_poll_extension=yes > else ac_cv_linux_poll_extension=no; fi]) > if test $ac_cv_linux_poll_extension = yes; then > AC_DEFINE(HAVE_LINUX_POLLING) > fi > > So I simply want to figure out an equalavant check I can do on FreeBSD. I believe the correct way is to read kern.features from sysctl and the appropriate code marks it with FEATURE(name, "description"); Having said that the polling code does not set this so would need to be added. Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 16:19:57 2009 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 6AEFE106566B for ; Mon, 12 Jan 2009 16:19:57 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2648FC0C for ; Mon, 12 Jan 2009 16:19:57 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by wa-out-1112.google.com with SMTP id m34so6026385wag.27 for ; Mon, 12 Jan 2009 08:19:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=Osj3nkQ3D5E6SVddrMO66+D4LTmuDDSumGRWQDKw9l4=; b=s95N7k9Fgdpdl4Yxz5G61KBF26Js5fyaPz8PsoME6zzBKTIwCqv7cxTWg08rxdlcZy UMnbc4IPf2FT6bcjifXuO45nmk09jvOhIIAWG4DO+OCNlfcsWZTY9M627M75tcWANEyU 47mQgBaqdgkCO+fs4QH5/vXq8vojazkAwowqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=xUSNVSjiEqP/0PRGk0l8RUWe3THNCGqK/CUkWth0BL0UWuYuOvo5dPLWE/EKJ1C9cI NIqCSewxQLCWWFKe4N+meLJnGJMtaXt3pxxIguOxqW9ggI8MLRWOgT2bRTI5doyUx3Mg nhoPQiNGox7ujL4d9+CwHJHMa3noNAlO0fdZw= Received: by 10.114.159.5 with SMTP id h5mr19405517wae.190.1231777196908; Mon, 12 Jan 2009 08:19:56 -0800 (PST) Received: by 10.114.202.10 with HTTP; Mon, 12 Jan 2009 08:19:56 -0800 (PST) Message-ID: <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> Date: Mon, 12 Jan 2009 17:19:56 +0100 From: "Alexej Sokolov" To: "Mateusz Guzik" In-Reply-To: <20090112141029.GA31108@skucha> MIME-Version: 1.0 References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 16:19:57 -0000 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 02:47:26PM +0100, Alexej Sokolov wrote: > > Hello, > > > > by unloading of folowing module I have kernel panic. > > > > I would like to get any explanation about my mistake. > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > > > struct mtx my_mtx; > > > > > > /* Load handler */ > > static int > > load(struct module *mod, int cmd, void *arg) > > { > > int error = 0; > > switch(cmd) { > > case MOD_LOAD: > > printf("Start! Addres of mutex = 0x%X \n", > > &my_mtx); > > mtx_init(&my_mtx, "My mutex name", "My mutex > > type", MTX_DEF); > > > > mtx_lock(&my_mtx); > > break; > > case MOD_UNLOAD: > > printf("Stop! Addres of mutex = 0x%X \n", > > &my_mtx); > > mtx_unlock(&my_mtx); > > break; > > default: > > error = EOPNOTSUPP; > > break; > > } > > > > return (error); > > } > > > > /* Module structure */ > > static moduledata_t mod_data = { > > "mymod", > > load, > > NULL > > }; > > MODULE_VERSION (kld, 1); > > DECLARE_MODULE (kld, mod_data, SI_SUB_DRIVERS, SI_ORDER_MIDDLE); > > > > > > Acutally it panics even on loading. :) Thanks, a lot. Yes, in this case the different processes try to lock and unlock the same mutex. Stupid mistake! But... > > > Mutexes have owners. It panics on loading because processes cannot > return to userland with locks held. i am not sure about it. Some time ago i implemented a charecter device with two syscalls: write, read. "write" lock the mutex and "read" unlock it. The user space programm opens device, then mekes "write" (mutex will held in kernel), goes back to user space, then makes "read" (mutex will unlocked in kernel) and it all run without panic. If needed i can post the source code. > It panics on unloading (in your > case) because curproc != my_mtx's owner. > > -- > Mateusz Guzik > Thanks, Alexej From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 16:27:11 2009 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 BE2B01065673 for ; Mon, 12 Jan 2009 16:27:11 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 216198FC08 for ; Mon, 12 Jan 2009 16:27:10 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by ewy14 with SMTP id 14so13166464ewy.19 for ; Mon, 12 Jan 2009 08:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=8JqoJQ4EaXiqe4a1NDU+G2eZAHQlq9Fpry3UKf5/wOo=; b=k0IYxWlimltE0W5KOnZiHJYs7mRRMLTfVMEiOl0J0ULveT6aIzlEA825pT79fxTcl/ PbHtQreHG5jrw3O4oqcJB5XyaWvQQ2CbJxjRKRKrPXNXOmRZF9WR+P2kHq8pezuwF3ta lz3sF2Tauk6yi05bSk0JQfMU3Ps6yM59JM8lE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=kleBKRuyo9NlYIV03iWc63E0RzTsJt7MsrclvzjSwu1r5tskmIura1p/yYK6/jRog9 yd5rhU7CEu8dc2bQM9PDqDll5NrKrNFbpbgY2SI3ieTEoVWIDWAIYpBOmSFLlb82HUoE Z5kBCZgVkeacyoxVmYZhc7ScV4hiIaghYLPSg= Received: by 10.210.104.20 with SMTP id b20mr322070ebc.182.1231777629902; Mon, 12 Jan 2009 08:27:09 -0800 (PST) Received: by 10.210.69.1 with HTTP; Mon, 12 Jan 2009 08:27:09 -0800 (PST) Message-ID: Date: Mon, 12 Jan 2009 16:27:09 +0000 From: "Andrew Brampton" Sender: brampton@gmail.com To: "Giorgos Keramidas" In-Reply-To: <873afolcrh.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090112145131.GA4375@svzserv.kemerovo.su> <873afolcrh.fsf@kobe.laptop> X-Google-Sender-Auth: 61ae79905ce8642c Cc: hackers@freebsd.org, Eugene Grosbein Subject: Re: Determine if a kernel is built with a specific option? 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, 12 Jan 2009 16:27:12 -0000 2009/1/12 Giorgos Keramidas : > On Mon, 12 Jan 2009 14:56:21 +0000, "Andrew Brampton" wrote: >> If you were going to do this, would you make it a configure flag... ie >> --enable-polling... That way it doesn't matter if the build box is >> different? > > If both choices are available (i.e. no header files are missing, no > link-time libraries are unavailable, and so on), I'd probably make it a > runtime option: That is the problem, if polling is enabled there are some symbols which are required which are unavailable if running on a GENERIC kernel. By turning off polling, different #defines are used in the code, removing any calls to the kernel polling functions. So as much as I was like to make this a runtime option, I don't think I can. > > * A configure-time flag to set the 'default' and > > * A runtime option to explicitly specify the current preference when > the program runs. > > This seems a bit more flexible, and does not require an expensive ``go > back to your vendor, and ask for a special build-time option'' cycle to > test different setups when a field installation is done. > Thanks to everyone that has replied. I think I'm just going to make this a configure flag, and if the target system doesn't have a suitable kernel then the software (or kernel) will have to be rebuilt. thanks for your wisdom Andrew From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 16:44:52 2009 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 4D2D9106566C for ; Mon, 12 Jan 2009 16:44:52 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id F1CFF8FC1D for ; Mon, 12 Jan 2009 16:44:51 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from [10.123.2.23] (h-66-166-149-52.snvacaid.covad.net [66.166.149.52]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n0CGipC1012970; Mon, 12 Jan 2009 08:44:51 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <496B7380.10804@freebsd.org> Date: Mon, 12 Jan 2009 08:44:48 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <49692659.2030306@freebsd.org> <49696C24.8010601@freebsd.org> <496AA714.1090904@freebsd.org> <496ABD9A.8080006@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, pluknet Subject: Re: extattr problems? 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, 12 Jan 2009 16:44:52 -0000 Robert Watson wrote: > On Sun, 11 Jan 2009, Tim Kientzle wrote: > >> I think this one is a bug. It appears that extattr_set_fd() obeys the >> permissions on the file, not the permissions of the descriptor. > > Hmm. Not clear. EAs live in a slightly hazy world between data and > meta-data. Normally you can perform operations like fchmod(2), which > are strictly meta-data operations, regardless of the flags of the file > descriptor they are performed on, subject to ownership/permissions. You can always call fchmod() on a newly-created file. But you cannot currently always call extattr_set_fd() on a newly created file. So extattr_set_fd() does not currently behave like other metadata operations. > With NFSv4 ACLs, where the right to change ACLs can be delegated, this > only becomes more true. I've chosen to generally treat EAs as meta-data > in this regard, where the file descriptor simply names the object rather > than as an access method as occurs with write(), etc. Hmmmm.... Then what is the secure way to create a file with no write permissions and EAs? The policy you've adopted means that you must open write permissions on the file even if the final file should not have such permissions. I'm also unclear about your reasoning here. There are only two ways to get a writable FD: You have write permissions on an existing file (or rather, *had* write permissions at the time you opened it), or you've just created the file. The former case would seem to cover your concerns here; I see no justification for disallowing the latter. I'm especially unhappy about this in the case of tar because it means I would have to introduce another system call (an otherwise-redundant fchmod()) into the performance-critical file creation path, not to mention some rather ugly logic to modify modes on newly created files if that file has extattrs and you're on FreeBSD. > How do other > systems handle this -- for example, Linux, with its notion of user vs. > system namespaces? I need to do some more research here. I'll let you know what I find. Tim From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 17:39:26 2009 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 91DD81065672 for ; Mon, 12 Jan 2009 17:39:26 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-gx0-f15.google.com (mail-gx0-f15.google.com [209.85.217.15]) by mx1.freebsd.org (Postfix) with ESMTP id A49BB8FC12 for ; Mon, 12 Jan 2009 17:39:21 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by gxk8 with SMTP id 8so9187826gxk.7 for ; Mon, 12 Jan 2009 09:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=W1BnLc0oFBU5n8Oizdl1dY7Ct+1Y42+dEAaFXl1XAnk=; b=aH1lWFa35i2uI8rAOrHyJaGRKdciHJmnqisMPicL4Dn8TzgJ++nvWWWRo8Dzy7ZRF3 ZJKeljdVdy4AfUoCUYctiUfo4euEOl12TX3q0xoJOHz4s1/5BvE5Mpy3mUzQomUTdoQ5 MOgTiCBMAZ1DbAR3i2nmnQVpLT7ni25ShWrp4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZZG8oz9dKmb+r/RmAnvd37np760hEwzJu32owzT15gR3VHLmretXpGfOZkaiM2OBJ3 Pq/icsvPg4jvbxcN6jsfZSKUYUca7l8fS1vF7vZZe2BgMGVrG06dPjaUcuZ8BP9no1Ow 1Lc8scVWq3MMNUhonPiLQohjmDbOlp5bWnGMw= Received: by 10.150.226.15 with SMTP id y15mr10751207ybg.99.1231781953266; Mon, 12 Jan 2009 09:39:13 -0800 (PST) Received: from gmail.com (sdferwer192.net.autocom.pl [77.236.1.49]) by mx.google.com with ESMTPS id e11sm12019516fga.12.2009.01.12.09.39.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 09:39:12 -0800 (PST) Date: Mon, 12 Jan 2009 18:39:13 +0100 From: Mateusz Guzik To: Alexej Sokolov Message-ID: <20090112173913.GA2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 17:39:26 -0000 On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > Mutexes have owners. It panics on loading because processes cannot > > return to userland with locks held. > > i am not sure about it. Some time ago i implemented a charecter device with > two syscalls: write, read. "write" lock the mutex and "read" unlock it. The > user space programm opens device, then mekes "write" (mutex will held in > kernel), goes back to user space, then makes "read" (mutex will unlocked in > kernel) and it all run without panic. If needed i can post the source code. > Do you have kernel compiled with WITNESS? At least on -CURRENT the kernel panicked like this (while loading your module): System call kldload returning with 1 locks held -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 18:16:52 2009 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 9B303106566B for ; Mon, 12 Jan 2009 18:16:52 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2308FC29 for ; Mon, 12 Jan 2009 18:16:52 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 24so13919863wfg.7 for ; Mon, 12 Jan 2009 10:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=NryGT+whINa4kDBf0QPmZO3lpOmnHKEauHTZOgriRi8=; b=gcMO6SGtfixUEyVMIaTX1akYDDlWmzGfBzOyjS2i3rZFJmCCVTeBv4AkycG/OsrTn5 h5d22cVk6i16zB98SFUo12cO+1C3WY7cIH/gkA48C8ZdGIV3XAoGlq+WbTtz6zBZXG+k melX3T6nOvP2c6UtW3zB/+JA4ih1j2ETWgBtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=H6lthgGsNheK+oUdOlLRxCLIpdjetc9bl9NJlDBW5zrJvohp+Qdmn6hutaCt6ACUCj aTsuUIWRKEwWkCK0U8eSZYm8CiPPIwoxzsqiCLq6ExXlW6Lc29nBqMr2sJ/uYgEpOJ7O WSHQfrrR9nH87JApw7SJ1i9YKo8Yl54ZCNJic= Received: by 10.114.184.7 with SMTP id h7mr19625226waf.151.1231784211775; Mon, 12 Jan 2009 10:16:51 -0800 (PST) Received: by 10.114.202.10 with HTTP; Mon, 12 Jan 2009 10:16:51 -0800 (PST) Message-ID: <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> Date: Mon, 12 Jan 2009 19:16:51 +0100 From: "Alexej Sokolov" To: "Mateusz Guzik" In-Reply-To: <20090112173913.GA2102@skucha> MIME-Version: 1.0 References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 18:16:53 -0000 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > 2009/1/12 Mateusz Guzik > > > Mutexes have owners. It panics on loading because processes cannot > > > return to userland with locks held. > > > > i am not sure about it. Some time ago i implemented a charecter device > with > > two syscalls: write, read. "write" lock the mutex and "read" unlock it. > The > > user space programm opens device, then mekes "write" (mutex will held in > > kernel), goes back to user space, then makes "read" (mutex will unlocked > in > > kernel) and it all run without panic. If needed i can post the source > code. > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > kernel panicked like this (while loading your module): > > System call kldload returning with 1 locks held My kernel is compiled without WITNESS. And it allows to lock mutex in one systcall (for example "write") and to unlock it in other ("read"). Do you mean it is "very bad idea" to do something like this ? I could not find anywhere in the documentation that a it is not allowed to return in the user space with a locked mutex. Can you give me some reference on man page, source code or something other from where can I understand it ? Thanx a lot, Alexej > > > -- > Mateusz Guzik > _______________________________________________ > 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 Mon Jan 12 18:47:13 2009 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 3EDBF1065679 for ; Mon, 12 Jan 2009 18:47:13 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id BAB578FC1E for ; Mon, 12 Jan 2009 18:47:12 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so6833663bwz.19 for ; Mon, 12 Jan 2009 10:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=yA17pCzMB8Jvt+LqfEyeJyzRVdC9Uju9rSygzm0zlag=; b=dRuW/6NZvHP7o6K9TeJQdgGEKoP95al5XeucZV7nLCDR3R2zsmS7i03Hrk9Hijs8S2 wLujIOqv2UF3GgvPuKxJbalG6tnL9D242f0CCxFNzdPJGj1ygghNeEfFf9FnwarPxU7h bmtzTrw/LgQSnbS/Xo2d6aNP/SJEJvVBPtKE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=A7dc/MfRevUIRRWM9A3wW9ngWw76WWghMJvLI29GNWGCKSlNESjUYz1xLUdwA6Et3k aVtMwsr816qfM1ERdR4mVPFXH3cmeLidXNI8EbFhG93Ylct8X7j9ysJPZUoMLzVvUQxv Tl263Jd4cuEuy2aU194nTEEyY3TK+0i2cDGH0= Received: by 10.181.193.15 with SMTP id v15mr10091437bkp.168.1231784429848; Mon, 12 Jan 2009 10:20:29 -0800 (PST) Received: by 10.181.26.3 with HTTP; Mon, 12 Jan 2009 10:20:29 -0800 (PST) Message-ID: <7d6fde3d0901121020j52e8b6b4saf8ad10b10df4ae1@mail.gmail.com> Date: Mon, 12 Jan 2009 10:20:29 -0800 From: "Garrett Cooper" To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" In-Reply-To: <868wpg7f3k.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> <20090111083300.GC7054@server.vk2pj.dyndns.org> <868wpg7f3k.fsf@ds4.des.no> Cc: Kamlesh Patel , hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: kernel panic 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, 12 Jan 2009 18:47:14 -0000 On Mon, Jan 12, 2009 at 6:50 AM, Dag-Erling Sm=F8rgrav wrote: > Peter Jeremy writes: >> Kamlesh Patel writes: >> > How do i recover the system from this error. I can't reload the >> > loader.old >> >> If you press any key during the first spinner [...] You can then >> enter the name of the program you wish to run - eg /boot/loader.old > > That won't work - he changed the forth code, not the compiled code. > >> (or directly load /boot/kernel/kernel) > > That will work. > > DES Maybe this? - Grab the liveCD (ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/7.0/7.0-RELEASE-i386-liv= efs.iso, or ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-amd64/7.0/7.0-RELEASE-amd64= -livefs.iso). Don't grab the 7.1 ones because they don't boot on all systems (it's in the release notes). - Mount your system. - chroot /wherever/your/install/is/mounted /bin/tcsh - Repeat steps to compile and install kernel Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 19:23:13 2009 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 DB209106564A; Mon, 12 Jan 2009 19:23:13 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 9AA6C8FC08; Mon, 12 Jan 2009 19:23:13 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D9BD46D43F; Mon, 12 Jan 2009 19:23:12 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id C313D844EF; Mon, 12 Jan 2009 20:23:12 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Garrett Cooper" References: <468090.72533.qm@web45413.mail.sp1.yahoo.com> <20090111083300.GC7054@server.vk2pj.dyndns.org> <868wpg7f3k.fsf@ds4.des.no> <7d6fde3d0901121020j52e8b6b4saf8ad10b10df4ae1@mail.gmail.com> Date: Mon, 12 Jan 2009 20:23:12 +0100 In-Reply-To: <7d6fde3d0901121020j52e8b6b4saf8ad10b10df4ae1@mail.gmail.com> (Garrett Cooper's message of "Mon, 12 Jan 2009 10:20:29 -0800") Message-ID: <86k590fhwf.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Kamlesh Patel , hackers@freebsd.org, freebsd-questions@freebsd.org Subject: Re: kernel panic 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, 12 Jan 2009 19:23:14 -0000 "Garrett Cooper" writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Peter Jeremy writes: > > > If you press any key during the first spinner [...] You can then > > > enter the name of the program you wish to run - eg /boot/loader.old > > That won't work - he changed the forth code, not the compiled code. > [...] > - Repeat steps to compile and install kernel which will achieve absolutely nothing, since the bug is in the forth code, not in the kernel or any other compiled code. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 19:28:23 2009 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 C96EB10657DC for ; Mon, 12 Jan 2009 19:28:23 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA028FC2D for ; Mon, 12 Jan 2009 19:28:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3778312fgb.35 for ; Mon, 12 Jan 2009 11:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=L5bNbVX4QsjOYSa7UPlMHxdqOiiwDrhVWrE8rNVIv2A=; b=mgeTzEzw7hh/aq730y64HI3M4V4ODrObQAkQLmk45+8HyZHOXV6lwJD08uRVm6quJV ZH8SWBw4L72YdwY1Re10YhBPn2xBrU4jZooXFBGJlXFkorl1Flq8QXXxYAgbeshdDM+n DZu/7VCH60KuNM/MYqB3lnvIfKIZ2dVBO5Ltk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZROZp+o6I1GlZ0ucFQr952JvoakXvMetafoK8dxFroKjnLJPApHmWIcyycXfdy3C8I 4lXkFPFh7npO97U1Ur36ISnDYLN6XtzymUNTT0fPnmC0Zm5g+AZBNB32FphZQ1DDe0ZS bR/mXk16SpCcN2ZZ1O4nGQgyYm6UVszm1KCzE= Received: by 10.86.76.16 with SMTP id y16mr17033757fga.65.1231788502201; Mon, 12 Jan 2009 11:28:22 -0800 (PST) Received: from gmail.com (sdferwer192.net.autocom.pl [77.236.1.49]) by mx.google.com with ESMTPS id d4sm7871468fga.31.2009.01.12.11.28.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 11:28:21 -0800 (PST) Date: Mon, 12 Jan 2009 20:28:22 +0100 From: Mateusz Guzik To: Alexej Sokolov Message-ID: <20090112192822.GB2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 19:28:24 -0000 On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > 2009/1/12 Mateusz Guzik > > > > Mutexes have owners. It panics on loading because processes cannot > > > > return to userland with locks held. > > > > > > i am not sure about it. Some time ago i implemented a charecter device > > with > > > two syscalls: write, read. "write" lock the mutex and "read" unlock it. > > The > > > user space programm opens device, then mekes "write" (mutex will held in > > > kernel), goes back to user space, then makes "read" (mutex will unlocked > > in > > > kernel) and it all run without panic. If needed i can post the source > > code. > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > kernel panicked like this (while loading your module): > > > > System call kldload returning with 1 locks held > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > systcall (for example "write") and to unlock it in other ("read"). > Do you mean it is "very bad idea" to do something like this ? > I could not find anywhere in the documentation that a it is not allowed to > return in the user space with a locked mutex. > Can you give me some reference on man page, source code or something other > from where can I understand it ? > Locks are used to synchronize access to data changeable by other threads. I don't know if I'm correct here, but let's consider the following situation: your process grabs a mutex and returns to userland, then it's killed due to segmentation violation. This mutex should (and can be) unlocked on exit, but the state of data protected by it is unknown. (For example your process was killed while inserting something into linked list.) So even if the kernel could be guided to unlock it on exit, the data could be in inconsistent state. Also your locking scheme doesn't make much sense. Consider this: proc1 calls write on your cdev but in the meantime proc2 calls read on your cdev So you get panic because proc1 was writing some data. (attempt to unlock mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would read inconsistend data because proc1 was writing. Proper solution is to lock mutex before and after reading/writing data. For working example you can check how devctl was implemented (sys/kern/subr_bus.c). -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 19:50:00 2009 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 75F0F1065670 for ; Mon, 12 Jan 2009 19:50:00 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id 4105A8FC13 for ; Mon, 12 Jan 2009 19:50:00 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 24so13959201wfg.7 for ; Mon, 12 Jan 2009 11:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=8oU7DRFGMPT6i6zdKP38ih+N8oquGOYeStB28+Cn8+I=; b=FBbtwawTI/hmUjbIYkxUsA+zY7ibw7WAAoYfMgmvH4GZ2XTQ9i5J2dkKF41f+D0FTW HbIsQ0kcYd2ll/i2FglEi6DYqrgqDIzNVtZ2Pft4M/7lSJUzk3ukIV63nU8oAnqn+zEb RiIhOxf9Gp6AKTGURk3LDmkMeQN+QhbPQy6YI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=bI5G39JnZbUxgl28BKJK3+xZtFHzvP7aSnQKwCFjo6TcCLsmH20a5AsiImUk6xqOTQ u5xqFwJGrlYxMEpgnns5ncdzULvH8qogkPH5eNgQQAtQx7+rtQczhaJ1KhW0EiVjYhWK zF1uilVsfHGlapi1uylhTAasXlRp89WyrmDoE= Received: by 10.114.148.2 with SMTP id v2mr19740598wad.26.1231789799676; Mon, 12 Jan 2009 11:49:59 -0800 (PST) Received: by 10.114.202.10 with HTTP; Mon, 12 Jan 2009 11:49:59 -0800 (PST) Message-ID: <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> Date: Mon, 12 Jan 2009 20:49:59 +0100 From: "Alexej Sokolov" To: "Mateusz Guzik" In-Reply-To: <20090112192822.GB2102@skucha> MIME-Version: 1.0 References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 19:50:00 -0000 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > 2009/1/12 Mateusz Guzik > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > 2009/1/12 Mateusz Guzik > > > > > Mutexes have owners. It panics on loading because processes cannot > > > > > return to userland with locks held. > > > > > > > > i am not sure about it. Some time ago i implemented a charecter > device > > > with > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock > it. > > > The > > > > user space programm opens device, then mekes "write" (mutex will held > in > > > > kernel), goes back to user space, then makes "read" (mutex will > unlocked > > > in > > > > kernel) and it all run without panic. If needed i can post the source > > > code. > > > > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > > kernel panicked like this (while loading your module): > > > > > > System call kldload returning with 1 locks held > > > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > > systcall (for example "write") and to unlock it in other ("read"). > > Do you mean it is "very bad idea" to do something like this ? > > I could not find anywhere in the documentation that a it is not allowed > to > > return in the user space with a locked mutex. > > Can you give me some reference on man page, source code or something > other > > from where can I understand it ? > > > > Locks are used to synchronize access to data changeable by other > threads. I don't know if I'm correct here, but let's consider the > following situation: your process grabs a mutex and returns to userland, > then it's killed due to segmentation violation. This mutex should (and > can be) unlocked on exit, but the state of data protected by it is > unknown. (For example your process was killed while inserting something > into linked list.) So even if the kernel could be guided to unlock it on > exit, the data could be in inconsistent state. > > Also your locking scheme doesn't make much sense. Consider this: > proc1 calls write on your cdev > but in the meantime > proc2 calls read on your cdev > > So you get panic because proc1 was writing some data. (attempt to unlock > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would > read inconsistend data because proc1 was writing. Proper solution is to > lock mutex before and after reading/writing data. For working example > you can check how devctl was implemented (sys/kern/subr_bus.c). > > -- > Mateusz Guzik > Ok , now I understaand it. If a thread return to user space with locked mutex, kernel doesen't know if the thread will come back to unlock it. It is really unsafe return to userspace without unlocking of helding mutexes. Thanks a lot for your help. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 19:50:55 2009 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 5E4EC1065672 for ; Mon, 12 Jan 2009 19:50:55 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by mx1.freebsd.org (Postfix) with ESMTP id C53428FC2A for ; Mon, 12 Jan 2009 19:50:54 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by an-out-0708.google.com with SMTP id c2so3836416anc.13 for ; Mon, 12 Jan 2009 11:50:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=xkBQAkrwFStE09cnAekttR/ArjpyW1EtX88DCdg2k2E=; b=iu7mupMr/1ceiS6G8IuRbpjZRJxepwqfiEIh6aZaTs0ND0kNB3n3vY+KzPRJzIN0dc 5eaL1pUlHa3bgrafC+Z+mUeJJxgd6BJQeCG35J4LOhLC7DcQk88Dq/3yONB1WUb+nIEj uJCPs+Im9Vldsa3PVWPBayO9zWsvZ49F+e7Dw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=evakJsUU+rK9hW0/zdTOCtH/cmaVhjrz3dajNe9NEp+ghgcQO8FpdlKm9r5YYEVd3Y Y3Cl/HJ83ulP807tMwoRz35IITk3efwpSlfK+0lSjjf6ZBUW3ugamXFvfPT0Lq0ILCG6 tGn46+BHIxINZ/HTlngr4sNKtgYSrISodVBeg= Received: by 10.100.216.10 with SMTP id o10mr14513605ang.125.1231789854135; Mon, 12 Jan 2009 11:50:54 -0800 (PST) Received: by 10.100.8.2 with HTTP; Mon, 12 Jan 2009 11:50:53 -0800 (PST) Message-ID: <671bb5fc0901121150s1951ab0cm646818ab3d12134e@mail.gmail.com> Date: Mon, 12 Jan 2009 20:50:53 +0100 From: "Alexej Sokolov" To: "Mateusz Guzik" In-Reply-To: <20090112192822.GB2102@skucha> MIME-Version: 1.0 References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 19:50:55 -0000 2009/1/12 Mateusz Guzik > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > 2009/1/12 Mateusz Guzik > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > 2009/1/12 Mateusz Guzik > > > > > Mutexes have owners. It panics on loading because processes cannot > > > > > return to userland with locks held. > > > > > > > > i am not sure about it. Some time ago i implemented a charecter > device > > > with > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock > it. > > > The > > > > user space programm opens device, then mekes "write" (mutex will held > in > > > > kernel), goes back to user space, then makes "read" (mutex will > unlocked > > > in > > > > kernel) and it all run without panic. If needed i can post the source > > > code. > > > > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > > kernel panicked like this (while loading your module): > > > > > > System call kldload returning with 1 locks held > > > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > > systcall (for example "write") and to unlock it in other ("read"). > > Do you mean it is "very bad idea" to do something like this ? > > I could not find anywhere in the documentation that a it is not allowed > to > > return in the user space with a locked mutex. > > Can you give me some reference on man page, source code or something > other > > from where can I understand it ? > > > > Locks are used to synchronize access to data changeable by other > threads. I don't know if I'm correct here, but let's consider the > following situation: your process grabs a mutex and returns to userland, > then it's killed due to segmentation violation. This mutex should (and > can be) unlocked on exit, but the state of data protected by it is > unknown. (For example your process was killed while inserting something > into linked list.) So even if the kernel could be guided to unlock it on > exit, the data could be in inconsistent state. > > Also your locking scheme doesn't make much sense. Consider this: > proc1 calls write on your cdev > but in the meantime > proc2 calls read on your cdev > > So you get panic because proc1 was writing some data. (attempt to unlock > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would > read inconsistend data because proc1 was writing. Proper solution is to > lock mutex before and after reading/writing data. For working example > you can check how devctl was implemented (sys/kern/subr_bus.c). > > -- > Mateusz Guzik > Ok , now I understaand it. If a thread return to user space with locked mutex, kernel doesen't know if the thread will come back to unlock it. It is really unsafe return to userspace without unlocking of helding mutexes. Thanks a lot for your help. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 20:07:14 2009 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 D73A21065729 for ; Mon, 12 Jan 2009 20:07:14 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 439158FC17 for ; Mon, 12 Jan 2009 20:07:13 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id n0CGHiok027807; Mon, 12 Jan 2009 18:17:44 +0200 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id n0CGHihE014383; Mon, 12 Jan 2009 18:17:44 +0200 Received: from kobe.laptop (adsl45-26.kln.forthnet.gr [77.49.172.26]) by MX-IN-01.forthnet.gr (8.14.3/8.14.3) with ESMTP id n0CGHfTm021988; Mon, 12 Jan 2009 18:17:42 +0200 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=keramida@ceid.upatras.gr; spf=neutral Authentication-Results: MX-IN-01.forthnet.gr header.from=keramida@ceid.upatras.gr; sender-id=neutral Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n0CGHfRA037763; Mon, 12 Jan 2009 18:17:41 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n0CGHcTv037756; Mon, 12 Jan 2009 18:17:38 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: "Andrew Brampton" References: <20090112145131.GA4375@svzserv.kemerovo.su> Date: Mon, 12 Jan 2009 18:17:38 +0200 In-Reply-To: (Andrew Brampton's message of "Mon, 12 Jan 2009 14:56:21 +0000") Message-ID: <873afolcrh.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: hackers@freebsd.org, Eugene Grosbein Subject: Re: Determine if a kernel is built with a specific option? 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, 12 Jan 2009 20:07:15 -0000 On Mon, 12 Jan 2009 14:56:21 +0000, "Andrew Brampton" wrote: > If you were going to do this, would you make it a configure flag... ie > --enable-polling... That way it doesn't matter if the build box is > different? If both choices are available (i.e. no header files are missing, no link-time libraries are unavailable, and so on), I'd probably make it a runtime option: * A configure-time flag to set the 'default' and * A runtime option to explicitly specify the current preference when the program runs. This seems a bit more flexible, and does not require an expensive ``go back to your vendor, and ask for a special build-time option'' cycle to test different setups when a field installation is done. From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 20:21:54 2009 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 375DD1065742 for ; Mon, 12 Jan 2009 20:21:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 9C6898FC22 for ; Mon, 12 Jan 2009 20:21:53 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so3791635fgb.35 for ; Mon, 12 Jan 2009 12:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=HRdgKe5sCf21eK4G1xdWvnHRNZEEWJTYjbFEu28ozX0=; b=jVwkyDMsfPOLQjg59Vyuz0CMYYdmlj4vURF4lqrpEfjEzQGVxfd+9+Hl0m3MfzueOa DZ59i5wJ62WDiwSfgwRw6/98c/u1PN0WxVUAXh7sNnvkQlfAM7ujSQ/qRyKbshGax/D7 iq0p78LY3gwcZMnAbiEVO9CdZLBKG5wzw8GO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=BAy5bydNusrP2Hdt3Dk8NLnDxVfHMgY3Rpyr97pGwN2VI1bK3Y8AUG/cERGRAtJt6h kytTqaYJeG74bYujafxdA2QcS9FmvqsxlPvsLySxuxvbRwo50OPL7Mc7c0NGDwTVIjaL Sga4Vwh+SxMVLMU4VhhAaFSoCJ4l7881/beAU= Received: by 10.86.4.14 with SMTP id 14mr17078534fgd.76.1231791712588; Mon, 12 Jan 2009 12:21:52 -0800 (PST) Received: from gmail.com (sdferwer192.net.autocom.pl [77.236.1.49]) by mx.google.com with ESMTPS id d4sm28165477fga.41.2009.01.12.12.21.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Jan 2009 12:21:52 -0800 (PST) Date: Mon, 12 Jan 2009 21:21:53 +0100 From: Mateusz Guzik To: Alexej Sokolov Message-ID: <20090112202152.GC2102@skucha> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 20:22:09 -0000 On Mon, Jan 12, 2009 at 08:49:59PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > > > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > > 2009/1/12 Mateusz Guzik > > > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > > 2009/1/12 Mateusz Guzik > > > > > > Mutexes have owners. It panics on loading because processes cannot > > > > > > return to userland with locks held. > > > > > > > > > > i am not sure about it. Some time ago i implemented a charecter > > device > > > > with > > > > > two syscalls: write, read. "write" lock the mutex and "read" unlock > > it. > > > > The > > > > > user space programm opens device, then mekes "write" (mutex will held > > in > > > > > kernel), goes back to user space, then makes "read" (mutex will > > unlocked > > > > in > > > > > kernel) and it all run without panic. If needed i can post the source > > > > code. > > > > > > > > > > > > > Do you have kernel compiled with WITNESS? At least on -CURRENT the > > > > kernel panicked like this (while loading your module): > > > > > > > > System call kldload returning with 1 locks held > > > > > > My kernel is compiled without WITNESS. And it allows to lock mutex in one > > > systcall (for example "write") and to unlock it in other ("read"). > > > Do you mean it is "very bad idea" to do something like this ? > > > I could not find anywhere in the documentation that a it is not allowed > > to > > > return in the user space with a locked mutex. > > > Can you give me some reference on man page, source code or something > > other > > > from where can I understand it ? > > > > > > > Locks are used to synchronize access to data changeable by other > > threads. I don't know if I'm correct here, but let's consider the > > following situation: your process grabs a mutex and returns to userland, > > then it's killed due to segmentation violation. This mutex should (and > > can be) unlocked on exit, but the state of data protected by it is > > unknown. (For example your process was killed while inserting something > > into linked list.) So even if the kernel could be guided to unlock it on > > exit, the data could be in inconsistent state. > > > > Also your locking scheme doesn't make much sense. Consider this: > > proc1 calls write on your cdev > > but in the meantime > > proc2 calls read on your cdev > > > > So you get panic because proc1 was writing some data. (attempt to unlock > > mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would > > read inconsistend data because proc1 was writing. Proper solution is to > > lock mutex before and after reading/writing data. For working example > > you can check how devctl was implemented (sys/kern/subr_bus.c). > > > > -- > > Mateusz Guzik > > > > Ok , now I understaand it. > If a thread return to user space with locked mutex, kernel doesen't know if > the thread will come back to unlock it. It is really unsafe return to > userspace without unlocking of helding mutexes. > Provided example is really unfortunate. :/ Forget it. (And a proper solution for your locking issue is of course to lock mutex before read/write and *unlock* it after it's done. (missed that word in my previous mail)) Threads in userland holding kernel locks would lead to panics in a lot of situations. For example you already have sleepable mutex and call some kernel function that acquires sx lock - the kernel panics as this is not allowed combination. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 12 20:41:01 2009 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 E34A2106564A for ; Mon, 12 Jan 2009 20:41:00 +0000 (UTC) (envelope-from prvs=julian=2560a13b2@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id CC1488FC1C for ; Mon, 12 Jan 2009 20:41:00 +0000 (UTC) (envelope-from prvs=julian=2560a13b2@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.87]) by smtp-outbound.ironport.com with ESMTP; 12 Jan 2009 12:12:25 -0800 Message-ID: <496BA428.8040102@elischer.org> Date: Mon, 12 Jan 2009 12:12:24 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Alexej Sokolov References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> <671bb5fc0901121150s1951ab0cm646818ab3d12134e@mail.gmail.com> In-Reply-To: <671bb5fc0901121150s1951ab0cm646818ab3d12134e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Mateusz Guzik Subject: Re: panic by unlocking of mutex in KLD 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, 12 Jan 2009 20:41:01 -0000 Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik > >> On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: >>> 2009/1/12 Mateusz Guzik >>> >>>> On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: >>>>> 2009/1/12 Mateusz Guzik >>>>>> Mutexes have owners. It panics on loading because processes cannot >>>>>> return to userland with locks held. >>>>> i am not sure about it. Some time ago i implemented a charecter >> device >>>> with >>>>> two syscalls: write, read. "write" lock the mutex and "read" unlock >> it. >>>> The >>>>> user space programm opens device, then mekes "write" (mutex will held >> in >>>>> kernel), goes back to user space, then makes "read" (mutex will >> unlocked >>>> in >>>>> kernel) and it all run without panic. If needed i can post the source >>>> code. >>>> Do you have kernel compiled with WITNESS? At least on -CURRENT the >>>> kernel panicked like this (while loading your module): >>>> >>>> System call kldload returning with 1 locks held >>> My kernel is compiled without WITNESS. And it allows to lock mutex in one >>> systcall (for example "write") and to unlock it in other ("read"). >>> Do you mean it is "very bad idea" to do something like this ? >>> I could not find anywhere in the documentation that a it is not allowed >> to >>> return in the user space with a locked mutex. >>> Can you give me some reference on man page, source code or something >> other >>> from where can I understand it ? >>> >> Locks are used to synchronize access to data changeable by other >> threads. I don't know if I'm correct here, but let's consider the >> following situation: your process grabs a mutex and returns to userland, >> then it's killed due to segmentation violation. This mutex should (and >> can be) unlocked on exit, but the state of data protected by it is >> unknown. (For example your process was killed while inserting something >> into linked list.) So even if the kernel could be guided to unlock it on >> exit, the data could be in inconsistent state. >> >> Also your locking scheme doesn't make much sense. Consider this: >> proc1 calls write on your cdev >> but in the meantime >> proc2 calls read on your cdev >> >> So you get panic because proc1 was writing some data. (attempt to unlock >> mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would >> read inconsistend data because proc1 was writing. Proper solution is to >> lock mutex before and after reading/writing data. For working example >> you can check how devctl was implemented (sys/kern/subr_bus.c). >> >> -- >> Mateusz Guzik >> > > Ok , now I understaand it. > If a thread return to user space with locked mutex, kernel doesen't know if > the thread will come back to unlock it. It is really unsafe return to > userspace without unlocking of helding mutexes. The system should panic if you try, and at least in debu mode it does chack and panic. I'm not sure if it does if all debugging is turned off. > > Thanks a lot for your help. > _______________________________________________ > 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 Tue Jan 13 02:54:58 2009 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 F00E5106566B for ; Tue, 13 Jan 2009 02:54:58 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id C24E88FC08 for ; Tue, 13 Jan 2009 02:54:57 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-81-192.phlapa.east.verizon.net [141.151.81.192]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 040E062173; Tue, 13 Jan 2009 11:54:55 +0900 (JST) Date: Mon, 12 Jan 2009 21:53:22 -0500 From: Yoshihiro Ota To: Christoph Mallon Message-Id: <20090112215322.1c284010.ota@j.email.ne.jp> In-Reply-To: <496B1E47.1030403@gmx.de> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> <496B1E47.1030403@gmx.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ota@j.email.ne.jp, hackers@freebsd.org Subject: Re: gcache [was: Re: 3x read to write ratio on dump/restore] 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, 13 Jan 2009 02:54:59 -0000 On Mon, 12 Jan 2009 11:41:11 +0100 Christoph Mallon wrote: > Yoshihiro Ota schrieb: > > Try GEOM Cache(gcache). > > Just a side note: gcache does not seem to have any documentation. "man > gcache" is unsuccessful, geom(8) does not mention it (geom and gcache > are the same hardlinked binary). Is there information about it somewhere? The CVS log was the best document available I took a look back in one year ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/cache/g_cache.h?rev=1.1 About the link, it is also true for many other providors, too. That is based on how GEOM library were implemented and so on. % ls -i /sbin/g* 590 /sbin/gbde 495 /sbin/ggatel 520 /sbin/gpt 592 /sbin/gcache 592 /sbin/gjournal 592 /sbin/graid3 592 /sbin/gconcat 592 /sbin/glabel 524 /sbin/growfs 592 /sbin/geli 592 /sbin/gmirror 592 /sbin/gshsec 592 /sbin/geom 592 /sbin/gmultipath 592 /sbin/gstripe 258 /sbin/ggatec 592 /sbin/gnop 528 /sbin/gvinum 440 /sbin/ggated 592 /sbin/gpart 592 /sbin/gvirstor Hiro From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 13 08:07:27 2009 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 AAD20106566B for ; Tue, 13 Jan 2009 08:07:27 +0000 (UTC) (envelope-from peterjeremy@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id C795B8FC14 for ; Tue, 13 Jan 2009 08:07:26 +0000 (UTC) (envelope-from peterjeremy@optusnet.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0D7uDFU027429 for ; Tue, 13 Jan 2009 18:56:13 +1100 Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0D7u13r026249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 18:56:05 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n0D7u19F032057; Tue, 13 Jan 2009 18:56:01 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n0D7u0OH032056; Tue, 13 Jan 2009 18:56:00 +1100 (EST) (envelope-from peter) Date: Tue, 13 Jan 2009 18:56:00 +1100 From: Peter Jeremy To: Yoshihiro Ota Message-ID: <20090113075600.GA31919@server.vk2pj.dyndns.org> References: <20090109.095027.-1672857892.imp@bsdimp.com> <20090111041710.GB5661@server.vk2pj.dyndns.org> <20090112050537.f423215c.ota@j.email.ne.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <20090112050537.f423215c.ota@j.email.ne.jp> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Tue, 13 Jan 2009 12:19:57 +0000 Cc: hackers@freebsd.org Subject: Re: 3x read to write ratio on dump/restore 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, 13 Jan 2009 08:07:27 -0000 --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jan-12 05:05:37 -0500, Yoshihiro Ota wrote: >Jermey, I tought you wrote this, >http://lists.freebsd.org/pipermail/freebsd-hackers/2007-February/019666.ht= ml. Yes, that is my message. I had forgotten it. If you dig back further, you'll find that I looked into the poor read behaviour of dump before the caching code existed (and one of the outcomes of that thread was the current caching code). --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklsSRAACgkQ/opHv/APuIfBiQCbBd2Lcoh8TCRq8bV618vXvHS+ /AcAn3naeJQEMbIvEZLnvw2bSvuIAdi5 =iDLR -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 15:29:34 2009 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 E606C1065675; Wed, 14 Jan 2009 15:29:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 881F58FC21; Wed, 14 Jan 2009 15:29:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LN7gS-0005wa-Lc; Wed, 14 Jan 2009 17:29:32 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n0EFTTOr005206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jan 2009 17:29:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n0EFTT7D070851; Wed, 14 Jan 2009 17:29:29 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n0EFTTkS070850; Wed, 14 Jan 2009 17:29:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 14 Jan 2009 17:29:29 +0200 From: Kostik Belousov To: freebsd-stable@freebsd.org Message-ID: <20090114152929.GO2247@deviant.kiev.zoral.com.ua> References: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJAv8lSwuaQsYd0G" Content-Disposition: inline In-Reply-To: <75a268720901090839q406ed8f3g8d09e83a9a452415@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LN7gS-0005wa-Lc 67d0892b47241b544b90df5dbcb15952 X-Terabit: YES Cc: Omer Faruk Sen , freebsd-hackers@freebsd.org Subject: Re: kernel dump with 7.1-RELEASE 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, 14 Jan 2009 15:29:36 -0000 --oJAv8lSwuaQsYd0G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 09, 2009 at 06:39:53PM +0200, Omer Faruk Sen wrote: > Hi, >=20 > I am having kernel dump with FreeBSD 7.1: >=20 > Here is crashinfo output of it (Actually i don't know the state of > crashinfo in Fbsd 7.1) >=20 > 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >=20 >=20 >=20 > panic: semexit - semid not allocated >=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "amd64-marcel-freebsd"... >=20 > Unread portion of the kernel message buffer: > Physical memory: 8173 MB > Dumping 437 MB: 422 406 390 374 358 342 326 310 294 278 262 246 230 > 214 198 182 166 150 134 118 102 86 70 54 38 22 6 >=20 > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:195 > #1 0x0000000000000004 in ?? () > #2 0xffffffff804b4ce9 in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:418 > #3 0xffffffff804b50f2 in panic (fmt=3D0x104
) > at /usr/src/sys/kern/kern_shutdown.c:574 > #4 0xffffffff804f846d in semexit_myhook (arg=3DVariable "arg" is not ava= ilable. > ) > at /usr/src/sys/kern/sysv_sem.c:1328 > #5 0xffffffff80490dbc in exit1 (td=3D0xffffff000995f370, rv=3D0) > at /usr/src/sys/kern/kern_exit.c:244 > #6 0xffffffff8049239e in sys_exit (td=3DVariable "td" is not available. > ) at /usr/src/sys/kern/kern_exit.c:109 > #7 0xffffffff8078a7c7 in syscall (frame=3D0xffffffffb0d4ac80) > at /usr/src/sys/amd64/amd64/trap.c:907 > #8 0xffffffff8077088b in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:330 > #9 0x0000000800a2a30c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) The change that is believed to fix the reported panic is committed as r187223 to HEAD. MFC is set to 1 month, because, mmm, because. The MFC requires mostly mechanical changes of the MAC hook names. --oJAv8lSwuaQsYd0G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkluBNgACgkQC3+MBN1Mb4i13wCgz0ReCvIsK93lCuIZhj+Hgokr UugAnjcstSMmRib2kRVNNVGYThWf3+dP =mza0 -----END PGP SIGNATURE----- --oJAv8lSwuaQsYd0G-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 18:01:45 2009 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 2AF12106564A for ; Wed, 14 Jan 2009 18:01:45 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id AB5428FC1B for ; Wed, 14 Jan 2009 18:01:44 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: by bwz13 with SMTP id 13so2304252bwz.19 for ; Wed, 14 Jan 2009 10:01:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=7q+Hx+IhJN4LlXH7TlfH9pTyaZyTRaSALUZiBCwd0fw=; b=vhzeBv1N7oyI8P3uYDcMF/b94BqkAuzbY9AGdGKuuu8OccWOuAJX70r3gHfvSL5J/Y TRrEivo46MId8zh8Ixt/EtcxT9WPFpkv7pJk/f3Q0yepF2vwNmdCBDoXIjdocM8AywHg pxATypEK3zvHKcygjwxeKezLhj22rlrpGRp8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=J2QTDgwecLBgDWCtyimY1CDG1gIXYdtiFhdTZq0ke0jZdu7K0t1LGEfzuTIOdiWXIo sPcSi1J6R8ciqe0DxKp+sJ8eQhtYlTbhLZ4MpOnCVAJ4TObg+XzmFAS0xTOUVBk/TGbx eKNRkoplOlhJY6QPdKPhX0uYeD7Ec7YvVMHzE= MIME-Version: 1.0 Received: by 10.103.6.18 with SMTP id j18mr192490mui.33.1231954327383; Wed, 14 Jan 2009 09:32:07 -0800 (PST) Date: Wed, 14 Jan 2009 11:32:07 -0600 Message-ID: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> From: Biks N To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: how ipfw firewall is implemented in the kernel 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, 14 Jan 2009 18:01:45 -0000 Hi, Can anyone please help me understand how the IPFW firewall is implemented in the kernel. I have created new ACTIONS in ipfw. I have already implemented in the userland. Now i need to check the IPFW rule list (in ip_input.c and in ip_output.c) and call a custom routine if there is a match to those rules. I would really appreciate if anyone could point me to right direction/reference. thanks From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 19:22:41 2009 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 3350C1065690 for ; Wed, 14 Jan 2009 19:22:41 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id B094F8FC18 for ; Wed, 14 Jan 2009 19:22:40 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so408420fgb.35 for ; Wed, 14 Jan 2009 11:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:organization:from :original-sender:message-id:lines:user-agent:mime-version :content-type:date; bh=tNp290Fc5texKQLKtzU/Z/f8EtS8hwsu42WihWHcgWw=; b=MUhFfbmuoFOaf+q2n1Gf0rRsnTWADW9lg9UWatOqUTJgvpBh4QaKzuCAORBGrtgzof JZGrie1lV22SSxd7YDl+jlmQ+Bi1mNXDU5i4ZZ+EKCzpx+CtHxh/OljUoUPnNF3TLNhs 7xGPw7jcRP5loDhGeN5s/hpRwqKJujo+kdvVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:organization:from:original-sender:message-id:lines :user-agent:mime-version:content-type:date; b=wJMjNs1dq07vmdDWJEH9VYxpBA8bHwChX6zga9Ux2S/zrKbxIQae2nz/t11JHrqYRI FYW+ETfmu8cERLSjOCUVXOFxxqE8cq0oglnyvK0i9qgqKBuYH8RWDuYjMMSZgZ8t+nF6 L1CiMb+EYmtztfJZ03Wp1CFy0pjZWjL2rG2wo= Received: by 10.86.53.8 with SMTP id b8mr869599fga.58.1231959137194; Wed, 14 Jan 2009 10:52:17 -0800 (PST) Received: from localhost ([195.69.244.128]) by mx.google.com with ESMTPS id 12sm40352956fgg.26.2009.01.14.10.52.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Jan 2009 10:52:16 -0800 (PST) To: freebsd-hackers@freebsd.org Organization: TOA Ukraine From: Mikolaj Golub Original-Sender: Mikolaj Golub Message-ID: <86iqohoh4b.fsf@kopusha.onet> Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jan 2009 10:52:16 -0800 (PST) Subject: How to calculate current kmem usage? 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, 14 Jan 2009 19:22:43 -0000 Hi, Could someone explain please, how to calculate current kernel memory utilization, one that is limited by vm.kmem_size? There is a script on http://wiki.freebsd.org/ZFSTuningGuide that calculates kernel memory utilization by summing the values from `kldstat' output (TEXT) and the values from `vmstat -m' output (DATA). Are these the only data needed for proper calculation of kmem? What about zone(9) allocations? Shouldn't data from `vmstat -z' output be added to calculate kmem usage? The reason I am asking about this is that we are tuning vfs.ufs.dirhash_maxmem on our storage servers. By default it is 2Mb that looks like very small value. We increased it to 30Mb and all 30Mb were filled very quickly, so we are considering to increase it more but we need the method to monitor the system resources we can hit (we use the default value for vm.kmem_size 300Mb that is not so large). So what the system parameters we should monitor increasing vfs.ufs.dirhash_maxmem? I see the growth of dirhash_maxmem corresponds the growth of wired memory. Currently wired is 222M on this host. Isn't wired memory limited by vm.kmem_size or it is limited only by vm.kvm_size? BTW, how reasonably large the value of vfs.ufs.dirhash_maxmem can be? I have seen recommendations to increase it until it all in usage, but may be there are other considerations I should take into account? We use rsync on our storage servers to synchronize data between the hosts and I suppose this is the main dirhash_mem eater. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 19:42:22 2009 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 ABBFC1065670 for ; Wed, 14 Jan 2009 19:42:22 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.freebsd.org (Postfix) with ESMTP id 3EB098FC1A for ; Wed, 14 Jan 2009 19:42:22 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-024-080.pools.arcor-ip.net [88.66.24.80]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1LNBd701ni-0005AF; Wed, 14 Jan 2009 20:42:21 +0100 Received: (qmail 40104 invoked from network); 14 Jan 2009 19:42:20 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by laiers.local with SMTP; 14 Jan 2009 19:42:20 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Wed, 14 Jan 2009 20:42:20 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> In-Reply-To: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200901142042.20449.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19h1xXgJzrAFlNM19/j22/pMfw1Vth0k2rrqYq JeiTOrcPcs07eu+Q0WqLdM++BnidmeXlDYk3zEo8S4q1gnA8Bp kLzxU6y5REtO71q4gUV9Q== Cc: Biks N Subject: Re: how ipfw firewall is implemented in the kernel 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, 14 Jan 2009 19:42:23 -0000 On Wednesday 14 January 2009 18:32:07 Biks N wrote: > Hi, > > Can anyone please help me understand how the IPFW firewall is > implemented in the kernel. > > I have created new ACTIONS in ipfw. I have already implemented in the > userland. > > Now i need to check the IPFW rule list (in ip_input.c and in > ip_output.c) and call a custom routine if there is a match to those > rules. > > I would really appreciate if anyone could point me to right > direction/reference. ipfw is hooked into the pfil(9) hook points in ip_{in,out}put() (look for=20 calls to pfil_run_hooks() in the respective files). =46rom there the call path goes on to the ipfw_check_* functions defined in= =20 netinet/ip_fw_pfil.c =46inally ipfw_chk() in netinet/ip_fw2.c where the ruleset is processed and= =20 where you should add your required processing. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 20:20:33 2009 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 566611065676 for ; Wed, 14 Jan 2009 20:20:33 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by mx1.freebsd.org (Postfix) with ESMTP id A2DE38FC20 for ; Wed, 14 Jan 2009 20:20:32 +0000 (UTC) (envelope-from freebsd.dev@gmail.com) Received: by fxm4 with SMTP id 4so171626fxm.19 for ; Wed, 14 Jan 2009 12:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:cc:content-type :content-transfer-encoding; bh=HToB+h78fJLN+VjYi1v0lSaDsE7z+CVWp4NGR6Z0j5E=; b=R7W30fbKC2DJq6SPr/U29TeSWj3F/cInnRW2ooieSRI2DqZ3uT9CUMdYWbcowxTown IkLRX1K5Jo0InCpDIbOvDDmAPOhbdTI/BPt9BEk+FDkWCQPFjwv9k1SpJkjGLdsZVW+P wnzBEiEVpXBfuyYeVECdkW5Ab6o/vEEvuAguQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:content-transfer-encoding; b=FyNNMKK73tm4Wv9aWAyAkzQhh/00J2iN+kb8WoEzX7X3zg++vbuXGfhDppeeWC+8NF 669al3UMa5MiOjMaUpjNFRB7aq7kHISDeR4e9+sJuJSO04D8eXR61+uCX1eTwWZWmGaK umOQ96ngxFhxw/JXNsjWGkVl/sb+A194nGSuU= MIME-Version: 1.0 Received: by 10.103.221.5 with SMTP id y5mr275149muq.66.1231964431325; Wed, 14 Jan 2009 12:20:31 -0800 (PST) In-Reply-To: <200901142042.20449.max@love2party.net> References: <50cd4e5f0901140932x5ed9fd09p7ef4fb35095a59a2@mail.gmail.com> <200901142042.20449.max@love2party.net> Date: Wed, 14 Jan 2009 14:20:31 -0600 Message-ID: <50cd4e5f0901141220o531c6a8hbb5d8097e5b22e6a@mail.gmail.com> From: Biks N Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: how ipfw firewall is implemented in the kernel 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, 14 Jan 2009 20:20:33 -0000 Thanks a lot! That was really very helpful!!! On Wed, Jan 14, 2009 at 1:42 PM, Max Laier wrote: > On Wednesday 14 January 2009 18:32:07 Biks N wrote: >> Hi, >> >> Can anyone please help me understand how the IPFW firewall is >> implemented in the kernel. >> >> I have created new ACTIONS in ipfw. I have already implemented in the >> userland. >> >> Now i need to check the IPFW rule list (in ip_input.c and in >> ip_output.c) and call a custom routine if there is a match to those >> rules. >> >> I would really appreciate if anyone could point me to right >> direction/reference. > > ipfw is hooked into the pfil(9) hook points in ip_{in,out}put() (look for > calls to pfil_run_hooks() in the respective files). > > From there the call path goes on to the ipfw_check_* functions defined in > netinet/ip_fw_pfil.c > > Finally ipfw_chk() in netinet/ip_fw2.c where the ruleset is processed and > where you should add your required processing. > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News > From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 05:30:34 2009 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 1EE33106564A for ; Thu, 15 Jan 2009 05:30:34 +0000 (UTC) (envelope-from shilp.kamal@yahoo.com) Received: from n61.bullet.mail.sp1.yahoo.com (n61.bullet.mail.sp1.yahoo.com [98.136.44.37]) by mx1.freebsd.org (Postfix) with SMTP id D92228FC08 for ; Thu, 15 Jan 2009 05:30:33 +0000 (UTC) (envelope-from shilp.kamal@yahoo.com) Received: from [69.147.65.149] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 15 Jan 2009 05:30:33 -0000 Received: from [69.147.65.152] by t9.bullet.mail.sp1.yahoo.com with NNFMP; 15 Jan 2009 05:30:33 -0000 Received: from [127.0.0.1] by omp400.mail.sp1.yahoo.com with NNFMP; 15 Jan 2009 05:30:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 645347.2737.bm@omp400.mail.sp1.yahoo.com Received: (qmail 25846 invoked by uid 60001); 15 Jan 2009 05:30:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=at6qRuYNvBd3ty3dVlvFVVnqX/IGqYcDhI6huGdh33xGaCIGrmuJPJmpkZamTaVGty0qyXc7GruZ7px2koQ28W4apiU458d98RyI6spNyn43vDRQ8QtDMCN2hVvZ1TA+mvZ3V8ZOSvTv6fBpGTq/HtFIkLqGTmztpGBl8uXG3Yk=; X-YMail-OSG: PRxAWWYVM1kYAPOH2uad8rDqdz7.QyN_e52q19plptCMNyn4CJj4Jtv3JBT9skoUBRg1sLDgI_1R4bglZFrUV9T9T0dl_yu12yQDKKqYF5v7XNqv894pMgVX7OzR2z9U8r_Xna2CGteJwKcWg_LUVSLnFw0- Received: from [130.86.72.24] by web45404.mail.sp1.yahoo.com via HTTP; Wed, 14 Jan 2009 21:30:33 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 14 Jan 2009 21:30:33 -0800 (PST) From: Kamlesh Patel To: Hackers freeBSD MIME-Version: 1.0 Message-ID: <550328.24456.qm@web45404.mail.sp1.yahoo.com> X-Mailman-Approved-At: Thu, 15 Jan 2009 05:51:05 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: panic: Going nowhere without my init! X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shilp.kamal@yahoo.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 05:30:34 -0000 Hi All, Thanks for answering my previous question "FreeBSD kernel Debugging tools f= or Virtual Memory Module", thank you Dag-Erling Sm=F8rgrav. Today i made a comment in Getpid() function of sys/kern/kern_prot.c file an= d i got error of=20 ---------------------------------------------------------------------------= ----- panic: Going nowhere without my init!=20 Can not dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort-------= ------------------------------------------------------------------------- Could anyone help me in solving this error? Thanks Kamlesh=20 MS CS, CSUS =0A=0A=0A From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 06:12:30 2009 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 EAB3F106564A for ; Thu, 15 Jan 2009 06:12:30 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 700708FC08 for ; Thu, 15 Jan 2009 06:12:30 +0000 (UTC) (envelope-from callumgibson@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n0F2cj7j025044 for ; Thu, 15 Jan 2009 13:38:45 +1100 Received: from omma.gibson.athome (c122-106-69-195.rivrw1.nsw.optusnet.com.au [122.106.69.195]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with SMTP id n0F2chYq027057 for ; Thu, 15 Jan 2009 13:38:44 +1100 Received: (qmail 31437 invoked by uid 107); 15 Jan 2009 13:38:43 +1100 Date: 15 Jan 2009 13:38:43 +1100 Date: Thu, 15 Jan 2009 13:38:43 +1100 From: Callum Gibson To: freebsd-hackers@freebsd.org Message-ID: <20090115023843.GA30963@omma.gibson.athome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: bg_fsck ignores fstab pass numbers? 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, 15 Jan 2009 06:12:31 -0000 Hi, I've noticed that fsck in background mode never checks separate disks in parallel for pass numbers >=2, as described in fsck(8). Taking a look at preen.c:checkfstab() (if I understand correctly) reveals that in background mode it will explicitly check each disk in turn (ironically in the foreground), rather than fork them off and queue up waiting for the children. Does anyone know the reason for that? Is it simply a matter of wanting to lower the impact and resource usage on the system? C -- Callum Gibson @ home http://members.optusnet.com.au/callumgibson/ From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 18:31:01 2009 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 65ECA1065672 for ; Thu, 15 Jan 2009 18:31:01 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id 347078FC12 for ; Thu, 15 Jan 2009 18:31:01 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 24so1316703wfg.7 for ; Thu, 15 Jan 2009 10:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=mjoF14Wd8TcJsPtFp5SBUzCiF1GcvJ/ageTtAUGxaK8=; b=YZFbXTDHIpFM3rBwP/Z0qkIIIGRvks4EAZCdoY0biec3N0XG+W2Mzbp62F9FJDYKwB 4nl71Ti7JmpUqar/sKRzgQPqCbcmtjuPC1kzelRLZjqCjTc17Bb357uXA4kN5XaK92oN bTs2IMmnRhzxFKfXifwz3V4x95lpYXVZAi0lA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=gmtCqL7FuQKmd1B78fOPy/OyW+iEVjESm+Zc6JccvehApE80/fID5vs1VL+HjfLKgn 0xbr+tw6+X2D0vWD9ue0612ufSuD4HlxevSzFEJZ/mxpJslNhzJxcnpNO26s83byojY4 pb2/QL8IklY2OhAFO7kNLM9o9Rj9CVAS0PtV8= Received: by 10.114.92.2 with SMTP id p2mr1095799wab.122.1232044260646; Thu, 15 Jan 2009 10:31:00 -0800 (PST) Received: by 10.114.202.10 with HTTP; Thu, 15 Jan 2009 10:31:00 -0800 (PST) Message-ID: <671bb5fc0901151031w2da249ebu273dfb9429f82ac7@mail.gmail.com> Date: Thu, 15 Jan 2009 19:31:00 +0100 From: "Alexej Sokolov" To: "Gerry Weaver" In-Reply-To: <20081223000534.f740ca8a@mail01.compvia.com> MIME-Version: 1.0 References: <20081223000534.f740ca8a@mail01.compvia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: How to access kernel memory from user space 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, 15 Jan 2009 18:31:01 -0000 2008/12/23 Gerry Weaver > Hello All, > > I am working on a driver that collects various network statistics via pfil. > I have a simple array of structures that I use to store the statistics. I > also have a user space process that needs to collect these statistics every > second or so. A copy operation from kernel to user space would be too > expensive. Is there a mechanism that would allow me to gain direct access to > my kernel array from user space? The user process would only need read > access. It seems like maybe this could be done with mmap, but since this is > not a character driver, there is no device file etc.. I'm a newbie, so I > apologize if this is something that should be obvious. > > > Thanks in advance, > Gerry > _______________________________________________ > 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" > Hi, some times ago I solve this task. That's my solution in a system call (whithout cdev). Thanx in advance for founded mistakes and possible bugs (-: #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* Arguments for syscall */ struct args { /* Pointer to allocated Buffer */ unsigned int *p; }; /* String to be located in maped buffer */ const char *str = "BSD IS SEXY"; /* Syscall func */ static int syscf(struct thread *td, void *sa) { int error; struct args *uap; vm_offset_t addr; /* Kernel space address */ vm_offset_t user_addr; /* User space address */ struct proc *procp = (struct proc *)td->td_proc; struct vmspace *vms = procp->p_vmspace; uap = (struct args *)sa; PROC_LOCK(procp); user_addr = round_page((vm_offset_t)vms->vm_daddr + lim_max(procp, RLIMIT_DATA)); PROC_UNLOCK(procp); MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO); vm_map_entry_t myentry; vm_object_t myobject; vm_pindex_t mypindex; vm_prot_t myprot; boolean_t mywired; vm_ooffset_t objoffset; vm_map_lookup(&kmem_map, addr, VM_PROT_ALL, &myentry, &myobject, &mypindex, &myprot, &mywired); /* OUT */ vm_map_lookup_done(kmem_map, myentry); printf("---> Syscall: hint for allocating space = 0x%X\n", addr); if (myobject == kmem_object){ printf("---> Syscall: Yes, it is kmem_obj! \n"); } /* Offset in vm_object */ objoffset = addr - myentry->start + myentry->offset; printf("------> Syscall: Object offset = 0x%X \n", (unsigned int)objoffset); /* * Try to map kernel buffer to user space */ vm_object_reference(myobject); /* NEEDED Increment vm_obj references */ error = vm_map_find(&vms->vm_map, myobject, objoffset, (vm_offset_t *)&user_addr, PAGE_SIZE, TRUE, VM_PROT_RW, VM_PROT_RW, MAP_ENTRY_NOFAULT); if (error == KERN_SUCCESS) { /* copy string using kernel address */ size_t len; copystr(str, (void *)addr, 12, &len); /* * Tell to user process it's user space address */ *uap->p = user_addr; /* * Try to read the string using user space address */ printf("String: %s\n", (char *)*uap->p); printf("---> Syscall: user_addr for allocating space = 0x%X\n", user_addr); } return (0); } /* Sysent entity for syscall */ static struct sysent sc_sysent = { 1, /* Number of arguments */ syscf /* Syscall function */ }; /* Offset in sysent[] */ static int offset = NO_SYSCALL; /* Loader */ static int load (struct module *m, int cmd, void *something) { int error = 0; switch(cmd){ case MOD_LOAD: printf("Module with sysc loaded. Offset = %d \n", offset); break; case MOD_UNLOAD: printf("Module with sysc unloaded. Offset = %d \n", offset); break; default: error = EOPNOTSUPP; break; } return (error); } /* Syscall macro*/ SYSCALL_MODULE(fiveg_sysc, &offset, &sc_sysent, load, NULL); If needed, I can post user space program. From owner-freebsd-hackers@FreeBSD.ORG Thu Jan 15 19:22:45 2009 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 D6BDA106564A for ; Thu, 15 Jan 2009 19:22:45 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from mail01.compvia.com (mail01.compvia.com [12.147.132.91]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8FB8FC12 for ; Thu, 15 Jan 2009 19:22:45 +0000 (UTC) (envelope-from gerryw@compvia.com) Received: from [10.10.40.235] ([10.10.40.235]) by mail01.compvia.com (Kerio MailServer 6.5.1); Thu, 15 Jan 2009 13:22:42 -0600 To: "Alexej Sokolov" From: "Gerry Weaver" In-Reply-To: 671bb5fc0901151031w2da249ebu273dfb9429f82ac7@mail.gmail.com Message-ID: <20090115192242.4fce7e00@mail01.compvia.com> Date: Thu, 15 Jan 2009 13:22:42 -0600 X-Mailer: Kerio MailServer 6.5.1 WebMail X-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: How to access kernel memory from user space 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, 15 Jan 2009 19:22:46 -0000 =5F=5F=5F=5F=5F =20 From: Alexej Sokolov [mailto:bsd.quest@googlemail.com] To: Gerry Weaver [mailto:gerryw@compvia.com] Cc: freebsd-hackers@freebsd.org Sent: Thu, 15 Jan 2009 12:31:00 -0600 Subject: Re: How to access kernel memory from user space 2008/12/23 Gerry Weaver Hello All, =20 I am working on a driver that collects various network statistics via = pfil. I have a simple array of structures that I use to store the statis= tics. I also have a user space process that needs to collect these stati= stics every second or so. A copy operation from kernel to user space wou= ld be too expensive. Is there a mechanism that would allow me to gain di= rect access to my kernel array from user space=3F The user process would= only need read access. It seems like maybe this could be done with mmap= , but since this is not a character driver, there is no device file etc.= . I'm a newbie, so I apologize if this is something that should be obvio= us. =20 =20 Thanks in advance, Gerry =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 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" Hi,=20 some times ago I solve this task. That's my solution in a system call (w= hithout cdev).=20 Thanx in advance for founded mistakes and possible bugs (-: #include #include #include #include #include #include #include #include #include =20 #include #include #include #include #include #include =20 =20 /* Arguments for syscall */ struct args { =20 /* Pointer to allocated Buffer */ unsigned int *p; };=20 =20 /* String to be located in maped buffer */ const char *str =3D "BSD IS SEXY"; =20 /* Syscall func */ static int=20 syscf(struct thread *td, void *sa) { int error; struct args *uap; =20 vm=5Foffset=5Ft addr; /* Kernel space address */ vm=5Foffset=5Ft user=5Faddr; /* User space address */ =20 struct proc *procp =3D (struct proc *)td->td=5Fproc; =20 struct vmspace *vms =3D procp->p=5Fvmspace; =20 =20 uap =3D (struct args *)sa; =20 PROC=5FLOCK(procp); user=5Faddr =3D round=5Fpage((vm=5Foffset=5Ft)vms->vm=5Fdaddr += =20 lim=5Fmax(procp, RLIMIT=5FDATA)); PROC=5FUNLOCK(procp); =20 MALLOC(addr, vm=5Foffset=5Ft, PAGE=5FSIZE, M=5FDEVBUF, M=5FWAITO= K | M=5FZERO); =20 vm=5Fmap=5Fentry=5Ft myentry; vm=5Fobject=5Ft myobject; vm=5Fpindex=5Ft mypindex; vm=5Fprot=5Ft myprot; boolean=5Ft mywired; vm=5Fooffset=5Ft objoffset; vm=5Fmap=5Flookup(&kmem=5Fmap, addr, VM=5FPROT=5FALL, &myentry, &myobject, &mypindex, &myprot, &mywire= d); /* OUT */ vm=5Fmap=5Flookup=5Fdone(kmem=5Fmap, myentry); =20 printf("---> Syscall: hint for allocating space =3D 0x%X\n", add= r); =20 if (myobject =3D=3D kmem=5Fobject){ printf("---> Syscall: Yes, it is kmem=5Fobj! \n"); } =20 /* Offset in vm=5Fobject */ =20 objoffset =3D addr - myentry->start + myentry->offset; =20 printf("------> Syscall: Object offset =3D 0x%X \n", (unsigned i= nt)objoffset); =20 /* * Try to map kernel buffer to user space =20 */ vm=5Fobject=5Freference(myobject); /* NEEDED Increment vm=5Fobj = references */ error =3D vm=5Fmap=5Ffind(&vms->vm=5Fmap, myobject, objoffset, (= vm=5Foffset=5Ft *)&user=5Faddr,=20 PAGE=5FSIZE, TRUE, VM=5FPROT=5FRW, VM=5FPROT= =5FRW,=20 MAP=5FENTRY=5FNOFAULT); =20 if (error =3D=3D KERN=5FSUCCESS) { /* copy string using kernel address */ size=5Ft len; copystr(str, (void *)addr, 12, &len);=20 =20 /*=20 * Tell to user process it's user space address=20 */ *uap->p =3D user=5Faddr; =20 /*=20 * Try to read the string using user space address */ =20 printf("String: %s\n", (char *)*uap->p);=20 =20 printf("---> Syscall: user=5Faddr for allocating space = =3D 0x%X\n", user=5Faddr); } =20 return (0); } =20 /* Sysent entity for syscall */ static struct sysent sc=5Fsysent =3D { 1, /* Number of arg= uments */ syscf /* Syscall function *= / }; =20 /* Offset in sysent[] */ static int offset =3D NO=5FSYSCALL; =20 /* Loader */ static int load (struct module *m, int cmd, void *something) { int error =3D 0; switch(cmd){ case MOD=5FLOAD: printf("Module with sysc loaded. Offset =3D %d= \n", offset); break; =20 case MOD=5FUNLOAD: printf("Module with sysc unloaded. Offset =3D %d= \n", offset); break; =20 default: error =3D EOPNOTSUPP; break; } return (error); } =20 /* Syscall macro*/ SYSCALL=5FMODULE(fiveg=5Fsysc, &offset, &sc=5Fsysent, load, NULL); =20 If needed, I can post user space program.=20 Hi, This looks like a very nice solution. I would like to see the user space= code very much. I really appreciate your help! Thanks Again, Gerry =20 From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 07:33:54 2009 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 B808E106566B for ; Fri, 16 Jan 2009 07:33:54 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 426DE8FC0A for ; Fri, 16 Jan 2009 07:33:54 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5086414bwz.19 for ; Thu, 15 Jan 2009 23:33:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lgEYKqhefkheLTs+Dfa/eunthdcfGEN1KOM9XG0//uA=; b=m/f4So25Wn+TVsjqKH8+tetyFXWZCeOSV7q7cZGqXZ+/l755fe++5iVIrmZhgOiJbM 6OFYElXBs26KnBaOv8HZwi0+k+aVy8M7/JIrd/E30jooMX7NZIWRMs3ovHun19uPIGbC AlWCe9kv0YdBJm6gT/YQpnuyNZbBYeUd324P0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XySwPcSbAzJ8Vj9qhGNFFym1i//zkxVkyT03EceJ0JQ2HprW9U/DRniQSmDRiwHVVr NFpaCc6jTOIOTYTNsJJ5ndcWRMO13z9NCZXbUzfcI9mEoXt31TQ0JFcWEh/en79jNWUU oTKBx27pkWBzGm21nQr1TXoVMQ2Pf/wZcTkmA= MIME-Version: 1.0 Received: by 10.181.50.1 with SMTP id c1mr752350bkk.3.1232091233229; Thu, 15 Jan 2009 23:33:53 -0800 (PST) In-Reply-To: <550328.24456.qm@web45404.mail.sp1.yahoo.com> References: <550328.24456.qm@web45404.mail.sp1.yahoo.com> Date: Thu, 15 Jan 2009 23:33:53 -0800 Message-ID: <7d6fde3d0901152333i53108c49m64e92abb7c5329cb@mail.gmail.com> From: Garrett Cooper To: shilp.kamal@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hackers freeBSD Subject: Re: panic: Going nowhere without my init! 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, 16 Jan 2009 07:33:55 -0000 On Wed, Jan 14, 2009 at 9:30 PM, Kamlesh Patel wrot= e: > Hi All, > > Thanks for answering my previous question "FreeBSD kernel Debugging tools= for Virtual Memory Module", thank you Dag-Erling Sm=F8rgrav. > > Today i made a comment in Getpid() function of sys/kern/kern_prot.c file = and i got error of > > -------------------------------------------------------------------------= ------- > panic: Going nowhere without my init! > Can not dump. No dump device defined. > Automatic reboot in 15 seconds - press a key on the console to abort-----= --------------------------------------------------------------------------- > > Could anyone help me in solving this error? "Made a comment" -- what kind of comment? Do you in fact mean add additional code? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:41:40 2009 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 5B13C1065672; Fri, 16 Jan 2009 08:41:40 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC4D8FC2B; Fri, 16 Jan 2009 08:41:39 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5155316bwz.19 for ; Fri, 16 Jan 2009 00:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YAEQoVT7GNzyxuqW1SNDHZBtvVbXJhG7DWwJEp6RNSY=; b=eHrnRJr+vtmRFQVKwi+YtKTNx7yxK30dEHZR7vymlJ2TikyFHzRuKObNAdMLf2aKw0 WHiyDMU3KcHeyfOM8FoRD7JzXt71I2zjZxOPzdzw2McWhuNQEzOpdO9wk4D+sJfjkHN4 yDko7MxalU9RaKOwr+r7nTgKHRfIGz44C3Rkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fdZXO7Ll9tSI5F2Tmx80h+h4SxhcpL5NzbSX81sQKFPJEo7B4l3n5hskih0v8OTOqr Tb4guzjFWlHzPUyNI5p8w0HxNOB6x13S3+87UzHdiZ2TeHXRlY38Cdt2QTKBYhvfHfXj dshBcMtXrNOKGfyqxsSsEJ6CYVBPKJldXCbUI= MIME-Version: 1.0 Received: by 10.181.135.5 with SMTP id m5mr764556bkn.87.1232095297847; Fri, 16 Jan 2009 00:41:37 -0800 (PST) Date: Fri, 16 Jan 2009 00:41:37 -0800 Message-ID: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> From: Garrett Cooper To: Hackers freeBSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "amd64@freebsd.org" Subject: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 08:41:40 -0000 Hi amd64 and Hackers, Uh, I'm really confused why 1) this error (errno => ENOMEM) would occur when I have more than enough free memory (both on x86 and amd64) and 2) why strerror would segfault in the call to errx in the attached sourcefile on amd64 only. Not initializing len causes the second output sample (errno => 14, which is EFAULT). Any ideas? Please CC me if mailing on amd64@ as I'm not subscribed to the list. Thanks, -Garrett /* Program */ #include #include #include #include #include int main() { int mib[4]; size_t len; if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { printf("Errno: %d\n", errno); errx(errno, "Error: %s", strerror(errno)); } printf("%lu\n", len); return 0; } # output for len preset to 0: [gcooper@optimus ~]$ ./test2 Errno: 12 test2: Segmentation fault: 11 (core dumped) [gcooper@optimus ~]$ uname -a FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sun Jan 11 12:30:31 PST 2009 root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 [gcooper@orangebox /usr/home/gcooper]$ ./test Errno: 12 test: Error: Cannot allocate memory [gcooper@orangebox /usr/home/gcooper]$ uname -a FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sat Jan 3 22:54:52 PST 2009 gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 # output for len not preset to 0: [gcooper@optimus ~]$ ./test2 Errno: 14 test2: Segmentation fault: 11 (core dumped) From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:44:30 2009 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 1B107106564A; Fri, 16 Jan 2009 08:44:30 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6C4418FC08; Fri, 16 Jan 2009 08:44:29 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5158414bwz.19 for ; Fri, 16 Jan 2009 00:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hGrcKhFFjIh3K4rcDdNrb8YWRufMl73vZuOz4eomO/E=; b=AvVH3AAhP3tkxAXqhkBnv6OX9ZR/PG5mmDMu9ujwH06Y2BH3bCq5zVHEuMr/imDtXO vflR0kJS5Y66Duth9wbPioPEfr61+fs63WSxz7mDTmjQTNjIo7Bm515aXRs8Us0G3kjb YK8KxvtElwKKxRmQa5uWl7+GcTbNiqkAcat/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fGi1XjJU4A3TUuT795vhTwr6yBFbgAIz3Ci4cjG9piqexfmCZ6DXwYosI+KC1/yerQ nSJZzoG+X4uo7pXyKDq7WdgRONfwIaG7EOM5J8w8KzGBgDU77KQGfdJlXmArXDetHlzQ 7FN8ixzt+w1B+qfttXbSJlKYk0XzsqT4GzuAk= MIME-Version: 1.0 Received: by 10.181.192.10 with SMTP id u10mr758578bkp.185.1232095467960; Fri, 16 Jan 2009 00:44:27 -0800 (PST) In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Date: Fri, 16 Jan 2009 00:44:27 -0800 Message-ID: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> From: Garrett Cooper To: Hackers freeBSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "amd64@freebsd.org" Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 08:44:30 -0000 On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: > Hi amd64 and Hackers, > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > occur when I have more than enough free memory (both on x86 and amd64) > and 2) why strerror would segfault in the call to errx in the attached > sourcefile on amd64 only. Not initializing len causes the second > output sample (errno => 14, which is EFAULT). > Any ideas? > Please CC me if mailing on amd64@ as I'm not subscribed to the list. > Thanks, > -Garrett > > /* Program */ > #include > #include > #include > #include > #include > > int > main() { > > int mib[4]; > > size_t len; > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); > } > > printf("%lu\n", len); > > return 0; > > } > > # output for len preset to 0: > [gcooper@optimus ~]$ ./test2 > Errno: 12 > test2: Segmentation fault: 11 (core dumped) > [gcooper@optimus ~]$ uname -a > FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: > Sun Jan 11 12:30:31 PST 2009 > root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 > > [gcooper@orangebox /usr/home/gcooper]$ ./test > Errno: 12 > test: Error: Cannot allocate memory > [gcooper@orangebox /usr/home/gcooper]$ uname -a > FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT > #4: Sat Jan 3 22:54:52 PST 2009 > gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX > i386 > > # output for len not preset to 0: > [gcooper@optimus ~]$ ./test2 > Errno: 14 > test2: Segmentation fault: 11 (core dumped) Almost forgot -- here are the actual values reported by sysctl(1), just for reference: [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax kern.ipc.shmall: 8192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax kern.ipc.shmall: 8192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:53:03 2009 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 954AC106564A for ; Fri, 16 Jan 2009 08:53:03 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id D6F3B8FC0A for ; Fri, 16 Jan 2009 08:53:02 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 08:53:01 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp056) with SMTP; 16 Jan 2009 09:53:01 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18o3C8/cC0oIDTtXxxDZ+wo92yQJK/699sT82PYiv iRjmRnbw9N3jjG Message-ID: <49704AEC.3080709@gmx.de> Date: Fri, 16 Jan 2009 09:53:00 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 08:53:03 -0000 Garrett Cooper schrieb: > Hi amd64 and Hackers, > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > occur when I have more than enough free memory (both on x86 and amd64) > and 2) why strerror would segfault in the call to errx in the attached > sourcefile on amd64 only. Not initializing len causes the second > output sample (errno => 14, which is EFAULT). > Any ideas? > Please CC me if mailing on amd64@ as I'm not subscribed to the list. > Thanks, > -Garrett len is not uninitialised. This leads to undefined behaviour. Anything can happen. Probably the syscall overwrites parts of the stack because len has some (random) high value. > /* Program */ > #include > #include > #include > #include > #include > > int > main() { > > int mib[4]; > > size_t len; > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); The use of errno is wrong. printf might change errno. Store the errno into a local variable before you do any call, which might modify it. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:53:21 2009 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 077F3106564A; Fri, 16 Jan 2009 08:53:21 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 56EC18FC14; Fri, 16 Jan 2009 08:53:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5168807bwz.19 for ; Fri, 16 Jan 2009 00:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tzNojY5j+qIwphmm/13LKzGKsS0ll8qLsfKya9TEXXM=; b=G2Rm+aHz8NIquPxnA/lwXsky4pa7FAdcHL6ZqfI4aR93zL45UXrnLROpuBV8qdHMXk zSlFrrTkUKyO9vS7a/Z/H1QhuokG0F6hAxesHxFCZE+f/XmR0S+LRMQv7qmpEzd06a0e XmLTs7WH1HQhBM86EJs/+iEQrsvo314s0mKwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oXvEQkX1YqcQuoTaPGD5JxqFMRRncGZsfBEwAFFOsluajIfVEu/xSl9m/dEWpgJj3H etKokDR3MGCvccCOn2MF+I3dWW9rByWJH6Zs2T06Tet2z1sRAiu+884b2AYO/XzCJlMm ttPfap4w3/gOqkXjxk+MW/Uis5xgKIs1zUk78= MIME-Version: 1.0 Received: by 10.181.60.13 with SMTP id n13mr771297bkk.39.1232095999355; Fri, 16 Jan 2009 00:53:19 -0800 (PST) In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Date: Fri, 16 Jan 2009 00:53:19 -0800 Message-ID: <7d6fde3d0901160053y22b2f9c9vb37d0f0621c2a7c9@mail.gmail.com> From: Garrett Cooper To: Jacques Fourie Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 08:53:21 -0000 On Fri, Jan 16, 2009 at 12:47 AM, Jacques Fourie wrote: > > You need to initialize len to the number of entries in the mib array. > Try adding 'len = 4' before calling sysctlnametomib() and see if your > issues go away. Ok, that solution works (I think). So, problem 2 down. Now: what about the segfaulting strerror(3) call on amd64 ;\? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:55:21 2009 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 EAB3A106567A; Fri, 16 Jan 2009 08:55:21 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (cl-2958.ham-01.de.sixxs.net [IPv6:2001:6f8:900:b8d::2]) by mx1.freebsd.org (Postfix) with ESMTP id 715508FC12; Fri, 16 Jan 2009 08:55:21 +0000 (UTC) (envelope-from maxim@macomnet.ru) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.14.2/8.14.2) with ESMTP id n0G8tJfh034193; Fri, 16 Jan 2009 11:55:20 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Fri, 16 Jan 2009 11:55:19 +0300 (MSK) From: Maxim Konovalov To: Garrett Cooper In-Reply-To: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Message-ID: <20090116115448.A32187@mp2.macomnet.net> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 08:55:22 -0000 On Fri, 16 Jan 2009, 00:44-0800, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: > > Hi amd64 and Hackers, > > Uh, I'm really confused why 1) this error (errno => ENOMEM) would > > occur when I have more than enough free memory (both on x86 and amd64) > > and 2) why strerror would segfault in the call to errx in the attached > > sourcefile on amd64 only. Not initializing len causes the second > > output sample (errno => 14, which is EFAULT). > > Any ideas? - size_t len; + size_t len = 4; -- Maxim Konovalov From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:57:49 2009 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 9175F1065691 for ; Fri, 16 Jan 2009 08:57:49 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 01AE38FC0C for ; Fri, 16 Jan 2009 08:57:48 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so890498fgb.35 for ; Fri, 16 Jan 2009 00:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HePQbiZQ3484BaRkY2f44bzExWMH4dA+YbKta370Ep8=; b=LmRJRpLFj7wwq4RwAZC5nmPWIoNqn9vurmzb65iTl4zSzPhKZOZwEyge8jX2qUkIB2 2AMLIHO9x7ZagUNTDWLJhd8bWhEKNkPW8ykVHEkxtZ4UtuwfiYzAJVx+P9fMLx3/zKIt GpWx48xwujo1PH4s6AZ1Nxr2qS83kUXy1qF5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DnW/NMaVaVAwGvHzBaTSuJljoKRoWRcQveyoy0OZoyY8jChvk1duDP2Lo2hx+WSHuM iZZRWjrWn94h4RyoP7kQ1fFb6oXoaKtRJlUDMy6EhepJmiQUeXFY3c4sHQcufkcaA+ye J/6ryPnC+WgYJGXKKlxltyC0c+AUlhjVj/ICM= MIME-Version: 1.0 Received: by 10.86.86.12 with SMTP id j12mr1859683fgb.64.1232095851785; Fri, 16 Jan 2009 00:50:51 -0800 (PST) In-Reply-To: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Date: Fri, 16 Jan 2009 10:50:51 +0200 Message-ID: From: Jacques Fourie To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 08:57:50 -0000 On Fri, Jan 16, 2009 at 10:47 AM, Jacques Fourie wrote: > On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: >>> Hi amd64 and Hackers, >>> Uh, I'm really confused why 1) this error (errno => ENOMEM) would >>> occur when I have more than enough free memory (both on x86 and amd64) >>> and 2) why strerror would segfault in the call to errx in the attached >>> sourcefile on amd64 only. Not initializing len causes the second >>> output sample (errno => 14, which is EFAULT). >>> Any ideas? >>> Please CC me if mailing on amd64@ as I'm not subscribed to the list. >>> Thanks, >>> -Garrett >>> >>> /* Program */ >>> #include >>> #include >>> #include >>> #include >>> #include >>> >>> int >>> main() { >>> >>> int mib[4]; >>> >>> size_t len; >>> >>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>> printf("Errno: %d\n", errno); >>> errx(errno, "Error: %s", strerror(errno)); >>> } >>> >>> printf("%lu\n", len); >>> >>> return 0; >>> >>> } >>> >>> # output for len preset to 0: >>> [gcooper@optimus ~]$ ./test2 >>> Errno: 12 >>> test2: Segmentation fault: 11 (core dumped) >>> [gcooper@optimus ~]$ uname -a >>> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: >>> Sun Jan 11 12:30:31 PST 2009 >>> root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 >>> >>> [gcooper@orangebox /usr/home/gcooper]$ ./test >>> Errno: 12 >>> test: Error: Cannot allocate memory >>> [gcooper@orangebox /usr/home/gcooper]$ uname -a >>> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT >>> #4: Sat Jan 3 22:54:52 PST 2009 >>> gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX >>> i386 >>> >>> # output for len not preset to 0: >>> [gcooper@optimus ~]$ ./test2 >>> Errno: 14 >>> test2: Segmentation fault: 11 (core dumped) >> >> Almost forgot -- here are the actual values reported by sysctl(1), >> just for reference: >> >> [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax >> kern.ipc.shmall: 8192 >> kern.ipc.shmmin: 1 >> kern.ipc.shmmax: 33554432 >> >> [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall >> kern.ipc.shmmin kern.ipc.shmmax >> kern.ipc.shmall: 8192 >> kern.ipc.shmmin: 1 >> kern.ipc.shmmax: 33554432 >> >> Thanks, >> -Garrett >> _______________________________________________ >> 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" >> > > You need to initialize len to the number of entries in the mib array. > Try adding 'len = 4' before calling sysctlnametomib() and see if your > issues go away. > Sorry, I only scanned through the code without reading the whole message before replying :) Please ignore... From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 08:58:59 2009 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 C5AA21065767; Fri, 16 Jan 2009 08:58:59 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 204CF8FC1C; Fri, 16 Jan 2009 08:58:58 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5175193bwz.19 for ; Fri, 16 Jan 2009 00:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=isi9Q67NvNtHgnkzXN2oeP93jB1Lhv7ooINUAzhu6+k=; b=wDzvpuHpCo/tNoe8AdcJ0Q2xsEtHyCGUDewBcnQ894Mra3Ztu2nGBAasWpsUJY86gw MEfglH3IUptkGDyHkLIZEd2BOvmo0cdw69WnGHusO8ih6dD+G1YZVuap8k9ITgTayH6N uxmu3A5/AYg8CLzMhlkb2i5/W36piPmZkhGUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pdN3P3eIIE/Pl5lcqdLuZqC2F+2cW089AneWVeTCsd8wRa84g6+s8LRVL6l7mG/8bc w8J+JpgtvjwrnOBQ/WYorRfIMw4HpcXIA5r9Kn85OsPSvMuvNFb2ANuAoVyBlZ9rEd77 FwEhbQzOuf44koeQe0e5U/LmiDaYHEI+K5A3A= MIME-Version: 1.0 Received: by 10.181.208.11 with SMTP id k11mr775034bkq.19.1232096337822; Fri, 16 Jan 2009 00:58:57 -0800 (PST) In-Reply-To: <49704C13.60505@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> Date: Fri, 16 Jan 2009 00:58:57 -0800 Message-ID: <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> From: Garrett Cooper To: Christoph Mallon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 08:59:00 -0000 On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon wrote: > Garrett Cooper schrieb: >> >> Good point. I modified the source to do that. >> Thanks, >> -Garrett > > You should reply to all so the discussion stays on the list. Yeah, that was a goofup on my part. Go-go Gmail web interface! -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 09:15:43 2009 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 39A801065686 for ; Fri, 16 Jan 2009 09:15:43 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id BB0958FC16 for ; Fri, 16 Jan 2009 09:15:42 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so893114fgb.35 for ; Fri, 16 Jan 2009 01:15:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OMhlaqZMbr/0bphrBOYTN3bAizaMsimrYKcCd8OgqJQ=; b=u3L4Mkv73neQnNE+Kcyx3sZwQwKgPV9pxrbkAUYVKcIicgyawkvYFde5mFnHv6Xj8T 7zOBACG/zQsNw52ic8VxaBkXlgXWQtEO5pqKrvPJSqkaKml1+xnAqkj/7nuBi42qvh/s TvlovZ3N6fL5zvwLEtfpPp3FIVwldX8Ig+RZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tAo6ZWpjl+FgMACKRTkRPhDKDoU5sClcaAC4vwC8p7sJGTOhljnwR7jKxN7nl4hPPD EwYHMHZfT9l+GODPw/Px0HzLIxr5+9/sxscgaj34jM4K+i1PCswz1Li++N2rv0RQ9LAi wz4Dtb4MHhywV8STdaT808x3DJlvgbeLBlLOc= MIME-Version: 1.0 Received: by 10.86.89.20 with SMTP id m20mr1098228fgb.71.1232095641673; Fri, 16 Jan 2009 00:47:21 -0800 (PST) In-Reply-To: <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <7d6fde3d0901160044x4d7735cep16f032cd99dbc835@mail.gmail.com> Date: Fri, 16 Jan 2009 10:47:21 +0200 Message-ID: From: Jacques Fourie To: Garrett Cooper Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 09:15:44 -0000 On Fri, Jan 16, 2009 at 10:44 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:41 AM, Garrett Cooper wrote: >> Hi amd64 and Hackers, >> Uh, I'm really confused why 1) this error (errno => ENOMEM) would >> occur when I have more than enough free memory (both on x86 and amd64) >> and 2) why strerror would segfault in the call to errx in the attached >> sourcefile on amd64 only. Not initializing len causes the second >> output sample (errno => 14, which is EFAULT). >> Any ideas? >> Please CC me if mailing on amd64@ as I'm not subscribed to the list. >> Thanks, >> -Garrett >> >> /* Program */ >> #include >> #include >> #include >> #include >> #include >> >> int >> main() { >> >> int mib[4]; >> >> size_t len; >> >> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >> printf("Errno: %d\n", errno); >> errx(errno, "Error: %s", strerror(errno)); >> } >> >> printf("%lu\n", len); >> >> return 0; >> >> } >> >> # output for len preset to 0: >> [gcooper@optimus ~]$ ./test2 >> Errno: 12 >> test2: Segmentation fault: 11 (core dumped) >> [gcooper@optimus ~]$ uname -a >> FreeBSD optimus.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: >> Sun Jan 11 12:30:31 PST 2009 >> root@optimus.gateway.2wire.net:/usr/obj/usr/src/sys/OPTIMUS amd64 >> >> [gcooper@orangebox /usr/home/gcooper]$ ./test >> Errno: 12 >> test: Error: Cannot allocate memory >> [gcooper@orangebox /usr/home/gcooper]$ uname -a >> FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT >> #4: Sat Jan 3 22:54:52 PST 2009 >> gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX >> i386 >> >> # output for len not preset to 0: >> [gcooper@optimus ~]$ ./test2 >> Errno: 14 >> test2: Segmentation fault: 11 (core dumped) > > Almost forgot -- here are the actual values reported by sysctl(1), > just for reference: > > [gcooper@optimus ~]$ sysctl kern.ipc.shmall kern.ipc.shmmin kern.ipc.shmmax > kern.ipc.shmall: 8192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 33554432 > > [gcooper@orangebox /usr/src/sys]$ sysctl kern.ipc.shmall > kern.ipc.shmmin kern.ipc.shmmax > kern.ipc.shmall: 8192 > kern.ipc.shmmin: 1 > kern.ipc.shmmax: 33554432 > > Thanks, > -Garrett > _______________________________________________ > 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" > You need to initialize len to the number of entries in the mib array. Try adding 'len = 4' before calling sysctlnametomib() and see if your issues go away. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 09:19:51 2009 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 71B7B1065690; Fri, 16 Jan 2009 09:19:51 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-fx0-f11.google.com (mail-fx0-f11.google.com [209.85.220.11]) by mx1.freebsd.org (Postfix) with ESMTP id AA4098FC21; Fri, 16 Jan 2009 09:19:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by fxm4 with SMTP id 4so349744fxm.19 for ; Fri, 16 Jan 2009 01:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kPTPDqfHts3ODwEQ3MbARfr8AopC4ZO86FKlSQSx7js=; b=XHb5NPny/VYC9QykZFxJ4xvmCrpO12P0LKDyGGT5bApM1FEC409Omg6UjpZU21+NM7 bRoelMAho2TagmdcKn09dtuO9hzm30WIE5KOxSuHresfwYqRfQnBnVwPJNgh8Oxyfljb dER4uyLP1pLRItSb/9v/WI07t9oIsNIZLi02A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aislnV7c99deiO3XVL5BSHfjUeMNdEeJeNh0H8G+pK47CqrrVDbjiAg+6HigsrO7Jd bd4C2KEiuq4jxvM8+q2w/WBzISNZIRhY8y9lG+pesFCN4yw/odu8NdieYh+YuxQnlwCL VIus+AwyBk4f42WwRRuxGSITf1c6G6VC0GzHw= MIME-Version: 1.0 Received: by 10.181.199.16 with SMTP id b16mr771011bkq.142.1232097589763; Fri, 16 Jan 2009 01:19:49 -0800 (PST) In-Reply-To: <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> Date: Fri, 16 Jan 2009 01:19:49 -0800 Message-ID: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> From: Garrett Cooper To: Christoph Mallon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 09:19:52 -0000 On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon > wrote: >> Garrett Cooper schrieb: >>> >>> Good point. I modified the source to do that. >>> Thanks, >>> -Garrett >> >> You should reply to all so the discussion stays on the list. > > Yeah, that was a goofup on my part. Go-go Gmail web interface! > -Garrett Hmmm... looks like the strerror issue it could be a serious bug: #include #include #include int main() { struct stat sb; int o_errno; if (stat("/some/file/that/doesn't/exist", &sb) != 0) { o_errno = errno; printf("Errno: %d\n", errno); err(errno, "%s", strerror(o_errno)); } return 0; } [gcooper@optimus ~]$ ./badfile Errno: 2 badfile: Segmentation fault: 11 (core dumped) I rebuilt my kernel and installed it, and I rebuilt world, but haven't installed it yet though, so let me reboot the amd64 machine and see what happens (may be a mismatched ABI issue)... Cheers, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 09:38:20 2009 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 B470710656D6 for ; Fri, 16 Jan 2009 09:38:20 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 1903B8FC0A for ; Fri, 16 Jan 2009 09:38:19 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 09:38:18 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp046) with SMTP; 16 Jan 2009 10:38:18 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+j4g4acfqj1tOvhWSSKqOJjmun4qhgh7CQjnDg4t dFqZbVvF84PYZd Message-ID: <4970558A.1010705@gmx.de> Date: Fri, 16 Jan 2009 10:38:18 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> In-Reply-To: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 16 Jan 2009 09:38:21 -0000 Garrett Cooper schrieb: > On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon >> wrote: >>> Garrett Cooper schrieb: >>>> Good point. I modified the source to do that. >>>> Thanks, >>>> -Garrett >>> You should reply to all so the discussion stays on the list. >> Yeah, that was a goofup on my part. Go-go Gmail web interface! >> -Garrett > > Hmmm... looks like the strerror issue it could be a serious bug: > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > err(errno, "%s", strerror(o_errno)); You are still using the wrong errno. Also err() itself prints the error string using strerror(). There might be some interference when the result of one call to strerror() (your call) is used after another call to strerror() (err() internally). I doubt there is a bug in the library, otherwise we would see many bugreports of segfaults on AMD64. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 10:03:52 2009 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 D23DA106564A for ; Fri, 16 Jan 2009 10:03:52 +0000 (UTC) (envelope-from prvs=12673418ee=christian.kandeler@hob.de) Received: from mailgate.hob.de (mailgate.hob.de [212.185.199.3]) by mx1.freebsd.org (Postfix) with ESMTP id 926E98FC08 for ; Fri, 16 Jan 2009 10:03:52 +0000 (UTC) (envelope-from prvs=12673418ee=christian.kandeler@hob.de) Received: from imap.hob.de (mail2.hob.de [172.25.1.102]) by mailgate.hob.de (Postfix) with ESMTP id 6E2F1520068 for ; Fri, 16 Jan 2009 10:39:01 +0100 (CET) Received: from linux04.hob.de (linux04.hob.de [172.22.0.192]) by imap.hob.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 2A530FD861 for ; Fri, 16 Jan 2009 10:38:13 +0100 (CET) From: Christian Kandeler Organization: HOB To: freebsd-hackers@freebsd.org Date: Fri, 16 Jan 2009 10:39:00 +0100 User-Agent: KMail/1.9.1 References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> In-Reply-To: <49704AEC.3080709@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901161039.00232.christian.kandeler@hob.de> Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 10:03:53 -0000 On Friday 16 January 2009 09:53, Christoph Mallon wrote: > > int > > main() { > > > > int mib[4]; > > > > size_t len; > > > > if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { > > printf("Errno: %d\n", errno); > > errx(errno, "Error: %s", strerror(errno)); > > The use of errno is wrong. printf might change errno. I don't think printf() can set errno. And even if it could, it wouldn't matter, because C has call-by-value semantics. Christian From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 10:21:26 2009 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 0D8C710656C4 for ; Fri, 16 Jan 2009 10:21:26 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4FFE58FC29 for ; Fri, 16 Jan 2009 10:21:25 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 10:21:23 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp060) with SMTP; 16 Jan 2009 11:21:23 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19KhO5QHnpKTGYJZgc8hjSdhtg+kY83+KzKPNnT8A GASGyd95RK03/e Message-ID: <49705FA2.2020605@gmx.de> Date: Fri, 16 Jan 2009 11:21:22 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Christian Kandeler References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> In-Reply-To: <200901161039.00232.christian.kandeler@hob.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 10:21:27 -0000 Christian Kandeler schrieb: > On Friday 16 January 2009 09:53, Christoph Mallon wrote: > >>> int >>> main() { >>> >>> int mib[4]; >>> >>> size_t len; >>> >>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>> printf("Errno: %d\n", errno); >>> errx(errno, "Error: %s", strerror(errno)); >> The use of errno is wrong. printf might change errno. > > I don't think printf() can set errno. And even if it could, it Of course it can. See ISO/IEC 9899:1999 (E) 7.5:3. > wouldn't matter, because C has call-by-value semantics. This has nothing to do with call-by-value. errno is read (even twice!) *after* the call to printf(). From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 10:36:01 2009 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 6EC38106564A for ; Fri, 16 Jan 2009 10:36:01 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id BEB0C8FC1E for ; Fri, 16 Jan 2009 10:36:00 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5301674bwz.19 for ; Fri, 16 Jan 2009 02:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IR5F44MNa2CyamvnthfrY26YDZFsRYMnrBm3ctWw4lM=; b=ClrgP5GsdMCWHzU5rZDi8mCZpufpE6cHI9s3wW5hfHsTIT5UXPGIQNQxdXVf/6idy1 wYbj9uw7kWj+VvWR8dB8LG3Vh5wGTG/52bJPJZrKA2TaerrZ7pGpDChZv4X0aB/jPP1A iLMaJA/6k5Q5kDxAUJ+QQA9GixVHPUy45AuoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CZOqtm5WZdH504q2Wq6vwBPtZjukMGXTemwF8KWQMpuHSgIDVWn89ALZnOmL7KaJKX f3KErvGj1Ojm8qO7NkIdTOR/ZDXoxT1gCep+0sfKAQQGFVY9DmtlRI54cqILnD1CM8Lp K1U711GDTcOmgy88n+eg4o2ETItEaAbbnbfdc= MIME-Version: 1.0 Received: by 10.181.134.11 with SMTP id l11mr798578bkn.73.1232102159587; Fri, 16 Jan 2009 02:35:59 -0800 (PST) In-Reply-To: <49705FA2.2020605@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> Date: Fri, 16 Jan 2009 02:35:59 -0800 Message-ID: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> From: Garrett Cooper To: Christoph Mallon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Christian Kandeler , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 10:36:01 -0000 On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon wrote: > Christian Kandeler schrieb: >> >> On Friday 16 January 2009 09:53, Christoph Mallon wrote: >> >>>> int >>>> main() { >>>> >>>> int mib[4]; >>>> >>>> size_t len; >>>> >>>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) !=3D 0) { >>>> printf("Errno: %d\n", errno); >>>> errx(errno, "Error: %s", strerror(errno)); >>> >>> The use of errno is wrong. printf might change errno. >> >> I don't think printf() can set errno. And even if it could, it > > Of course it can. See ISO/IEC 9899:1999 (E) =A77.5:3. > >> wouldn't matter, because C has call-by-value semantics. > > This has nothing to do with call-by-value. errno is read (even twice!) > *after* the call to printf(). Ok, I just installworld'ed, recompiled the program with the following modifications, and I still get segfaults. And the question of the night is: why amd64 on a VERY recent CURRENT? I'm going to try the same app on an amd64 freebsd VMware instance with RELENG_7. Remember: just because a bunch of other people aren't reporting issues with CURRENT/amd64 doesn't mean that it isn't environmental, related to my hardware or compile options ;). Cheers, -Garrett #include #include #include int main() { struct stat sb; int o_errno; if (stat("/some/file/that/doesn't/exist", &sb) !=3D 0) { o_errno =3D errno; printf("Errno: %d\n", errno); printf("%s\n", strerror(o_errno)); } return 0; } #include #include #include int main() { struct stat sb; int o_errno; if (stat("/some/file/that/doesn't/exist", &sb) !=3D 0) { o_errno =3D errno; printf("Errno: %d\n", errno); printf("%s\n", strerror(o_errno)); } return 0; } [gcooper@optimus ~]$ gcc -o badfile badfile.c [gcooper@optimus ~]$ ./badfile Errno: 2 Segmentation fault: 11 (core dumped) [gcooper@optimus ~]$ From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 10:44:29 2009 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 8FD2010656C9 for ; Fri, 16 Jan 2009 10:44:29 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id E06898FC17 for ; Fri, 16 Jan 2009 10:44:28 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so5312812bwz.19 for ; Fri, 16 Jan 2009 02:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Oj1sHaYNc8PPbkrWZlRx6ZX7en2h6FeyO1CDZCG+giI=; b=unCdPoGMrhVZciNmsA+v4E6T4cNOTyeRYATTKkGLS/FrM6lj9rbI5z6IrmwHIPTWzZ ns0Kf+NbNQZUL50dvfZjp1oZgn5elqvr0Q8AsmZ/FzXd1KCCZo3ibDPyZH+fBPM1StK8 Fusvcdf0n3fc0ejWv0ZMVVPl1k0GlRmlf0eNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ik8mxFCME5N9KDBSD5zhs2S7S0XcmdQEhgAbG8qhlvsL3snhEK5CvyrilgGLOQiUMu K6XPfBNzYYLzffVHZyrDbxJk0Y74OZziLP4rylavE3XU6Q4QVPgEZbwkYdMekrKmTKd9 wr913tQzVPbA7W2I6ljL20m0Fs3intMccy1lQ= MIME-Version: 1.0 Received: by 10.181.145.6 with SMTP id x6mr800934bkn.94.1232102667426; Fri, 16 Jan 2009 02:44:27 -0800 (PST) In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> Date: Fri, 16 Jan 2009 02:44:27 -0800 Message-ID: <7d6fde3d0901160244r6d72a3f1k5c27ea03fbc37ef5@mail.gmail.com> From: Garrett Cooper To: Christoph Mallon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Christian Kandeler , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 10:44:30 -0000 On Fri, Jan 16, 2009 at 2:35 AM, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon > wrote: >> Christian Kandeler schrieb: >>> >>> On Friday 16 January 2009 09:53, Christoph Mallon wrote: >>> >>>>> int >>>>> main() { >>>>> >>>>> int mib[4]; >>>>> >>>>> size_t len; >>>>> >>>>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) !=3D 0) { >>>>> printf("Errno: %d\n", errno); >>>>> errx(errno, "Error: %s", strerror(errno)); >>>> >>>> The use of errno is wrong. printf might change errno. >>> >>> I don't think printf() can set errno. And even if it could, it >> >> Of course it can. See ISO/IEC 9899:1999 (E) =A77.5:3. >> >>> wouldn't matter, because C has call-by-value semantics. >> >> This has nothing to do with call-by-value. errno is read (even twice!) >> *after* the call to printf(). > > Ok, I just installworld'ed, recompiled the program with the > following modifications, and I still get segfaults. And the question > of the night is: why amd64 on a VERY recent CURRENT? > I'm going to try the same app on an amd64 freebsd VMware instance > with RELENG_7. > Remember: just because a bunch of other people aren't reporting > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > related to my hardware or compile options ;). > Cheers, > -Garrett Ugh... I pasted it twice by accident. Sorry. -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 10:48:16 2009 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 973F810656E8 for ; Fri, 16 Jan 2009 10:48:16 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id EF0BB8FC22 for ; Fri, 16 Jan 2009 10:48:15 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 10:48:14 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp047) with SMTP; 16 Jan 2009 11:48:14 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+Nj+N/JQGN44tVswTI2wFqCfN0lYewhPGq8WNj7I FPy5Ok1WpTom8U Message-ID: <497065ED.7050705@gmx.de> Date: Fri, 16 Jan 2009 11:48:13 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: Christian Kandeler , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 10:48:17 -0000 Garrett Cooper schrieb: > Ok, I just installworld'ed, recompiled the program with the > following modifications, and I still get segfaults. And the question > of the night is: why amd64 on a VERY recent CURRENT? > I'm going to try the same app on an amd64 freebsd VMware instance > with RELENG_7. > Remember: just because a bunch of other people aren't reporting > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > related to my hardware or compile options ;). > Cheers, > -Garrett > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > [gcooper@optimus ~]$ gcc -o badfile badfile.c > [gcooper@optimus ~]$ ./badfile > Errno: 2 > Segmentation fault: 11 (core dumped) > [gcooper@optimus ~]$ Well, compile with -g, start in gdb, check what value is wrong, the usual stuff. Probably the return value of strerror() is interesting. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 11:01:03 2009 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 4376910656EC for ; Fri, 16 Jan 2009 11:01:03 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 401F88FC2A for ; Fri, 16 Jan 2009 11:01:01 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 11:00:54 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp034) with SMTP; 16 Jan 2009 12:00:54 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1/VdG5LfTrVWG2NEBDL8kpovESwO4M9fj3Z0ysDTi iIfJe4W7I79gal Message-ID: <497068E5.1050903@gmx.de> Date: Fri, 16 Jan 2009 12:00:53 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Cc: Christian Kandeler , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 11:01:04 -0000 Garrett Cooper schrieb: > On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon > wrote: >> Christian Kandeler schrieb: >>> On Friday 16 January 2009 09:53, Christoph Mallon wrote: >>> >>>>> int >>>>> main() { >>>>> >>>>> int mib[4]; >>>>> >>>>> size_t len; >>>>> >>>>> if (sysctlnametomib("kern.ipc.shmmax", mib, &len) != 0) { >>>>> printf("Errno: %d\n", errno); >>>>> errx(errno, "Error: %s", strerror(errno)); >>>> The use of errno is wrong. printf might change errno. >>> I don't think printf() can set errno. And even if it could, it >> Of course it can. See ISO/IEC 9899:1999 (E) 7.5:3. >> >>> wouldn't matter, because C has call-by-value semantics. >> This has nothing to do with call-by-value. errno is read (even twice!) >> *after* the call to printf(). > > Ok, I just installworld'ed, recompiled the program with the > following modifications, and I still get segfaults. And the question > of the night is: why amd64 on a VERY recent CURRENT? > I'm going to try the same app on an amd64 freebsd VMware instance > with RELENG_7. > Remember: just because a bunch of other people aren't reporting > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > related to my hardware or compile options ;). > Cheers, > -Garrett > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > > [gcooper@optimus ~]$ gcc -o badfile badfile.c > [gcooper@optimus ~]$ ./badfile > Errno: 2 > Segmentation fault: 11 (core dumped) > [gcooper@optimus ~]$ Compile with -Wall (you ALWAYS should do that) and then you'll see what the problem is. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 11:33:41 2009 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 B1770106567D for ; Fri, 16 Jan 2009 11:33:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 6554D8FC16 for ; Fri, 16 Jan 2009 11:33:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LNmxG-000PSq-DI; Fri, 16 Jan 2009 13:33:38 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Christoph Mallon In-reply-to: <497065ED.7050705@gmx.de> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> Comments: In-reply-to Christoph Mallon message dated "Fri, 16 Jan 2009 11:48:13 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 2009 13:33:38 +0200 From: Danny Braniss Message-ID: Cc: Christian Kandeler , Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 11:33:42 -0000 > Garrett Cooper schrieb: > > Ok, I just installworld'ed, recompiled the program with the > > following modifications, and I still get segfaults. And the question > > of the night is: why amd64 on a VERY recent CURRENT? > > I'm going to try the same app on an amd64 freebsd VMware instance > > with RELENG_7. > > Remember: just because a bunch of other people aren't reporting > > issues with CURRENT/amd64 doesn't mean that it isn't environmental, > > related to my hardware or compile options ;). > > Cheers, > > -Garrett > > > > #include > > #include > > #include > > > > int > > main() > > { > > > > struct stat sb; > > > > int o_errno; > > > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > > o_errno = errno; > > printf("Errno: %d\n", errno); > > printf("%s\n", strerror(o_errno)); > > } > > > > return 0; > > > > } > > > > #include > > #include > > #include > > > > int > > main() > > { > > > > struct stat sb; > > > > int o_errno; > > > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > > o_errno = errno; > > printf("Errno: %d\n", errno); > > printf("%s\n", strerror(o_errno)); > > } > > > > return 0; > > > > } > > > > [gcooper@optimus ~]$ gcc -o badfile badfile.c > > [gcooper@optimus ~]$ ./badfile > > Errno: 2 > > Segmentation fault: 11 (core dumped) > > [gcooper@optimus ~]$ > > Well, compile with -g, start in gdb, check what value is wrong, the > usual stuff. Probably the return value of strerror() is interesting. some facts: #include int main() { printf("%s\n", strerror(2)); return 0; } 1- it works fine on i386 2- it bombs on amd64 3- with a local strerror.c (instead of the one in libc) works fine so, there is something realy wrong going on here! (and it gows back to at least 7.0-stable) danny From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 11:39:16 2009 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 F0CD6106564A for ; Fri, 16 Jan 2009 11:39:16 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 3AE668FC13 for ; Fri, 16 Jan 2009 11:39:16 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 16 Jan 2009 11:39:14 -0000 Received: from p54A3E7DB.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.231.219] by mail.gmx.net (mp068) with SMTP; 16 Jan 2009 12:39:14 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+AAvJlqaSAwljwgTzvJc9/w0P2aLShMREcb+06cA k4h8tdnYw+kuu9 Message-ID: <497071E2.3040809@gmx.de> Date: Fri, 16 Jan 2009 12:39:14 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Danny Braniss References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 Cc: Christian Kandeler , Garrett Cooper , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 11:39:17 -0000 Danny Braniss schrieb: > some facts: > #include > int > main() > { > printf("%s\n", strerror(2)); > return 0; > } > > 1- it works fine on i386 > 2- it bombs on amd64 > 3- with a local strerror.c (instead of the one in libc) > works fine > so, there is something realy wrong going on here! > (and it gows back to at least 7.0-stable) No, everything is perfectly correct. I suggested this earlier: Compile with -Wall and you'll see what the problem is. From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 11:50:48 2009 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 DF8AD106566B for ; Fri, 16 Jan 2009 11:50:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 91AD18FC14 for ; Fri, 16 Jan 2009 11:50:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LNnDr-000PbR-Dm; Fri, 16 Jan 2009 13:50:47 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Christoph Mallon , Christian Kandeler , Garrett Cooper , freebsd-hackers@freebsd.org In-reply-to: <20090116113928.GA1361@lizard.fafoe.narf.at> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> <20090116113928.GA1361@lizard.fafoe.narf.at> Comments: In-reply-to Stefan Farfeleder message dated "Fri, 16 Jan 2009 12:39:28 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jan 2009 13:50:47 +0200 From: Danny Braniss Message-ID: Cc: Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 11:50:49 -0000 > On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote: > > some facts: > > #include > > int > > main() > > { > > printf("%s\n", strerror(2)); > > return 0; > > } > > > > 1- it works fine on i386 > > 2- it bombs on amd64 > > 3- with a local strerror.c (instead of the one in libc) > > works fine > > so, there is something realy wrong going on here! > > (and it gows back to at least 7.0-stable) > > The compiler thinks strerror returns an int. Include . ahh, RTFM ALL THE WAY! I just saw the top few lines: LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include but later it shows: #include char * strerror(int errnum); on the other hand, compiling with -static workes ok, which sent me on the wrong trail. danny From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 11:57:02 2009 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 165301065670 for ; Fri, 16 Jan 2009 11:57:02 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by mx1.freebsd.org (Postfix) with ESMTP id 61FCA8FC17 for ; Fri, 16 Jan 2009 11:57:00 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from edge01.upc.biz ([192.168.13.236]) by viefep11-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090116113931.XLNF9925.viefep11-int.chello.at@edge01.upc.biz>; Fri, 16 Jan 2009 12:39:31 +0100 Received: from lizard.fafoe.narf.at ([213.47.85.26]) by edge01.upc.biz with edge id 4BfV1b0060a5KZh01BfWp1; Fri, 16 Jan 2009 12:39:30 +0100 X-SourceIP: 213.47.85.26 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id BBE45BCF7; Fri, 16 Jan 2009 12:39:28 +0100 (CET) Date: Fri, 16 Jan 2009 12:39:28 +0100 From: Stefan Farfeleder To: Danny Braniss Message-ID: <20090116113928.GA1361@lizard.fafoe.narf.at> Mail-Followup-To: Danny Braniss , Christoph Mallon , Christian Kandeler , Garrett Cooper , freebsd-hackers@freebsd.org References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <200901161039.00232.christian.kandeler@hob.de> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <497065ED.7050705@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Christian Kandeler , Garrett Cooper , Christoph Mallon , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 11:57:02 -0000 On Fri, Jan 16, 2009 at 01:33:38PM +0200, Danny Braniss wrote: > some facts: > #include > int > main() > { > printf("%s\n", strerror(2)); > return 0; > } > > 1- it works fine on i386 > 2- it bombs on amd64 > 3- with a local strerror.c (instead of the one in libc) > works fine > so, there is something realy wrong going on here! > (and it gows back to at least 7.0-stable) The compiler thinks strerror returns an int. Include . From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 11:10:45 2009 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 048C51065853 for ; Fri, 16 Jan 2009 11:10:45 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtpfb1-g21.free.fr (smtpfb1-g21.free.fr [212.27.42.9]) by mx1.freebsd.org (Postfix) with ESMTP id 724598FC2E for ; Fri, 16 Jan 2009 11:10:42 +0000 (UTC) (envelope-from thierry.herbelot@free.fr) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) by smtpfb1-g21.free.fr (Postfix) with ESMTP id AC0C67801D6 for ; Fri, 16 Jan 2009 11:53:11 +0100 (CET) Received: from smtp6-g21.free.fr (localhost [127.0.0.1]) by smtp6-g21.free.fr (Postfix) with ESMTP id 99CAAE080E5 for ; Fri, 16 Jan 2009 11:53:06 +0100 (CET) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp6-g21.free.fr (Postfix) with ESMTP id 9ACA6E08073 for ; Fri, 16 Jan 2009 11:53:03 +0100 (CET) Received: from tulipe.herbelot.nom (tulipe.herbelot.nom [192.168.2.5]) by mail.herbelot.nom (8.14.1/8.14.1) with ESMTP id n0GAqx88015216; Fri, 16 Jan 2009 11:52:59 +0100 (CET) From: Thierry Herbelot To: freebsd-hackers@freebsd.org Date: Fri, 16 Jan 2009 11:52:52 +0100 User-Agent: KMail/1.9.10 References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> In-Reply-To: <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200901161152.53478.thierry.herbelot@free.fr> X-Mailman-Approved-At: Fri, 16 Jan 2009 12:25:33 +0000 Cc: Christoph Mallon Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 11:10:47 -0000 Le Friday 16 January 2009, Garrett Cooper a crit : > On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > printf("%s\n", strerror(o_errno)); > } > > return 0; > > } > with this, it's better on an amd64/ RELENG_7 machine : % diff -ub badfile.c.ori badfile.c --- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100 +++ badfile.c 2009-01-16 11:49:03.470465677 +0100 @@ -1,6 +1,7 @@ #include #include #include +#include int main() Cheers TfH From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 13:21:25 2009 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 0A4AB106566B for ; Fri, 16 Jan 2009 13:21:25 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id 4DE898FC13 for ; Fri, 16 Jan 2009 13:21:24 +0000 (UTC) (envelope-from bsd.quest@googlemail.com) Received: by bwz13 with SMTP id 13so5535014bwz.19 for ; Fri, 16 Jan 2009 05:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:reply-to:mail-followup-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=1AMfbZ2UWAn6WMKRnb/7Ih+Aw/kHhEfYfQamdbPnob8=; b=VrEFlEfH+9iyt0T5E+X11+WVkmuUWmz5wzz2hd45OQnr1qiHypV2Bt59qMu0PezkMn kngOmC2nb2GgMuMX0DGJSsaKYN/nhTAVORLQLeENgbwoahdJToPWc/Xu/nFRIy3qg4PD 4XyQqvPY9tnZlBoH2QO0VlPCCtBWtvV3DsOMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; b=gYxzrkJdIkRDRsxZ78EIZH11WhCnorJIFnSHoEgZT5278yVCLi6/lLBkLvchsKcHIQ qoSwEn/BQdalE6oWxtIbCLLQqreeP9+mrbCirBYzVtu3gjqVieYUggDmJ20S/zPbrNHC TVbjmXvXLzOF04PqWz27P4mXvi+/di7KNETAE= Received: by 10.223.126.69 with SMTP id b5mr882293fas.34.1232112082635; Fri, 16 Jan 2009 05:21:22 -0800 (PST) Received: from localhost (BAJ3f95.baj.pppool.de [77.137.63.149]) by mx.google.com with ESMTPS id b17sm1219148fka.4.2009.01.16.05.21.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Jan 2009 05:21:21 -0800 (PST) Date: Fri, 16 Jan 2009 14:20:53 +0100 From: Alexej Sokolov To: freebsd-hackers@freebsd.org Message-ID: <20090116132053.GA3271@debian.samsung.router> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20090115192242.4fce7e00@mail01.compvia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20090115192242.4fce7e00@mail01.compvia.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: How to access kernel memory from user space X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexej Sokolov List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 13:21:25 -0000 On Thu, Jan 15, 2009 at 01:22:18PM -0600, Gerry Weaver wrote: > _____ > > From: Alexej Sokolov [mailto:bsd.quest@googlemail.com] > To: Gerry Weaver [mailto:gerryw@compvia.com] > Cc: freebsd-hackers@freebsd.org > Sent: Thu, 15 Jan 2009 12:31:00 -0600 > Subject: Re: How to access kernel memory from user space > > > > > 2008/12/23 Gerry Weaver > Hello All, > > I am working on a driver that collects various network statistics via pfil. I have a simple array of structures that I use to store the statistics. I also have a user space process that needs to collect these statistics every second or so. A copy operation from kernel to user space would be too expensive. Is there a mechanism that would allow me to gain direct access to my kernel array from user space? The user process would only need read access. It seems like maybe this could be done with mmap, but since this is not a character driver, there is no device file etc.. I'm a newbie, so I apologize if this is something that should be obvious. > > > Thanks in advance, > Gerry > _______________________________________________ > 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" > Hi, > some times ago I solve this task. That's my solution in a system call (whithout cdev). > Thanx in advance for founded mistakes and possible bugs (-: > > > #include > #include > #include > #include > #include > #include > #include > #include > #include > > #include > #include > #include > #include > #include > #include > > > /* Arguments for syscall */ > struct args { > > /* Pointer to allocated Buffer */ > unsigned int *p; > }; > > /* String to be located in maped buffer */ > const char *str = "BSD IS SEXY"; > > /* Syscall func */ > static int > syscf(struct thread *td, void *sa) > { > int error; > struct args *uap; > vm_offset_t addr; /* Kernel space address */ > vm_offset_t user_addr; /* User space address */ > > struct proc *procp = (struct proc *)td->td_proc; > > struct vmspace *vms = procp->p_vmspace; > > uap = (struct args *)sa; > > PROC_LOCK(procp); > user_addr = round_page((vm_offset_t)vms->vm_daddr + > lim_max(procp, RLIMIT_DATA)); > PROC_UNLOCK(procp); > > MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO); > > vm_map_entry_t myentry; > vm_object_t myobject; > vm_pindex_t mypindex; > vm_prot_t myprot; > boolean_t mywired; > vm_ooffset_t objoffset; > > vm_map_lookup(&kmem_map, addr, VM_PROT_ALL, > &myentry, &myobject, &mypindex, &myprot, &mywired); /* OUT */ > vm_map_lookup_done(kmem_map, myentry); > > printf("---> Syscall: hint for allocating space = 0x%X\n", addr); > > if (myobject == kmem_object){ > printf("---> Syscall: Yes, it is kmem_obj! \n"); > } > > /* Offset in vm_object */ > objoffset = addr - myentry->start + myentry->offset; > > printf("------> Syscall: Object offset = 0x%X \n", (unsigned int)objoffset); > > /* > * Try to map kernel buffer to user space > */ > vm_object_reference(myobject); /* NEEDED Increment vm_obj references */ > error = vm_map_find(&vms->vm_map, myobject, objoffset, (vm_offset_t *)&user_addr, > PAGE_SIZE, TRUE, VM_PROT_RW, VM_PROT_RW, > MAP_ENTRY_NOFAULT); > > if (error == KERN_SUCCESS) { > /* copy string using kernel address */ > size_t len; > copystr(str, (void *)addr, 12, &len); > > /* > * Tell to user process it's user space address > */ > *uap->p = user_addr; > > /* > * Try to read the string using user space address > */ > printf("String: %s\n", (char *)*uap->p); > > printf("---> Syscall: user_addr for allocating space = 0x%X\n", user_addr); > } > > return (0); > } > > /* Sysent entity for syscall */ > static struct sysent sc_sysent = { > 1, /* Number of arguments */ > syscf /* Syscall function */ > }; > > /* Offset in sysent[] */ > static int offset = NO_SYSCALL; > > /* Loader */ > static int > load (struct module *m, int cmd, void *something) > { > int error = 0; > switch(cmd){ > case MOD_LOAD: > printf("Module with sysc loaded. Offset = %d \n", offset); > break; > > case MOD_UNLOAD: > printf("Module with sysc unloaded. Offset = %d \n", offset); > break; > > default: > error = EOPNOTSUPP; > break; > } > return (error); > } > > /* Syscall macro*/ > SYSCALL_MODULE(fiveg_sysc, &offset, &sc_sysent, load, NULL); > > If needed, I can post user space program. > Hi, > > This looks like a very nice solution. I would like to see the user space code very much. > I really appreciate your help! > > Thanks Again, > Gerry User space program: #include #include #include #include #include #include int main(int argc, char *argv[]) { int sysc_num, error; struct module_stat mstat; /* This Variable will save the addres of remapped buffer */ unsigned int some_var; /* Pointer to pointer to remapped buffer */ unsigned int *p = &some_var; printf("USER: Pointer = %p \n", p); /* Search module with system call */ mstat.version = sizeof(mstat); if ( !(modstat(modfind("fiveg_sysc"), &mstat)) ){ /* Our module */ sysc_num = mstat.data.intval; printf("USER: Module found! Syscall number = %d \n", sysc_num); /* make system call */ error = syscall(sysc_num, p); /* Read the string from remapped buffer */ printf("USER: String = %s\n", (char *)*p); } else { printf("USER: Module seems to be not loaded! \n"); } return(0); } -- Alexej Sokolov From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 17:38:21 2009 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 6072510656D6 for ; Fri, 16 Jan 2009 17:38:21 +0000 (UTC) (envelope-from clc@ournetos.com) Received: from ournetos.com (203186153252.ctinets.com [203.186.153.252]) by mx1.freebsd.org (Postfix) with ESMTP id 188488FC3B for ; Fri, 16 Jan 2009 17:38:21 +0000 (UTC) (envelope-from clc@ournetos.com) Received: from www.ournetos.com (localhost.localdomain [127.0.0.1]) by ournetos.com (Postfix) with ESMTP id 688F2830021 for ; Sat, 17 Jan 2009 00:59:25 +0800 (HKT) Received: from 123.203.190.250 (SquirrelMail authenticated user clc) by www.ournetos.com with HTTP; Sat, 17 Jan 2009 00:59:25 +0800 (HKT) Message-ID: <59218.123.203.190.250.1232125165.squirrel@www.ournetos.com> Date: Sat, 17 Jan 2009 00:59:25 +0800 (HKT) From: clc@ournetos.com To: freebsd-hackers@freebsd.org User-Agent: SquirrelMail/1.4.8-4.0.1.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Fri, 16 Jan 2009 17:55:10 +0000 Subject: a CD you might interested in 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, 16 Jan 2009 17:38:22 -0000 Dear All, I think the following CD might interest you. URL: http://www.ournetos.com/itcf3.iso & http://www.compass.com.hk/itcf3.iso It is a bootable CD using grub-0.95 as of Nevada-b99, so, it is UNDI-based NICs netbootable. Also, I'd put onto it gPXE-0.96 *.lkrn for using gPXE of http://etherboot.org. Network installation media for a) FreeBSD-7.1 b) Nevada-b105 c) Debian-4.0 d) Fedora-10 e) OpenSUSE-11.1 f) Ubuntu-8.10 are on it. Also, flavors of Linuxes may be WANbooted on PCs w/ internet connectivity. Wish you enjoy it, Clarence Data Expert Limited clc@ournetos.com From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 18:06:54 2009 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 8E94A1065731 for ; Fri, 16 Jan 2009 18:06:54 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-bw0-f20.google.com (mail-bw0-f20.google.com [209.85.218.20]) by mx1.freebsd.org (Postfix) with ESMTP id DD5BE8FC12 for ; Fri, 16 Jan 2009 18:06:53 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by bwz13 with SMTP id 13so6020008bwz.19 for ; Fri, 16 Jan 2009 10:06:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1YwjP1+jk9x1gM9NWpeDO4L7bsH5BG+KSC/DR74054o=; b=CVaT9VGWkWgc+te5jWgafaRIGf7Duxt6iVoetygiYSJPUhBixQJSJGErnKq82WtYiQ elo9uB11c9niPrOW4fGNYg9nKvZvyenHxzWTF+nz/0VnQqx/arZdThihna7N5+h6K2cc 7s5u0Y26H0R5LZEM9kXzPwDF3l37SV/f7RinM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CsEoHeQ7IbsMok1D2uqPFmzKXgDM+ED6qtsEluOqDDVjyLJItQXCsbaJLMb+DxjmL0 PN+wJu/QRT+Nu5J3d4gNUcAmF5EO1q9E80VtiPsXEjUoAab74yjSEl16dLtTwX89yU2E DAAwRClXCSyOKygKywsyp/ci0iIdNeJf5HqR4= MIME-Version: 1.0 Received: by 10.181.159.11 with SMTP id l11mr921566bko.186.1232129212788; Fri, 16 Jan 2009 10:06:52 -0800 (PST) In-Reply-To: <200901161152.53478.thierry.herbelot@free.fr> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <200901161152.53478.thierry.herbelot@free.fr> Date: Fri, 16 Jan 2009 10:06:52 -0800 Message-ID: <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> From: Garrett Cooper To: Thierry Herbelot Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Christoph Mallon Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 18:06:55 -0000 On Fri, Jan 16, 2009 at 2:52 AM, Thierry Herbelot wrote: > Le Friday 16 January 2009, Garrett Cooper a =E9crit : >> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon >> >> #include >> #include >> #include >> >> int >> main() >> { >> >> struct stat sb; >> >> int o_errno; >> >> if (stat("/some/file/that/doesn't/exist", &sb) !=3D 0) { >> o_errno =3D errno; >> printf("Errno: %d\n", errno); >> printf("%s\n", strerror(o_errno)); >> } >> >> return 0; >> >> } >> > with this, it's better on an amd64/ RELENG_7 machine : > > % diff -ub badfile.c.ori badfile.c > --- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100 > +++ badfile.c 2009-01-16 11:49:03.470465677 +0100 > @@ -1,6 +1,7 @@ > #include > #include > #include > +#include > > int > main() > > Cheers > > TfH That's hilarious -- why does it pass though without issue on x86 though? -Garrett From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 18:33:18 2009 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 0A2BC1065674 for ; Fri, 16 Jan 2009 18:33:18 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from euclid.ucsd.edu (euclid.ucsd.edu [132.239.145.52]) by mx1.freebsd.org (Postfix) with ESMTP id DC4228FC1E for ; Fri, 16 Jan 2009 18:33:17 +0000 (UTC) (envelope-from neldredge@math.ucsd.edu) Received: from zeno.ucsd.edu (zeno.ucsd.edu [132.239.145.22]) by euclid.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n0GIXFo29370; Fri, 16 Jan 2009 10:33:15 -0800 (PST) Received: from localhost (neldredg@localhost) by zeno.ucsd.edu (8.11.7p3+Sun/8.11.7) with ESMTP id n0GIXFU21412; Fri, 16 Jan 2009 10:33:15 -0800 (PST) X-Authentication-Warning: zeno.ucsd.edu: neldredg owned process doing -bs Date: Fri, 16 Jan 2009 10:33:15 -0800 (PST) From: Nate Eldredge X-X-Sender: neldredg@zeno.ucsd.edu To: Garrett Cooper In-Reply-To: <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> Message-ID: References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <200901161152.53478.thierry.herbelot@free.fr> <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-570397931-1232130795=:18030" Cc: Thierry Herbelot , freebsd-hackers@freebsd.org, Christoph Mallon Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 18:33:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-570397931-1232130795=:18030 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 16 Jan 2009, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 2:52 AM, Thierry Herbelot > wrote: >> Le Friday 16 January 2009, Garrett Cooper a =E9crit : >>> On Fri, Jan 16, 2009 at 2:21 AM, Christoph Mallon >>> >>> #include >>> #include >>> #include >>> >>> int >>> main() >>> { >>> >>> struct stat sb; >>> >>> int o_errno; >>> >>> if (stat("/some/file/that/doesn't/exist", &sb) !=3D 0) { >>> o_errno =3D errno; >>> printf("Errno: %d\n", errno); >>> printf("%s\n", strerror(o_errno)); >>> } >>> >>> return 0; >>> >>> } >>> >> with this, it's better on an amd64/ RELENG_7 machine : >> >> % diff -ub badfile.c.ori badfile.c >> --- badfile.c.ori 2009-01-16 11:49:44.778991057 +0100 >> +++ badfile.c 2009-01-16 11:49:03.470465677 +0100 >> @@ -1,6 +1,7 @@ >> #include >> #include >> #include >> +#include >> >> int >> main() >> >> Cheers >> >> TfH > > That's hilarious -- why does it pass though without issue on x86 though? > -Garrett As pointed out, when you don't have a declaration for strerror, it's=20 implicitly assumed to return `int'. This "feature" was widely used in the= =20 early days of C and so continues to be accepted by compilers, and gcc by=20 default doesn't warn about it. On x86, int and char * are the same size. So even though the compiler=20 thinks strerror is returning an int which is being passed to printf, the=20 code it generates is the same as for a char *. On amd64, int is 32 bits=20 but char * is 64. When the compiler thinks it's using int, it only keeps= =20 track of the lower 32 bits, and the upper 32 bits get zeroed. So the=20 pointer that printf receives has had its upper 32 bits zeroed, and no=20 longer points where it should. Hence segfault. Since running on amd64 I've seen a lot of bugs where people carelessly=20 assume (perhaps without noticing) that ints and pointers are practically=20 interchangeable, which works on x86 and the like but breaks on amd64.=20 Variadic functions are special offenders because the compiler can't do=20 much type checking. Pop quiz: which of the following statements is correct? #include #include execl("/bin/sh", "/bin/sh", 0); execl("/bin/sh", "/bin/sh", NULL); --=20 Nate Eldredge neldredge@math.ucsd.edu ---559023410-570397931-1232130795=:18030-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 18:38:14 2009 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 C7C21106564A for ; Fri, 16 Jan 2009 18:38:14 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by mx1.freebsd.org (Postfix) with ESMTP id 217218FC20 for ; Fri, 16 Jan 2009 18:38:13 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from edge04.upc.biz ([192.168.13.239]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090116183812.NOE13616.viefep17-int.chello.at@edge04.upc.biz>; Fri, 16 Jan 2009 19:38:12 +0100 Received: from lizard.fafoe.narf.at ([213.47.85.26]) by edge04.upc.biz with edge id 4JeA1b02c0a5KZh04JeBug; Fri, 16 Jan 2009 19:38:12 +0100 X-SourceIP: 213.47.85.26 Received: by lizard.fafoe.narf.at (Postfix, from userid 1001) id 03D04BCF2; Fri, 16 Jan 2009 19:38:06 +0100 (CET) Date: Fri, 16 Jan 2009 19:38:06 +0100 From: Stefan Farfeleder To: Nate Eldredge Message-ID: <20090116183806.GB1355@lizard.fafoe.narf.at> Mail-Followup-To: Nate Eldredge , Garrett Cooper , Thierry Herbelot , freebsd-hackers@freebsd.org, Christoph Mallon References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49705FA2.2020605@gmx.de> <7d6fde3d0901160235o6aa1f096q11c5096b70f3577@mail.gmail.com> <200901161152.53478.thierry.herbelot@free.fr> <7d6fde3d0901161006r79f0cac4yf80c9c5079152b87@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Thierry Herbelot , Garrett Cooper , Christoph Mallon , freebsd-hackers@freebsd.org Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl (3) setting `odd' errno's 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, 16 Jan 2009 18:38:15 -0000 On Fri, Jan 16, 2009 at 10:33:15AM -0800, Nate Eldredge wrote: > Pop quiz: which of the following statements is correct? > > #include > #include > > execl("/bin/sh", "/bin/sh", 0); > execl("/bin/sh", "/bin/sh", NULL); None, as NULL is allowed to expand to 0. You have to write execl("/bin/sh", "/bin/sh", (char *)0); From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 21:20:13 2009 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 E572F1065675; Fri, 16 Jan 2009 21:20:13 +0000 (UTC) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green.homeunix.org [66.92.150.152]) by mx1.freebsd.org (Postfix) with ESMTP id DAD008FC26; Fri, 16 Jan 2009 21:20:12 +0000 (UTC) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (obama@localhost [127.0.0.1]) by green.homeunix.org (8.14.3/8.14.1) with ESMTP id n0GLK5T2041273; Fri, 16 Jan 2009 16:20:05 -0500 (EST) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.14.3/8.14.1/Submit) id n0GLJxe4041269; Fri, 16 Jan 2009 16:19:59 -0500 (EST) (envelope-from green) Date: Fri, 16 Jan 2009 16:19:59 -0500 From: Brian Fundakowski Feldman To: Julian Elischer Message-ID: <20090116211959.GA12007@green.homeunix.org> References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49678BBC.8050306@elischer.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: hackers@freebsd.org, jasone@freebsd.org Subject: Re: threaded, forked, rethreaded processes will deadlock 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, 16 Jan 2009 21:20:14 -0000 On Fri, Jan 09, 2009 at 09:39:08AM -0800, Julian Elischer wrote: > Brian Fundakowski Feldman wrote: >> On Thu, Jan 08, 2009 at 11:09:16PM -0800, Julian Elischer wrote: >>> Brian Fundakowski Feldman wrote: >>>> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote: >>>>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote: >>>>> >>>>>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that >>>>>> when a threaded program forks, and then its child attempts to go threaded, it >>>>>> deadlocks because it already appears to have locks held. I am not familiar >>>>>> enough with the current libthr/libc/rtld-elf interaction that I've been able >>>>>> to fix it myself, unfortunately. >>>>> There's really nothing to fix - according to POSIX you are only >>>>> allowed to call async-signal-safe functions in the child forked >>>>> from a threaded process. If you are trying to do anything other >>>>> than that, it may or may not work on FreeBSD, but it is not >>>>> guaranteed and is not portable. >>>>> >>>>> The rationale is that what is the point of forking and creating >>>>> more threads, when you can just as easily create more threads in >>>>> the parent without forking? The only reason to fork from a threaded >>>>> process is to call one of the exec() functions. >>>> Well, it worked until the last major set of changes to malloc. For me, the point >>>> was that I was able to have transparent background worker threads in any program >>>> regardless of its architecture, using the standard pthread fork hooks. Could you >>>> point me to the POSIX section covering fork and threads? If it's really not >>>> supposed to work then that's fine, but there's an awful lot of code there dedicated >>>> to support going threaded again after a fork. >>>> >>> Practically, you can't go threaded again after a fork >>> (by which I mean creating new threads or use things >>> like mutexes etc.) in any posix system I know of. >>> >>> It would require that: >>> The forking thread stop until: >>> Every other thread has released every resource it owns >>> and reports itself to be in a "safe quiescent state", >>> or at least report every resource it owns, especially >>> locks, >>> and >>> After the fork: >>> The child, post fork, to take ownership of all >>> of them, and free them. >>> >>> You might be able to do that in a simple >>> threaded program, but consider then that the libraries may have >>> threads running in them of which you are unaware, and that >>> some of the resources may interract with resources owned by the >>> forking thread. >>> >>> Add to this that there may be a signal thrown into this mix as well >>> >>> (signals are the bane of thread developement) >> >> Well, I wouldn't mind showing all of you what I can of what I had been doing >> with the background threads -- it works pretty well modulo this particular >> malloc lock bug. Due to it being inappropriate to share library resources >> between a child and parent for an open socket connection, I always considered >> the only "safe" behavior to be going single-threaded for the duration of the fork >> processes in both the parent and child, and the pthread_atfork(3) hooks have been >> sufficient to do so. > > > ahhhh > well going single threaded for the duration of the fork, changes > everything! Could you, and anyone else who would care to, check this out? It's a regression fix but it also makes the code a little bit clearer. Thanks! Index: lib/libc/stdlib/malloc.c =================================================================== --- lib/libc/stdlib/malloc.c (revision 187160) +++ lib/libc/stdlib/malloc.c (working copy) @@ -415,6 +415,7 @@ /* Set to true once the allocator has been initialized. */ static bool malloc_initialized = false; +static bool malloc_during_fork = false; /* Used to avoid initialization races. */ static malloc_mutex_t init_lock = {_SPINLOCK_INITIALIZER}; @@ -1205,7 +1206,7 @@ malloc_mutex_lock(malloc_mutex_t *mutex) { - if (__isthreaded) + if (__isthreaded || malloc_during_fork) _SPINLOCK(&mutex->lock); } @@ -1213,7 +1214,7 @@ malloc_mutex_unlock(malloc_mutex_t *mutex) { - if (__isthreaded) + if (__isthreaded || malloc_during_fork) _SPINUNLOCK(&mutex->lock); } @@ -1260,7 +1261,7 @@ { unsigned ret = 0; - if (__isthreaded) { + if (__isthreaded || malloc_during_fork) { if (_pthread_mutex_trylock(lock) != 0) { /* Exponentially back off if there are multiple CPUs. */ if (ncpus > 1) { @@ -1296,7 +1297,7 @@ malloc_spin_unlock(pthread_mutex_t *lock) { - if (__isthreaded) + if (__isthreaded || malloc_during_fork) _pthread_mutex_unlock(lock); } @@ -5515,9 +5516,8 @@ void _malloc_prefork(void) { + arena_t *larenas[narenas]; bool again; - unsigned i, j; - arena_t *larenas[narenas], *tarenas[narenas]; /* Acquire all mutexes in a safe order. */ @@ -5530,19 +5530,23 @@ */ memset(larenas, 0, sizeof(arena_t *) * narenas); do { + unsigned int i; + again = false; malloc_spin_lock(&arenas_lock); for (i = 0; i < narenas; i++) { if (arenas[i] != larenas[i]) { + arena_t *tarenas[narenas]; + unsigned int j; + memcpy(tarenas, arenas, sizeof(arena_t *) * narenas); malloc_spin_unlock(&arenas_lock); for (j = 0; j < narenas; j++) { if (larenas[j] != tarenas[j]) { larenas[j] = tarenas[j]; - malloc_spin_lock( - &larenas[j]->lock); + malloc_spin_lock(&larenas[j]->lock); } } again = true; @@ -5558,6 +5562,7 @@ #ifdef MALLOC_DSS malloc_mutex_lock(&dss_mtx); #endif + malloc_during_fork = true; } void @@ -5582,6 +5587,12 @@ if (larenas[i] != NULL) malloc_spin_unlock(&larenas[i]->lock); } + /* + * This ends the special post-__isthreaded exemption behavior for + * malloc stuff. We should really be single threaded right now + * in effect regardless of __isthreaded status. + */ + malloc_during_fork = false; } /* Index: lib/libthr/thread/thr_fork.c =================================================================== --- lib/libthr/thread/thr_fork.c (revision 187160) +++ lib/libthr/thread/thr_fork.c (working copy) @@ -105,7 +105,7 @@ struct pthread_atfork *af; pid_t ret; int errsave; - int unlock_malloc; + int was_threaded; int rtld_locks[MAX_RTLD_LOCKS]; if (!_thr_is_inited()) @@ -122,16 +122,16 @@ } /* - * Try our best to protect memory from being corrupted in - * child process because another thread in malloc code will - * simply be kill by fork(). + * All bets are off as to what should happen soon if the parent + * process was not so kindly as to set up pthread fork hooks to + * relinquish all running threads. */ if (_thr_isthreaded() != 0) { - unlock_malloc = 1; + was_threaded = 1; _malloc_prefork(); _rtld_atfork_pre(rtld_locks); } else { - unlock_malloc = 0; + was_threaded = 0; } /* @@ -159,7 +159,7 @@ _thr_umutex_init(&curthread->lock); _thr_umutex_init(&_thr_atfork_lock); - if (unlock_malloc) + if (was_threaded) _rtld_atfork_post(rtld_locks); _thr_setthreaded(0); @@ -173,7 +173,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) + if (was_threaded) _malloc_postfork(); /* Run down atfork child handlers. */ @@ -188,7 +188,7 @@ /* Ready to continue, unblock signals. */ _thr_signal_unblock(curthread); - if (unlock_malloc) { + if (was_threaded) { _rtld_atfork_post(rtld_locks); _malloc_postfork(); } Index: tools/regression/pthread/malloc_thread_fork_survival/no_deadlock.c =================================================================== --- tools/regression/pthread/malloc_thread_fork_survival/no_deadlock.c (revision 0) +++ tools/regression/pthread/malloc_thread_fork_survival/no_deadlock.c (revision 0) @@ -0,0 +1,55 @@ +/* + * Public domain, originally by Brian Fundakowski Feldman . + * $FreeBSD$ + */ +#include +#include + +#include +#include +#include +#include + +void * +noop(void *unused) +{ + return (NULL); +} + +void * +exit0(void *unused) +{ + const char ok[] = "ok\n"; + write(1, ok, sizeof(ok)); + exit(0); +} + +void * +exitN(int code) +{ + if (code == 0) { + exit0(NULL); + } else { + const char not_ok[] = "not ok\n"; + write(1, not_ok, sizeof(not_ok)); + exit(code); + } +} + +int +main() +{ + pthread_t thread; + int exited; + + pthread_create(&thread, NULL, noop, NULL); + pthread_join(thread, NULL); + if (fork() == 0) { + alarm(1); + pthread_create(&thread, NULL, exit0, NULL); + pthread_join(thread, NULL); + /* UNREACHED */ + } + wait(&exited); + exitN(WIFSIGNALED(exited) ? WTERMSIG(exited) : WEXITSTATUS(exited)); +} Index: tools/regression/pthread/malloc_thread_fork_survival/Makefile =================================================================== --- tools/regression/pthread/malloc_thread_fork_survival/Makefile (revision 0) +++ tools/regression/pthread/malloc_thread_fork_survival/Makefile (working copy) @@ -1,8 +1,8 @@ # $FreeBSD$ -PROG= cv_cancel1 +PROG= no_deadlock NO_MAN= -LDADD= -lpthread +LDADD= -lthr .include -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 22:46:55 2009 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 12D0C10656E4 for ; Fri, 16 Jan 2009 22:46:55 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9348FC0A for ; Fri, 16 Jan 2009 22:46:54 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id ACF4E28448 for ; Sat, 17 Jan 2009 06:46:53 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 3A033EC3905; Sat, 17 Jan 2009 06:46:53 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id iqXB4UiGC2LZ; Sat, 17 Jan 2009 06:46:47 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id A4356EC3885; Sat, 17 Jan 2009 06:46:45 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=vDfqF2lU79xjjGiZm/iHwX1gv9Snin5FbdMWLSCoc3BeaDgUVKUNjaD0sFNdp7iZ4 FKY4EpIaKRCZrInPyu9Hg== Message-ID: <49710E4F.6020404@delphij.net> Date: Fri, 16 Jan 2009 14:46:39 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090112) MIME-Version: 1.0 To: "Shaowei Wang (wsw)" References: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> In-Reply-To: <2e566b9e0901070005s630c2212k44a0e59a1bcf69aa@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------080608000400060203020104" Cc: freebsd-hackers@freebsd.org Subject: Re: A patch of HPTIOP driver for 7.1-RELEASE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2009 22:46:55 -0000 This is a multi-part message in MIME format. --------------080608000400060203020104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Shaowei, It seems that I can not apply your patch directly, I have tried to do it manually, as attached, please let me know if it's Ok. I can commit for you against -HEAD if it looks fine and take care for MFC. Note that, however, I am more or less concerned about the driver if 32-bit utility is running on amd64 platform. There seems to have three pointer style field in hpt_iop_ioctl_param. I have checked hptrr(4) and found that it has defined a 32-bit compatibility ioctl structure. According to my understanding to hptiop(4), this could be a problem. PS. For faster handling it is probably a good idea to submit patch through our PR system: http://www.freebsd.org/send-pr.html Shaowei Wang (wsw) wrote: > Hi, guys > > hptiop driver in the 7.1 release has a little bug. > Because this issue the Raid-manage GUI program which we provided can NOT > work anymore. > > So we give the patch: > > Index: hptiop.h > =================================================================== > --- hptiop.h (revision 186851) > +++ hptiop.h (working copy) > @@ -260,7 +260,7 @@ > unsigned long lpOutBuffer; /* output data buffer */ > u_int32_t nOutBufferSize; /* size of output data buffer > */ > unsigned long lpBytesReturned; /* count of HPT_U8s returned */ > -}; > +}__attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > ==================================================================== > > -wsw > > /************************************************************************/ > > 大家好： > > hptiop的驱动在7.1发行版中有个小错误。 > 这个小错误导致了我们提供的阵列管理程序无法运行。 > > 我们给出了补丁： > > Index: hptiop.h > =================================================================== > --- hptiop.h (revision 186851) > +++ hptiop.h (working copy) > @@ -260,7 +260,7 @@ > unsigned long lpOutBuffer; /* output data buffer */ > u_int32_t nOutBufferSize; /* size of output data buffer > */ > unsigned long lpBytesReturned; /* count of HPT_U8s returned */ > -}; > +}__attribute__((packed)); > > #define HPT_IOCTL_FLAG_OPEN 1 > #define HPT_CTL_CODE_BSD_TO_IOP(x) ((x)-0xff00) > > ==================================================================== > > -wsw > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAklxDk4ACgkQi+vbBBjt66CvUQCfaAnk0XQTh3Wrn2O4Dy0pEUFW oqsAoIvlTSNGRDg71SNyGfZ5VjDh9Z93 =1xSB -----END PGP SIGNATURE----- --------------080608000400060203020104 Content-Type: text/plain; name="hptiop.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="hptiop.diff" SW5kZXg6IHN5cy9kZXYvaHB0aW9wL2hwdGlvcC5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9k ZXYvaHB0aW9wL2hwdGlvcC5oCe+8iOeJiOacrCAxODczMzjvvIkKKysrIHN5cy9kZXYvaHB0 aW9wL2hwdGlvcC5oCe+8iOW3peS9nOWJr+acrO+8iQpAQCAtMjYwLDcgKzI2MCw3IEBACiAJ dW5zaWduZWQgbG9uZyAgICBscE91dEJ1ZmZlcjsgICAgICAgICAgIC8qIG91dHB1dCBkYXRh IGJ1ZmZlciAqLwogCXVfaW50MzJfdCAgICAgICAgbk91dEJ1ZmZlclNpemU7ICAgICAgICAv KiBzaXplIG9mIG91dHB1dCBkYXRhIGJ1ZmZlciAqLwogCXVuc2lnbmVkIGxvbmcgICAgbHBC eXRlc1JldHVybmVkOyAgICAgICAvKiBjb3VudCBvZiBIUFRfVThzIHJldHVybmVkICovCi19 OworfSBfX2F0dHJpYnV0ZV9fKChwYWNrZWQpKTsKIAogI2RlZmluZSBIUFRfSU9DVExfRkxB R19PUEVOIDEKICNkZWZpbmUgSFBUX0NUTF9DT0RFX0JTRF9UT19JT1AoeCkgKCh4KS0weGZm MDApCg== --------------080608000400060203020104-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jan 16 22:54:59 2009 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 1581810656D6; Fri, 16 Jan 2009 22:54:59 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id EAC1C8FC19; Fri, 16 Jan 2009 22:54:58 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from [192.168.168.201] (unknown [192.168.168.201]) by canonware.com (Postfix) with ESMTPA id A2E7D50819; Fri, 16 Jan 2009 14:36:47 -0800 (PST) Message-ID: <49710BD6.7040705@FreeBSD.org> Date: Fri, 16 Jan 2009 14:36:06 -0800 From: Jason Evans User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Brian Fundakowski Feldman References: <20090109031942.GA2825@green.homeunix.org> <20090109053117.GB2825@green.homeunix.org> <4966F81C.3070406@elischer.org> <20090109163426.GC2825@green.homeunix.org> <49678BBC.8050306@elischer.org> <20090116211959.GA12007@green.homeunix.org> In-Reply-To: <20090116211959.GA12007@green.homeunix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jasone@freebsd.org, hackers@freebsd.org, Julian Elischer Subject: Re: threaded, forked, rethreaded processes will deadlock 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, 16 Jan 2009 22:54:59 -0000 Brian Fundakowski Feldman wrote: > Could you, and anyone else who would care to, check this out? It's a regression > fix but it also makes the code a little bit clearer. Thanks! > > Index: lib/libc/stdlib/malloc.c Why does malloc need to change for this? Unless there's a really good reason, I don't want the extra branches in the locking functions. Thanks, Jason From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 13:23:50 2009 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 AA95910656EB for ; Sat, 17 Jan 2009 13:23:50 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 67F578FC13 for ; Sat, 17 Jan 2009 13:23:50 +0000 (UTC) (envelope-from des@des.no) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 979F06D43F; Sat, 17 Jan 2009 13:23:49 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 7AD5E844EF; Sat, 17 Jan 2009 14:23:49 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Garrett Cooper References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> Date: Sat, 17 Jan 2009 14:23:49 +0100 In-Reply-To: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> (Garrett Cooper's message of "Fri, 16 Jan 2009 00:41:37 -0800") Message-ID: <86wscuyska.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "amd64@freebsd.org" , Hackers freeBSD Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 17 Jan 2009 13:23:51 -0000 Garrett Cooper writes: > #include > #include > #include > #include > #include You should always put your sys includes before your non-sys includes, and in any case, should always come first. > printf("Errno: %d\n", errno); > errx(errno, "Error: %s", strerror(errno)); In addition to what everybody else said, errno is not an appropriate value for errx's first argument. Use 1 or EXIT_FAILURE (or one of the macros defined in , but I wouldn't recommend it). Also, you probably want to use err(), not errx(), and *always* compile with -Wall -Wextra, and unless you're going to run gdb on your program, -O2 (which enables additional code analysis) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 14:49:52 2009 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 8F44E1065670 for ; Sat, 17 Jan 2009 14:49:52 +0000 (UTC) (envelope-from lazaax.und@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 6712E8FC0C for ; Sat, 17 Jan 2009 14:49:52 +0000 (UTC) (envelope-from lazaax.und@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2087092rvf.43 for ; Sat, 17 Jan 2009 06:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=UAUGswAmIxUTUTnEXIzLbRGtdAFI6VZoSELweYiBlNQ=; b=jJ0pQbxG9EJYTybvSwrXdj8AamSu7dJgpks3GV0g7Vf232vFbZI4ki1CtIKc/KTIhm NcMzbR97vOiIeuDjLOQiH4n8ySupYBfOCPhCweLtaWvMxRemg7cF7w+lE/toiO8iRK8Q wCMhkqLtMlNho5/p+lzIwSnt5jduMha42AbNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=AX/X2orctZIv++//ky73f5HYtITh4vGG8GYDcETK9mvwXp9ZSPuPp3spr1AmKEQJpO 5jOpFTnZeimNjyD0Dtf06Ci3Zq+M+qFx6s/S6WBEnWPOVkKKcF5BIQZdOSesRFFmHKlI 2TFN4jQHPHHmLL9oRqTnTHQO0dDRg6j1yoOak= MIME-Version: 1.0 Received: by 10.141.36.10 with SMTP id o10mr1809259rvj.254.1232203792031; Sat, 17 Jan 2009 06:49:52 -0800 (PST) Date: Sat, 17 Jan 2009 15:49:51 +0100 Message-ID: <4374ff010901170649t38435dc4jdea9684cfa147b45@mail.gmail.com> From: lazaax - To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: admin jop 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, 17 Jan 2009 14:49:52 -0000 hi hackers, is someone that can tell me how mach money can a company pay me each mount for admin a bsd server installed in the company, i will adminthe server remotly, is not a stable jop.... please can tell me on us dolar -- Leon Chavez Colima, Mexico "lazaax" From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 22:16:29 2009 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 152A21065677; Sat, 17 Jan 2009 22:16:29 +0000 (UTC) (envelope-from mbsd@pacbell.net) Received: from nlpi015.prodigy.net (nlpi015.sbcis.sbc.com [207.115.36.44]) by mx1.freebsd.org (Postfix) with ESMTP id BA1998FC08; Sat, 17 Jan 2009 22:16:28 +0000 (UTC) (envelope-from mbsd@pacbell.net) Received: from antec (adsl-99-22-93-85.dsl.pltn13.sbcglobal.net [99.22.93.85]) (authenticated bits=0) by nlpi015.prodigy.net (8.13.8 smtpauth/dk/map_regex/8.13.8) with ESMTP id n0HM5WRs009370; Sat, 17 Jan 2009 16:05:52 -0600 Date: Sat, 17 Jan 2009 14:05:33 -0800 (PST) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= To: Garrett Cooper In-Reply-To: <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> Message-ID: <20090117140506.A2568@antec.home> References: <7d6fde3d0901160041n55466290l55f737d274a40895@mail.gmail.com> <49704AEC.3080709@gmx.de> <7d6fde3d0901160056y7c395cb1m4675a3957b85f33d@mail.gmail.com> <49704C13.60505@gmx.de> <7d6fde3d0901160058x785b0af7r741fc779eb537d5@mail.gmail.com> <7d6fde3d0901160119u7ca9606dw55300cd279410ad2@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "amd64@freebsd.org" , Hackers freeBSD , Christoph Mallon Subject: Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's 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, 17 Jan 2009 22:16:29 -0000 Hi Garrett, On Fri, 16 Jan 2009, Garrett Cooper wrote: > On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper wrote: >> On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon >> wrote: >>> Garrett Cooper schrieb: >>>> >>>> Good point. I modified the source to do that. >>>> Thanks, >>>> -Garrett >>> >>> You should reply to all so the discussion stays on the list. >> >> Yeah, that was a goofup on my part. Go-go Gmail web interface! >> -Garrett > > Hmmm... looks like the strerror issue it could be a serious bug: Add #include . Without it you don't get the strerror() prototype, so the return value defaults to an int. Thus the compiler will truncate the pointer value to junk. The crash happens when formatting the output. Compile with -Wall and pay attention to warnings (or use -Werror) to catch these things. $.02, /Mikko > > #include > #include > #include > > int > main() > { > > struct stat sb; > > int o_errno; > > if (stat("/some/file/that/doesn't/exist", &sb) != 0) { > o_errno = errno; > printf("Errno: %d\n", errno); > err(errno, "%s", strerror(o_errno)); > } > > return 0; > > } > > [gcooper@optimus ~]$ ./badfile > Errno: 2 > badfile: Segmentation fault: 11 (core dumped) > > I rebuilt my kernel and installed it, and I rebuilt world, but > haven't installed it yet though, so let me reboot the amd64 machine > and see what happens (may be a mismatched ABI issue)... > Cheers, > -Garrett > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Sat Jan 17 23:41:57 2009 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 106C3106566B for ; Sat, 17 Jan 2009 23:41:57 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9800D8FC08 for ; Sat, 17 Jan 2009 23:41:56 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ey-out-2122.google.com with SMTP id d26so236787eyd.7 for ; Sat, 17 Jan 2009 15:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition; bh=WPeDrc+7sbkuCWW4ge7jCCFycSdKRN5v4Z1V18MTV/I=; b=JA/e10lyy8/xKZXJzC5fO1bcb4TbSfgj2B9D+RJG0ZXGLMVOCXDjSCviCZbZqhYxFs ldbnmWdGi9PWJnLb2eEuD3Szo0M7buuMuIrV01Sr+aDtR8KlsuA/SzyEHoQk5SPawMWL CggLIAd9mcLnYqCo7mCrdRvDlr6zCLyx6U200= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition; b=Wm/VGANeomFu/X5cXJkdRpn2Me57KGv3Ky71+121O+1fGjTIlLP6P4GKG/d6kMP70C uFRgKk5xBWnpCTgMvzcL32CmaLLmHZqDUQPsE46Q8g8QfEXmU0nCrAgG2Dbj97/hAXHL ZcGoOXRhDN4XpFHboOpH/CVvpZvt2RnwJn3rY= Received: by 10.210.61.8 with SMTP id j8mr5154989eba.45.1232234046837; Sat, 17 Jan 2009 15:14:06 -0800 (PST) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id t2sm4950499gve.26.2009.01.17.15.14.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Jan 2009 15:14:06 -0800 (PST) Received: by logik.internal.network (Postfix, from userid 11001) id 045815C2B; Sat, 17 Jan 2009 23:14:04 +0000 (UTC) Date: Sat, 17 Jan 2009 23:14:04 +0000 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20090117231404.GB77134@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: gcc 4.3.2 libgcc_s.so exception handling broken? 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, 17 Jan 2009 23:41:58 -0000 Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the "foreign" code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. To clarify: 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. process exits In this case, the C code lives inside a dynamic library, which is linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified this explicity, I'm assuming -fexceptions causes this). If I statically link the C code (so libgcc_s.so isn't involved, I think), the exception is propagated correctly. 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. stack unwinds back to Ada_program_main. 5. Ada_program_main handles exception. Why is it that the code can't unwind the call stack correctly? Is this a bug? The same code seems to work correctly on Debian Lenny with the same compiler. Any help would be appreciated. xw