From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 13 09:48:13 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04BDE106566C; Sun, 13 Nov 2011 09:48:13 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 42F3D8FC12; Sun, 13 Nov 2011 09:48:12 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 6BEC46A61CD; Sun, 13 Nov 2011 10:48:11 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id 3AKlb2JRGj5K; Sun, 13 Nov 2011 10:48:11 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 1D8476A6016; Sun, 13 Nov 2011 10:48:11 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id pAD9mAln027044; Sun, 13 Nov 2011 10:48:10 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id pAD9mAfV026672; Sun, 13 Nov 2011 10:48:10 +0100 (CET) (envelope-from lars) Date: Sun, 13 Nov 2011 10:48:10 +0100 From: Lars Engels To: rank1seeker@gmail.com Message-ID: <20111113094810.GC80782@e-new.0x20.net> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uXxzq0nDebZQVNAZ" Content-Disposition: inline In-Reply-To: <20111112.144149.725.1@DOMY-PC> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 13 Nov 2011 12:07:37 +0000 Cc: pyunyh@gmail.com, freebsd-acpi@freebsd.org, hackers@freebsd.org Subject: Re: Adventure into S3 state and back 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, 13 Nov 2011 09:48:13 -0000 --uXxzq0nDebZQVNAZ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 12, 2011 at 03:41:49PM +0100, rank1seeker@gmail.com wrote: > ----- Original Message ----- > From: YongHyeon PYUN > To: rank1seeker@gmail.com > Cc: hackers@freebsd.org, freebsd-acpi@freebsd.org > Date: Fri, 11 Nov 2011 16:27:27 -0800 > Subject: Re: Adventure into S3 state and back >=20 > > On Thu, Nov 10, 2011 at 07:29:48PM +0100, rank1seeker@gmail.com wrote: > > > 8.2-p4 RELEASE amd64 > > >=20 > > > I've built a custom kernel, only with drivers, that I need > > > After resuming from S3 ... > > >=20 > > > I hit: > > > # ifconfig > > > and all hells breaks loose: > > > ---- > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) > > > media: Ethernet autoselect > > > status: no carrier > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) > > > ugen3.2: at usbus3 (disconnected) > > > ukbd0: at uhub3, port 1, addr 2 (disconnected) > > > ums0: at uhub3, port 1, addr 2 (disconnected) > > > uhid0: at uhub3, port 1, addr 2 (disconnected) > > > bge0: PHY read timed out (phy 1, reg 4, val 0xffffffff) > > > ugen3.2: at usbus3 > > > ukbd0: on= =20 > usbus3 > > > kbd2 at ukbd0 > > > ums0: on= =20 > usbus3 > > > ums0: 16 buttons and [XYZT] coordinates ID=3D2 > > > uhid0: on= =20 > usbus3 > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) > > > pflog0: flags=3D141 metric 0 mtu 33152 > > > lo0: flags=3D8049 metric 0 mtu 16384 > > > options=3D3 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > > inet6 ::1 prefixlen 128 > > > inet 127.0.0.1 netmask 0xff000000 > > > nd6 options=3D3 > > > cruiser# ifconfig > > > bge0: flags=3D8802 metric 0 mtu 1500 > > > =20 > options=3D8009b > > > ether 00:21:70:70:01:df > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > >=20 > > > ... ... ... > >=20 > > Known issue. kern/136876. > > Mobile bge(4) controllers seem to have this issue. >=20 > I can see this has been reported, when 8.0-BETA1 was released. > Now is almost 8.3 out and problem is still present >=20 > > > ---- > > >=20 > > > So, taking into account: > > > "A common problem with suspend/resume is that many device drivers do= =20 > not save, restore, or reinitialize their firmware, registers, or device= =20 > memory properly." > > >=20 > > > Next step was to get rid of 'bge' device from my KERNCONF and recompi= le=20 > it. > > > Voila! S3 works! > > >=20 > > > But another, mouse problem, didn't go away! > > > In 9 out of 10 cases, mouse doesn't resume. > > > As it is USB mouse, I've did: > > >=20 > > > # camcontrol rescan all > > > didn't help > > >=20 > > > I've also tried adding into loader.conf and nada: > > > --- > > > hint.psm.0.flags=3D"0x3000" > > > --- > > > But i think it is PS/2 related > > >=20 > > > What works 100% for a mouse is to unplug and then plug back it's USB= =20 > receiver > > >=20 > > > This is Dell D830 laptop > > >=20 >=20 > How do I solve mouse issue? > It is annoying to unplug and then plug back it's USB receiver, each time. stop moused in rc.suspend and start it in rc.resume. --uXxzq0nDebZQVNAZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6/kloACgkQKc512sD3afiP4ACfWQNbSYsSVJTm6vdOF2ymiGpd ftkAoLp+sFNEQ8IMx6zpQOz51Ofltiar =mGyx -----END PGP SIGNATURE----- --uXxzq0nDebZQVNAZ-- From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 13 13:29:30 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3479106566C; Sun, 13 Nov 2011 13:29:30 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4241F8FC13; Sun, 13 Nov 2011 13:29:29 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so6841004bkb.13 for ; Sun, 13 Nov 2011 05:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:in-reply-to:references:x-mailer; bh=0lEFaUOmpNGx1xmo6/bVKLS5afJjAmIFU+CAVAJ6pXI=; b=NT1VsPb9Vu1dqpx9I+X668uGTFYcJNc0dsrySOf6JAU0avomtBw6lOAD/xMtiA9kSR 8Ag25Wxm4Cs0cr+j2UASdO33rcIQL85UXNZDqL+xjqGQGU5OSjBTBpTrT6ziLK4Z7dj7 aTCqJKTwMC4I40QdS79dZDkgHWx7tFEk3fwis= Received: by 10.205.141.73 with SMTP id jd9mr4713639bkc.21.1321190968903; Sun, 13 Nov 2011 05:29:28 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id r12sm25211005bkw.5.2011.11.13.05.29.22 (version=SSLv3 cipher=OTHER); Sun, 13 Nov 2011 05:29:27 -0800 (PST) Message-ID: <20111113.132924.396.1@DOMY-PC> From: rank1seeker@gmail.com To: "Lars Engels" , pyunyh@gmail.com, hackers@freebsd.org, freebsd-acpi@freebsd.org Date: Sun, 13 Nov 2011 14:29:24 +0100 In-Reply-To: <20111113094810.GC80782@e-new.0x20.net> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> <20111113094810.GC80782@e-new.0x20.net> X-Mailer: POP Peeper (3.8.0.0) Cc: Subject: Re: Adventure into S3 state and back 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, 13 Nov 2011 13:29:31 -0000 ----- Original Message ----- From: Lars Engels To: rank1seeker@gmail.com Cc: pyunyh@gmail.com, hackers@freebsd.org, freebsd-acpi@freebsd.org Date: Sun, 13 Nov 2011 10:48:10 +0100 Subject: Re: Adventure into S3 state and back > On Sat, Nov 12, 2011 at 03:41:49PM +0100, rank1seeker@gmail.com wrote: > > ----- Original Message ----- > > From: YongHyeon PYUN > > To: rank1seeker@gmail.com > > Cc: hackers@freebsd.org, freebsd-acpi@freebsd.org > > Date: Fri, 11 Nov 2011 16:27:27 -0800 > > Subject: Re: Adventure into S3 state and back > > > > > On Thu, Nov 10, 2011 at 07:29:48PM +0100, rank1seeker@gmail.com wrote: > > > > 8.2-p4 RELEASE amd64 > > > > > > > > I've built a custom kernel, only with drivers, that I need > > > > After resuming from S3 ... > > > > > > > > I hit: > > > > # ifconfig > > > > and all hells breaks loose: > > > > ---- > > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) > > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) > > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) > > > > media: Ethernet autoselect > > > > status: no carrier > > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > > bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) > > > > ugen3.2: at usbus3 (disconnected) > > > > ukbd0: at uhub3, port 1, addr 2 (disconnected) > > > > ums0: at uhub3, port 1, addr 2 (disconnected) > > > > uhid0: at uhub3, port 1, addr 2 (disconnected) > > > > bge0: PHY read timed out (phy 1, reg 4, val 0xffffffff) > > > > ugen3.2: at usbus3 > > > > ukbd0: on > > usbus3 > > > > kbd2 at ukbd0 > > > > ums0: on > > usbus3 > > > > ums0: 16 buttons and [XYZT] coordinates ID=2 > > > > uhid0: on > > usbus3 > > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) > > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) > > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) > > > > pflog0: flags=141 metric 0 mtu 33152 > > > > lo0: flags=8049 metric 0 mtu 16384 > > > > options=3 > > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > > > inet6 ::1 prefixlen 128 > > > > inet 127.0.0.1 netmask 0xff000000 > > > > nd6 options=3 > > > > cruiser# ifconfig > > > > bge0: flags=8802 metric 0 mtu 1500 > > > > > > options=8009b > > > > ether 00:21:70:70:01:df > > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > > > > > > ... ... ... > > > > > > Known issue. kern/136876. > > > Mobile bge(4) controllers seem to have this issue. > > > > I can see this has been reported, when 8.0-BETA1 was released. > > Now is almost 8.3 out and problem is still present > > > > > > ---- > > > > > > > > So, taking into account: > > > > "A common problem with suspend/resume is that many device drivers do > > not save, restore, or reinitialize their firmware, registers, or device > > memory properly." > > > > > > > > Next step was to get rid of 'bge' device from my KERNCONF and recompile > > it. > > > > Voila! S3 works! > > > > > > > > But another, mouse problem, didn't go away! > > > > In 9 out of 10 cases, mouse doesn't resume. > > > > As it is USB mouse, I've did: > > > > > > > > # camcontrol rescan all > > > > didn't help > > > > > > > > I've also tried adding into loader.conf and nada: > > > > --- > > > > hint.psm.0.flags="0x3000" > > > > --- > > > > But i think it is PS/2 related > > > > > > > > What works 100% for a mouse is to unplug and then plug back it's USB > > receiver > > > > > > > > This is Dell D830 laptop > > > > > > > > How do I solve mouse issue? > > It is annoying to unplug and then plug back it's USB receiver, each time. > > stop moused in rc.suspend and start it in rc.resume. > Thanks, but it isn't that. Even with it, mouse works on random, after resume from S3. But what I did figured out, looking kernel msgs on console, just after resume, is that IF I see >1 of this: -- uhub_reattach_port: port 1 reset failed, error=USB_ERR_TIMEOUT uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 -- Mouse won't work unless I unplug/plug it's USB receiver From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 13 20:10:25 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03D2C106566B; Sun, 13 Nov 2011 20:10:25 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A5EB48FC14; Sun, 13 Nov 2011 20:10:24 +0000 (UTC) Received: by ywe9 with SMTP id 9so2687024ywe.13 for ; Sun, 13 Nov 2011 12:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CGnGL2xXJmRmvRvFxwpSkCQ/Kn9v6E7s+4t/Q1F+UTM=; b=LejLfeWatbyvx8TmXvBY8oxzWRHVMn6RYnRlOos/heDu9vHFKvrj7zW8IRTwzP2+VS iBliy25ESn2ER4uT2nbmfu97ESxNSMkfhZL+ASqpC1ktVz8rzAn+MPM2YdNgEe7PhH9F 6/wLfjMOqt0J2cSaRQtwcQd70aV917cnK1Dvg= MIME-Version: 1.0 Received: by 10.182.12.66 with SMTP id w2mr1256326obb.7.1321213362402; Sun, 13 Nov 2011 11:42:42 -0800 (PST) Received: by 10.182.7.34 with HTTP; Sun, 13 Nov 2011 11:42:42 -0800 (PST) In-Reply-To: <20111113.132924.396.1@DOMY-PC> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> <20111113094810.GC80782@e-new.0x20.net> <20111113.132924.396.1@DOMY-PC> Date: Sun, 13 Nov 2011 11:42:42 -0800 Message-ID: From: Garrett Cooper To: rank1seeker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pyunyh@gmail.com, freebsd-acpi@freebsd.org, hackers@freebsd.org, Lars Engels Subject: Re: Adventure into S3 state and back 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, 13 Nov 2011 20:10:25 -0000 On Sun, Nov 13, 2011 at 5:29 AM, wrote: > ----- Original Message ----- > From: Lars Engels > To: rank1seeker@gmail.com > Cc: pyunyh@gmail.com, hackers@freebsd.org, freebsd-acpi@freebsd.org > Date: Sun, 13 Nov 2011 10:48:10 +0100 > Subject: Re: Adventure into S3 state and back > >> On Sat, Nov 12, 2011 at 03:41:49PM +0100, rank1seeker@gmail.com wrote: >> > ----- Original Message ----- >> > From: YongHyeon PYUN >> > To: rank1seeker@gmail.com >> > Cc: hackers@freebsd.org, freebsd-acpi@freebsd.org >> > Date: Fri, 11 Nov 2011 16:27:27 -0800 >> > Subject: Re: Adventure into S3 state and back >> > >> > > On Thu, Nov 10, 2011 at 07:29:48PM +0100, rank1seeker@gmail.com wrot= e: >> > > > 8.2-p4 RELEASE amd64 >> > > > >> > > > I've built a custom kernel, only with drivers, that I need >> > > > After resuming from S3 ... >> > > > >> > > > I hit: >> > > > # ifconfig >> > > > and all hells breaks loose: >> > > > ---- >> > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) >> > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) >> > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) >> > > > =A0 =A0 =A0 =A0 media: Ethernet autoselect >> > > > =A0 =A0 =A0 =A0 status: no carrier >> > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) >> > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) >> > > > bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) >> > > > ugen3.2: at usbus3 (disconnected) >> > > > ukbd0: at uhub3, port 1, addr 2 (disconnected) >> > > > ums0: at uhub3, port 1, addr 2 (disconnected) >> > > > uhid0: at uhub3, port 1, addr 2 (disconnected) >> > > > bge0: PHY read timed out (phy 1, reg 4, val 0xffffffff) >> > > > ugen3.2: at usbus3 >> > > > ukbd0: > on >> > usbus3 >> > > > kbd2 at ukbd0 >> > > > ums0: o= n >> > usbus3 >> > > > ums0: 16 buttons and [XYZT] coordinates ID=3D2 >> > > > uhid0: > on >> > usbus3 >> > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) >> > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) >> > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) >> > > > pflog0: flags=3D141 metric 0 mtu 33152 >> > > > lo0: flags=3D8049 metric 0 mtu 1638= 4 >> > > > =A0 =A0 =A0 =A0 options=3D3 >> > > > =A0 =A0 =A0 =A0 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 >> > > > =A0 =A0 =A0 =A0 inet6 ::1 prefixlen 128 >> > > > =A0 =A0 =A0 =A0 inet 127.0.0.1 netmask 0xff000000 >> > > > =A0 =A0 =A0 =A0 nd6 options=3D3 >> > > > cruiser# ifconfig >> > > > bge0: flags=3D8802 metric 0 mtu 1500 >> > > > >> > > options=3D8009b >> > > > =A0 =A0 =A0 =A0 ether 00:21:70:70:01:df >> > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) >> > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) >> > > > >> > > > ... ... ... >> > > >> > > Known issue. kern/136876. >> > > Mobile bge(4) controllers seem to have this issue. >> > >> > I can see this has been reported, when 8.0-BETA1 was released. >> > Now is almost 8.3 out and problem is still present >> > >> > > > ---- >> > > > >> > > > So, taking into account: >> > > > "A common problem with suspend/resume is that many device drivers > do >> > not save, restore, or reinitialize their firmware, registers, or devic= e >> > memory properly." >> > > > >> > > > Next step was to get rid of 'bge' device from my KERNCONF and > recompile >> > it. >> > > > Voila! S3 works! >> > > > >> > > > But another, mouse problem, didn't go away! >> > > > In 9 out of 10 cases, mouse doesn't resume. >> > > > As it is USB mouse, I've did: >> > > > >> > > > # camcontrol rescan all >> > > > =A0 =A0 didn't help >> > > > >> > > > I've also tried adding into loader.conf and nada: >> > > > --- >> > > > hint.psm.0.flags=3D"0x3000" >> > > > --- >> > > > But i think it is PS/2 related >> > > > >> > > > What works 100% for a mouse is to unplug and then plug back it's > USB >> > receiver >> > > > >> > > > This is Dell D830 laptop >> > > > >> > >> > How do I solve mouse issue? >> > It is annoying to unplug and then plug back it's USB receiver, each > time. >> >> stop moused in rc.suspend and start it in rc.resume. >> > > Thanks, but it isn't that. > Even with it, mouse works on random, after resume from S3. > > But what I did figured out, looking kernel msgs on console, just after > resume, is that IF I see >1 of this: > -- > uhub_reattach_port: port 1 reset failed, error=3DUSB_ERR_TIMEOUT > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 > -- > > Mouse won't work unless I unplug/plug it's USB receiver You may need to kldunload and kldload ums(4) in order to get things to work (which suggests a driver bug in the newbus suspend and resume functions). FWIW I only need to do /etc/rc.d/moused restart in rc.resume to get things to work, but I'm using psm(4). The mouse pointer is kind of braindead for a second, but then it comes to life and does the right thing. So, bottom line is that there's something that gets out of sync with some mice drivers and moused, and mice driver bugs or bugs with moused might be involved. HTH, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 13 20:42:48 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12D6F106566B; Sun, 13 Nov 2011 20:42:48 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 964008FC08; Sun, 13 Nov 2011 20:42:47 +0000 (UTC) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mail.0x20.net (Postfix) with ESMTP id 602666A61CD; Sun, 13 Nov 2011 21:42:46 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.0x20.net Received: from mail.0x20.net ([217.69.76.211]) by mail.0x20.net (mail.0x20.net [217.69.76.211]) (amavisd-new, port 10024) with ESMTP id A5Y-35dmK6Q9; Sun, 13 Nov 2011 21:42:46 +0100 (CET) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 13E356A6016; Sun, 13 Nov 2011 21:42:46 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.4/8.14.4) with ESMTP id pADKgj7V061978; Sun, 13 Nov 2011 21:42:45 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.4/8.14.4/Submit) id pADKgjqJ060709; Sun, 13 Nov 2011 21:42:45 +0100 (CET) (envelope-from lars) Date: Sun, 13 Nov 2011 21:42:45 +0100 From: Lars Engels To: rank1seeker@gmail.com Message-ID: <20111113204245.GD80782@e-new.0x20.net> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> <20111113094810.GC80782@e-new.0x20.net> <20111113.132924.396.1@DOMY-PC> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OaZoDhBhXzo6bW1J" Content-Disposition: inline In-Reply-To: <20111113.132924.396.1@DOMY-PC> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.2-RELEASE-p3 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Mon, 14 Nov 2011 02:12:31 +0000 Cc: pyunyh@gmail.com, freebsd-acpi@freebsd.org, hackers@freebsd.org Subject: Re: Adventure into S3 state and back 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, 13 Nov 2011 20:42:48 -0000 --OaZoDhBhXzo6bW1J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 13, 2011 at 02:29:24PM +0100, rank1seeker@gmail.com wrote: > ----- Original Message ----- > From: Lars Engels > To: rank1seeker@gmail.com > Cc: pyunyh@gmail.com, hackers@freebsd.org, freebsd-acpi@freebsd.org > Date: Sun, 13 Nov 2011 10:48:10 +0100 > Subject: Re: Adventure into S3 state and back > >=20 > > stop moused in rc.suspend and start it in rc.resume. > >=20 >=20 > Thanks, but it isn't that. > Even with it, mouse works on random, after resume from S3. >=20 > But what I did figured out, looking kernel msgs on console, just after=20 > resume, is that IF I see >1 of this: > -- > uhub_reattach_port: port 1 reset failed, error=3DUSB_ERR_TIMEOUT > uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling port 1 > -- >=20 > Mouse won't work unless I unplug/plug it's USB receiver >=20 You might also build a trimmed down kernel without USB support compiled in and use USB modules. Before suspending, unload them and re-load them after waking up again. That used to work on my Thinkpad. --OaZoDhBhXzo6bW1J Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7AK8UACgkQKc512sD3afj6JgCgs7vgUcQHpqFym763TgdeaVuL or4An19noVLc2N3OvEEKPBosth4eYlw4 =YCD1 -----END PGP SIGNATURE----- --OaZoDhBhXzo6bW1J-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 14 02:16:17 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E51EE1065670; Mon, 14 Nov 2011 02:16:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8F39D8FC1B; Mon, 14 Nov 2011 02:16:16 +0000 (UTC) Received: by ywe9 with SMTP id 9so2880539ywe.13 for ; Sun, 13 Nov 2011 18:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=G0DCQS234YwcMFVXmKxTIEcE/yIJb4PL/JUvpgqnjX0=; b=r9dxXHMJnmTNQuIPOaX9vdlXQet8LUrvmUP8/0dP6rYpm/JtVchOe7Q0eKdyae9s1G hcEzZ04zHHL1Cne0z2L6rTgyifV4Lir1jM0b/+Mf9X8axv9DYDgOYOeWFctPhxx6f1Zp YGggUa1rlrdoXFgWAxzbHhV/fa797VS/R+LiA= Received: by 10.68.209.9 with SMTP id mi9mr5269967pbc.62.1321236975449; Sun, 13 Nov 2011 18:16:15 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id wf19sm52621432pbb.17.2011.11.13.18.16.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 Nov 2011 18:16:14 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 13 Nov 2011 18:14:13 -0800 From: YongHyeon PYUN Date: Sun, 13 Nov 2011 18:14:13 -0800 To: rank1seeker@gmail.com Message-ID: <20111114021413.GA1709@michelle.cdnetworks.com> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111112.144149.725.1@DOMY-PC> User-Agent: Mutt/1.4.2.3i Cc: freebsd-acpi@freebsd.org, hackers@freebsd.org Subject: Re: Adventure into S3 state and back 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: Mon, 14 Nov 2011 02:16:17 -0000 On Sat, Nov 12, 2011 at 03:41:49PM +0100, rank1seeker@gmail.com wrote: > ----- Original Message ----- > From: YongHyeon PYUN > To: rank1seeker@gmail.com > Cc: hackers@freebsd.org, freebsd-acpi@freebsd.org > Date: Fri, 11 Nov 2011 16:27:27 -0800 > Subject: Re: Adventure into S3 state and back > > > On Thu, Nov 10, 2011 at 07:29:48PM +0100, rank1seeker@gmail.com wrote: > > > 8.2-p4 RELEASE amd64 > > > > > > I've built a custom kernel, only with drivers, that I need > > > After resuming from S3 ... > > > > > > I hit: > > > # ifconfig > > > and all hells breaks loose: > > > ---- > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) > > > media: Ethernet autoselect > > > status: no carrier > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) > > > ugen3.2: at usbus3 (disconnected) > > > ukbd0: at uhub3, port 1, addr 2 (disconnected) > > > ums0: at uhub3, port 1, addr 2 (disconnected) > > > uhid0: at uhub3, port 1, addr 2 (disconnected) > > > bge0: PHY read timed out (phy 1, reg 4, val 0xffffffff) > > > ugen3.2: at usbus3 > > > ukbd0: on > usbus3 > > > kbd2 at ukbd0 > > > ums0: on > usbus3 > > > ums0: 16 buttons and [XYZT] coordinates ID=2 > > > uhid0: on > usbus3 > > > bge0: PHY read timed out (phy 1, reg 5, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 10, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 25, val 0xffffffff) > > > pflog0: flags=141 metric 0 mtu 33152 > > > lo0: flags=8049 metric 0 mtu 16384 > > > options=3 > > > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > > > inet6 ::1 prefixlen 128 > > > inet 127.0.0.1 netmask 0xff000000 > > > nd6 options=3 > > > cruiser# ifconfig > > > bge0: flags=8802 metric 0 mtu 1500 > > > > options=8009b > > > ether 00:21:70:70:01:df > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > bge0: PHY read timed out (phy 1, reg 1, val 0xffffffff) > > > > > > ... ... ... > > > > Known issue. kern/136876. > > Mobile bge(4) controllers seem to have this issue. > > I can see this has been reported, when 8.0-BETA1 was released. > Now is almost 8.3 out and problem is still present Actually I spent a lot of time to address this but all attempts failed mainly because I have no access to such bge(4) controllers. Remote debugging does not work for suspend/resume issues so chances would be low to get it fixed in near future unless someone donate problematic hardwares to me. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 14 19:51:04 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B1BF106564A; Mon, 14 Nov 2011 19:51:04 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CA8CB8FC14; Mon, 14 Nov 2011 19:51:03 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so8687114bkb.13 for ; Mon, 14 Nov 2011 11:51:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:content-type :content-transfer-encoding:in-reply-to:references:x-mailer; bh=+JQw/hwGWhqVxG4njFjFqLJUjTPYSJEeCI+5GqfHBII=; b=HR8+7Fa7lfxvK9Ijm75uLYnkJ500nQwlHeBTmcQZa2bpHpAclEw3uky+swt2Bfr967 uLRtwWFyCt7EsvVK2PyICWnUZ1XcbGBjgmnj520i2VHLAEKDeAL6lhEkrswMEjZOJQr4 t2rgBfv7NV7cqS9G1V3Bt2cwSBhe14sJ3JX1g= Received: by 10.204.129.70 with SMTP id n6mr20972312bks.0.1321300262524; Mon, 14 Nov 2011 11:51:02 -0800 (PST) Received: from DOMYPC ([82.193.208.173]) by mx.google.com with ESMTPS id a4sm24435431bkq.13.2011.11.14.11.50.57 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 11:51:00 -0800 (PST) Message-ID: <20111114.195057.675.1@DOMY-PC> From: rank1seeker@gmail.com To: "Garrett Cooper" , "Lars Engels" , "Ian Smith" , pyunyh@gmail.com, hackers@freebsd.org, freebsd-acpi@freebsd.org Date: Mon, 14 Nov 2011 20:50:57 +0100 Content-Type: text/plain; charset="Windows-1250" Content-Transfer-Encoding: quoted-printable In-Reply-To: <20111114021413.GA1709@michelle.cdnetworks.com> References: <20111110.182948.630.1@DOMY-PC> <20111112002727.GD17792@michelle.cdnetworks.com> <20111112.144149.725.1@DOMY-PC> <20111114021413.GA1709@michelle.cdnetworks.com> X-Mailer: POP Peeper (3.8.0.0) Cc: Subject: Re: Adventure into S3 state and back 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, 14 Nov 2011 19:51:04 -0000 ----- Original Message -----=0D=0AFrom: YongHyeon PYUN = =0D=0ATo: rank1seeker@gmail.com=0D=0ACc: = hackers@freebsd.org, freebsd-acpi@freebsd.org=0D=0ADate: Sun, 13 Nov 2011 = 18:14:13 -0800=0D=0ASubject: Re: Adventure into S3 state and = back=0D=0A=0D=0A> > > =0D=0A> > > Known issue. kern/136876.=0D=0A> > > = Mobile bge(4) controllers seem to have this issue.=0D=0A> > =0D=0A> > I = can see this has been reported, when 8.0-BETA1 was released.=0D=0A> > Now = is almost 8.3 out and problem is still present=0D=0A> =0D=0A> Actually I = spent a lot of time to address this but all attempts=0D=0A> failed mainly = because I have no access to such bge(4) controllers.=0D=0A> Remote = debugging does not work for suspend/resume issues so chances=0D=0A> would = be low to get it fixed in near future unless someone donate=0D=0A> = problematic hardwares to me.=0D=0A=0D=0A=0D=0AThen you have to = update:=0D=0Ahttp://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/136876=0D=0A=0D=0AAnd = post at the end, something like ...=0D=0A"All attempts to fix problem = failed, due to physicall unavailability of bge(4) controller.=0D=0ASTATUS = -> Waiting for donation of bge(4) hardware, in order to resume fixing a = problem"=0D=0A=0D=0A=0D=0A> > Mouse won't work unless I unplug/plug it's = USB receiver=0D=0A> =0D=0A> You may need to kldunload and kldload ums(4) = in order to get things to=0D=0A> work (which suggests a driver bug in the = newbus suspend and resume=0D=0A> functions).=0D=0A> =0D=0A> FWIW I only = need to do /etc/rc.d/moused restart in rc.resume to get=0D=0A> things to = work, but I'm using psm(4). The mouse pointer is kind of=0D=0A> braindead = for a second, but then it comes to life and does the right=0D=0A> = thing.=0D=0A> =0D=0A> So, bottom line is that there's something that gets = out of sync with=0D=0A> some mice drivers and moused, and mice driver = bugs or bugs with moused=0D=0A> might be involved.=0D=0A> =0D=0A> = HTH,=0D=0A> -Garrett=0D=0A>=0D=0A----- Original Message -----=0D=0AFrom: = Lars Engels =0D=0A> =0D=0A> You might also build a = trimmed down kernel without USB support compiled=0D=0A> in and use USB = modules. Before suspending, unload them and re-load them=0D=0A> after = waking up again. That used to work on my Thinkpad.=0D=0A> = =0D=0A=0D=0AFirst I tried to build kernel only without 'ums' and kldload = it.=0D=0A3 times in a row, to S3 and back worked, so I hopped it works, = until 4th and 5th time, resulted in error.=0D=0AI like things to 'WORK' = or 'NOT TO WORK'.=0D=0AThis is some borderline case, where IT does "this" = on random, so I was so pissed of, with need to test 10 times in a row = (slapping lid), to confirm not/working status!=0D=0A=0D=0AThen I tried = ums, uhid, ukbd drivers and recompiled kernel.=0D=0ASlapping lid around = again and nada!=0D=0A=0D=0AThen what really drained me, was point of = removing usb drivers 1 by 1, which caused many kernel builds to = fail.=0D=0AThen again build with 1 job, just to see what was missing, and = again ...=0D=0ADuh!=0D=0A=0D=0AFirst echi, then it was uhci, then umass = wasn't happy, then uhid ... Tsk tsk!=0D=0AAnyway now it DOES work: (after = ~16 kern builds!)=0D=0A=0D=0A# vi = /boot/loader.conf=0D=0A--=0D=0Aums_load=3D"YES"=0D=0Aehci_load=3D"YES"=0D=0Auhci_load=3D"YES"=0D=0Ausb_load=3D"YES"=0D=0Aumass_load=3D"YES"=0D=0Auhid_load=3D"YES"=0D=0Aukbd_load=3D"YES"=0D=0A--=0D=0A=0D=0AAnd = appropriate kld(un)load lines in /etc/rc.suspend and /etc/rc.resume, made = it work.=0D=0ANow upon resume, I see at least 8 times more kernel = output.=0D=0A=0D=0A=0D=0A=0D=0ADomagoj Smol=E8i=E6=0D=0A=0D=0A From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 14 20:31:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B7B106566C; Mon, 14 Nov 2011 20:31:42 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6A12B8FC17; Mon, 14 Nov 2011 20:31:41 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so8737883bkb.13 for ; Mon, 14 Nov 2011 12:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=k0q6FO4rMR55mJH9zpssXt1fNUGSiFOCxNRtcOHhrIE=; b=k2kJa9H0T40ah9QCRKKgUCXdiDc5crN8M+vP+1U2NmKddGhNCWjGkgPZiMdkxLUw/Z o9i2dX3Dis57jWfu5dC40qxHJQ0TNebl79rmPI2gk6rxlFqMk96WdpOyJDVyEYhuXJJl fpWFZUaxXeyiQJEmF8qUr6h1c+2O913ZHKHI0= Received: by 10.204.41.66 with SMTP id n2mr20903520bke.77.1321302699857; Mon, 14 Nov 2011 12:31:39 -0800 (PST) Received: from localhost ([95.69.173.122]) by mx.google.com with ESMTPS id z7sm34643541bka.1.2011.11.14.12.31.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Nov 2011 12:31:36 -0800 (PST) From: Mikolaj Golub To: Kostik Belousov References: <86vcr21agm.fsf@kopusha.home.net> <20111105135801.GT50300@deviant.kiev.zoral.com.ua> <86ehxmpogp.fsf@kopusha.home.net> <20111105154443.GB50300@deviant.kiev.zoral.com.ua> <86ehxmjsza.fsf@kopusha.home.net> <20111105194553.GK50300@deviant.kiev.zoral.com.ua> <8662iyjof9.fsf@kopusha.home.net> <20111106181041.GH50300@deviant.kiev.zoral.com.ua> <86r51iqoad.fsf@kopusha.home.net> <20111109124455.GW50300@deviant.kiev.zoral.com.ua> <20111109125329.GX50300@deviant.kiev.zoral.com.ua> X-Comment-To: Kostik Belousov Sender: Mikolaj Golub Date: Mon, 14 Nov 2011 22:31:33 +0200 In-Reply-To: <20111109125329.GX50300@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Wed, 9 Nov 2011 14:53:29 +0200") Message-ID: <864ny6zbru.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org, Robert Watson Subject: Re: "ps -e" without procfs(5) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 20:31:42 -0000 On Wed, 9 Nov 2011 14:53:29 +0200 Kostik Belousov wrote: >> > http://people.freebsd.org/~trociny/env.sys.4.patch >> > >> > Investigating cases when EFAULT was returned and if the fallback was >> > successful I noticed that most of the cases were when p->p_comm changed during >> > the read, so the process was in exec in that time. In order to avoid this >> > error I added a check for P_INEXEC flag. >> And now you return success and nothing gets copied out for the process >> in P_INEXEC state. Either you should return an error like EAGAIN, or >> consider the P_INEXEC state as transitional and wait till process >> leaves it. Or, ignore the state as it was before, and return whatever >> error proc_rwmem generated (my preference). KB> Forgot to say that the check does not change much because you drop KB> process lock immediately after the check, so the process may enter KB> the INEXEC state right after the check. I believe you already tried KB> to do this with P_WEXIT. Ok, eventually I decided not to check for P_INEXEC (as the simplest :-). The updated patch: http://people.freebsd.org/~trociny/env.sys.5.patch -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 14 22:52:33 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D662106566B for ; Mon, 14 Nov 2011 22:52:33 +0000 (UTC) (envelope-from slonoman2011@yandex.ru) Received: from forward15.mail.yandex.net (forward15.mail.yandex.net [IPv6:2a02:6b8:0:801::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEF78FC16 for ; Mon, 14 Nov 2011 22:52:32 +0000 (UTC) Received: from web150.yandex.ru (web150.yandex.ru [95.108.130.108]) by forward15.mail.yandex.net (Yandex) with ESMTP id BB5F79E6926 for ; Tue, 15 Nov 2011 02:52:30 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321311150; bh=Pn3FJLriGHc1J17/W548LVI7RYL4CRpEx/n1k8+GuGs=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=Il1+NMseRV1110BJ/esxZiBCfddugS711XD1IvUrlt/AzbTmkqjCgQ9Pakirjs6aK RzAj9XCcf4uFfCtLOyEBqHIq+S9lNqJyabgjZXitLZNLkthQkSLKOb4WC0BgrpqU1V HjmdfQHUt3u1YedX2TbmUfEgnN9MXITGfeQwt7mw= Received: from localhost (localhost.localdomain [127.0.0.1]) by web150.yandex.ru (Yandex) with ESMTP id 97DAF6570321 for ; Tue, 15 Nov 2011 02:52:30 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321311150; bh=Pn3FJLriGHc1J17/W548LVI7RYL4CRpEx/n1k8+GuGs=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=Il1+NMseRV1110BJ/esxZiBCfddugS711XD1IvUrlt/AzbTmkqjCgQ9Pakirjs6aK RzAj9XCcf4uFfCtLOyEBqHIq+S9lNqJyabgjZXitLZNLkthQkSLKOb4WC0BgrpqU1V HjmdfQHUt3u1YedX2TbmUfEgnN9MXITGfeQwt7mw= X-Yandex-Spam: 1 Received: from nat140-249-205-109.tvoe.tv (nat140-249-205-109.tvoe.tv [109.205.249.140]) by web150.yandex.ru with HTTP; Tue, 15 Nov 2011 02:52:30 +0400 From: Slono Slono To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-Id: <565501321311150@web150.yandex.ru> Date: Tue, 15 Nov 2011 02:52:30 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Mon, 14 Nov 2011 23:20:12 +0000 Subject: The zombie has involved into /dev/null 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, 14 Nov 2011 22:52:33 -0000 On one of servers where installed cacti in jail there is strange enough situation. Sometimes processes poller.php haven't time to successful complete until to beginning of the following session (absence of lock is other problem - its ok) therefore processes breed yet won't begin them kill. During such moments appear zombie processes. However, these zombie show that keep devfs the device. Possibly because are started as php /poller.php 2>/dev/null 2>&1 Sending of any signals (SIGCHILD too) changes nothing. Strange that with -f (force) optons through a umount command is impossible to unmount devfs with which worked as the zombie. ps axf shows: .. 99551 ?? DsJ 0:00.12 /usr/local/bin/php /usr/local/share/cacti/poller.php 99554 ?? ZJ 0:00.02 . lsof -p 99551 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME php 99551 root cwd VBAD (revoked) php 99551 root rtd VDIR 225,1035534442 3 678909 /usr/jails/jails/mon php 99551 root jld VDIR 225,1035534442 3 678909 /usr/jails/jails/mon php 99551 root txt VREG 225,1035534442 3261754 1620922 /usr/jails/jails-data/mon-data/usr/local/bin/php php 99551 root txt VREG 225,1035534442 246776 626780 /usr/jails/jails-data/mon-data/libexec/ld-elf.so.1 php 99551 root txt VREG 225,1035534442 33600 626862 /usr/jails/jails-data/mon-data/lib/libcrypt.so.5 php 99551 root txt VREG 225,1035534442 377814 1267501 /usr/jails/jails-data/mon-data/usr/local/lib/libpcre.so.0 php 99551 root txt VREG 225,1035534442 150656 626861 /usr/jails/jails-data/mon-data/lib/libm.so.5 php 99551 root txt VREG 225,1035534442 1495740 649173 /usr/jails/jails-data/mon-data/usr/local/lib/libxml2.so.5 php 99551 root txt VREG 225,1035534442 84848 626828 /usr/jails/jails-data/mon-data/lib/libz.so.5 php 99551 root txt VREG 225,1035534442 1074175 649584 /usr/jails/jails-data/mon-data/usr/local/lib/libiconv.so.3 php 99551 root txt VREG 225,1035534442 1270640 626857 /usr/jails/jails-data/mon-data/lib/libc.so.7 php 99551 root txt VREG 225,1035534442 74189 636259 /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/session.so php 99551 root txt VREG 225,1035534442 63195 637380 /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/xml.so php 99551 root txt VREG 225,1035534442 40650 638507 /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/snmp.so php 99551 root txt VREG 225,1035534442 337128 665903 /usr/jails/jails-data/mon-data/usr/lib/libssl.so.6 php 99551 root txt VREG 225,1035534442 730269 8050234 /usr/jails/jails-data/mon-data/usr/local/lib/libnetsnmp.so.30 php 99551 root txt VREG 225,1035534442 35264 626850 /usr/jails/jails-data/mon-data/lib/libkvm.so.5 php 99551 root txt VREG 225,1035534442 19720 626858 /usr/jails/jails-data/mon-data/lib/libdevstat.so.7 php 99551 root txt VREG 225,1035534442 1693344 626824 /usr/jails/jails-data/mon-data/lib/libcrypto.so.6 php 99551 root txt VREG 225,1035534442 105904 666224 /usr/jails/jails-data/mon-data/usr/lib/libelf.so.1 php 99551 root txt VREG 225,1035534442 61034 635955 /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/mysql.so php 99551 root txt VREG 225,1035534442 54114 637132 /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/sockets.so php 99551 root 0u PIPE 0xfffffe07514ab5b0 16384 ->0xfffffe07514ab708 php 99551 root 1w VCHR 0,27 0t0 27 /usr/jails/jails/mon/dev (devfs) (like character special /dev/null) php 99551 root 2w VCHR 0,27 0t0 27 /usr/jails/jails/mon/dev (devfs) (like character special /dev/null) php 99551 root 3u unix 0xfffffe074ad832a8 0t0 ->(none) php 99551 root 5u PIPE 0xfffffe043c62fcb8 0 ->0xfffffe043c62fb60 mount -t devfs |grep mon devfs on /usr/jails/jails/mon/dev (devfs, local, multilabel) umount -f /usr/jails/jails/mon/dev umount: unmount of /usr/jails/jails/mon/dev failed: Device busy However apparently devfs is unmount when executed jail stop: ls -la /usr/jails/jails/mon/dev total 5 drwxr-xr-x 2 root wheel 2 Nov 14 22:36 . drwxr-xr-x 3 root wheel 3 Nov 14 22:36 .. As can be that zombie blocks devfs or that in system there is an information on active mount when the file system isn't present PS: FreeBSD 9.0-RC2 amd64 From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 15 20:24:50 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 54046106566C; Tue, 15 Nov 2011 20:24:50 +0000 (UTC) Date: Tue, 15 Nov 2011 20:24:50 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20111115202450.GA73512@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: easy way to determine if a stream or fd is seekable 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, 15 Nov 2011 20:24:50 -0000 hi there, one of the things i'm missing is an easy way to determine, whether a stream or fd is seekable. i checked the dd(1) and hd(1) sources and those tools are performing so much stuff just to find out if this is the case, and they still are doing a very poor job. dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the result: `dd if=/dev/zero bs=1m count=1 skip=100000`: on freebsd: 57,41 real 0,05 user 43,21 sys on openbsd: 0,88 real 0,00 user 0,07 sys on freebsd dd(1) is very easy fixable (1 line diff). the point however is: there doesn't seem to exist a unified way of checking seekable == TRUE. so every userspace application seems to do it differently and most of them (dd(1) and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only regular files are seekable. this means that hd(1) fired at /dev/ada* with a high skip value takes ages! dd(1) is a bit smarter in this case, but still not correct. idealy there would be something like stat.st_mode (see stat(2)) where one could simply do a S_ISSEEK(m). so far the best and easiest solution i've seen is: fd = open(argv[1], O_RDONLY); if (fd == -1) exit(1); if (lseek(fd, 0, SEEK_CUR) != -1) printf ("%d is seekable.\n", fd); else printf ("%d is not seekable.\n", fd); seeing an application iterate through a stream or fd via getchar(), although a simple seek() would work is very frustrating. i think what would be needed is a simple function or macro that userspace applications can make use of. maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd, solaris or plan9? cheers. alex references: [1] http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485 [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 15 20:18:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A1DE106566B for ; Tue, 15 Nov 2011 20:18:51 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1008FC0C for ; Tue, 15 Nov 2011 20:18:50 +0000 (UTC) Received: by faar19 with SMTP id r19so1207885faa.13 for ; Tue, 15 Nov 2011 12:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=JOMAwzXOS7FnoIyfs8vy4Hv0J+cYesvHQbffm3pFP5E=; b=a57UFYsV1m8pAJwhJwwN5Sufox6YD/lNbhf+tfJAUfHFRD2lpazpyUEjF8lmr2uLiQ j7JYe7D3qgdp/IyObwkfmIdwYmHNgLTWhc5eXVSixfgGuEqDTk3mVoZUwGbfFrtkBTGu G0hIMr3WkfDGXRNFlWYAB2rADl6LYL26FX/9Q= Received: by 10.205.139.71 with SMTP id iv7mr20022210bkc.60.1321388330020; Tue, 15 Nov 2011 12:18:50 -0800 (PST) Received: from imax.localnet (76-55-133-95.pool.ukrtel.net. [95.133.55.76]) by mx.google.com with ESMTPS id i3sm18306066faf.0.2011.11.15.12.18.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 12:18:48 -0800 (PST) From: Maxim Ignatenko To: freebsd-hackers@freebsd.org Date: Tue, 15 Nov 2011 22:18:40 +0200 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.7.3; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201111152218.41031.gelraen.ua@gmail.com> X-Mailman-Approved-At: Tue, 15 Nov 2011 21:03:34 +0000 Subject: Communication between kernel and userspace via local socket 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, 15 Nov 2011 20:18:51 -0000 frHi, I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and looking for most convenient way to establish communication between userspace processes and kernel part. Communication pattern best fits to listening PF_LOCAL socket opened from kernel and userspace processes connecting to it. Clients should be able to send requests and receive responses from kernel (to retrieve list of loaded modules, active ruleset, add or remove rules, ...) and vice versa: kernel should be able to send request to userspace process and receive response (I'm planning to add interactive features like in most firewalls for windows(r)). First part can be implemented via ioctl, but it should be called not only by processes with euid == 0, so supplied pointer to receive buffer cannot be trusted (is there any mechanism to check memory allocation?) and any unprivileged user can instruct kernel to write some trash at arbitrary address (for example, VM just rebooted ungracefully when I supplied (void*)123 as pointer to destination buffer). So, requirements is: 1) message exchange can initiated from userspace and from kernel 2) safe to communicate with unprivileged processes (not like in above case with ioctl) 3) kernel part should be able to determine process uid 4) messages size can be large (from 1KB to 10KB and more) Now I'm thinking about few variants: 1) emulation of local socket via character device. This way requires to manually handle per-process IO buffers, which almost certainly will have many bugs 2) opening local socket from kernel. This, as I think, require to spawn new process in kernel (but I don't know how to do this) to listen for incoming connections and messages 3) userspace mux/demux daemon (like devd): one and only one process opens character device and uses local socket to communicate with other processes. This requires to design 2 ABIs - kernel<->daemon and daemon<->client. 2nd variant looks most appropriate but know I don't know how to implement it. Can anyone point me to some documentation about spawning processes in kernel an working with sockets from kernelspace, or suggest better way of communication between processes and kernel? From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 15 21:17:43 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFF8F106566B for ; Tue, 15 Nov 2011 21:17:43 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-dy0-f54.google.com (mail-dy0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 658D08FC16 for ; Tue, 15 Nov 2011 21:17:42 +0000 (UTC) Received: by dyk29 with SMTP id 29so455208dyk.13 for ; Tue, 15 Nov 2011 13:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PIaAYpWsP+PM2zjCVfIrmpCUhYJw5lc9ar3FL66U8y4=; b=LG0zg0ddIhOf99PmXrjHEiAUsN39GNmPJ69NwF+RxVC5u9O9d44L2F+80kWww88D+e p/N5D6dc9n5aqzLLvv6hWq1MYAbGQ/L0c+sLkyimeq9Qg8emkgZVegpblmh2oNUgYput xBHooCjleqVq2dmmIKXh60mcewZlwlQwWVzGw= MIME-Version: 1.0 Received: by 10.68.59.73 with SMTP id x9mr3498046pbq.42.1321391861115; Tue, 15 Nov 2011 13:17:41 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Tue, 15 Nov 2011 13:17:41 -0800 (PST) In-Reply-To: <201111152218.41031.gelraen.ua@gmail.com> References: <201111152218.41031.gelraen.ua@gmail.com> Date: Tue, 15 Nov 2011 13:17:41 -0800 X-Google-Sender-Auth: eDfWnmFP9Ci67h6Jhu872v9Hgkk Message-ID: From: mdf@FreeBSD.org To: Maxim Ignatenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: Communication between kernel and userspace via local socket 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, 15 Nov 2011 21:17:44 -0000 On Tue, Nov 15, 2011 at 12:18 PM, Maxim Ignatenko wrote: > frHi, > > I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and > looking for most convenient way to establish communication between userspace > processes and kernel part. Communication pattern best fits to listening > PF_LOCAL socket opened from kernel and userspace processes connecting to it. > Clients should be able to send requests and receive responses from kernel (to > retrieve list of loaded modules, active ruleset, add or remove rules, ...) and > vice versa: kernel should be able to send request to userspace process and > receive response (I'm planning to add interactive features like in most > firewalls for windows(r)). > > First part can be implemented via ioctl, but it should be called not only by > processes with euid == 0, so supplied pointer to receive buffer cannot be > trusted (is there any mechanism to check memory allocation?) and any > unprivileged user can instruct kernel to write some trash at arbitrary address > (for example, VM just rebooted ungracefully when I supplied (void*)123 as > pointer to destination buffer). Were you using copyout(9)? I think FreeBSD's memory isolation between processes is pretty decent. I would be very surprised if copyout to an invalid address did something other than return EFAULT. At least the amd64 implementation of copyout(9) will also explicitly check that the address is a user address, so that you can't corrupt kernel memory with a rogue pointer from user-space. Thanks, matthew > So, requirements is: > 1) message exchange can initiated from userspace and from kernel > 2) safe to communicate with unprivileged processes (not like in above case > with ioctl) > 3) kernel part should be able to determine process uid > 4) messages size can be large (from 1KB to 10KB and more) > > Now I'm thinking about few variants: > 1) emulation of local socket via character device. This way requires to > manually handle per-process IO buffers, which almost certainly will have many > bugs > 2) opening local socket from kernel. This, as I think, require to spawn new > process in kernel (but I don't know how to do this) to listen for incoming > connections and messages > 3) userspace mux/demux daemon (like devd): one and only one process opens > character device and uses local socket to communicate with other processes. > This requires to design 2 ABIs - kernel<->daemon and daemon<->client. > > 2nd variant looks most appropriate but know I don't know how to implement it. > Can anyone point me to some documentation about spawning processes in kernel > an working with sockets from kernelspace, or suggest better way of > communication between processes and kernel? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 03:01:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BF3C1065670; Wed, 16 Nov 2011 03:01:42 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id A3E688FC0A; Wed, 16 Nov 2011 03:01:41 +0000 (UTC) Received: by wwe3 with SMTP id 3so623221wwe.1 for ; Tue, 15 Nov 2011 19:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jeYNm+2ZiwsTRtGFEmbHD38nbh/qug9AcgBGdyVoQsg=; b=Stb2cKiRm0LNmpRHKMBcF8lyQRGB27/q/xASz0iCwhw4oaFuFZt7xNv5EMB2v+HFSX woCJMLXUg22XkOpKlFeyEWrm8aEKafBlaemHo2BZNmtj8oSaviRbXCCqUTV++ObmZ8Bx zv5va1gw4jisE1cl5S+VUKFUvHq4MhcYbw+5g= MIME-Version: 1.0 Received: by 10.216.24.93 with SMTP id w71mr211744wew.11.1321411020085; Tue, 15 Nov 2011 18:37:00 -0800 (PST) Received: by 10.216.63.143 with HTTP; Tue, 15 Nov 2011 18:36:59 -0800 (PST) Received: by 10.216.63.143 with HTTP; Tue, 15 Nov 2011 18:36:59 -0800 (PST) In-Reply-To: <20111115202450.GA73512@freebsd.org> References: <20111115202450.GA73512@freebsd.org> Date: Tue, 15 Nov 2011 20:36:59 -0600 Message-ID: From: Brandon Gooch To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 03:01:42 -0000 On Nov 15, 2011 2:25 PM, "Alexander Best" wrote: > > hi there, > > one of the things i'm missing is an easy way to determine, whether a stream or > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > performing so much stuff just to find out if this is the case, and they still > are doing a very poor job. > > dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the result: > > `dd if=/dev/zero bs=1m count=1 skip=100000`: > > on freebsd: > 57,41 real 0,05 user 43,21 sys > > on openbsd: > 0,88 real 0,00 user 0,07 sys > > on freebsd dd(1) is very easy fixable (1 line diff). the point however is: > > there doesn't seem to exist a unified way of checking seekable == TRUE. so > every userspace application seems to do it differently and most of them (dd(1) > and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only regular > files are seekable. this means that hd(1) fired at /dev/ada* with a high skip > value takes ages! dd(1) is a bit smarter in this case, but still not correct. > > idealy there would be something like stat.st_mode (see stat(2)) where one > could simply do a S_ISSEEK(m). so far the best and easiest solution i've seen > is: > > fd = open(argv[1], O_RDONLY); > if (fd == -1) > exit(1); > if (lseek(fd, 0, SEEK_CUR) != -1) > printf ("%d is seekable.\n", fd); > else > printf ("%d is not seekable.\n", fd); > > seeing an application iterate through a stream or fd via getchar(), although > a simple seek() would work is very frustrating. i think what would be needed > is a simple function or macro that userspace applications can make use of. > maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd, > solaris or plan9? > > cheers. > alex > > references: > [1] http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes > [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485 > [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 So, according to APUE 2nd Edition, seek should be supported on anything that's not a pipe, FIFO, or socket. In fact, the "test for seekability" you've provided above closely resembles the example given in that text. Need to think about this more before commenting further... -Brandon From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 08:55:10 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1477106564A for ; Wed, 16 Nov 2011 08:55:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (mx0.hoeg.nl [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 35FBF8FC0A for ; Wed, 16 Nov 2011 08:55:09 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id EFC792A28CC9; Wed, 16 Nov 2011 09:55:08 +0100 (CET) Date: Wed, 16 Nov 2011 09:55:08 +0100 From: Ed Schouten To: Maxim Ignatenko Message-ID: <20111116085508.GF36205@hoeg.nl> References: <201111152218.41031.gelraen.ua@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KuLpqunXa7jZSBt+" Content-Disposition: inline In-Reply-To: <201111152218.41031.gelraen.ua@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: Communication between kernel and userspace via local socket 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, 16 Nov 2011 08:55:10 -0000 --KuLpqunXa7jZSBt+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Maxim Ignatenko , 20111115 21:18: > I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch an= d=20 > looking for most convenient way to establish communication between usersp= ace=20 > processes and kernel part. Communication pattern best fits to listening= =20 > PF_LOCAL socket opened from kernel and userspace processes connecting to = it.=20 What's wrong with a character device? --=20 Ed Schouten WWW: http://80386.nl/ --KuLpqunXa7jZSBt+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iQIcBAEBAgAGBQJOw3psAAoJEG5e2P40kaK7uXUQAKTClAkglU7xYH+W1S8nOyic iwEBXDrRyx+AhG2JPGajflcj/Z3gZlUg6IFGLUWcV6CxZPvGK+CdO0hGTcNtzdHy zo07Wa4IsBbsZknHi6XwHlety/YztFZxIkY96nUb11utUg/xlwy6cmIOLMNTpRH0 k4DuGIKqE+jyrPO82HFttD4mt5NcvI1F5WTh+TdyBAOmDFuxSXsqSIjy+4dtG7/0 IY5Dm3TqB33yYyDyMNp7dCoRG4M3k48aDJXRtzxiLa25NqlWTTNKLxT96VDy4Xlo uiZu9kgROuEgKdVIX/jwZ0OfYiOEe0nf/oA08FzoXA6z31/ZqDhOFkf6eGaX0qnV 5h0Sx652pLqEW3kB0gsOX8YA0qfa5RKG5A+e6dAt6hZDf1CG7XEmOcxGHZt6to5B trPoeGHxn15RZuI+R2GDVNKObrBwUfzpmAOWNXN5zzNpcUNhZGz8sxjGu2vSpabN GLg3AvmIzl6yJkpF1r72zenPJsgOleEAWM0bHX+I/ZBPkkvcqU3wJbWHzksGF0wl jHwOwxriJO6k0wruT/El767p0LpJP5V68fpvmkdfR5ynmTwJoLEXwkaJDNY8js7B /vix4UrpFkGEE5LSlRhwcskaKnaHxnA7MfLGpONQoAz5phcQ2Toafy8iO9BYRIpR 1FwAjknU/Fk8S80PegYC =Pt5t -----END PGP SIGNATURE----- --KuLpqunXa7jZSBt+-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 10:14:23 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 021A11065670; Wed, 16 Nov 2011 10:14:23 +0000 (UTC) Date: Wed, 16 Nov 2011 10:14:22 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20111116101422.GA20453@freebsd.org> References: <20111115202450.GA73512@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 10:14:23 -0000 On Tue Nov 15 11, Brandon Gooch wrote: > On Nov 15, 2011 2:25 PM, "Alexander Best" wrote: > > > > hi there, > > > > one of the things i'm missing is an easy way to determine, whether a > stream or > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > performing so much stuff just to find out if this is the case, and they > still > > are doing a very poor job. > > > > dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the > result: > > > > `dd if=/dev/zero bs=1m count=1 skip=100000`: > > > > on freebsd: > > 57,41 real 0,05 user 43,21 sys > > > > on openbsd: > > 0,88 real 0,00 user 0,07 sys > > > > on freebsd dd(1) is very easy fixable (1 line diff). the point however is: > > > > there doesn't seem to exist a unified way of checking seekable == TRUE. so > > every userspace application seems to do it differently and most of them > (dd(1) > > and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only > regular > > files are seekable. this means that hd(1) fired at /dev/ada* with a high > skip > > value takes ages! dd(1) is a bit smarter in this case, but still not > correct. > > > > idealy there would be something like stat.st_mode (see stat(2)) where one > > could simply do a S_ISSEEK(m). so far the best and easiest solution i've > seen > > is: > > > > fd = open(argv[1], O_RDONLY); > > if (fd == -1) > > exit(1); > > if (lseek(fd, 0, SEEK_CUR) != -1) > > printf ("%d is seekable.\n", fd); > > else > > printf ("%d is not seekable.\n", fd); > > > > seeing an application iterate through a stream or fd via getchar(), > although > > a simple seek() would work is very frustrating. i think what would be > needed > > is a simple function or macro that userspace applications can make use of. > > maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd, > > solaris or plan9? > > > > cheers. > > alex > > > > references: > > [1] > http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes > > [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485 > > [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 > > So, according to APUE 2nd Edition, seek should be supported on anything > that's not a pipe, FIFO, or socket. In fact, the "test for seekability" > you've provided above closely resembles the example given in that text. if this really is the case, things could even be easier in a freebsd specific manor than the code above: !S_ISFIFO(m) && !S_ISSOCK(m) this means it would be trivial to write a new macro S_ISSEEK which would test stat.st_mode against the according bits. cheers. alex > > Need to think about this more before commenting further... > > -Brandon From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 10:23:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3CB106564A for ; Wed, 16 Nov 2011 10:23:26 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by mx1.freebsd.org (Postfix) with ESMTP id 599538FC0A for ; Wed, 16 Nov 2011 10:23:26 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/avgusCdvwXOZ/NA7x/bslx4UOSLYuW7Bwv8PtjkoBcppeXE= X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de ([2001:6f8:13f0:0:224:d7ff:fe63:d530]) by smtp.strato.de (klopstock mo40) (RZmta 26.10 AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id L04d2fnAG9XbLv for ; Wed, 16 Nov 2011 11:23:12 +0100 (MET) Received: by britannica.bec.de (sSMTP sendmail emulation); Wed, 16 Nov 2011 11:22:39 +0100 Date: Wed, 16 Nov 2011 11:22:39 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20111116102239.GA2687@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20111115202450.GA73512@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111115202450.GA73512@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 10:23:26 -0000 On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote: > one of the things i'm missing is an easy way to determine, whether a stream or > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > performing so much stuff just to find out if this is the case, and they still > are doing a very poor job. Isn't the primary issue that FreeBSD doesn't properly report errors for lseek(2)? I think you should start from that and not hack around the fallout... Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 10:31:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 73D1C106566B; Wed, 16 Nov 2011 10:31:44 +0000 (UTC) Date: Wed, 16 Nov 2011 10:31:44 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20111116103144.GA22928@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116101422.GA20453@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tThc/1wpZn/ma/RB" Content-Disposition: inline In-Reply-To: <20111116101422.GA20453@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 10:31:44 -0000 --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed Nov 16 11, Alexander Best wrote: > On Tue Nov 15 11, Brandon Gooch wrote: > > On Nov 15, 2011 2:25 PM, "Alexander Best" wrote: > > > > > > hi there, > > > > > > one of the things i'm missing is an easy way to determine, whether a > > stream or > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > > performing so much stuff just to find out if this is the case, and they > > still > > > are doing a very poor job. > > > > > > dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the > > result: > > > > > > `dd if=/dev/zero bs=1m count=1 skip=100000`: > > > > > > on freebsd: > > > 57,41 real 0,05 user 43,21 sys > > > > > > on openbsd: > > > 0,88 real 0,00 user 0,07 sys > > > > > > on freebsd dd(1) is very easy fixable (1 line diff). the point however is: > > > > > > there doesn't seem to exist a unified way of checking seekable == TRUE. so > > > every userspace application seems to do it differently and most of them > > (dd(1) > > > and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only > > regular > > > files are seekable. this means that hd(1) fired at /dev/ada* with a high > > skip > > > value takes ages! dd(1) is a bit smarter in this case, but still not > > correct. > > > > > > idealy there would be something like stat.st_mode (see stat(2)) where one > > > could simply do a S_ISSEEK(m). so far the best and easiest solution i've > > seen > > > is: > > > > > > fd = open(argv[1], O_RDONLY); > > > if (fd == -1) > > > exit(1); > > > if (lseek(fd, 0, SEEK_CUR) != -1) > > > printf ("%d is seekable.\n", fd); > > > else > > > printf ("%d is not seekable.\n", fd); > > > > > > seeing an application iterate through a stream or fd via getchar(), > > although > > > a simple seek() would work is very frustrating. i think what would be > > needed > > > is a simple function or macro that userspace applications can make use of. > > > maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd, > > > solaris or plan9? > > > > > > cheers. > > > alex > > > > > > references: > > > [1] > > http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes > > > [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485 > > > [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 > > > > So, according to APUE 2nd Edition, seek should be supported on anything > > that's not a pipe, FIFO, or socket. In fact, the "test for seekability" > > you've provided above closely resembles the example given in that text. > > if this really is the case, things could even be easier in a freebsd specific > manor than the code above: > > !S_ISFIFO(m) && !S_ISSOCK(m) > > this means it would be trivial to write a new macro S_ISSEEK which would test > stat.st_mode against the according bits. here's a patch, which also fixes a comment. cheers. alex > > cheers. > alex > > > > > Need to think about this more before commenting further... > > > > -Brandon --tThc/1wpZn/ma/RB Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stat.h.diff" diff --git a/sys/sys/stat.h b/sys/sys/stat.h index 1b03bd2..ab5ae44 100644 --- a/sys/sys/stat.h +++ b/sys/sys/stat.h @@ -238,10 +238,11 @@ struct nstat { #define S_ISCHR(m) (((m) & 0170000) == 0020000) /* char special */ #define S_ISBLK(m) (((m) & 0170000) == 0060000) /* block special */ #define S_ISREG(m) (((m) & 0170000) == 0100000) /* regular file */ -#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* fifo or socket */ +#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* pipe or fifo */ #if __POSIX_VISIBLE >= 200112 #define S_ISLNK(m) (((m) & 0170000) == 0120000) /* symbolic link */ #define S_ISSOCK(m) (((m) & 0170000) == 0140000) /* socket */ +#define S_ISSEEK(m) (((m) & 0150000) == 0) /* seekable file */ #endif #if __BSD_VISIBLE #define S_ISWHT(m) (((m) & 0170000) == 0160000) /* whiteout */ --tThc/1wpZn/ma/RB-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 10:35:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D59A1065672 for ; Wed, 16 Nov 2011 10:35:21 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8925E8FC0A for ; Wed, 16 Nov 2011 10:35:20 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RQcpq-0005Cs-TL for freebsd-hackers@freebsd.org; Wed, 16 Nov 2011 11:35:18 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2011 11:35:18 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Nov 2011 11:35:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Wed, 16 Nov 2011 11:35:04 +0100 Lines: 133 Message-ID: References: <565501321311150@web150.yandex.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0EF87A10C19060CDCAB9BD11" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111004 Thunderbird/7.0.1 In-Reply-To: <565501321311150@web150.yandex.ru> X-Enigmail-Version: 1.1.2 Subject: Re: The zombie has involved into /dev/null 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, 16 Nov 2011 10:35:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0EF87A10C19060CDCAB9BD11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, if I understand you correctly, you are reporting a bug in which a jailed process is holding (the jailed instance of) /dev/null open and "umount -f" doesn't work on the jailed /dev ? On 14/11/2011 23:52, Slono Slono wrote: > On one of servers where installed cacti in jail there is strange enough= situation. Sometimes processes poller.php haven't time to successful com= plete until to beginning of the following session (absence of lock is oth= er problem - its ok) therefore processes breed yet won't begin them kill.= During such moments appear zombie processes. However, these zombie show = that keep devfs the device. Possibly because are started as >=20 > php /poller.php 2>/dev/null 2>&1 >=20 > Sending of any signals (SIGCHILD too) changes nothing. Strange that wi= th -f (force) optons through a umount command is impossible to unmount de= vfs with which worked as the zombie. >=20 > ps axf shows: > .. >=20 > 99551 ?? DsJ 0:00.12 /usr/local/bin/php /usr/local/share/cacti/p= oller.php > 99554 ?? ZJ 0:00.02 > . >=20 > lsof -p 99551 > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME= > php 99551 root cwd VBAD (rev= oked) > php 99551 root rtd VDIR 225,1035534442 3 678909 /usr= /jails/jails/mon > php 99551 root jld VDIR 225,1035534442 3 678909 /usr= /jails/jails/mon > php 99551 root txt VREG 225,1035534442 3261754 1620922 /usr= /jails/jails-data/mon-data/usr/local/bin/php > php 99551 root txt VREG 225,1035534442 246776 626780 /usr= /jails/jails-data/mon-data/libexec/ld-elf.so.1 > php 99551 root txt VREG 225,1035534442 33600 626862 /usr= /jails/jails-data/mon-data/lib/libcrypt.so.5 > php 99551 root txt VREG 225,1035534442 377814 1267501 /usr= /jails/jails-data/mon-data/usr/local/lib/libpcre.so.0 > php 99551 root txt VREG 225,1035534442 150656 626861 /usr= /jails/jails-data/mon-data/lib/libm.so.5 > php 99551 root txt VREG 225,1035534442 1495740 649173 /usr= /jails/jails-data/mon-data/usr/local/lib/libxml2.so.5 > php 99551 root txt VREG 225,1035534442 84848 626828 /usr= /jails/jails-data/mon-data/lib/libz.so.5 > php 99551 root txt VREG 225,1035534442 1074175 649584 /usr= /jails/jails-data/mon-data/usr/local/lib/libiconv.so.3 > php 99551 root txt VREG 225,1035534442 1270640 626857 /usr= /jails/jails-data/mon-data/lib/libc.so.7 > php 99551 root txt VREG 225,1035534442 74189 636259 /usr= /jails/jails-data/mon-data/usr/local/lib/php/20090626/session.so > php 99551 root txt VREG 225,1035534442 63195 637380 /usr= /jails/jails-data/mon-data/usr/local/lib/php/20090626/xml.so > php 99551 root txt VREG 225,1035534442 40650 638507 /usr= /jails/jails-data/mon-data/usr/local/lib/php/20090626/snmp.so > php 99551 root txt VREG 225,1035534442 337128 665903 /usr= /jails/jails-data/mon-data/usr/lib/libssl.so.6 > php 99551 root txt VREG 225,1035534442 730269 8050234 /usr= /jails/jails-data/mon-data/usr/local/lib/libnetsnmp.so.30 > php 99551 root txt VREG 225,1035534442 35264 626850 /usr= /jails/jails-data/mon-data/lib/libkvm.so.5 > php 99551 root txt VREG 225,1035534442 19720 626858 /usr= /jails/jails-data/mon-data/lib/libdevstat.so.7 > php 99551 root txt VREG 225,1035534442 1693344 626824 /usr= /jails/jails-data/mon-data/lib/libcrypto.so.6 > php 99551 root txt VREG 225,1035534442 105904 666224 /usr= /jails/jails-data/mon-data/usr/lib/libelf.so.1 > php 99551 root txt VREG 225,1035534442 61034 635955 /usr= /jails/jails-data/mon-data/usr/local/lib/php/20090626/mysql.so > php 99551 root txt VREG 225,1035534442 54114 637132 /usr= /jails/jails-data/mon-data/usr/local/lib/php/20090626/sockets.so > php 99551 root 0u PIPE 0xfffffe07514ab5b0 16384 ->0x= fffffe07514ab708 > php 99551 root 1w VCHR 0,27 0t0 27 /usr= /jails/jails/mon/dev (devfs) (like character special /dev/null) > php 99551 root 2w VCHR 0,27 0t0 27 /usr= /jails/jails/mon/dev (devfs) (like character special /dev/null) > php 99551 root 3u unix 0xfffffe074ad832a8 0t0 ->(n= one) > php 99551 root 5u PIPE 0xfffffe043c62fcb8 0 ->0x= fffffe043c62fb60 >=20 > mount -t devfs |grep mon > devfs on /usr/jails/jails/mon/dev (devfs, local, multilabel) >=20 > umount -f /usr/jails/jails/mon/dev > umount: unmount of /usr/jails/jails/mon/dev failed: Device busy >=20 > However apparently devfs is unmount when executed jail stop: >=20 > ls -la /usr/jails/jails/mon/dev > total 5 > drwxr-xr-x 2 root wheel 2 Nov 14 22:36 . > drwxr-xr-x 3 root wheel 3 Nov 14 22:36 .. >=20 > As can be that zombie blocks devfs or that in system there is an inform= ation on active mount when the file system isn't present >=20 > PS: FreeBSD 9.0-RC2 amd64 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 --------------enig0EF87A10C19060CDCAB9BD11 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7DkdkACgkQldnAQVacBcgpEACcC6w9Lh/3qQ9z5hsITeizknGK uO8AoJ+GIclwph9hUcuLbHClFyr84i1T =USHk -----END PGP SIGNATURE----- --------------enig0EF87A10C19060CDCAB9BD11-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 11:01:00 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F6B7106566B for ; Wed, 16 Nov 2011 11:01:00 +0000 (UTC) (envelope-from vkushnir@bigmir.net) Received: from ex.volia.net (ex.volia.net [82.144.192.10]) by mx1.freebsd.org (Postfix) with ESMTP id D78B08FC1D for ; Wed, 16 Nov 2011 11:00:58 +0000 (UTC) Received: from em.volia.net ([82.144.192.9]) by ex.volia.net with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1RQclF-000Lje-QY for hackers@freebsd.org; Wed, 16 Nov 2011 12:30:33 +0200 Received: from enough.saddler.volia.net ([93.72.207.82] helo=kushnir1.kiev.ua) by em.volia.net with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1RQclF-000Fxh-ED for hackers@freebsd.org; Wed, 16 Nov 2011 12:30:33 +0200 Received: from localhost (localhost [IPv6:::1]) by kushnir1.kiev.ua (8.14.5/8.14.5) with ESMTP id pAGAUZiE000934 for ; Wed, 16 Nov 2011 12:30:35 +0200 (EET) (envelope-from vkushnir@bigmir.net) Date: Wed, 16 Nov 2011 12:30:35 +0200 (EET) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: hackers@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="4266313884-669419637-1321439435=:26465" X-Volia-Original-IP: 93.72.207.82 Cc: Subject: Base compiler and amdfam10 - anybody/anything? 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, 16 Nov 2011 11:01:00 -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. --4266313884-669419637-1321439435=:26465 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi, Are there any attempts to bring to -CURRENT newer AMD chips support? Personally, I've just tried to apply the patches from openSUSE's gcc-4.2.1 SRPM. With slight adaptation they've applied and gave rather significant boost in resulting code speed. At least, testfcpy by Alexander Konovalenko (http://daemon.safety.sci.kth.se/~kono/testfcpu) gave me ~20% (!) speedup with -march=amdfam10 compared to our -march=athlon64-sse3 on Phenom II 970. Unfortunately, the patched compiler with -march=amdfam10 fails in buildworld ("internal compiler error"'s while compiling clang). The buildworld was successful with patched compiler and -march=athlon64-sse3 but since this is my main working system... Well, I had to come back to our unpatched compiler :-( If anyone is interested, the patches were taken from gcc42-4.2.1_20070724-17.src.rpm (actually, I applied all the patches marked as AMD stuff), the resulting patches towards our src/contrib/gcc and share/mk/bsd.cpu.mk are attached (or I can send them by email), and I am quite ready to test what comes out of it. WBR, Vladimir --4266313884-669419637-1321439435=:26465 Content-Type: APPLICATION/octet-stream; name=gcc-amdfam10.diff.gz Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=gcc-amdfam10.diff.gz H4sICLaXwk4AA2djYy1hbWRmYW0xMC5kaWZmAO19a3fbtrLoZ3fdH4H6nN1j JbTDlyjKac6u60fjU7/qR5vefbq4aJGyuCOJikjZTpPc335nAJAEKZCiZPmV Nqu1JBIYYJ4YDAbAixcvyMbGq6tOZyMcB1evNl55YeeVfxv7Q28j9m+DFV3V tHW1ua7pRNM3DXNTMzfU5B95qRqq+s36+jopqYn/NYlqb5rqptrK1dSh5ov8 P/xNWnqzqbR0SyX0EQLnj1otAr/WvyHk2u4FxHEuJ0E/DoZO4Bq6M3IvoxtN t8kavm1AqR+gLyQauP2+f+sORn0fnn3zkpz3fNIN+/3wJhheEQpjPRiS7mTY iYNwGBF37BP32g367mXfJzc9f0h+CEf47tP6IIp80/1CgohMIt/bAHjw3w+5 Vl6S6zDwiPjPGQycKB77Lnx4ZM0LJwD6heI4A+ix13gNdX7yh/7Yjf2IxNDB Hzqh538ahNfDOPK+kIHb6QVDnwRDgDKh/dyY1U5E1rr90I2TZma0EpW2wqoH +VaA1WO3EztRYJlkjRdRkrKlbWG1D9KWyE0Q90g47H8kZ2e7ZOxfBVHsj0k4 AiBDL5rVk6DYlWAY0z8L9yXXDegCCQYD3wsAyuxOATB/PDd1WK0l04cBnSJP fTrN7lVNSk0rJGgPuaNCGt4wvBEUkpCtfp+EXURgQK44PhQdWf/jnhtj5ZE7 jnktMnQHPgKi9mjaPgbD6/C9v4h9nKrJ7WN707A2VbOWfWxqhtLU2sw6ErI+ GIbr3dH62EeirRt2C59FYTdep9pPf12PjfWo1w8uyQ9XYT+pdRN4/vpgAiZ0 BEIFz8axhx9uP7garjMblVUYjf2uPx773noUu53365fhZOi5449vfrh2x5+G k8EXVvZbKDsY3NJ2I59/6OzDoB/sk/ItAx/3wGp5Ee8a6wJwCSQiHNGnwbAP vIM3feF51rtJ1Ft3x1e0qNvpTAAvYPt6OImvQiicvgOZvwzi9X4Iz4ootq3i KySKfwWyMRDQZLjw56w2sjhhDB+jni1j6AiXMgjgh6POMMbmLwdfC79kitVW LU2BP1bmePBHLTVh6uHhOwWtHf2jK8Twjo5/+1Yh/rDnDju+xx9QG2iZ69C9 nLGJ/JhQHylCu7ZBnZQgBjP13l5H6itgLsGEhkP+y417gB0Awp9QeB+YHV5D M9f+mIJAi/XeTqvRdpNKqWk2pvoQTUajcBxTm0zbdwde1x1oqkIu3XHHh/ou vNs63CF77iAAIdTUHumEYIcvXbCyZPvkImLwb21rHdoqa4GQtfNeEAEweAKd 9uNoiojYRfrX3CqlqEK2fjwUyAoAaxEWhhSw+aP1joXk2zknv7EHZNtCJBTi +W4fmUQiMPrkxv1I3IgEpm0x9FzPC7AFt4/dFtsEeDlSSkXKAMe1bVi6IFJG sw2PWnoiUrSft0yNOJtZ17lGThXBZy+FMqCtwm8GBR5lYKgiF8CwZ1k1puTJ A14o/5BZgEIRfEJwNA6Gnn9L0MDkfkOR4iPoXgmxLBMpoyZDW1YlxUCEmzwE 9wHMWQTs6sA3EBzqJYRj4gUR/YpDOvgGqCsC/yJkOr5CcQTjKBFIVB2AY+wc hTffMvnyQCILghdtpJ3IRJD5LP0oFBwXEKxp52YTQODE5Aew4p/egdj9mBTZ S4p8UcA9AnT8GCBFiZOSuUcMYw+1AwBxrD1y+RHLCaTZ4ALYQjLbqU17CmRO 1R+1/Ksi+bQL2QmHXfgSGLb1yh/AOImj40Zv2pXU9RJXshKCOOXWtFoupaEq hpVo3X8EXSB5lzi7h4f7R+en+0fOW2f/aPvgYmd3B9/DS3Siy94DjwEEheAg nx2HAh12+hPPJ9/fZv39byxNyKsXVB7Ii1cUPeiMmcrmcjozzPUGHhHwl4C9 q7Td4jgyDOOEv6tY2O+DwfoWQUFPf4PZgQ+cpu0GTBi643BA5QOnQT3wimAS 1A36fgQY1Ua9Wk7wz8IiIlbOpKO1aTRrSYdmaopmCl4Re5AGYxIenG+d/rR7 7vy0e7R7ur9t6GQtAOfAiSfw7s0bcnJ6vL17dnZ8mpVolNbGmWp1bcssrw0+ R7Evnz9PtdCAoaxQHxyeva1DTS1tPCnQYPxLq18c7R5unf1M1jTy/fckrYzF 0ECNh+A8gZjhNBs9JgfspNP33WtfoT/RG3YG/iAcf2QP/gRvzmHWz0E/xAFD 81rOHXAnNCBXxh1LhQdWwh1p8/4o6IdXEx/6Ab62MwiTjnh+JwRfgPXudVl1 cBGhR31wliKnC17aR2cATqcDUxwGJeoF3VgrrQ4OgIPT7cDtO+CVQ6MjtPIA R0nfR6N+EOPbCKMSpWAmQzrz8D2Kg4NBAZglVbYcfxz5oJuRE8Xgz0ZZkzAp 81Tn8qMzug3HpSCQc93u2PdHpUXg0x9D1wAB7FXSBIwH3qTvy9moqy1F1wQ/ UVfb8MAqUbKTrdPz/a0D53T3J2dn92T3aGf3aPt3skaFSUpa8l0qpRLFAStU BvN/ofQK/GMBpbVqBuZamVIvbOXiaOtg/6ej3R3n8PjXXef45Hz/cOsAWnkp a0XO39m4nJ0c7J8jJmcZrEykZtc///1k9wBU3jk7Pz7dFYAUpGc2pIPjrR3V +fF35+Td8WkGJydsOSjSAbrdhkFRUHJTNRRTS4fJlS8r7B8yi/3DUYsE3dQU /mw30hIrSeCcd3dt1aHmynlvO85q4zUr97IEUmoDV5JypfCSaWUCtbx7IG7n +xeHZo1OgqzFwWRgzgZ6dLx9fLSVgJQR1tTB29CbAmF1SzENIyWspBPorwpk ShoX2qUubWOlEpWzApiXMjDgEmdULuuMucXBkMK/kr7tOodb52/Jd98JYtqo 7CmrMU3vmWD1RjnlW03FtIVFHtMGkW5nlCdE0pf3tkD3siI55giqMSXQQTKY lQzyiXh/EkDIG00EPaHQrHIZLV9WKm9JD0VtoUh+EkDIW060JmlXxhMawUy0 YcqabZ9cwLiwt3VxcO4MQxjyXKK1qothxAhcVbu6FI3RBx2itQte1XTRo61D sMafVtGlXVXIKgZq8JNjJ3zFsMOqkg1eyfPROBRK6cJ3A75nLKj6t5oSE2pf +aHn45f3Fvu7rvPPBCDvAIvL4Tv2bZ1WB4nOlUq7T3sGQ0wnjGP8zkhOC3+b FKb0ZZ2gJFz9winI5zzb2xoMhbvbAlGTR2T1H2udjuZ0RpMGWWUBbLB9TaNd 4nI8BPunPAaxXKI74Br9LSd3lBMEnpishWVG6sdqqg1+q2YInqym6+jb2olg EcGSbYN7pSuFh+m0reSFZSrUmE+b7GKFgYuxxy+v5Yt5U5PkDp9hG+tai2ja pmluGsbUJLlkht0pLuk1NzW73pKeaSvNpkAyfGBpAsG2j8/Oz5wjZ//o7Ai8 UaPZUICzr17AzCOiy5Z7Z7+cnucW7gmh4QeG+0vCXhAQ6w64r+HYwZpRGvin P8kb8okSttCc1lBk4i007w4xUp4LpUDrElD6bFAEpp41IJV36todBzT6R+eh hCE6LxA6pXNhRicB8qnIDikUASeABLOl4RVJF/UwuvjLfgKw2C2zDGD1v7el AEt7WP3vbNk93CkF2Gx8kUCcCTCMe/44galKmSmBmfAlZccIgPguuFm4YodB wBJOa20Z3jnp9YLrwPNfDUJvBpNRiefDuJy/TakgV8EqZ60tFZYqWOVcBVgS tlbByjF0WlvzVm8QXke3cxT+My1sK9RfhterfXd85a+ixUlNTTt9S4MUp1vn +8fJOzN9RwEjj3Eyj9r9yz5wHRdBqKpDc5f9VJAMBWoS44uyku9VUheDRleA eZJGE/GACM7qgiEHrYAI0CZwIfSMft0Qyp36fTcOrn0ShwhnHf7Hbvhodtl4 UNkVDGlIu1KCOlSBIgq20u17r7pRpjYmbULTS9HtjgqYEurZMGTP9hiyO3sp su/Y1wS+pRD4zy5FoQB+Xvj6FKJARoSLa8BpopNAz3K+ijUKPD3LeLmzn0MP yVeK2yIQSxHKZW7luVeOk1hJ2gMlaR57cj6Nm0KapejdBbiR6S0QCTQzhx5o RSLavHxS+nhIfrazJ2iHQPF3sCr4muR2gFklZGWHJpms7NGgIDGFzqXFwWet URzaSzxWGRBZm1s7O8RIQxiL/9NeafRP3c4vu92E9FZmTKLgT7pqTBOZYhyE +2HnfVIQChz5NzQXJXVeIzL0r4GN3jgcpdX86DXGTGD8+Eg67hCX8S59HNnB RA98L8EhTU3sf1RYYVw3/jDxJ74HRvI3ny0CTgaXmFwJchmgl+AO/XASCW0l 4ECowGPFISRzGan57fZ98LfjXhCRtYA63pfglH7EXEPsmkuuQnARwFVw8bcA rh8MArEDWZvEhXr9voLL2tDzAHyWW78zoU4yXfiO3fdQKgoHfgovGPiC7ddU NSW70II7xpzMvtgUr9BMi/84doedHlNX+YhrTk1KUHhQS/fOLn6kA2yUdWVm 5cOLg+kJjWygb09V3dn/tVZVfbrHP54tWHP7bb2ateduL3HuRhNkQarioMPk i/6UTuXSuHg6lSMSYhUbl8/cZLNU2zAV2xQWIex2W2lrWjFeNKDhSZNAY99/ L4lZ5or+bBfL/WznS2ydvz04PmIFafnP6UNxiWmQLd4WAIprtllptjZQLMtX DHIlaYiiWJA+zJcTFr5zRaXL3QNxpVtW3DKlxZEGwqq2CKdAjYRsIl0K9GNf 80vaIBo/8YCcKBOdXhh0cEYdTvoe2tVOOBhgwsTkEs0l2kmWCMeTA1l8bO3k ZBy+ouLwipH2FSXcqy0a2XoFvGayLpU301JsS0ui0dCxA1wxTw1otwsGFj2G IxaNxAiVjoGWsR+BxcYx4oq6w2jowTjSnA7qHIZj1j2OKLAg8v1BBJb3vc/M Mua9s3EpHrueH3a7bGiAceW/kuwQEjDv39AxH5ECTEKZl37HxVSoIE56exOO 32PbN36/zzILkTQ0m5JgPiI3jN+W5QmAPg8cw7Yoy362gOvHO7sCKxPGMmHN ycXrKahCukFduEylP2eKI20MY035pmSJDLRNk7eJgKd7CN7pLS1W6AWoyRzd 4d8RI5AeEU+g9XRfWQ4x76aH3fx/tM50SWQLMN2JfWppeakp5g3HYb+P+3H6 /nAK6TxCeTx/tsroW2yjQ+d3b0RQdVk4DYym+jlunvDTxTzfHzmXzB3ItbwU +clcjR40GIHGgHs2mtAc3ROT5x+j5QloyjgaJ6bwG+THCddDt4v+PpS+AU9p 4OKcYRgmriCmFYOGDsFSxrRACCZsjFnVyHkG4FLowQbZj5l7FQw7Yx/aZ5tj UhuxQbbYE9YPhaVZaobSzmLef1uvGVYmG6buyYzlG3h0e1boztdv2PIIL9vC VXO3pqnLgNzZ6C0qbV+B9ZP6ci1Dse00s6Cgx0IqGUx1wMQkBJ4W0KRst+9e 5SrUU1+U716AISOnG4SjnNkwC+ZDIveYRZar/f/WSsfwVBWmutWQ9wvkXKUd +rlEMTv92EvaTICX6ZGkDdyvBY14QfejczMOYp/ZAWawKgoXm0R8JeBZeh1u xmJZjwITpwz3OByEse/wePmbohalTRVZM8PXfc2sIdO2f7L1z3zLXTeKHYxy BLdFtJI2oE0ZdjD8gQlNdrLlBGfa2hRrf2BCg1mytFkVWqBOgqkq7Wa6Fegr V4tpm/i3ftyTfszwpp6VokjHE7uNWzWT8YTQXMRwMiaYZT3wqWfr4ukI6LVy 5SBUJyI2KuJWRp/54Nd+kiuR70uv0JdSzibs6gUsu7icsdHk0vGjkWPefW5b DtyuAl6UmEUbAzeyFJMpWb1LA5XY5FpaFmp8jchhq4OpsqIA1JjTpn2rcNob EpWXp9NLcF8QKzZPcgZBBALd6QkjynLgZ3u4nWQPt0P3cNdsopxuUoUrbl+p kpIaECUbYu4Ike2BYUOIKZtElW+iYQZkRohorinF/jAN6qJMwxzeJz2cl7t0 70q3H3Ri0sOpBkwzLv34xod5HYvd8kUFPvOgk31mcOnBGewUAMI26eeXbnGR ig0GBLfCRHTP+iQi0H8BFgXDALLEmQKQOCTxTUgsE+H33P51uo21aSntlpGl yD3rEeBO0YDaQ0FJK/c8JjiFif/9DQ4l+D3aKDHt8D7kcFGj9eWMG8tpqN4A cieS/j2SzJyR/VWHFNkko63B7Fw3hUkGzeZgJ09hEA4DcjjNgWeYjaKr/6Bh fJZ8NvYjPJZAITe9ADqcxu+hUXp4CPzDfrP643By1et/JPqG+Q+hMqNIxx3S TBbQeSgycKP37KiBjgvzs0mf8J2lAIiBZdldfklQvmLz5pvFVAp3sftsNYGf sBXhIV1jdiQE7pikSSBpQ4HPzmoAJMP+NYtnAotY59NsLexjRNegURwAp5te 2PczPtJVkRs81AtpAtjB/+Tfk4izvh/ecCB0cbrj9t0xuXb7E5+eSAGKjzm/ NCIaY8Y5zYajR1iMRrwiAzQZsjV1T+4jFHaWzlg6k20hLVSRNZDfLZoLP88O dWc7lmc1NfZHaLD66T7b4uS9YlylkiGPywTDjud3hDDCbCNDfSzm57VaSrut C37e30oodRUSU/63Rs6tkSW7zN/kqDq3Kuc48kA6XdHmU1Nu6Yir07Ox5MtE /m3s2Cp4NU6SaBlNh0aFxKYZnRFWE3k6VaI5IUwft08uSIfyFPWCrtjTM45C zJH00LehE0gwDUNiJgtmhWOPEnPlE80CUxH7eBqZF97ITUIXJq/OvyeDkcMS QHMSsZwYTXIERRVseaC5BnC6dBxPDzFA0e1wMKKHM4HN8W87QLMrn07CYR7n s20ytgqurVyfO4MR1LnKrVqXAbUpnaMCcJ4ZycDTQaXdUjRVbcoXXv4WtKVN 6mZI3IzQwF1ErzgePikZlNo+XAs0Lbnt4+1r1iXFssgE3p3dpAv0GEjPq4/f bT4tZDrc4MH4EU/GQ1k8VzopSGeJHUwSQtmEyeHYvaKn7+IUcTJkDgqf0CVn qxE8I7fDMhuCSPQcqApQ5y9RS4X4KMC4VkXWLifgNYSA/bhBkmk9PZ+NHoqk qjZovGbKNf6pkteZsYz3pOgsE2qtqWmK1jTESTTr6fHJuYNHQW7yh+w0kW+p P4ipyCufcPs6WDXcWhHThe2IfIduBh6TQw8XAVIk343sOx698nq6Llh18Ak7 gMbnN2Q2CCTtype0b4w7BIyuz4k+hYi+OCYL9v6uPTbm7rHYWq0+zu4X1c5m Cw8xU8VZ3j1Lya65tVSRKcJ7LPlZGK+l4jK/ZK3dtf/z9Vluq2wVbJUtZhXA v0/fsRM16LYaBfeYF//7ogiF6VEbubKapZCW8JErznNujZlVvi1WsczqKryR LymPxF1EBEayMXmR/BhNHDzzPvrXHzD+lB2n8pofL2jCSGo1m6KuPl8qiVVy Z2EkNXBPZEv4uA+6yqWxjXRW05ETlODkfMsxdo6OfwNo7HAU8aGzBY/xaJT0 sWX+uH8ODzXdVpga4VN2rvEbojctqiSEKtXrBC/6yfqf7TBz+4EbOTFOTRAX LgkWzKKs7FaW++ghfwouDr7YfgcTnDekqQE36MyGVzg5Ptk+onBU3RQA4WnC AAYcM8rnFDxaizfEVNuLU0DKM8sy8OxNWziNs2VYitYy01OVkj23BMwV74xB RGFPTv3p3q4qwkk2P9sKLY8bm1nNk9Pdvd3z7bcIgj9ipP+ckVbSYMKJtPns m/5FSXf6fsoOCFJkB+3U7Ez9ncNCr8t6Oi8wPlynZP4sCMu8sFCUPgvi8+rF 51QkX7zKES49Qv9vytWiXFL802pq53OUy46DIipaAuY14Lyb3oaD177QGc76 gJ6Ux87ephMxIoNumTLouOc+I+OCrXwpseW23lQ02xBOO9TaKtiFtq4LxjPn FE370OhJye1R8McG96SmJKrBQLO1bra5G6PPYP2YL4RnYwCytWEj0xq0Fpme OVOQbOvyHL1NhIpaqe++I9+uyZ297xhBWPlGg9WQ0owVeT1XN0BK6/cBCld2 AN7P1zrVjPrts5NBq3pAS6Riw10PJtsUfK1e0fINLkLsyPS1VQxYfgwnJPLx gAM8Cj302S4xvgM4uRJklQ4+ZLVwvvpqSUqvrqqGAn/s3BnITUXXVDPzNadO WeWaV0YEgx9/Rl2Ic5wDsKUtIzkjM+JKTS/NyDbtTx3Dyq1eRTsvmTuYb0eX tGMkQaJiMzOx0ctIhyfsqXpLPHRPw3P49JaUdHR8qGwMxicZ5bijVcDJvRxI KYdqUkW3TE+LHWSSxzv4KTeZTGDjKdLOzvHFjwe78kOT27rZUtp6M/Ogv2TT 1SLpdVQLlm3/hvyqs6yuBnqSfMY6jm8Jbv7jbj/zSX/Dq8gKKSowYNDVR4zu hTy/RMFlUVxBphmJrDr8w10GdJEzZOuy4QjLd0l8E3R8YbXCQETwFpn0uOcF EEnHQeG7iBa94SD7VzjbV35sdyNXpQgb/4Uj3LMBI6/TD2/o2u9a0im8tUil 8/tiFa2qiiapguFJh8Y717AeRlNwrXMy8sgaNMKqSeqxsEDx+ZeHZbFcdlsW bh/WhdmfDElcRO4JWMKfQaNRCH7wCyxWPjE4Bc7Kj31vJBjQVumyOGuatrF9 fHR2rjqn5+/IGpUv1iRvismsjbfMtG3Bv7krAnIpu0dBNc/mFlShSj1BZXIa LSan35IHYqnUqzVsA6a78Fec7xptsw0P2/kAEY0OTp8Fsyl/zdY/Sl7+bG/y MaVYi0+wSuqxRZ2Sl+kUo/q9BT2WksJUDbwTRTXy16RgqMzUmqn/8oDozoFR Ik/pVnocqd04Hieb69dQTkrcNs1smaaCf9si6ralw0O7JUjB/juYL/x4sX9w vn8EIvrj2W806iN9tcNfJf5Hug62zi6KokeC7Qur4Jn/kYMFNuDo/GxHKXtz Jnmz++789Jf9sheS5/tHZ7un59Iq/JWSuDi5l7/ubkOB/XPnV/1sX0KI7L35 tvq9jY1LudM0LZDBptkSThfWms02sKxpZWc34b831K3znGSFkGY3Of0AF/1w TGO/h2jdvkkOU6T/Rhj0FN6SXzXrl33xwdHFwYFzfrq720idynjs++Ra9wKn SwvSr5NhxPKwki9c9Ku6Br5Brq3C7xrRirRVAYrkWQ1IIp6lSN4Xps8Ac836 ECwD0YJ8zd0/KvG0i/QqVlulwF4XHoMNmnrOfstVzVZRq2xVNISgaWAIm21L UDXP7yZXl5O1LMijkNWpK80xLXG8qpCUjvAF/gO/U0ldzCnzif7PaeO1zHxm xjO5Fi9KDaesW/ROvmK3+K3k0K1pwlNDwbo64seOAOu7itQsc1mZs+FoZsOU e861GcnbPZu3XXpReCBvdpYFU2SDy0IdWJXIuVTDFNm4NW+T/NLvoFardTBP RskFO1K3H/JWG2J4ZquDoa9kSnbtdxy8yo+MwOXxx4krgWUp6BmW6ixnmZJd YcWhkmrq9MucWZIaFctQ8To3IwmLIRx/OBnQ7B6HHsIS4F/RRg09v4PpvQgX JkC7p1tHOzA/yP3yb0cKURv4v1DVHV9RvIp1aelkPpOUhEkD/NXoX529wmhC Mo/BP7qCVGXvaK95NrpDAxQxmynhX5V9aOxDZx8G61kiTzRdqtthJyLs7G4f OHsXR9vn+8dHzjZmDa4xxBvZwiwN0cPzDg2B8NXrpo735VlqZo+fIj3pX6OU quHIuBtp2Ye5XArLJdjWcCHb1kUP1Gq3QKxbqm3k0wiE+TFg13idvkgSOGgY MR3a+KxGNrZspuaCVw1Yau/IHXosXT8zP4icsweTIhoEdq4HdKBh4xZnITMg 1W2eLaFNOmbVapNbts3SAtTsZ10KOF/XOIPfSEpPm9h/kkJH6VA0XW6zWI6b bW7t8R+KeKIJv24dXIA8iYimhbRCIfp9++3W/lFWQajBAjecyEPcPdKn5dRc GU1aRhPKxPysFWoIPDd2/0Up9scGbkuBev9S/9gYUMuQ1KBqVVVDk9XQq2ro xRo0fYqsvahqgyWKu7Hf4LEc2rFGQ+ASI1InHH104pCaCNwcwyI9WhLfqt2m XmwzMS6FNrXSNvUkQCa2STem4KmFnz9zRUcpVXPCBq8wynVIzREr1CDfvmHc K5asRELNI8FgKQxQDo+kKzTSh5u10B6vsXIZAmCuoMhPu0fO3jYIKm1MAJtG 94pkRjMnNMYNB/ULTs/fZaWnLGPB1CSWscJiMN9z2iLINDy4d73FUa6ihrT2 Pag9DKfSMvqTNw10HK+qYXxFxuRTTreTtWh+S70bvSeDSUTP+3eH2Qn/q0I/ BFWp1GMMq9fuu1Hse+Je1eh73x9exb377fxfwaJSj/gxzWoysZ1pWJMp9VM3 rTjzqFldDuqRzDRMiqRljK/QlNPZW1UNM6vxSPb/kfzJh7Hejz3ymMW+JzP6 v0eehx15aCzmIYYf9nx6+MmtIm7WKGa+rVXMxhHtxew7UwcevzS1ua7pRNM3 DXNT13P3nhrll6Ymtfmtqfam2S7WLrs1VWsauNwiLrZg9r2QLEjWLo7wLBDn 5Oztxd6PKyuarjaKb/Z/OsIXWvEFW0bBV3ojNSuvyR67VczcStId2YukGptj kfw/zVAbkmJkqpjWIElkKymZeBeFknpDWqwIkGcU/sEvd1ljB2dk+9rlhG3r itZOA87/B/5//ZqcJBmj9PyQDULOcYsopgkEl5PYZ5bEv3U77HwUjAtieD1L NMVqDBTGK0Fx+TZUQgWht/HNt2n/ECpZ7Ywmq4Re4azg/c0K30KtZDc0K/RS ZeW9pbBNE8krU3lvK2xDkkK3GilpZrmSZYFT0qyxjR5r0cfBZYiHsXShSQzb xZMhWMIGpxz0egsPmSpci8NJcUq7PfDxpABvQnfvg+JO2AP4cenzpG9b0bNs 1q+VsEq6c+RBKSwTZR1zijVdPCeYnleiBPRUNf6hKeMwhqGDf2gKHq6vBF5w zRP7g85gpOCdCEpwOVYiP+4ABLyYgL/HmyiUUThSOng9G/65VujFF3x7GaCj dPoeL93Fil0o3Y2uhkoX2+piW91RNOooXQq3iy12bzs9pQs+9Yj+xY/x0OOL vwg28vvhlcI+NPwMXM+jn1EPsMMvCJ13IvLxCUKHD14QX8MHtoYf4SCgn9es Mv/MCDEY3CrwP8KAD4SBvwAGfCAM/IA68IEdEPnPT4Qmq/SC11XGdZ7kDSyy xYM8H4tFl0E8cIfB6LnzCn8Oo/thmVTLdFXRdWHfLNb3yL/W/A/c4qAWg8m5 OzVXkyzGQhfBmLX4u6lW5yA9Xam9E/HLOghvy/o3J4dKGoDXq2yRE1ih6Iaw mf4vzA6uC4/MFanSGKA0Rqo0bAQ8h4F97TKcDOmxxQP3FigxaBA+Y2PXNYqj Yzpn2xC8O4YGq+NkszqyukqNS5k0cLMrms5k3AJDqVAjoNAb05ndpdaziDeu IKtFiuJhnczhaCE/FEYUWT0qvgaIr2kIObPPkTDKVBK3+C8ZaZZMPqmc2aai t9VEzoCWeDTgDW5rULsweaWxSn7TA/iduM9xmmbsvaN2KbGoTQm6DiA+dDA/ PNk6shZggGGKfnj7lUi+KZXjGKbIJTt/BOw0yTMVnUcqMm0NcEz3Oj0FHJUC i5eDrIzBpmYoptYWdooUjRBuski6gWcXFXr/Ddun963bn2jK0L8ahpnXRY0w uleIEkMy87S+4Rerd7OBAgeS5HHecFebajoUJBXzpjcztnx8M8HdMMHdyHaW PBTCqYP4CJjLWN+2bKXdamWO12rk9rpMeP+1FvE0/sTkgdBpq0mYI3vJZngO mDjQEihz7XficCwpOGDvz/ZXG39kkzZ+nDNOY+n+Jy8EX9ofRUTDo5zxSFVi 4GQ0HOLthBtsz0qieTT0tfoCEO2OnMAZBLe+J3SfrI39q83t7b0Tsnew9dMZ 7mihbAV+05PX2Ls1djQ5jwYSlawmm7WSZ+jsKIl/1G41lbYt7ExYKtVeFgsm p4qkRb1gDIXvkcBQCYXthUIm/LObfAbsS5e9AGOGp4TnjhNEsuNAGLB7f6FL UeNRWSYVfBtY2NZyJ/XkrXW+gc2zPSDXKlr2xLRK5jlne1Vvd/ZosOLbmoJQ jLkV6Iae5yyqsaMqDTyqUs3lyT0xVKcLlsr8EqgikwekEJLJesYSQedMdUQC 8GzjYYbWX0MmatFFLhQa0klviq6RHDH+8g+5O/FumXyeVJjMi2lW64iCkXN2 HgCFpXGvNrZyBhomYG+qz1erJ6UmTcJrswnYNvW/hFrXJIxcLHCLsdpsPmex KDNqErGwNMDWsv8iYlGLMHKxwK2uast8DHPP1/IO8bof0Z3GMANno41stO0n bskrEZGSXW+BkdZtwUiLkyghPlI945l6h0uOzsgNxlBgOJJhUlP1WEYYNnbd C3KylVebt/s4DxmGwzQ0KMxF+NwREAUh09vC7PGRsa3DYLoREwlDKGHugTZS yTDaGh4FYT9ZyeC2J7pxR73A0WfiL5mjvmSRkpXp8lppeS5KJh4BZ2rPW5Re orU4wmsL6EHohRp46njHT44+Fc8lOTvfOjjAYKwXRHj2GDtcL9mo/BR4JBXp pgU+WrOlPweR/lBNrl9KyfVBSq5fSsn1IRXppk13u2vPSaQzSj6CSD8sj2Qi rWu4eq+Jy/dz82znocbvuGqMOq8xfuswHgG2pnUHCV0utksbv+9EG5lkwNCk KvBHkIzVznUcR5EeBZ8+fPnf+NM/NIX8Q/38DxU+tC/TIfRsyT9gqxhlSr9X g2KMDEq15cMlPHBahx2v603HE/NE2SnTrjdjZZwsNmktJEJLOEjxKRGhtvQo mRDdN9lKZKkNZLSaRVnylk7GneXLUtSNZhHlrJYs2ShL9pQsPQ0iLF2WlkA2 uSzBRB9U0pTZpactSN6yBKmNgtSWGqWvTYqWQDO5FLVaqIyGzCI9ESnCnGg8 2IiwF4SVp37lIMKsJ0wEF6I0YlLLyPdHeD+nnuRMYNKEKjU9z1ZilkMfqXSY BtgY+Cf3itPUAL2cFG9lbqKQyzWvR8wjc9vhEK+9xsX55FrtLi6xkFGIaULo DdLzrzBYSB+lIUjTtHTAyWrLfd8HxmmBmdmdKCDnsg1eidk2s01EZlMzFbOp iwvuJa5aCR1eKDRT74XyokbaCJTiepAKd40MElmtYksYTYcpSTTuQAU8mb80 VkCJFQVRV2dmVk6pNlCqqeYopTfhkVE92a/n9c4i0/wkuhfysKVoKX2aho7E aIn0QZe3aTX/YpLkzZCkpomUMnOUwjlWs1U9Kf9KJMmbJUkWjtSW2hToY+kg SZZRLUk7y5SkZMBNUtUeySZ5lZJkaUgpLUcpEx/NCO/U82JmkWl+Et0Leaok yTSQGLZInxaMbpZdPbp9fZLkzZKkJlKqmaOUDaObNSOU/ZVIkjdDkizbUhX4 I2iaZbcNxWqrgqatipd3sCkEy0BgEfXjYXYOLXuyf3hxgPcq4N1L/CMYDGyy skMpMV1o4A+yQr9SGpwAMaugGXodcFgqg1fWPbJSDUp8P03pwaTvBYajOWP/ Ntl9PH98TUnXsib9GItOV9ZKA73/GA8U+E8tmRJbtq0Dm21haLbaOrLZSLfj sKNMC+m70CI7Kj4XVG7w4oUEhtSr/6YsCSJRhIagCmRNrgv0EqRk504+19/t 43muMA+4RpVRFY0VngeBl9UIvJyJAH9ftZRQutwx6UeBUaaQbeRUO8cpmLFa 7aZgsFbnUUK8Xo1/lCshvgVCZYXKlDAPrUwJ8+DySlgCr0QHU0gzdTBCHVw0 lpTXvrMp7Tu7i/a1NVQ1zRZ5arXgkXDF5t/at0TtO5NoX0FQnD/927hEB5nC mYbIr3ZLaanq3/x6MH4J1rJXai3bJjWNAqdaqqYDp3Rz2n15u48nEjmHW+dv K+1n3gDhlcL8o9oyYgmgXr2CGUTNqgtyVkn6UWJGU0jZe5lq9GbY0NJMnGkb +nbKhr69kw21LDSYmshpA3XSLKbQl4q+prAA6MMqYw09vINiVcVzKzTqQ7lG tZDOdo7OTQ3oLB6snmjULxUaNaVQXBILDgg+BcEUn0ol88MMySxNqHnjilL5 y5RU/lIpleXy2IaJU7vdFOlktYFOrWZVPncqDeyoHjZhrMrXzm/arCuZM1OC E1hl8vNLhfxMKDtKjTJYYAstcE6E2vBIUyt3QHwNpJlFGVNFiyUKjaaDcuWu 8/w6KTOhs+S4nDQWCk3OvuMtay3hkrWHIg2PvdQjDS88izQ7+a2/v9ErJf8r xhMLSIzHgvFLSnC/r2VeBjFhFz2wnET4OfYjsF8Rvo9vQhL5I3cMtooY+iV9 y++wLCFu2wDitm2RuC3USPvBNfI+iDvDfawSO01ro/oJq18tPFoM/rSfA2UW Dj945RQxm6h1qkgRA8yWblRuS30qFLmLrEx4JK8XXPXw2s8yCtlosm1LpBBM 51t6y/gaKFQlOxM+fZ5BIR09AD3nARioVcbz1qqKsEKRMBXhBdAkGNd0MbzQ MnQgmGE8C2u8iGZF9TQLNAjVSBynDAum80b1JsmnTpkqjYrqaZShgoExkgMv GWUwJGWqz8LmLKBRRcJUaZSh26g+okaZOLCb+oNPxu6LOvyotOQuO3Aa3Tg7 NDby6eXl8AgT43wQLJojB35lN+j7G1KqaapBj5swtKY8Fy7ZM0EPUJLtjBDO 1ZKdpCPuqrjrFhE8VtYyHdoVx/X+LdlJ/H8l++5VjR4zYFeu9T4ogovsW7o7 OeT8b+p4CkPTEI9hmB/9h9njixin6BYiQaX8t7QW7rDXTXlWxKMguDwBmIMc Uv5reIIg/G3P2OH9FPTfjXpjOmcR8JQtrtO+eoFkf7dmtGzA1rBnbMt9fsbg TrSRSobZbOIF901LyJIuwvYmI6I2yNptOBbWS5On2fGGhpaGqelw2Q8vL/1x IqWCkAKKf/AgMqULjyVPOQaX0XixVd5EEmhSEPwtRGofErtPFEO8UoJH0rd+ POTSwN/hP+ESCbzWotP/Mwp0x70c4DUcFK/oX+ofeFEF/6H90eB3j+K/neOj 3eTXF/j8gi0IZ8YzemZQGdkXoGp2ICoQ4M95V8+FUy+qyMdkIiMXF5L+n51h /Kkv22KVYpPX4LE/4ipc1D5uAoQDPoslZrutd5HOEl20WqiLLUMcpSspxcWM fkB/5qJOYt/KDDEw2AvSnc0YhOz3/X6iWGhiTZj+i+PtvXd1BpckMj/Ck2Mn wzhCTBYW+pW1BM5DiPzJ8cn20TmXemz40cReQtAXAkWdzmCUoype5iT4It9m R0bid2hoUTKOB6uUjtkSanqeborBUpiKdh8NvYwj5Lvv2HXArGinQy8iW0O6 KATcMHoF0TNhG59jV/Eus/QpC7N/d+YkEeHXY2hFUmV+aPrTH4d4B6pPK1Wx ucBnmvaKbH6efJ/HjJeMQK02jkB2s543uFPhL1nG3P5SPvl4hmd4lxzc1D9s 6Tjitsx2Pf/wnvFd1Ff07sVX9Gb6irMUcoU6iXMmOC8yYhb1tug0Svfl3586 yqLASxPcEsW16TSubc7nOkrS/dE3m4deOTfy/yTxy7Hveuv9sOP2SQSzWvdK CGjikTq7B3sbtGyiiE0d+m+bxnz+5BL7P4OZFb6lV+lbzlaSdHx6BE2R+ZqP oy1VTot3J19zTrIu4msuxGS5r7k0H+QJsFHwQXqZkqQ+yLeS4XZm/ukq5w1U CIaTiGafCtduNOnrlcSA/DlvdioqVeZMVg/jnBSV+Ijuw9sK9wE6XrtdLjB3 cRl69+Iy9Ga6DBVpxYLLsADP7hpXunlYbXlbbvRgAMNzPO9AwmrFWITC1CbO QWROWhyL5yHsrLG4nGqJee1VjsWzSZea6QcQQdnY+3TEUKDo7LE3+TcjVrCI 1C0WK5jF6aq+LTkG9DgsXcgXl84tmk0Vb2luqu1sbrEafRjHUTTXqUMVy651 Thx6UZ4/gn1JNz+XehRne2Ui0U3iAU06DYG/QjzgcVCdLjO9x/5+CVIiC6aG smC2irLgLYlAtU6fqkbdm436Th1ZwKOv4a9dlIWHRvXOsnBngpTIQktFWWiJ h4t2sb1SctBbScsJ8q7WyWPVlxBg+yz0G3VvZ+P9roYg2DoKgq2LgvBweNbg /kOSpEQUbCoK9hMVBW9pomDg+GAb7UcRBSi1TGlYAlVk0qCreGkA/k0HiRU2 X6867kKyG5lWlGxexho6nvBc4oYLGztrzKKTifPPNvn8OQm6/LR7tHu6v22Z DXT4vg1HcTAI/vSdCP4wVuLjyI2DqBv4kUPd0rGLB7b8LMyp9T8aEtKif2k0 Ct4mF5AkliAPIhQoOA1IT69TVS3TBCZYTTW3kf1ZMkF4lmw0fY58kSuLqSKf TE2VKEvZ2uo8fDr7SyvLWU1labZQWSxDoizPjAnPQ1lm8qVEWTQblUU3c8py J07NyauvWWPyeRM1OZWqUAsHfat40M2zZc2T16MFuVWiWEYTFcvUMsUqH/TT INyCduwbkbdRZ4yfCNoAR3P17oqzNE7oiw//aiMPNlMTGy2Y1TYzNXnShJ5T DZ4o7UuEvokmy2y2qoX+7P54cfbMhX46YV4q9C3q47Y0tVronwyhn4XQz6R9 idBb6OqaWZK5nBdvl+KxSnnx9q5Cv3xaTq/MF2hZ27PgAo8XcsFfq1rgnwyR 6wn8U6Y7CvfGxqurTmcjHAdXrzZegS524Utg2NYrFlHbGHgruqpp62pzXdOJ pm8a5qaub6jJP/JSNVSV8rCyPv7XJKq9aaqbmparr0N9qeK1FUM4ewR/5o4z qzqmrOpMsG9epgG+6oBg4Txmumm5DDBbDaTLh9k/Bk/lnxr/1IvF2L//xT+f 4f9XUmpohobpfokJYjD+ZzIY5S6spTud/Vu/M4l9j56H0/PJJWhIp0fwLGuC q819P/b7HwlY3WGES8/DmMQhmUSFyKcz9iN/fO0i4DTCymCtEpWmRqyQwnmK 4mZx5b2tXPlDfxx0LLMwSUkrJDsLL8fJYZArSf11zgX+K/AnFMjMLnZAhbCD ZJkdRKAK/rme7icXk0I/GYcOwEgNOx9xy/loEvVYvhDtbhCBuel87PT9SCGX k5jsnp2Qa7c/8fGVe+0GfbxPkYHx3XE/8Md10MdmVom+XP5QoDMY5F5Nkq+4 aO7X49YoHK0Sky0WGLhqnrr5z03ElcSO/NVk/WW9fjopfYhKD3cs63BGxpe1 e/kyT012tvyz1si64nTvqikdjXCXsGWKDrEUr3lMDLQ2jQZj5FrGyZf8az90 vUY9PPq+i8eKGrO1ZEYXGaAynVhCJ533NvazQlDmIGhJb+uQlK/dthW8b1Dw xx+JxzUMDEAW7IuxBPvC+/pSplZ/y6OM+XUt1l0EU2qMcBN4Szj+CS85FC4c XeLQCF2vY2uHYdyD+QGVMBxyfDfxWOghlVs/XTBX5SaIe0RjYw7pJwNT7nDg OowSJF9bguRzJKWSL0UyGVoPJ/0cntHI7wRun+DENRjhcMnQhtbcTg+8N/DJ 9ncvireES9EMAMgqacoFoGVhgEYcjUr9FTX5jp1KcEg/hXKrbE5H/vnPf5Lf As8f4oSPY/IRHQJ+/SLewEgld6MuGqBVzs4+Dq2LGfp88fT2bqAPL7cyXSp/ izeWWRFe0iWlVZpV7CuT4ftheDNM14emhECdSc4iGeuSZfHBrx5NZmM8J8KL IQqtrxJ7bvO/KI5oPpVLYI0Ewbx+0JIZTjVVZT7ME+lvPTnpz9Hp7oS6A4FW ifXAerAcGcmhTEdizGvLDhr86ixzmcvzt4m+M3Hu2VbX8Kwoxmlw+C2Vi/m9 qypsX1aLAr14+OUcovByEQ3L0QXr/z2O3cs49vC24lkOaMu2GvcwssmXidsw 0qUbvmB4giZhwiOGrjeycWv3dgToDvxhHJGoF96wM2vpze1ecI0XIJDw2h/3 3RGbJI7DyVUPRjeLByh5E+yyd9YSri19M5W/LucMtDGDJbPnxnKGIOQ7mfHp 6IX6wnqZ/OyOIpw5JvzostKNmkEN7B2zWu3Hwb2GMK6tycURqNCoR4b0OGS2 mBxEAxQUvmSZW0oBXwmUG7ykzgRF0fc2CDkEMerjrRqRO/DJjfuRQXQjJpkw Ze+MfbxdIxog+DFxJ3E4cGMX6p7T2zrG4aV7CbLqhT6DD29jKDiYdHq1XDHo 4f1IJwKuySCFB8rnsxnAJO754r0QejM9tP6x7AGNP11EyHl8Q3na8yfjIIqD DtvMmthbZPHPNgOPjd6rLZnPyn+lRmXZRPjbutxR3u/HMs3F5gcyUVIXxjAV 3RJTOyWeJ78RPQB+XvnjTOXuPGWd373kGT9Ev1uMP1+LA58+jvoBCTI1cZuf NoymDvJ+EF7PmLQv6u8g5NmyWjpVFwV0frRwNn6PfE83Ey+R7wk1ZpNjUWXg lLGem0aUUabWBG1urQC5ZaaTaI+jFmWGexlZGwmS1A94IB2hDm+zpRiaLYR6 H2/0qBPc42S629JpgT6lO8tLI32lBFk87Pf3cDrfcFpHWLh1zYRFvwdhSWnz gMIykzYP4m3MGfNbqtsxP4p/Ic9jDkOKlQUFuftSycNY04wyVVb0b59sIZ9s DtNaEB/rmdjXMvGZi0gP47su28gu7MTOh/BD+rHSqEhLVfSWcC25oWuKYUhz GiRGI+nGNPcpOYrvMxrNRaBnaHizdcmZhjfpaykNX8poSB/VFTZuhZiwPYyp lgtbW9FtYdebYbQVo5nf+i6QYfajeQRKIMIzNMVlAiUxxRKBmv1oMfOVGutH s1+2peht4bppo2kphtUWJ+oycqbmvcS+S/K0wdY3lmDQaJVnODEXKFZ31wCj 2J3kjCstl7OHmbxL5axtgJwJ11MbLRgnbWNhOSvfxkCptlSTVxS55zK9LxW5 OYgnl74kp3+LPiZdsJtxMCSjEE+Sxp7WEc5u37vtggLrUokxVF0xVFtcbxJx zI57nDUH6Y7QquuF9coX7XrTNNpJmqOkLTX7vFt0oQspXPkpxEwCUJWyW4rR LlWpp0yxuWYfSyadVPg0UzF0tbjYuWAsidEz/eUOP9amJKVj5ebQOwvenZCC 1pPfiW2gothuK6baLIb7nzr97iaGyyakVDB1cM8M/Q5WsZDGkTP8a6KZ17OM D24AWnWTXgAFbgLsx7CZbN7HPP5altPUNMXUWnewnE+UqvdiV+cir1SIDRio mvps6yq2NGumUUV5plIvRT7Up/mjmOAngHkQxTP2usyeMUxhDkBHCv6NZXu9 HwQvuga15BNQGEdn2fl83pzreUl++uxOQ+F0dYlaLF1XTKM1e4B9AoI0rwot exR+AiRYSJfq7ph/tkpVG8GH1C7pgNVsKoZl3dN0wKuZ35Z2c/l7QLt4nMU9 uLJz4bb80UZ6oMgssakr8ZN+3iKbqmI2tXua8tyzjMxncp+nsNS2Ng8lNVJL Y7UVwzbvx9LUN4hJN+/B0tTbkze/9MyF3PJNDW1+Pqmp3+Poarh8lxWB3luP cdcLk3Odm8emqZj5daXnI9hzeqTPU8Lre2NPTtRrd/3hZF5q3HmA/pGNe9LP +1jVqLcNbVHZp4akBTPf1lQm+TMh4nyW5H6pKRXRtqWYWvHWCpkq0b7dpypR wlamsc0z2t1rd/FOOq76mnofm6myW+/mFgXZ0l5hZW8OLBHBJZ/uzHGb1W/Z ptOaHe8MwsQyt5gNsTXFbBcPk38GUl57oHu64j6fBXzOcl+bWQ+rADKzj/eA mdn5JBV97UhjcffRV6YaSz0Ijvd+WeIkjKjzo0ixay5reLsjW16/Jt1OOAiE 89FYZpJHLj+SSeRHJBz28fRRn4yCkb9BzSheZN7UijcvPSupmc8aPVvxqW2K HlyOpNbIMBXTLIbbCz2ecyfKwgFVRCeTrEUVtkye8pHUebfxLIMkCwVgkShL PjZgNrYl9JtTWhmS1HxpbaVpFCP2z0vM5rVffyl5q0echxU8qb1rqoo5fbTK Qy8dAZEzCVzq8dNTgvfwS0aA3PJD6EwMFloqgpHyyL/2xyTy/SEOjvRAIiw6 wYONLv2OC8MluYGHcdDvEy8c/heelkRGYRSTsX+1HsVu5z2DxOsFwyt6aNhs atx2+J0jr+cmx+sKeiDYRlqoJkF4NiczyUZTaWbnoj0vTbibLX4mKjGHJ/mX 0o08Xe5NSWTDR1OzlKYu7OGyVE2xdGN6XiaVxMHgFpx+JYr8+05opsevHWcX WBCXMo9e7EHwVLa+T7CLfI8LGQETYeaAj6KO23fH5Oxs95Z4buwyWNhORAhl gosXfuHtX6wzUDnuKdm1GV2iU0AgJXgsHMoPEJXsnTBI7GIKejAdbl+JNshR COJHb3/yiT+Mx4HPDogDIvVHt6/goze6ZT1QyE0v6PQYpKoumLQL2DZK9N7W zs6rvcOLA+hF1gHWvsKBRVjyI7lBMcd+X/oZtht19jABW/veUvcuJUfRJfLy so68VO3iTeRFJiGHh+8ov+djtcmpB/3GszETZufozBldh4agIf3lnl6RU71l 0lAhOZOBFeqMBdAR4CcmKVbeOzSv31c0LVLrZRgwCxN2BlrgA1jN9j1Yr3tO BF3QvKU2jVBIEYOTF/QMUpldS43K2fnx6e60XaPSTq1aYsxS68at2oRZNe/D hNszbJlB4aGcqaYNSdMv9GlztkxrFsUPZM0Kux/Y5PBX82xP+VXf2VPOq4/f z8tayRWElcJWJW0v9EUEThxE8TkYVwZDkD6Z4FUOqMB9BiQnfQUBqGllGXuj Xji+FyYXbUWV1S3Yisot2/eTUw19dEcRT51folGutsYtW2nahmCN222lpda1 xuhthFcK+9AWdCZz13PyvaiAZErRwaSfyH8t9ye8Wv7xU2X4Lm8gT9GFWdFn AfWa0sO6tIx7BIs4lgiODZMQ8SCJlqYrLV1f5gWR0z2plhzZ+nZ9mbmbAZrd 92opYH2vEoKXfA8+HhA/gtl27nI9tv1ByQ7ExuH2BuxqD4Z2GBbikFyyg+Dd y3AS0wPl652+H/nQVpLnVku4pOLSNhVLtcr2sc53Mt2icR4Bl+XHPBnwinA7 9yjAnwBvYmefORTLIcUi4SDe37vGSOvSopIMC8WNqNHRm0rLKN3I+8TFar6j 4P8i8nVXoixf0GT2zNLAnmltYfgzQRKbzfp+0+Lx4Fn+EvR6Hn8JOiI/dXGZ XhPDdnne0oLimJxqvBQviUe8peKh64qltwTxaNpKy5p9CfF83pE85i71iu4u HUv3j3jv6/hFC7E7WWGvdV5kXWuDC9MlPDeA56boEbfAI25rc5gEBnz56UaM bDUZniYmZAxvLtMSMCQf2RTQ/II7HiNaVyHrpAnMwZtFLraHacN+jMtrg4jk wZGeC4/I5QSv66ExHQTiIEoK6Qa3vpe7JmemTlPu3p9Sizu3l6XTFaO8aShW s/nos5b72wieol/Tq3xsl3IZ28brEqKcBovPV9qGYufPyXpGAjWva/71S9Zd KbJkEZPaMAtsmCWst9kayGDtbIHKTj/wTAWK39f58EVsH9c9SRFF12sJMxXa dol4tDTFalmCeOiWYucPNF/CTIX34D5nKpl03G0KW977RZwaFrPdDofX/jii aQiXfs+99jFffvyRBOOxfzXpu+P+R7q6JmQ+0RsUI9IZB3HQcfuk5499fkfo ufveJ77b6YlXLOICr4sref2PG4RsRdFk4GcXh6KBQXBu/8b9iIvBMcaE4Y1c KmxTsdrCMfc2eEK2VQi0Se35zl5myQsEnTbnCycW1fKWr2MH/o8iPfKKFqO1 zBnNddXR0ZLTpqnYC6vJ5XR8WZuO0vXmqjWmwaT/MkfX+gtNImGXfMh0kap1 c9cL1+RMn0+4Iz3NsVqH7yBuT0PSCodMl1Ol6ox8+UlbhQVvZqipcYJOjiJ9 lN3vmlzuKtxGzHNbkr1Ceyekk1nI2utSjOC0MXErRfWgxSVSFEepBWzbdB08 s4AtVbHbZg0LSNNFaOKIGIKf3xbO8p4Ews8loQLB7inYO69BzB+/X4+sC5vG ekPMAiKI0jcrnU4iffdgDJMBpswY5kk5W/QkZvFuRpIR7H7yuu4sfbOpNY8j mAkUs41RAOMDATlVwPNDj4xVx2wrmnIFPU5LQYm0FGUJFiiCwgBeTG+AH01i orEMsCjJDsBsMJbqRROz2AXXQlKXVVPSg2R4CxJvCqddMsvZgvllSxMnnGBK 25paw3LS6e9TcR+nMRYEtr1EgQ3ux4FMiPnwPmQmnREVdDIlwwsIXcSFrr1w DkpLhyHdEHLd2rqqtA39IQRzBi3nHsqnKfO3cNYQTgRRMJ9TNjb1Std4GjRQ fovCqesV5C0HP/FlKV5py7CUlrjG2DaaStusMy+vKcJ4Rew8IrwM2ypc7rRM N3Ru0Z2aLt1FdAVCVs+uFrOrKLbLsauU6nNP4aXSaZogncKcqd0EA2st0cCW SucsovK7Fxa2sH+L6Fwi6iVD/5SEKoKvyu+0yjYZtOcMQHnp4IdGttIzmMPG NnWl1RRyd9oW2NhWPRt77z6CMfd0X6DS/bgI9+UhPKbv6iU2lgsw04iZAqzp C0jwKqu2DANsqUrLEsL2bRsMcLueAV6i9S0s5HDju6joZlJrP6VY6sJSW9vs zhF3nSf24ukjwWra9xm+lwtpS2m1dEFI26aiqapVJ7Sa3453z6HV+QVWoO1z srXyXY4PbnUp9US3oa7VVb9Jd8b81vtIghgrd+HtGBdAh6lF/+cCmoIaIhXj FkzFbGEqpqmaCnKs17G288nxnHa36PMuJsRPYwXrPuS31P7OzkeY6TQEs71e bV5/Nx0N3wH8+lGwWg6DDTM2uy0Ksd4EIS5uqZGPdfu5tK25rXDdMxLrCO80 jcQpm7pECb6vgBgn5j3a3lmSK11tuJPk5tlyp9htu63YqikKqtkCQW01lyeo tUNfy8gSoHJ6P57t40roHazrtIC+zDwD7wMVUGinnoBi2FbIWp8n5ENbe4ZB 9Udx3hZnUevOLLofH+URubN814T9V4e0s66qslVbsfN3ZC8td732WfRCP+9l M0TxLp86weo7EmGRG394T+9rJ0T5jUY5Aix04QAbvFttGLxze+OekzDNm/b/ lUvVXcmxTPGSWi4dLJe48A+iB/KnzXPMzeKXfC35eBsofv+bIJKzU2pgO1d2 3ZyiuNRNEPwaM6mAGJZii8vqmqbpICC6tuRtEPKr1KrH9oXlY+nbIHjv58l+ o1VW0qwLL7iOPBIHg2B4FW0Q+jtiwboo9sc1JUO4eE1deEZpm6ZiN+/nRBpk mdaqLem5u8X0pV49z6A/7uAzJykoV+/FrSm/Xu2O4w7DkBkO3QTDYVj35dk8 gFzNO5z/BQTsriRZsqRJ7Rn00rbEUK5moig2Jff1zN/tBZ0cseeGWXsMg37I fRx9mYniDNt7cXIom/iwNxfCq8SoFySd4Wjw++CkgtLSFbslhlK1ZgsExbKX 7OzI76TLS8rCgiHIxCLR/fLuVrI61cCa0aphVDhFpfTf7M5X/yuPZg2jGtUL VBFCVo3KyvOkLjDDRTY2Xl11OhvhOLh6tfGqEw678CUwbOvVaAB+YTwOhhu9 FV3VtHW1ua7pRNM3DXNT1zfU5B95qRqqSoV3BgT8r0lUe9NUNzUtB0EHCDL9 0BSuG9+SVy/Idjj6CD3txWRtuwGyphoK/jXp3yb9a5G9se+Ts7Ab3+AZunvh ZOhRWVDI/rCzwUJw8O+8h54uHscInyN3HOMGjJ+2t2kJqokKN9a1m6Z/W0vp gIwWhqoYqYv8H0F3CEJPnJPDw/2j89P9I+ets3+0fXCxs7uD75lGlL4HrAAE heCcne0ajkOBDjv9ieeT728z3v137oWff0EpBR0z0x0ly+nYMNczeET88TgE ZcAnhY3WMT1f0x+6YMu8VSzs9yMfPhnnfvPJ0Pc9QtsN2Onz3XE4oDsgARw7 SRm+kJ7vev6Y8iR68WoxelQrVXxnpZqCsHylejAVehyFOZ8hlyXv8wozrTGj giAQEsWARQeKB8M+hewMNN0O4BPtenA5iX3HWVuDn/QYAF7McRqNCq26U++H +e7n1GrpegUGsq52LZV21RoIg/DGwFtQ+cTKC+ldenrV69couWTgdnqInudH nXEwooTHE76QXgIzIrwQ5/W0AvFxh8GbqUWvX7OC5XrEdDZdxV9qJ5muL62r MvrSLWR6s7CnTE+n/+AhJXsI/jf+9A9dIf9QP/9DhQ/9yyp9/681EPuyNUjm lmUFuGtZSEpVhAXIQvmSNNasRrEFIY/1j8b04iHtXLot4sOqnCiGobTFKz7a hqm0M8siEOXDV0aVCPNc5EQxLaXdFLdumTY8MAtEQQBIEy2jibYMmvB5l5BU NYsmvMZMmuzXoUmZpDTbStsyxb0WOjywJUT58KyosjOLKpWi0tKUtngmU7vV VNq2lqfK1ygr1cJig1mxRbNigwa1TRlZviJp0ZEw3gdMRZYP8XZTV+CPnQz0 mXn1lmFdxfOIvq1HoeRIhWqcaA8/CD0iawM37vScEC8qGnqbmNFLVLI69q8C XB5KXkBDb26V2yTkDqgD/lZzenh5bPyny88aee6dYnIJsppAwZYmkaClDND3 J0IeNaKl9DjbL6PGWBmn8tNC/Wm1JfLz2NgvXYDuSC+59LRQ/8RLhOCXBY+y jWecpN5XNWBlFC0ZsIACGpJBGMm1tqoq8Kc4QfC+wjErkTYpadqqgXRo503O 8kREYGBdpUtoVAerKiO8U8fotDXEX1eLzssTwL+G0SnIyH1TTC5BWhMpqMkk aCmqJAj6ckUInTlv0VE8FSAdTCzMtGUC9NjoL1uC7kowufyYSMCmLsjP+dbp T7vnuASgr6YkpanmcxGU0bNIA2FNrYitfzvCkGWmMbTNKoTN0pE6lQ/0its5 r/ih0KvN/nunhJzxlgmUaamzGP8QnJ92JqJqZOtMiNqtFiBom7NY/8R4v2xa yJmPzmq73SpMdbx5A7SLRSLLRumquKKenbVLibuQBSRkBY+zcgb++MqnpfER tNbth24Mahf7HAp7TujpV07k9wEDeH62hxlThPVfwgid7l0JBgPfC9zYF5q/ HbDmeV08orrf9/uARiccRjHgGRO1QYRfGtCi0WDtydDUpGiqSTM5SI3GHxUK QKm6BLYLM7xZBo3tKed62tYVXdWM6bnAQ8jiw0TF7y69yiPLr/JQAqw8pAgv jftzCL3MIIP8UyWwa7hho2h5YxVyfZbY0lNq7+in66puA35GHT9s+fgtbTS+ KynkrNcNII3ensl6bHyJpNFFmX29jH8UDue3qQJS2ZGMD4pUHX4XAqtLxF/G ZLOpmwr8EWJgZtPUFdPKTV1H7mX0/WBwC0YnCv70/3uaMK8rKJNePi63UMzv fknoXuVlYItw2MbnrcMdTEowt/JpCWmB5bRWSDelOJuucz0YhNfD+Fr3uqvU oMuDK1QxWU6zqJaDXFro2mQYjfwOlv6XOHTC79L8z/pj221FCmrZiPoHDnzS ShdHZye7287h8a9H50khQcnMLUaNVUqdSKZkKbGm9ziF15LRMT/WlTKENrhs ZkwBKCXxcyNXIr9mVEWys0qSrSS0OisI7hkV3JVqiUXXr0piV2Z4fVxGabH5 yCwb6hck81kdqVwaiadqVorj06YMTBvGH4IKwoBJKw1N30pVltYoUok+LJ+2 1rOvOEdJZS8f5qoJwCgDUGI4Us7tvjs//WW/inWUksg4A+cfwlQE/jcqGVjO vfP9Gtx7Jszb/FWzftlHFs5luvMcqMWAwjzwPggP3/1x/KQUp2Rqj9VLaX5n takLwFxU7/aPznZPz6s1jzMDWW+iskn0D/43K0VB2CO0sDQ8c2H4Y6p+ngc1 WVBb++qQ/EVlWjn+2QhH8YKJ5fnqC6WWpxsdXpPjEc/GD8c0GX9/a91gefgw Q7JMMgrHcYSZ1PiyEw5GQd8f010U3xJZAneNfG3abtUGjdc8uTzNtVh+N+fb hFWnyyUxMkVXhRk0fZAdNHrujq9A60597D45dKP3a3RzBc6IzyYj9vTwHd0c wXZI0L8G3yeB3y4nQT9eD4akOxmyOSx9iTEDQrd8UkyQEC/JgOo9fJG2C2qB cl2jXZw112yXGp/BKBx1hrG84ZPjk23wLoWWCzCQyggA2BLndp2gLKQvkv5E 2ODQHfj9j8Rx6NNg6CTFFMmzPu245Hmf9969HMi7vvXj4Yx+b3nX7rDje+TH AOsMg9Gkz17SyrnYgwKgbnoBvRuU7XVhZKPd6//ZyWMfKXn8KfH7f2Z0mJsM 0oeUOAAqewWNKPmf/eJvSjhCxQ1sNmjKQJT1f8Mk78i/AjJc+6nsne7+dLJ1 eoiCfxHRLUEkMfegalGEd6rSmwaHmR2AKQxiDRNrtL4zjK4r3wungeG0NrXm lOGctrslEOYyvaqQUKa0eBztpXTD20yz9JLHd8rNUlICN+ZgGYQXcXivycdw QjruEOjsAZ3ZPik8gRlo+gqoCzQNuh8ZgADPbvZ8ZnqBJYPU1P50dEF+oiLf JyeTy37QIQdBx4dxlbjQG3wS9UD+LzkkrFOG12viB/SSSX6fJAGrAx1Zc2Ps 65iEdAzgY687/EjPI0xLT6GbYUWvUsOWe+A5sJt16YVqIN2XPplEfnfSV1hd KE5+2z9/e3xxTraOfie/bZ2ebh2d//6a3r8WwlsfZJACCwajfgCwAQvwRmK8 lI3BONw93X4LlbZ+3D/YP/8dcdjbPz/aPTsje8enZIuApJ/vb18cbJ2Sk4vT k+Oz3Q2w975Pb/VlKJSTtUt5M8YtVrEb9KMM79+BoRH0sY9Xy4Fujf2ODzrm ERdUZ/RxNss4ZfshKBu9bg4o+ZpErGNMxLaPT37fP/oJ+rvfxS1/CrkZByA3 cTibvwppavDSHb7vAz/OYigG9feCLrS01w/DMefBj2EUY+nDLaLqmqauawYM m+TibAuaffGK4QsqswVDDkGvMwBM/NuOP2KtBF0q24kVjVE/hA2F8CIOQQ8m 4w7HmG4zTLwGlFVEXJmu6IVQDPc5XuJR5ZHf74ICTRK6IepjP5qgGbzit/jh dki8rvkSnRIQVAZdzgUGhbNig+t1ilbWeC+8ARkcAxrXbj8A0vpUGej9rAzG 2HcjNJI3PdaW0BeKx4Damco+MUB58chTfx/E3x+APYb66VZOyo1u0GFjHOdA qn4Ycz8Zh1djMKWgtFxb3OEEaHAxQkyUTPc3btPW0t2oW7INqy+zDa0l70UQ zP93HHwm7BPPrwNMb2h9yTe0JtjfcUPry7INrRR+cUPrdRh4dXazwjA9GDiA he/ChweTPnYv2guofKLwfbEI6Xcs+4nSPxu5A9fQecgRqtIa8BfXKBq0Cq5n fFlmByOeBJDvX43uRUL3zGh29+bYEMx6iDEZtxM7UQBTi7Ws+jtFgCX0cuzH k/EwLdkodpvGeMgaIyd9/Y71XrM+BFPdT8U560lAu7IGtfYVctAg/4tT+urm gqy9tXcNXrGxJAKxibOEPguRh0/Dsw6n9GE/SqnDKmbE+b0efZIwWIFC6Y/f C+Si2j8Edwg1P7UgmXnK3skMEJab9k15h6KNjiQM0CwJAxQrpR6oYW9qdi0P tGXoJnieunDeFH9kZOdNfWErsuQLmzcSxG0vBL+ii8M0WbttwNgCIwe5RUdr GA6HiT8PYx0Y0WEHyyTjBcEReQ2He8wvGTtCeWcE7t34Kj2qhksK4uk5yczS 6bj9Pq1KI0O97pCxE/hI1s5Pd3ed899PdhkgdCFWspOayY8X+wfnwArn/PTi aBv4CoXAJY2pRH0jNNkF9BzadfjrDiNwpGFsc1h7YKhg9Oj0xeqcOlIam6au wB/hKjL8BY+sChpH4HLB5G9tZ3f7wNmD3p7vHx8528c7u0nzKZk+8c/trbNd Zw8Q3DsiaymqB3sHx8enjc3qQoVSGY/7dZi8t/+OkTTPaFKX2Ssi2Sm7NbKW AnV2352cKkTgrfA1oQVnNXVZAerrtAOXMLy8T36CtXDBJdtMfn+R8b0b3Ppe LV4XtBjxXI8id3009qWabJVosqxips3tTWN6RioN5aktS9HU/G027FF2mw11 TtEnH/o3yJPXuYfXPfKGwMzcAW9y4js98FjAZVjDgo205GUY9gkSowPvr8Dv eUO6LvhDSNWsAHqk4wDmQkC5rAQH8evuNpMLhVx1GuTFNTjOEZT6devgYteB +dLOwa7z68XZ7hlZu+41SuvFtOLrMt3TNAMPzzPFTW2a0cRj0oSLrBM5BYoA 2uTbNwTEAL410reoZPQAtDzWYCEY0isrOWw/vwElca5wTug7AxxokrdJIwyj lRUqyRRp+ubG7b/3xw0pD3IVM2uB379kiY18XFzhOrw/hEkJzBNhtgf1M56g OMOUIPH+4/FH1GMUfxYzdWnYJll2d69ccEi5XqfkElFuZKU/UYJQaYoHI+Q8 Nab+eOhCK2vbWwcH0xpNBSw119jXcKQq+Mn1TmHP9AajNzUrg1GyuP/pm2SR /wzG2xMK1Dk6PjljpV6nr2m/y1iDRcV0AW4U4HEC4EuGJjcdKVRBMoQ80+uh A/bz/WTk4GF3nkfZmKJ0dHFw0HgtNybbFNZBeDWHR1Cow01Ie7PZ2jTqhaRs 1VBsVbz1HR9k+9tWXhCYGK/3w5uNDuUaCKcDT5wks6KxibGATg+H7A6M2ev/ 3eleKSza5IVAcDcOx5GCoEYwsxee8aClDzPAEYFKMCXtYmSDcQFm0RtsbMRo 2LpqIjnIaQAkH3vkpwkMzxgsIt+Pr/j3HyIwDRuez6dRKyen1MStY+BoEPxJ J6WvdNOy26VvDc1Q6ZUUL6gQr9PlP0Scrzk5/geYrTojQHobiIABDnD4dn/a PXW2z84JhoIw0gXGwYNJc4Qza6rTGwwmlcKg+xEhdlxMXAa9C/70UVDGdMAE wOc8XjCMMP45jGksBusntR0MVWBYxemj9QqH/Y90xsr7GJH4JqS0jXvIBBqX WsFA1u/O6e5ehMIL5PpIsPc4y5XpRhKAGLjv/YhiBDNiGneACRuNjIz6bifB Kx3OOp0R4jZwP176DjUDYbeLy2Rx6FDiOGO/CzgeBO/9myCi9YHJKYc1Qv4n 7A3JjnsNU8qt4RWGisj3nnvtb7j01w/DcWe9A382rjobHZefAQV9GLnY8sh1 onDguBHODoIYL5iis3Noc3cYTcY8/scENTmtiPo3sVQ92mpbaWviQSe6lrt7 PvoILiObaFO+AFEdFJToxh05nY4XOKOgA61jWHv1bGcV46JUqsZgYWOEgBG9 dMk6J/LGOsyHyQ6YD/e9CzrTI6fuv92rcARcB6LQ5xvj5NEP7sDbgC4k4v+C sPA1EKqzSbY6GEkil+644/fDoYv9cEliCWG0SDJON8S6wpIjKgHwfxx4mGWf EFVkJNTyws4rkKHwvb8R+7dBCaMZXofwipzFExgyyPeDcfSDOwIxZBgkTOW9 8NzxTTBsb4B7vHV26BxfnJ9cnDtbB/s/He3ugI98eHh8BJ3Z8jz5aU9aywQX oNUU4+8ti27k1QVDx1sbRxbYTN7oOjBqMNoAgcIJIv0R0tkwSPWE2gEcOaG6 47BokcPCbVAgdjvv8aocFIu+H9MgtcBdHUz8ylt3HPVc8j8w4EaBu/J9j/7e +Df7XcZSviJBN4psDDzCz5x3un3vtuu8t8F5TR/gT6ybPIniQpEozv2k41Ty YxBe5yqDnaJH+2Ylkic5GPBQgMGi6yvC7wIM4TIPoVtXw1y15FDsrIRwTHb+ YQHjUTTqFKrio+xXB9BkBcRq6dMcfPo09wDGs7RYrj68yBWTAAsHTGwxSi/o 3/JkhKouSsitbTmR2+s6mkI6g1F35ARg8WHek/2MIp8ikPyGuq307aRQekKL Z7+wLFZGuxcB3vjZC7A1/PYh/QYGcezfWiZ4CMEtm3FHwLS08fSplzwVC0bF R17yCOsijiDxnRtsjMYWYQjt6knPhScMCP72hBK0/exhVigKvCkwHi8hVCoW 8tJCBETcCwxHS5CH3xH+ptWTH86f/m1M3/XoO/z2gX2b0K/iY/yO6TwUwoTC j5NHtDh0Mf1deJ1/mwEwnB7MDnARMennhPctfZ6rkXvDOh/JAVHRkMIiU48Z IGSmZTpRr++lzMUfSID03RhIHX0YxwKXk58Jb5LfTJrxl5cvnPIo+RGksgwP 2A41ENEciNuuzr4kr2/l9bz0xZSe850ddOCsY9sDtgEkPZdatDVB4XDt1MIk lXLHsctq5gsUq1+Gca+yer5AsTq91qyyfr4E0OoI5q4lB3VTihWpgv3HwarY NDxjl6px8tO278XSTnOMxi1lWI/C0TSxYB5UIADWqEODS3AdO70U0GgS9USo 17445gQ42OZHKv7I2dnPlxr4g6ma7BkWFQHAoCtS/hqLpQ/A1b3nQW6a9Li3 SC7wg8FtXyLpUCGS6xZUYC+jXjiO55DRe8ZPPKO+nryUeAYMVsoi9hODQxwW zXDEBEhKlKGXez6BSZYEODv9dpOcwbQUq5J0YQkB8yZw4sPXYhLQydLMvdGP bTormjv+NMd+3Lg3GMnNY+7dVK3UIcxXwMfFsuAol7aQvZvTLLDeZd4m+53A FJ7jz4dTzWTTs2QwSl9lBEh2WhYJkz6fAhBMwybJcbUlbQZTbbLS+UdeOQBv qjS7hF3S6dzl7CmA6WuvWZu5a4a5rZnB+DItZJRHvDIMP7CveOKmyICAPecv sq8f0ppe9u2DSIUgJVUKw8tgsMe8OD28hL3IvlJKpp3yhLKjKGN6mROVmZcH MLzTd5mIw0X5LTjiWDN92VsBRsltgXN4RqwjYqOy+TJrarrxpOBDTE97ZC1L zncujpK4zuHxr7vO8cn5/uHWAUd84HbGIUOTzgci35kM3X5wNcQFvPCahaYG bp+Xp/Gty36Zl50EtmbC2h2y9CkYsSgWA2frcGdv65CHy9YChMCD45xvFMIg iChERkaWIgwDIM8S9gkUmoy8V/SDhlmxhbQXhIGiGUQsxPgKM2GhIyNwbgOa KIV8YkOp2KN741DSyDQ/eIHtkwv4/8ShK837R2ci5tjLXJhxh+VyCFV3dve2 Lg7OnVyxNUmBo63D3QR4vvBoHHb8KAIWoOfBi5ycHm/vnp0dn2aMW6mQCfRd RMgsWooLap3RJO/M0M0qCCbfLia9TdOR9pALE/rTZOT7o16I+YdInAKRp6SW h3KhYxFPOsda6+u4QrCOPQuzI/dzRCkX/dSSdsIolmnN2qCC6fDu/O3B8ZHz s11RCpVjAupFJyNs9o6TFIdtXGUPQAVu2bfJcBzCxAmmDX1/mE79Me7G6xre MLxxXPbDAwKmM6CkoSjAlHCnG4SjFACwZxDGvvPLPr5jZYNh7F/5Y2dnj5bH JqKsgjuOA7cPBvYKWhnBbB5vP+e9ZVtuQb3ZXqUohrmeQpKqbqeD4RF6IM0k vgpBaR1cf2WV3THU4KlVXej4R5p6kEbQEmNU1T6+RykDwYnY5DnrNxKgi8tv o4wgwbADIyX73Q0nY+ffE/QQg0EQZ23i1U+Tvp/VuuRhGPAebzu9K8265MyD oYEt0kU0gYRL9CsPrF1iJvM6KVk5ENWLCh8qk6BDdL+AE6dyiFOJyUiiyLnm iD/EpW1QvrxKgkV1IwEas9hBFE18By1xuZnISrvevycwD+SKUmrVFrW9ZUoK JGOtofmp2FGyjjtV6Gp2MZW167sxLn11++7VRgoKKrAdJg36It1PMoxJAUhW h6XKQk26lagxlTSba6lsMGHY8GQ2IYU2uSnE3Cqfrk5bv60fD3MbYwgbBAp7 ZxoVk9QiROm5IGDrWPKpQniSrEJooqWSTFplTTArK+90YTMV5vUhACwKrAQb 8SYV6hJyCltSyrHA91HQicpW6LAePJxgLjffuDSkDbIhiTIa3MXLgULSfVx0 rl5YMETALOhZCjjrlohxuiyI+oLp/5fkt6AfhbjwexlebtzQHz+4ncFGOL6a WhvEJiOXf9CFdVxddYfxKAxZvApX6c7eByOCVoicXfx4uvtTtCHJwMgG2TlS uYqV0hwMU9tU6yVl6lZb0e30XMvgX4bZtFp/2Nb6i/UXNLcExnZq798g3/EB TQx2WFp59GY1EwQyGNDxEb4JF5ER4e4xeoUqz/MRks+JcF0Ynma0Qk8HYpH2 R+0HJtpDHy6D2OndwJs3H/0o7V/gJr2j+ys5IfmS7uMTkrhPj6hTfapJYOnC uq62FQ23tHLZXVn5D0wOPdzdBCNmmSzGl2NDskfpEmbt/X54A2MZDqu8bh+T AtYHhk5rZoTaoO9pZtu71f/8hA6vA3T7sgoWjuL8jl9w+vldB7wh/fO7YQia 6X5+BzDWLfPzu/f253cwlPrjcPj5HZvr4uPkqstbfuHpa5Zu947/TBp6w8Hn Cr3ghfxOLySrF0NufgEjmKngxjK69SVzz9/8ZwJOIVlZmiAUba4S7b+/43c9 M4C8SUIRIgwfwtAh723CkSEJLiRFhYNifbsFR0HLdduP3A7LgUi5l2ZGPlXu JYPN53dpBsvXxtJ0tM9ydO7MZelo09Sait7UhWSY5JFwshv+e/2afw0szv3P JGhl1pT9o2z9z0/cYR+GwzSz7QuyNzueIUFw/cXnFEUEJJ6lkTInKZx7m3YI /723ARAnD3zj4SsUuIZQSgD53s49Lzn4Tm82kRZWjjxNGx9ZJeTJ2/Ovkyqt dhOHVi0z9FzE2Nf/IMc/868AgUr86iqIC0jw51SGP2dS/DmTY/jOFeEz14vP hOtJQwqdfklGfBuPVLDVVmbCavUrVbbPgrrdb3en/U0xxXSOpN/pagvk/QLN dCCclnqd1BNBoU0zRTeLj7aOftplL+gRua9ekOMk5ZRtdTTIwP2IY8Nw0u+z 9HGaGJ3sADs+cc62DnfJmtrgjsp335H0oZak32cPHdyM7WDWNFnTq18bDZZY zaWCIpdut1k+cumxxEkeMGbR0xRXUG/Pv01TfzHdFoxzwNM+MduyG4yjGEOK N34KBmHTbdte0O36uPmILpxGdEt65A58Dg235NSlLNuHg4cXdaKYpS7zrTTH J7uA8A7dkKMqRGsoTDew4lQBDQs0BM/y82eRaUvh2rRy5HOK51APWcWcghj1 9tZYuqbAH+GUW8z6/zaJGf4JNmJE1vx+zHOcG4mBDbxb8oZQstPToy6DIZY8 Obg44/sgoIRCspoKURkV8BRYcQ+cSdZSgcXDEIIrOlFQwGZhwhIFQ9O24Qvj Dx7CSs84ZLwHDw15z7qJ75CVjNXQ1CuQBtw3QRdcnIuj/XNWkMbNG41s51Ny RzMniXBG7pMkCYqWg2IsfM0hMy1tWWb+HFP/YqWFpAzvlbJU4RhtPNqg3yed nt95H4FT2enA/Mz3QOl/RALwdYghX0qiB6vzLTxRnFgG+KDb73A3joRsXofR LLz8N911oKRbjKg8HO4fJVuU6O+d48Ot/SOy5rlMMpTUFsxZnEon5/3uu63t c2dn/9dkbxBWPdv/v7tcEFkfU8OUCfaUyPKSXGCnUNcA9Z2dU94Mx5yXyaSC yTdjhuDnPSdmlIr9giT5/0V7v9hjewIA --4266313884-669419637-1321439435=:26465 Content-Type: APPLICATION/octet-stream; name=bsd.cpu.mk.amdfam10.gz Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=bsd.cpu.mk.amdfam10.gz H4sICCyZwk4AA2JzZC5jcHUubWsuYW1kZmFtMTAA3VTLTsJAFF3LV1yqq9KW Tt+QsCCEBBcaYnRhYmKGdipN6SNtiSTqvztTWm2xCAosdEImM8x9nHPuveV5 HtI5Tkg38Luz1JHseCkFvhQl3tOZIiMksp8OyOhrSl82Jblc0JEVWW6JotgU oOZr9tUedf/iy9cXu4PWE3QN8isLza4G0JPYAhhN727vp2MYQEzCzFsGYhCs 6P8SAFl4Lly8FBZvMBgA5+mWwTW5tTrbXHDguDhAMgevr5tvM5zYZBGFmKP+ lZgJSe0oy7bjiOKMJFEopilRmwLjbE7DGtqnwQMNlq8NS99a29RJlQCa5ESq JSCtEBTgPLcmoU0gcgGzKOASnC0TItHnnENO4Go4mlxejx+pwfBmNCkEVZmg bcbzUJY0UyUFZbF+FldxcQLfBNUJo2dg9mxT2Aa04uAb4OvAyguexjaKa6f8 32H6IZwdSFjfIk2multl555Q9z1btr03QTwLGD8N76t8+ziN/59bonE0LSQg yyxHs56sgj90PDc/FkwaW4R2AcN8lNlsMKh8eOo4fatSksMEb0y7PeN6zCxd QD21HLNTavjLOfsQqD5WxxqaP1Krdxe5RIxnCAAA --4266313884-669419637-1321439435=:26465-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 06:00:29 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24E0F1065686 for ; Wed, 16 Nov 2011 06:00:29 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AAA368FC16 for ; Wed, 16 Nov 2011 06:00:19 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so174408bkb.13 for ; Tue, 15 Nov 2011 22:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=Ho99Kqi5Ok4wxKL2BfgnAnSmG0jCizyXYNLKPWSlllk=; b=Z23nnwuJtiltGskSYlCBf2U66Knjuv3fdpAEYhHO/sZ5A4Nem5YJ6HI+cqZuM0svPV kaQjzjGM6iY+ECYrenHfYmZMZhem7TlOjUPvOZr84bJh4WZiIYNTaBrZnux2vE5fYreu U+ccOMv5DiJsPmH5IIfd2pXwDD24dWFnYNqK4= Received: by 10.204.130.85 with SMTP id r21mr26942649bks.38.1321423218273; Tue, 15 Nov 2011 22:00:18 -0800 (PST) Received: from imax.localnet (76-55-133-95.pool.ukrtel.net. [95.133.55.76]) by mx.google.com with ESMTPS id a10sm4411222fam.20.2011.11.15.22.00.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Nov 2011 22:00:16 -0800 (PST) From: Maxim Ignatenko To: mdf@freebsd.org Date: Wed, 16 Nov 2011 08:00:00 +0200 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.7.3; i386; ; ) References: <201111152218.41031.gelraen.ua@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201111160800.02270.gelraen.ua@gmail.com> X-Mailman-Approved-At: Wed, 16 Nov 2011 12:07:05 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Communication between kernel and userspace via local socket 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, 16 Nov 2011 06:00:29 -0000 On =D0=B2=D1=82, 15 =D0=BB=D0=B8=D1=81 2011 23:17:41 mdf@freebsd.org wrote: > On Tue, Nov 15, 2011 at 12:18 PM, Maxim Ignatenko = =20 wrote: > > frHi, > >=20 > > I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch > > and looking for most convenient way to establish communication between > > userspace processes and kernel part. Communication pattern best fits to > > listening PF_LOCAL socket opened from kernel and userspace processes > > connecting to it. Clients should be able to send requests and receive > > responses from kernel (to retrieve list of loaded modules, active > > ruleset, add or remove rules, ...) and vice versa: kernel should be able > > to send request to userspace process and receive response (I'm planning > > to add interactive features like in most firewalls for windows(r)). > >=20 > > First part can be implemented via ioctl, but it should be called not on= ly > > by processes with euid =3D=3D 0, so supplied pointer to receive buffer > > cannot be trusted (is there any mechanism to check memory allocation?) > > and any unprivileged user can instruct kernel to write some trash at > > arbitrary address (for example, VM just rebooted ungracefully when I > > supplied (void*)123 as pointer to destination buffer). >=20 > Were you using copyout(9)? I think FreeBSD's memory isolation between > processes is pretty decent. I would be very surprised if copyout to an > invalid address did something other than return EFAULT. At least the > amd64 implementation of copyout(9) will also explicitly check that the > address is a user address, so that you can't corrupt kernel memory > with a rogue pointer from user-space. >=20 Yep. I've used this https://gitorious.org/acpi_call-freebsd/acpi_call- freebsd/blobs/master/acpi_call.c#line49 for tests.=20 From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 09:48:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08F7106564A for ; Wed, 16 Nov 2011 09:48:16 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 728AF8FC0A for ; Wed, 16 Nov 2011 09:48:15 +0000 (UTC) Received: by vcbfo14 with SMTP id fo14so420213vcb.13 for ; Wed, 16 Nov 2011 01:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=DVXpANN7TURhbvOsCW2+ti3pRvoQdSl/Z711a8XTkac=; b=Xx3QrJQVAw6RXMCVE88Dx76o+bPAXCDrlDWK9i4vlOqe+eT3w85k4p1wtZtW8VhTYi T5WHArJV7DCmap7V2ErgBP1gte9QJBseq3WcxuAe53X7HlZJHbHAmiZFLfduVDSyikrN no5GxTpJCd4s3jy7iw64kOLlccz6m+q2LOMPI= Received: by 10.52.183.36 with SMTP id ej4mr50681111vdc.26.1321436894081; Wed, 16 Nov 2011 01:48:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.115.130 with HTTP; Wed, 16 Nov 2011 01:47:53 -0800 (PST) In-Reply-To: <20111116085508.GF36205@hoeg.nl> References: <201111152218.41031.gelraen.ua@gmail.com> <20111116085508.GF36205@hoeg.nl> From: Maxim Ignatenko Date: Wed, 16 Nov 2011 11:47:53 +0200 Message-ID: To: Ed Schouten Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 16 Nov 2011 12:07:20 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: Communication between kernel and userspace via local socket 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, 16 Nov 2011 09:48:17 -0000 On 16 November 2011 10:55, Ed Schouten wrote: > * Maxim Ignatenko , 20111115 21:18: >> I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and >> looking for most convenient way to establish communication between userspace >> processes and kernel part. Communication pattern best fits to listening >> PF_LOCAL socket opened from kernel and userspace processes connecting to it. > > What's wrong with a character device? > With character device I'll need to manually maintain "per-connection" buffers, this will bloat the code. From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 12:26:12 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AC841065672 for ; Wed, 16 Nov 2011 12:26:12 +0000 (UTC) (envelope-from slonoman2011@yandex.ru) Received: from forward11.mail.yandex.net (forward11.mail.yandex.net [IPv6:2a02:6b8:0:801::1]) by mx1.freebsd.org (Postfix) with ESMTP id AD39C8FC0C for ; Wed, 16 Nov 2011 12:26:11 +0000 (UTC) Received: from web143.yandex.ru (web143.yandex.ru [95.108.130.11]) by forward11.mail.yandex.net (Yandex) with ESMTP id 29D2CE84DC3 for ; Wed, 16 Nov 2011 16:26:10 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321446370; bh=LWY7FTUmLzZ99RrHqmHyIA/eYnuOtY30lbneTSEwqlo=; h=From:To:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=w4DwSPHU0rBxFWIahXvQFfqT9Hp61b6/Qf/DnCLY7QyiIZilJe38GWkKcBSM3W0H1 EpcKvyDirhLLHhpc/ToZ5g3FCfj25GtCFXn94Jb6zeV1GBVHMlAk4XCYBn36AMk36W HXTz8vs9nMiUG+aw88q5NlSaEXT0bQsnL2EVFor0= Received: from localhost (localhost.localdomain [127.0.0.1]) by web143.yandex.ru (Yandex) with ESMTP id 0F7FF3980030 for ; Wed, 16 Nov 2011 16:26:10 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321446370; bh=LWY7FTUmLzZ99RrHqmHyIA/eYnuOtY30lbneTSEwqlo=; h=From:To:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=w4DwSPHU0rBxFWIahXvQFfqT9Hp61b6/Qf/DnCLY7QyiIZilJe38GWkKcBSM3W0H1 EpcKvyDirhLLHhpc/ToZ5g3FCfj25GtCFXn94Jb6zeV1GBVHMlAk4XCYBn36AMk36W HXTz8vs9nMiUG+aw88q5NlSaEXT0bQsnL2EVFor0= X-Yandex-Spam: 1 Received: from nat140-249-205-109.tvoe.tv (nat140-249-205-109.tvoe.tv [109.205.249.140]) by web143.yandex.ru with HTTP; Wed, 16 Nov 2011 16:26:09 +0400 From: Slono Slono To: freebsd-hackers@freebsd.org In-Reply-To: References: MIME-Version: 1.0 Message-Id: <37971321446369@web143.yandex.ru> Date: Wed, 16 Nov 2011 16:26:09 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Wed, 16 Nov 2011 12:31:35 +0000 Subject: Re: The zombie has involved into /dev/null 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, 16 Nov 2011 12:26:12 -0000 On Wednesday 16 November 2011 14:35:04 Ivan Voras wrote: > So, if I understand you correctly, you are reporting a bug in which a > jailed process is holding (the jailed instance of) /dev/null open and > "umount -f" doesn't work on the jailed /dev ? Hello, Yes, correct. > > On 14/11/2011 23:52, Slono Slono wrote: > > On one of servers where installed cacti in jail there is strange enough > > situation. Sometimes processes poller.php haven't time to successful > > complete until to beginning of the following session (absence of lock is > > other problem - its ok) therefore processes breed yet won't begin them > > kill. During such moments appear zombie processes. However, these zombie > > show that keep devfs the device. Possibly because are started as > > > > php /poller.php 2>/dev/null 2>&1 > > > > Sending of any signals (SIGCHILD too) changes nothing. Strange that with > > -f (force) optons through a umount command is impossible to unmount > > devfs with which worked as the zombie. > > > > ps axf shows: > > .. > > > > 99551 ?? DsJ 0:00.12 /usr/local/bin/php > > /usr/local/share/cacti/poller.php 99554 ?? ZJ 0:00.02 > > . > > > > lsof -p 99551 > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > > php 99551 root cwd VBAD > > (revoked) php 99551 root rtd VDIR 225,1035534442 3 > > 678909 /usr/jails/jails/mon php 99551 root jld VDIR > > 225,1035534442 3 678909 /usr/jails/jails/mon php 99551 root > > txt VREG 225,1035534442 3261754 1620922 > > /usr/jails/jails-data/mon-data/usr/local/bin/php php 99551 root txt > > VREG 225,1035534442 246776 626780 > > /usr/jails/jails-data/mon-data/libexec/ld-elf.so.1 php 99551 root > > txt VREG 225,1035534442 33600 626862 > > /usr/jails/jails-data/mon-data/lib/libcrypt.so.5 php 99551 root txt > > VREG 225,1035534442 377814 1267501 > > /usr/jails/jails-data/mon-data/usr/local/lib/libpcre.so.0 php 99551 > > root txt VREG 225,1035534442 150656 626861 > > /usr/jails/jails-data/mon-data/lib/libm.so.5 php 99551 root txt > > VREG 225,1035534442 1495740 649173 > > /usr/jails/jails-data/mon-data/usr/local/lib/libxml2.so.5 php 99551 > > root txt VREG 225,1035534442 84848 626828 > > /usr/jails/jails-data/mon-data/lib/libz.so.5 php 99551 root txt > > VREG 225,1035534442 1074175 649584 > > /usr/jails/jails-data/mon-data/usr/local/lib/libiconv.so.3 php 99551 > > root txt VREG 225,1035534442 1270640 626857 > > /usr/jails/jails-data/mon-data/lib/libc.so.7 php 99551 root txt > > VREG 225,1035534442 74189 636259 > > /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/session.so php > > 99551 root txt VREG 225,1035534442 63195 637380 > > /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/xml.so php > > 99551 root txt VREG 225,1035534442 40650 638507 > > /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/snmp.so php > > 99551 root txt VREG 225,1035534442 337128 665903 > > /usr/jails/jails-data/mon-data/usr/lib/libssl.so.6 php 99551 root > > txt VREG 225,1035534442 730269 8050234 > > /usr/jails/jails-data/mon-data/usr/local/lib/libnetsnmp.so.30 php > > 99551 root txt VREG 225,1035534442 35264 626850 > > /usr/jails/jails-data/mon-data/lib/libkvm.so.5 php 99551 root txt > > VREG 225,1035534442 19720 626858 > > /usr/jails/jails-data/mon-data/lib/libdevstat.so.7 php 99551 root > > txt VREG 225,1035534442 1693344 626824 > > /usr/jails/jails-data/mon-data/lib/libcrypto.so.6 php 99551 root > > txt VREG 225,1035534442 105904 666224 > > /usr/jails/jails-data/mon-data/usr/lib/libelf.so.1 php 99551 root > > txt VREG 225,1035534442 61034 635955 > > /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/mysql.so php > > 99551 root txt VREG 225,1035534442 54114 637132 > > /usr/jails/jails-data/mon-data/usr/local/lib/php/20090626/sockets.so php > > 99551 root 0u PIPE 0xfffffe07514ab5b0 16384 > > ->0xfffffe07514ab708 php 99551 root 1w VCHR 0,27 > > 0t0 27 /usr/jails/jails/mon/dev (devfs) (like character special > > /dev/null) php 99551 root 2w VCHR 0,27 0t0 > > 27 /usr/jails/jails/mon/dev (devfs) (like character special /dev/null) > > php 99551 root 3u unix 0xfffffe074ad832a8 0t0 > > ->(none) php 99551 root 5u PIPE 0xfffffe043c62fcb8 0 > > ->0xfffffe043c62fb60 > > > > mount -t devfs |grep mon > > devfs on /usr/jails/jails/mon/dev (devfs, local, multilabel) > > > > umount -f /usr/jails/jails/mon/dev > > umount: unmount of /usr/jails/jails/mon/dev failed: Device busy > > > > However apparently devfs is unmount when executed jail stop: > > > > ls -la /usr/jails/jails/mon/dev > > total 5 > > drwxr-xr-x 2 root wheel 2 Nov 14 22:36 . > > drwxr-xr-x 3 root wheel 3 Nov 14 22:36 .. > > > > As can be that zombie blocks devfs or that in system there is an > > information on active mount when the file system isn't present > > > > PS: FreeBSD 9.0-RC2 amd64 > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to > > "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 13:03:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 869021065675; Wed, 16 Nov 2011 13:03:16 +0000 (UTC) Date: Wed, 16 Nov 2011 13:03:16 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20111116130316.GA38494@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116101422.GA20453@freebsd.org> <20111116103144.GA22928@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20111116103144.GA22928@freebsd.org> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 13:03:16 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed Nov 16 11, Alexander Best wrote: > On Wed Nov 16 11, Alexander Best wrote: > > On Tue Nov 15 11, Brandon Gooch wrote: > > > On Nov 15, 2011 2:25 PM, "Alexander Best" wrote: > > > > > > > > hi there, > > > > > > > > one of the things i'm missing is an easy way to determine, whether a > > > stream or > > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > > > performing so much stuff just to find out if this is the case, and they > > > still > > > > are doing a very poor job. > > > > > > > > dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the > > > result: > > > > > > > > `dd if=/dev/zero bs=1m count=1 skip=100000`: > > > > > > > > on freebsd: > > > > 57,41 real 0,05 user 43,21 sys > > > > > > > > on openbsd: > > > > 0,88 real 0,00 user 0,07 sys > > > > > > > > on freebsd dd(1) is very easy fixable (1 line diff). the point however is: > > > > > > > > there doesn't seem to exist a unified way of checking seekable == TRUE. so > > > > every userspace application seems to do it differently and most of them > > > (dd(1) > > > > and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only > > > regular > > > > files are seekable. this means that hd(1) fired at /dev/ada* with a high > > > skip > > > > value takes ages! dd(1) is a bit smarter in this case, but still not > > > correct. > > > > > > > > idealy there would be something like stat.st_mode (see stat(2)) where one > > > > could simply do a S_ISSEEK(m). so far the best and easiest solution i've > > > seen > > > > is: > > > > > > > > fd = open(argv[1], O_RDONLY); > > > > if (fd == -1) > > > > exit(1); > > > > if (lseek(fd, 0, SEEK_CUR) != -1) > > > > printf ("%d is seekable.\n", fd); > > > > else > > > > printf ("%d is not seekable.\n", fd); > > > > > > > > seeing an application iterate through a stream or fd via getchar(), > > > although > > > > a simple seek() would work is very frustrating. i think what would be > > > needed > > > > is a simple function or macro that userspace applications can make use of. > > > > maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd, > > > > solaris or plan9? > > > > > > > > cheers. > > > > alex > > > > > > > > references: > > > > [1] > > > http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes > > > > [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485 > > > > [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 > > > > > > So, according to APUE 2nd Edition, seek should be supported on anything > > > that's not a pipe, FIFO, or socket. In fact, the "test for seekability" > > > you've provided above closely resembles the example given in that text. > > > > if this really is the case, things could even be easier in a freebsd specific > > manor than the code above: > > > > !S_ISFIFO(m) && !S_ISSOCK(m) > > > > this means it would be trivial to write a new macro S_ISSEEK which would test > > stat.st_mode against the according bits. > > here's a patch, which also fixes a comment. hmmm...the patch doesn't seem to work for directories and symbolic links unfortunately. does anybody spot the problem? i've attached two testing applications. mode.c will do the tests via the S_IS* macros and requires the patch i've posted beforehand to stat.h. the other application is seekable.c, which will use lseek(2) to test, whether a file argument is seekable or not. basically both applications should report the same! cheers. > > cheers. > alex > > > > > cheers. > > alex > > > > > > > > Need to think about this more before commenting further... > > > > > > -Brandon > diff --git a/sys/sys/stat.h b/sys/sys/stat.h > index 1b03bd2..ab5ae44 100644 > --- a/sys/sys/stat.h > +++ b/sys/sys/stat.h > @@ -238,10 +238,11 @@ struct nstat { > #define S_ISCHR(m) (((m) & 0170000) == 0020000) /* char special */ > #define S_ISBLK(m) (((m) & 0170000) == 0060000) /* block special */ > #define S_ISREG(m) (((m) & 0170000) == 0100000) /* regular file */ > -#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* fifo or socket */ > +#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* pipe or fifo */ > #if __POSIX_VISIBLE >= 200112 > #define S_ISLNK(m) (((m) & 0170000) == 0120000) /* symbolic link */ > #define S_ISSOCK(m) (((m) & 0170000) == 0140000) /* socket */ > +#define S_ISSEEK(m) (((m) & 0150000) == 0) /* seekable file */ > #endif > #if __BSD_VISIBLE > #define S_ISWHT(m) (((m) & 0170000) == 0160000) /* whiteout */ --OgqxwSJOaUobr8KG-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 13:14:28 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 5941E1065672; Wed, 16 Nov 2011 13:14:28 +0000 (UTC) Date: Wed, 16 Nov 2011 13:14:28 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20111116131428.GA40723@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111116102239.GA2687@britannica.bec.de> Cc: Joerg Sonnenberger Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 13:14:28 -0000 On Wed Nov 16 11, Joerg Sonnenberger wrote: > On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote: > > one of the things i'm missing is an easy way to determine, whether a stream or > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > performing so much stuff just to find out if this is the case, and they still > > are doing a very poor job. > > Isn't the primary issue that FreeBSD doesn't properly report errors for > lseek(2)? I think you should start from that and not hack around the > fallout... what do you mean? lseek(2) returns -1, when the file descriptor is not seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...) and it always returned the correct result. cheers. alex > > Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 13:17:02 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 49E901065675; Wed, 16 Nov 2011 13:17:02 +0000 (UTC) Date: Wed, 16 Nov 2011 13:17:02 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20111116131702.GA42162@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116101422.GA20453@freebsd.org> <20111116103144.GA22928@freebsd.org> <20111116130316.GA38494@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <20111116130316.GA38494@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 13:17:02 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed Nov 16 11, Alexander Best wrote: > On Wed Nov 16 11, Alexander Best wrote: > > On Wed Nov 16 11, Alexander Best wrote: > > > On Tue Nov 15 11, Brandon Gooch wrote: > > > > On Nov 15, 2011 2:25 PM, "Alexander Best" wrote: > > > > > > > > > > hi there, > > > > > > > > > > one of the things i'm missing is an easy way to determine, whether a > > > > stream or > > > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > > > > performing so much stuff just to find out if this is the case, and they > > > > still > > > > > are doing a very poor job. > > > > > > > > > > dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the > > > > result: > > > > > > > > > > `dd if=/dev/zero bs=1m count=1 skip=100000`: > > > > > > > > > > on freebsd: > > > > > 57,41 real 0,05 user 43,21 sys > > > > > > > > > > on openbsd: > > > > > 0,88 real 0,00 user 0,07 sys > > > > > > > > > > on freebsd dd(1) is very easy fixable (1 line diff). the point however is: > > > > > > > > > > there doesn't seem to exist a unified way of checking seekable == TRUE. so > > > > > every userspace application seems to do it differently and most of them > > > > (dd(1) > > > > > and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only > > > > regular > > > > > files are seekable. this means that hd(1) fired at /dev/ada* with a high > > > > skip > > > > > value takes ages! dd(1) is a bit smarter in this case, but still not > > > > correct. > > > > > > > > > > idealy there would be something like stat.st_mode (see stat(2)) where one > > > > > could simply do a S_ISSEEK(m). so far the best and easiest solution i've > > > > seen > > > > > is: > > > > > > > > > > fd = open(argv[1], O_RDONLY); > > > > > if (fd == -1) > > > > > exit(1); > > > > > if (lseek(fd, 0, SEEK_CUR) != -1) > > > > > printf ("%d is seekable.\n", fd); > > > > > else > > > > > printf ("%d is not seekable.\n", fd); > > > > > > > > > > seeing an application iterate through a stream or fd via getchar(), > > > > although > > > > > a simple seek() would work is very frustrating. i think what would be > > > > needed > > > > > is a simple function or macro that userspace applications can make use of. > > > > > maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd, > > > > > solaris or plan9? > > > > > > > > > > cheers. > > > > > alex > > > > > > > > > > references: > > > > > [1] > > > > http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes > > > > > [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485 > > > > > [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 > > > > > > > > So, according to APUE 2nd Edition, seek should be supported on anything > > > > that's not a pipe, FIFO, or socket. In fact, the "test for seekability" > > > > you've provided above closely resembles the example given in that text. > > > > > > if this really is the case, things could even be easier in a freebsd specific > > > manor than the code above: > > > > > > !S_ISFIFO(m) && !S_ISSOCK(m) > > > > > > this means it would be trivial to write a new macro S_ISSEEK which would test > > > stat.st_mode against the according bits. > > > > here's a patch, which also fixes a comment. > > hmmm...the patch doesn't seem to work for directories and symbolic links > unfortunately. does anybody spot the problem? > > i've attached two testing applications. mode.c will do the tests via the S_IS* > macros and requires the patch i've posted beforehand to stat.h. the other > application is seekable.c, which will use lseek(2) to test, whether a file > argument is seekable or not. basically both applications should report the > same! grrrr...the attachments got scrubbed! > > cheers. > > > > > cheers. > > alex > > > > > > > > cheers. > > > alex > > > > > > > > > > > Need to think about this more before commenting further... > > > > > > > > -Brandon > > > diff --git a/sys/sys/stat.h b/sys/sys/stat.h > > index 1b03bd2..ab5ae44 100644 > > --- a/sys/sys/stat.h > > +++ b/sys/sys/stat.h > > @@ -238,10 +238,11 @@ struct nstat { > > #define S_ISCHR(m) (((m) & 0170000) == 0020000) /* char special */ > > #define S_ISBLK(m) (((m) & 0170000) == 0060000) /* block special */ > > #define S_ISREG(m) (((m) & 0170000) == 0100000) /* regular file */ > > -#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* fifo or socket */ > > +#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* pipe or fifo */ > > #if __POSIX_VISIBLE >= 200112 > > #define S_ISLNK(m) (((m) & 0170000) == 0120000) /* symbolic link */ > > #define S_ISSOCK(m) (((m) & 0170000) == 0140000) /* socket */ > > +#define S_ISSEEK(m) (((m) & 0150000) == 0) /* seekable file */ > > #endif > > #if __BSD_VISIBLE > > #define S_ISWHT(m) (((m) & 0170000) == 0160000) /* whiteout */ > --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mode.c.txt" #include #include #include #include #include int main(int argc, char **argv) { int m; int bflag, iscflag, isdflag, isfflag, islflag, isregflag, issflag, isseflag; int iswflag; bflag = iscflag = isdflag = isfflag = islflag = isregflag = isseflag = 0; issflag = iswflag = 0; if (argc != 2) { fprintf(stderr, "usage: mode filename\n"); exit(1); } struct stat *test_stat; test_stat = malloc(sizeof(test_stat)); m = lstat(argv[1], test_stat); if (m == -1) err(1, "lstat failed"); if(S_ISBLK(test_stat->st_mode)) bflag = 1; if(S_ISCHR(test_stat->st_mode)) iscflag = 1; if(S_ISDIR(test_stat->st_mode)) isdflag = 1; if(S_ISFIFO(test_stat->st_mode)) isfflag = 1; if(S_ISLNK(test_stat->st_mode)) islflag = 1; if(S_ISREG(test_stat->st_mode)) isregflag = 1; if(S_ISSOCK(test_stat->st_mode)) issflag = 1; if(S_ISWHT(test_stat->st_mode)) iswflag = 1; if(S_ISSEEK(test_stat->st_mode)) isseflag = 1; printf("Block special file: %d\n" "Character special file: %d\n" "Directory: %d\n" "Pipe or FIFO special file: %d\n" "Symbolic link: %d\n" "Regular file: %d\n" "Socket: %d\n" "Whiteout: %d\n" "Seekable: %d\n" "st_mode: %u\n", bflag, iscflag, isdflag, isfflag, islflag, isregflag, issflag, iswflag, isseflag, test_stat->st_mode); exit(0); } --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="seekable.c.txt" #include #include #include #include int main (int argc, char **argv) { int fd; if (argc != 2) { fprintf(stderr, "usage: seekable filename\n"); exit(1); } fd = open(argv[1], O_RDONLY); if (fd == -1) err(1, "open failed"); if (lseek(fd, 0, SEEK_CUR) != -1) printf ("%d is seekable.\n", fd); else printf ("%d is not seekable.\n", fd); exit(0); } --tKW2IUtsqtDRztdT-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 18:44:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6498A106567D; Wed, 16 Nov 2011 18:44:06 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 172028FC12; Wed, 16 Nov 2011 18:44:05 +0000 (UTC) Received: by pzk33 with SMTP id 33so32285pzk.3 for ; Wed, 16 Nov 2011 10:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4BpZ0Z4nccw0gMa5lFUh+g6Bu/Xa0kKS27dqADRnx88=; b=gtseJR/tOdetoqsm7gqMEF1Hnhs/9V13VGsaf7gt+Z9Hi54Ma5prhBTOcGoDREPqcw Ve8I2AZ9mEZH8jNW3mOGivMoCcDxxtOR1euVkaxCv8BrEoa+9XLpzCOpBYJSxQ0M8AZF 50om4m1944zYew+5OISrK0CqDuWOFy8N+VH5w= MIME-Version: 1.0 Received: by 10.182.12.66 with SMTP id w2mr4798100obb.7.1321469044310; Wed, 16 Nov 2011 10:44:04 -0800 (PST) Received: by 10.182.7.34 with HTTP; Wed, 16 Nov 2011 10:44:03 -0800 (PST) In-Reply-To: References: <4D934AF4.9080503@FreeBSD.org> <742085CD-7F6F-4879-9FFD-517EC3203D52@bsdimp.com> <5AF348C8-6AB6-490D-A12E-89A51528F58F@bsdimp.com> Date: Wed, 16 Nov 2011 10:44:03 -0800 Message-ID: From: Garrett Cooper To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 Cc: mdf@freebsd.org, "Robert N. M. Watson" , Dimitry Andric , freebsd-hackers Subject: Re: Include file search path 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, 16 Nov 2011 18:44:06 -0000 On Wed, Sep 14, 2011 at 8:23 PM, Arnaud Lacombe wrote: > Hi, ... > ping, Warner ? > > FWIW, I guess that in 4 months, either you had time to finish the > patch, or I could have found to time to complete it myself based on > your incomplete version. I'd really be interested to benchmark recent, > decent, compiler. I've pinged Warner multiple times with no response on this issue apart from the first reply. I'll try to compile all of the details in this thread and do my best to engineer the work from scratch because it appears that the work was never made available for public consumption. So rather than wait for 2038 to roll around, I'll talk to folks (brooks, etc) and just get it done. Thanks, -Garrett From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 18:46:21 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DF8BC1065670; Wed, 16 Nov 2011 18:46:21 +0000 (UTC) Date: Wed, 16 Nov 2011 18:46:21 +0000 From: Alexander Best To: Brandon Gooch Message-ID: <20111116184621.GA5725@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116101422.GA20453@freebsd.org> <20111116103144.GA22928@freebsd.org> <20111116130316.GA38494@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <20111116130316.GA38494@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 18:46:22 -0000 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed Nov 16 11, Alexander Best wrote: > On Wed Nov 16 11, Alexander Best wrote: > > On Wed Nov 16 11, Alexander Best wrote: > > > On Tue Nov 15 11, Brandon Gooch wrote: > > > > On Nov 15, 2011 2:25 PM, "Alexander Best" wrote: > > > > > > > > > > hi there, > > > > > > > > > > one of the things i'm missing is an easy way to determine, whether a > > > > stream or > > > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > > > > performing so much stuff just to find out if this is the case, and they > > > > still > > > > > are doing a very poor job. > > > > > > > > > > dd(1) e.g. identifies /dev/zero as non-seekable, even though it is. the > > > > result: > > > > > > > > > > `dd if=/dev/zero bs=1m count=1 skip=100000`: > > > > > > > > > > on freebsd: > > > > > 57,41 real 0,05 user 43,21 sys > > > > > > > > > > on openbsd: > > > > > 0,88 real 0,00 user 0,07 sys > > > > > > > > > > on freebsd dd(1) is very easy fixable (1 line diff). the point however is: > > > > > > > > > > there doesn't seem to exist a unified way of checking seekable == TRUE. so > > > > > every userspace application seems to do it differently and most of them > > > > (dd(1) > > > > > and hd(1) e.g) aren't doing it right. hd(1) e.g. believes that only > > > > regular > > > > > files are seekable. this means that hd(1) fired at /dev/ada* with a high > > > > skip > > > > > value takes ages! dd(1) is a bit smarter in this case, but still not > > > > correct. > > > > > > > > > > idealy there would be something like stat.st_mode (see stat(2)) where one > > > > > could simply do a S_ISSEEK(m). so far the best and easiest solution i've > > > > seen > > > > > is: > > > > > > > > > > fd = open(argv[1], O_RDONLY); > > > > > if (fd == -1) > > > > > exit(1); > > > > > if (lseek(fd, 0, SEEK_CUR) != -1) > > > > > printf ("%d is seekable.\n", fd); > > > > > else > > > > > printf ("%d is not seekable.\n", fd); > > > > > > > > > > seeing an application iterate through a stream or fd via getchar(), > > > > although > > > > > a simple seek() would work is very frustrating. i think what would be > > > > needed > > > > > is a simple function or macro that userspace applications can make use of. > > > > > maybe such a thing already exists in linux, openbsd, netbsd, dragonflybsd, > > > > > solaris or plan9? > > > > > > > > > > cheers. > > > > > alex > > > > > > > > > > references: > > > > > [1] > > > > http://www.mavetju.org/mail/view_thread.php?list=freebsd-hackers&id=3290708&thread=yes > > > > > [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=152485 > > > > > [3] http://www.freebsd.org/cgi/query-pr.cgi?pr=86485 > > > > > > > > So, according to APUE 2nd Edition, seek should be supported on anything > > > > that's not a pipe, FIFO, or socket. In fact, the "test for seekability" > > > > you've provided above closely resembles the example given in that text. > > > > > > if this really is the case, things could even be easier in a freebsd specific > > > manor than the code above: > > > > > > !S_ISFIFO(m) && !S_ISSOCK(m) > > > > > > this means it would be trivial to write a new macro S_ISSEEK which would test > > > stat.st_mode against the according bits. > > > > here's a patch, which also fixes a comment. > > hmmm...the patch doesn't seem to work for directories and symbolic links > unfortunately. does anybody spot the problem? here's an updated patch, which should work. cheers. alex > > i've attached two testing applications. mode.c will do the tests via the S_IS* > macros and requires the patch i've posted beforehand to stat.h. the other > application is seekable.c, which will use lseek(2) to test, whether a file > argument is seekable or not. basically both applications should report the > same! > > cheers. > > > > > cheers. > > alex > > > > > > > > cheers. > > > alex > > > > > > > > > > > Need to think about this more before commenting further... > > > > > > > > -Brandon > > > diff --git a/sys/sys/stat.h b/sys/sys/stat.h > > index 1b03bd2..ab5ae44 100644 > > --- a/sys/sys/stat.h > > +++ b/sys/sys/stat.h > > @@ -238,10 +238,11 @@ struct nstat { > > #define S_ISCHR(m) (((m) & 0170000) == 0020000) /* char special */ > > #define S_ISBLK(m) (((m) & 0170000) == 0060000) /* block special */ > > #define S_ISREG(m) (((m) & 0170000) == 0100000) /* regular file */ > > -#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* fifo or socket */ > > +#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* pipe or fifo */ > > #if __POSIX_VISIBLE >= 200112 > > #define S_ISLNK(m) (((m) & 0170000) == 0120000) /* symbolic link */ > > #define S_ISSOCK(m) (((m) & 0170000) == 0140000) /* socket */ > > +#define S_ISSEEK(m) (((m) & 0150000) == 0) /* seekable file */ > > #endif > > #if __BSD_VISIBLE > > #define S_ISWHT(m) (((m) & 0170000) == 0160000) /* whiteout */ > --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="stat.h.diff2" diff --git a/sys/sys/stat.h b/sys/sys/stat.h index 1b03bd2..6fe78e7 100644 --- a/sys/sys/stat.h +++ b/sys/sys/stat.h @@ -238,13 +238,15 @@ struct nstat { #define S_ISCHR(m) (((m) & 0170000) == 0020000) /* char special */ #define S_ISBLK(m) (((m) & 0170000) == 0060000) /* block special */ #define S_ISREG(m) (((m) & 0170000) == 0100000) /* regular file */ -#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* fifo or socket */ +#define S_ISFIFO(m) (((m) & 0170000) == 0010000) /* pipe or fifo */ #if __POSIX_VISIBLE >= 200112 #define S_ISLNK(m) (((m) & 0170000) == 0120000) /* symbolic link */ #define S_ISSOCK(m) (((m) & 0170000) == 0140000) /* socket */ #endif #if __BSD_VISIBLE #define S_ISWHT(m) (((m) & 0170000) == 0160000) /* whiteout */ +#define S_ISSEEK(m) ((((m) & 0170000) != 0140000) && \ + (((m) & 0170000) != 0010000)) /* seekable file */ #endif #if __BSD_VISIBLE --zYM0uCDKw75PZbzx-- From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 16 23:22:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B17106566B for ; Wed, 16 Nov 2011 23:22:09 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0597C8FC0A for ; Wed, 16 Nov 2011 23:22:08 +0000 (UTC) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/auYssSp3n4k1Y2DJ X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-2-207-88-10.web.vodafone.de [2.207.88.10]) by smtp.strato.de (klopstock mo36) (RZmta 26.10 AUTH) with (DHE-RSA-AES128-SHA encrypted) ESMTPA id x04ae0nAGLqTQp for ; Thu, 17 Nov 2011 00:21:54 +0100 (MET) Received: by britannica.bec.de (sSMTP sendmail emulation); Thu, 17 Nov 2011 00:21:52 +0100 Date: Thu, 17 Nov 2011 00:21:52 +0100 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Message-ID: <20111116232152.GC21793@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111116131428.GA40723@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: easy way to determine if a stream or fd is seekable 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, 16 Nov 2011 23:22:09 -0000 On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote: > On Wed Nov 16 11, Joerg Sonnenberger wrote: > > On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote: > > > one of the things i'm missing is an easy way to determine, whether a stream or > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > > performing so much stuff just to find out if this is the case, and they still > > > are doing a very poor job. > > > > Isn't the primary issue that FreeBSD doesn't properly report errors for > > lseek(2)? I think you should start from that and not hack around the > > fallout... > > what do you mean? lseek(2) returns -1, when the file descriptor is not > seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...) > and it always returned the correct result. If that were the case, you wouldn't need your flag to detect seek support. But e.g. some devices silently ignore seek requests without reporting errors. At least that is what I remember from the last time this has brought up. Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 00:24:38 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1E85A1065670; Thu, 17 Nov 2011 00:24:38 +0000 (UTC) Date: Thu, 17 Nov 2011 00:24:38 +0000 From: Alexander Best To: freebsd-hackers@freebsd.org Message-ID: <20111117002438.GA55931@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111116232152.GC21793@britannica.bec.de> Subject: Re: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 00:24:38 -0000 On Thu Nov 17 11, Joerg Sonnenberger wrote: > On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote: > > On Wed Nov 16 11, Joerg Sonnenberger wrote: > > > On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote: > > > > one of the things i'm missing is an easy way to determine, whether a stream or > > > > fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > > > > performing so much stuff just to find out if this is the case, and they still > > > > are doing a very poor job. > > > > > > Isn't the primary issue that FreeBSD doesn't properly report errors for > > > lseek(2)? I think you should start from that and not hack around the > > > fallout... > > > > what do you mean? lseek(2) returns -1, when the file descriptor is not > > seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...) > > and it always returned the correct result. > > If that were the case, you wouldn't need your flag to detect seek > support. But e.g. some devices silently ignore seek requests without > reporting errors. At least that is what I remember from the last time > this has brought up. this is the first time i hear about problems with seek requests. would be nice to see some examples cases. was this discussed on the mailinglists? or submitted as a problem report? even if lseek(2) would always work, it would be overhead. there's no need to test a file operand against seeking, because we can derive that from its type. a file operand that isn't a pipe, fifo or socket IS seekable. i consider running S_ISSEEK(m) much more intuitive than first opening a file, saving its filedescriptor, dealing with errors, running lseek(2) with a zero offset argument (which appears to be very hackish), dealing with lseek(2) errors and finally evaluating lseek(2)'s return value. also the way of checking, whether a file operand is seekable via lseek(2) as always existed and people don't seem to understood that. hexdump(1) and dd(1) weren't written by amateurs -- still they aren't using lseek(2) on their file operand or aren't doing it correctly. so i believe developers should be given a more intuitive way to check for the ability to seek on a given file operand. S_ISSEEK(m) seems to be a very good solution from my point of view. cheers. alex > > Joerg From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 07:14:32 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DD9D106564A for ; Thu, 17 Nov 2011 07:14:32 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 0FFE28FC12 for ; Thu, 17 Nov 2011 07:14:31 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAH7EVJ2053532; Thu, 17 Nov 2011 07:14:31 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id s39c2n5is3743qiu6vvg8jf996; Thu, 17 Nov 2011 07:14:31 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20111117002438.GA55931@freebsd.org> Date: Wed, 16 Nov 2011 23:14:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 07:14:32 -0000 On Nov 16, 2011, at 4:24 PM, Alexander Best wrote: > On Thu Nov 17 11, Joerg Sonnenberger wrote: >> On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote: >>> On Wed Nov 16 11, Joerg Sonnenberger wrote: >>>> On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote: >>>>> one of the things i'm missing is an easy way to determine, whether = a stream or >>>>> fd is seekable. i checked the dd(1) and hd(1) sources and those = tools are >>>>> performing so much stuff just to find out if this is the case, and = they still >>>>> are doing a very poor job. >>>>=20 >>>> Isn't the primary issue that FreeBSD doesn't properly report errors = for >>>> lseek(2)? I think you should start from that and not hack around = the >>>> fallout... >>>=20 >>> what do you mean? lseek(2) returns -1, when the file descriptor is = not >>> seekable. i fired lseek(2) at all sorts of file types (dir, sockets, = ...) >>> and it always returned the correct result. >>=20 >> If that were the case, you wouldn't need your flag to detect seek >> support. But e.g. some devices silently ignore seek requests without >> reporting errors. At least that is what I remember from the last time >> this has brought up. >=20 > this is the first time i hear about problems with seek requests. would = be nice > to see some examples cases. was this discussed on the mailinglists? or > submitted as a problem report? There was a version of bsdtar that made the mistake of assuming lseek() would return an error. lseek() on a tape drive does not return an error, nor does it actually do anything. After a few experiments, bsdtar stopped using lseek() on FreeBSD for anything other than regular files and block devices. I believe there are other things that do support seeking, but I don't believe there is an accurate mechanism for determining whether lseek() is correctly supported. Tim From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 09:59:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1AE8F106566C; Thu, 17 Nov 2011 09:59:51 +0000 (UTC) Date: Thu, 17 Nov 2011 09:59:51 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20111117095951.GA34444@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 09:59:51 -0000 On Wed Nov 16 11, Tim Kientzle wrote: > > On Nov 16, 2011, at 4:24 PM, Alexander Best wrote: > > > On Thu Nov 17 11, Joerg Sonnenberger wrote: > >> On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote: > >>> On Wed Nov 16 11, Joerg Sonnenberger wrote: > >>>> On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote: > >>>>> one of the things i'm missing is an easy way to determine, whether a stream or > >>>>> fd is seekable. i checked the dd(1) and hd(1) sources and those tools are > >>>>> performing so much stuff just to find out if this is the case, and they still > >>>>> are doing a very poor job. > >>>> > >>>> Isn't the primary issue that FreeBSD doesn't properly report errors for > >>>> lseek(2)? I think you should start from that and not hack around the > >>>> fallout... > >>> > >>> what do you mean? lseek(2) returns -1, when the file descriptor is not > >>> seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...) > >>> and it always returned the correct result. > >> > >> If that were the case, you wouldn't need your flag to detect seek > >> support. But e.g. some devices silently ignore seek requests without > >> reporting errors. At least that is what I remember from the last time > >> this has brought up. > > > > this is the first time i hear about problems with seek requests. would be nice > > to see some examples cases. was this discussed on the mailinglists? or > > submitted as a problem report? > > There was a version of bsdtar that made the mistake of assuming > lseek() would return an error. > > lseek() on a tape drive does not return an error, nor does it > actually do anything. > > After a few experiments, bsdtar stopped using lseek() on > FreeBSD for anything other than regular files and block > devices. I believe there are other things that do support > seeking, but I don't believe there is an accurate mechanism > for determining whether lseek() is correctly supported. dealing with tape drives wouldn't be that difficult. there's code in dd(1) e.g. that identifies a file argument as D_TAPE or !D_TAPE via an ioctl() call. if tapes are the only devices types that have issues with lseek(), this could easily be dealt with. i'll take a look at the bsdtar commit logs to find out where the exact problems were. however i vote that the lseek(2) and also fseek(3) should have their "BUGS" section extended with a description for the issue(s) that exist. might the problem with lseek() be related to this bug report? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60313 cheers. alex ps: since i've never worked with tape: what file type does it identify as? character special file, or block special file, or ...? > > Tim From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 17:55:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8E641065670 for ; Thu, 17 Nov 2011 17:55:22 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 818F48FC14 for ; Thu, 17 Nov 2011 17:55:22 +0000 (UTC) Received: (qmail 3292 invoked by uid 0); 17 Nov 2011 17:55:16 -0000 Received: from 67.206.187.41 by rms-us001.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Thu, 17 Nov 2011 12:55:02 -0500 From: "Dieter BSD" Message-ID: <20111117175514.274040@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: 7T+sfUEl33erJQ7YAmtnpDsjL0tsZg08 Subject: Re: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 17:55:22 -0000 > lseek() on a tape drive does not return an error, nor does it > actually do anything. IIRC some tape drives can seek, while others cannot. Vague memories that it is supposed to be possible to put a filesystem on a DECtape and mount the filesystem. It might be that FreeBSD doesn't currently support seeking on a tape, but we shouldn't paint ourselves into a corner by assuming that it is fundimentally impossible. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 19:12:57 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90633106566C for ; Thu, 17 Nov 2011 19:12:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 63C988FC0A for ; Thu, 17 Nov 2011 19:12:56 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pAHIk1Q6088251 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 17 Nov 2011 10:46:12 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EC55669.2060908@freebsd.org> Date: Thu, 17 Nov 2011 10:46:01 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <201111152218.41031.gelraen.ua@gmail.com> <20111116085508.GF36205@hoeg.nl> In-Reply-To: <20111116085508.GF36205@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Communication between kernel and userspace via local socket 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, 17 Nov 2011 19:12:57 -0000 On 11/16/11 12:55 AM, Ed Schouten wrote: > * Maxim Ignatenko, 20111115 21:18: >> I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and >> looking for most convenient way to establish communication between userspace >> processes and kernel part. Communication pattern best fits to listening >> PF_LOCAL socket opened from kernel and userspace processes connecting to it. > What's wrong with a character device? you can't easily have a different character device depending on which jail you are in.. (well, you can but it gets tricky).. see the problem with /dev/pflog and vimages. Maxim, look at the usage of sockets with netgraph ng_socket node.. also divert sockets. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 19:40:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C2E9106564A for ; Thu, 17 Nov 2011 19:40:36 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id C08978FC08 for ; Thu, 17 Nov 2011 19:40:35 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so3334182bkb.13 for ; Thu, 17 Nov 2011 11:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:content-type:from:date:user-agent :content-transfer-encoding:subject:to:references:lines:mime-version; bh=71bAGtiKY9giP9jTXFbw1t5D1JpGI2CRthkJebGfp6Q=; b=Llu6y2epgpP6Z0AwW5BjI6O6EMOzg01eB3tv4z88xDesr2PIwVNIzl9jJzeBoBxxn9 4DXEhOw4uBpveeD7IcGxUdK3LMQ2znVcbqZvE7AumYIVXOBV0s8QWBwatMi3aP8P+V3+ BDjCronQ+40PP/UCzDm1E6Jc9AK9N1Zyx6QAY= Received: by 10.204.156.141 with SMTP id x13mr22110bkw.54.1321558834329; Thu, 17 Nov 2011 11:40:34 -0800 (PST) Received: from imax.localnet (75-85-132-95.pool.ukrtel.net. [95.132.85.75]) by mx.google.com with ESMTPS id w11sm2989218fad.7.2011.11.17.11.40.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Nov 2011 11:40:31 -0800 (PST) Message-ID: <4ec5632f.4b25df0a.1118.ffff9381@mx.google.com> Content-Type: text/plain; charset="ISO-8859-1" From: Maxim Ignatenko Date: Thu, 17 Nov 2011 21:40:22 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 7Bit To: Julian Elischer , freebsd-hackers@freebsd.org References: <201111152218.41031.gelraen.ua@gmail.com> <20111116085508.GF36205@hoeg.nl> <4EC55669.2060908@freebsd.org> Lines: 28 MIME-Version: 1.0 Cc: Subject: Re: Communication between kernel and userspace via local socket 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, 17 Nov 2011 19:40:36 -0000 Julian Elischer wrote: > On 11/16/11 12:55 AM, Ed Schouten wrote: >> * Maxim Ignatenko, 20111115 21:18: >>> I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and >>> looking for most convenient way to establish communication between >>> userspace processes and kernel part. Communication pattern best fits to >>> listening PF_LOCAL socket opened from kernel and userspace processes >>> connecting to it. >> What's wrong with a character device? > > you can't easily have a different character device depending on which > jail you are in.. > (well, you can but it gets tricky).. see the problem with /dev/pflog > and vimages. > > > Maxim, look at the usage of sockets with netgraph ng_socket node.. also > divert sockets. > Did you meant ng_ksocket? I've looked on it, but in case of ng_ksocket connections accepted upon receiving control message NGM_KSOCKET_ACCEPT, but I need to accept connections without such "punch". As far as I understand, I need to spawn kernel process or thread which will listen for incoming connections and respond to requests, just like normal network daemon does, but I don't know how to do this. divert(4) will not do the job, since packets written to divert socket goes to IP stack. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 20:49:35 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 27E1A106567A; Thu, 17 Nov 2011 20:49:35 +0000 (UTC) Date: Thu, 17 Nov 2011 20:49:35 +0000 From: Alexander Best To: freebsd-hackers@FreeBSD.org Message-ID: <20111117204935.GA68820@freebsd.org> References: <20111117175514.274040@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111117175514.274040@gmx.com> Cc: Subject: Re: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 20:49:35 -0000 On Thu Nov 17 11, Dieter BSD wrote: > > lseek() on a tape drive does not return an error, nor does it > > actually do anything. > > IIRC some tape drives can seek, while others cannot. > Vague memories that it is supposed to be possible to put a > filesystem on a DECtape and mount the filesystem. i took a look at the bsdtar sources and before the lseek() a function called test_for_append() is run. apart from other things it will do the following: if (!S_ISREG(s.st_mode) && !S_ISBLK(s.st_mode)) lafe_errc(1, 0, "Cannot append to %s: not a regular file.", bsdtar->filename); but again this is too restrictive. take a look at /dev/zero e.g.: otaku% ./mode /dev/zero Block special file: 0 Character special file: 1 Directory: 0 Pipe or FIFO special file: 0 Symbolic link: 0 Regular file: 0 Socket: 0 Whiteout: 0 Seekable: 1 it is not regular file and no block special file, so bsdtar will bail out for no reason! i think there are two possibilities: 1) add code to lseek() that will return -1 for all tape drives. 2) deal with those tape drives that don't support seeking individually. identifying a tape drive is easy. here's dd's code snippet: if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) { if (ioctl(io->fd, FIODTYPE, &type) == -1) err(1, "%s", io->name); if (type & D_TAPE) io->flags |= ISTAPE; } this could be added to lseek() and when "type & D_TAPE" == TRUE, then we could return -1. this would be method 1). no idea how to fix this issue using method 2) though. probably driving into the driver code of the according tape drives. cheers. alex ps: thanks to nox@ for pointing me to the initial thread, where this issue was discussed [1]. however the purpose of that thread was mainly fixing libarchive/bsdtar and not so much really fixing the issue at hand. also i'll consider re-opening problem report [2], wince this was never really fixed. [1] http://markmail.org/message/n6tp5dbv7sbzzujc [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60313 > > It might be that FreeBSD doesn't currently support seeking > on a tape, but we shouldn't paint ourselves into a corner > by assuming that it is fundimentally impossible. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 21:48:05 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D1F581065670; Thu, 17 Nov 2011 21:48:05 +0000 (UTC) Date: Thu, 17 Nov 2011 21:48:05 +0000 From: Alexander Best To: freebsd-hackers@FreeBSD.org Message-ID: <20111117214805.GA96937@freebsd.org> References: <20111117175514.274040@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111117175514.274040@gmx.com> Cc: Subject: Re: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 21:48:05 -0000 On Thu Nov 17 11, Dieter BSD wrote: > > lseek() on a tape drive does not return an error, nor does it > > actually do anything. > > IIRC some tape drives can seek, while others cannot. > Vague memories that it is supposed to be possible to put a > filesystem on a DECtape and mount the filesystem. or how about the following: 1) if the file argument we're seeking on is a tape drive, just do a regular seek operation. 2) afterwards use ftell() to verify that the seek REALLY happend. if it didn't, return -1 and set errno = EBADF. cheers. alex > > It might be that FreeBSD doesn't currently support seeking > on a tape, but we shouldn't paint ourselves into a corner > by assuming that it is fundimentally impossible. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 22:16:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2602106566C; Thu, 17 Nov 2011 22:16:54 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2DF8FC0C; Thu, 17 Nov 2011 22:16:54 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pAHMGrVx084242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 14:16:54 -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 pAHMGraP084241; Thu, 17 Nov 2011 14:16:53 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01998; Thu, 17 Nov 11 14:01:22 PST Date: Thu, 17 Nov 2011 21:01:04 -0800 From: perryh@pluto.rain.com To: arundel@freebsd.org Message-Id: <4ec5e690.l2CUTtl0GR+evQV5%perryh@pluto.rain.com> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> <20111117095951.GA34444@freebsd.org> In-Reply-To: <20111117095951.GA34444@freebsd.org> 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: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 22:16:54 -0000 Alexander Best wrote: > since i've never worked with tape: what file type does it identify > as? character special file, or block special file, or ...? IIUC all devices are now character, block devices having been dropped from FreeBSD some time ago. Come to think of it, it would not be altogether surprising if that turned out to be the point at which the ability to seek a device went away. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 22:16:55 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64AC1065673 for ; Thu, 17 Nov 2011 22:16:55 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id B71888FC13 for ; Thu, 17 Nov 2011 22:16:55 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id pAHMGqWS084236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Nov 2011 14:16:53 -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 pAHMGqP0084235; Thu, 17 Nov 2011 14:16:52 -0800 (PST) Received: from fbsd81 ([192.168.200.81]) by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA01982; Thu, 17 Nov 11 14:00:56 PST Date: Thu, 17 Nov 2011 21:00:38 -0800 From: perryh@pluto.rain.com To: dieterbsd@engineer.com Message-Id: <4ec5e676.P+DwfO0SrmiegcuB%perryh@pluto.rain.com> References: <20111117175514.274040@gmx.com> In-Reply-To: <20111117175514.274040@gmx.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: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 22:16:55 -0000 "Dieter BSD" wrote: > IIRC some tape drives can seek, while others cannot. > Vague memories that it is supposed to be possible to put a > filesystem on a DECtape and mount the filesystem. Back in the Bell Labs 6th Edition days, it was possible to put a filesystem on a _9-track magtape_ and mount it, although such a mount had to be read-only since writing to a 9-track would effectively delete any blocks following the one written. I've done it. Access was painfully slow (no surprise), but it did work. DECtape _could_ be updated in place. It was effectively the linear equivalent of a floppy disk (before floppy disks existed). Sequential access was slow. Random access was very slow. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 17 21:13:44 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 204D3106566B; Thu, 17 Nov 2011 21:13:44 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id D37F28FC19; Thu, 17 Nov 2011 21:13:43 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id E8C7B1E00233; Thu, 17 Nov 2011 21:57:55 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id pAHKtaGm061119; Thu, 17 Nov 2011 21:55:36 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id pAHKtZso061118; Thu, 17 Nov 2011 21:55:35 +0100 (CET) (envelope-from nox) Date: Thu, 17 Nov 2011 21:55:35 +0100 (CET) From: Juergen Lock Message-Id: <201111172055.pAHKtZso061118@triton8.kn-bremen.de> To: tim@kientzle.com X-Newsgroups: local.list.freebsd.hackers In-Reply-To: References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> Organization: X-Mailman-Approved-At: Thu, 17 Nov 2011 22:33:30 +0000 Cc: Alexander Best , freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 17 Nov 2011 21:13:44 -0000 In article you write: >On Nov 16, 2011, at 4:24 PM, Alexander Best wrote: > >> On Thu Nov 17 11, Joerg Sonnenberger wrote: >>> On Wed, Nov 16, 2011 at 01:14:28PM +0000, Alexander Best wrote: >>>> On Wed Nov 16 11, Joerg Sonnenberger wrote: >>>>> On Tue, Nov 15, 2011 at 08:24:50PM +0000, Alexander Best wrote: >>>>>> one of the things i'm missing is an easy way to determine, whether a stream or >>>>>> fd is seekable. i checked the dd(1) and hd(1) sources and those tools are >>>>>> performing so much stuff just to find out if this is the case, and they still >>>>>> are doing a very poor job. >>>>> >>>>> Isn't the primary issue that FreeBSD doesn't properly report errors for >>>>> lseek(2)? I think you should start from that and not hack around the >>>>> fallout... >>>> >>>> what do you mean? lseek(2) returns -1, when the file descriptor is not >>>> seekable. i fired lseek(2) at all sorts of file types (dir, sockets, ...) >>>> and it always returned the correct result. >>> >>> If that were the case, you wouldn't need your flag to detect seek >>> support. But e.g. some devices silently ignore seek requests without >>> reporting errors. At least that is what I remember from the last time >>> this has brought up. >> >> this is the first time i hear about problems with seek requests. would be nice >> to see some examples cases. was this discussed on the mailinglists? or >> submitted as a problem report? > >There was a version of bsdtar that made the mistake of assuming >lseek() would return an error. > >lseek() on a tape drive does not return an error, nor does it >actually do anything. > >After a few experiments, bsdtar stopped using lseek() on >FreeBSD for anything other than regular files and block >devices. I believe there are other things that do support >seeking, but I don't believe there is an accurate mechanism >for determining whether lseek() is correctly supported. Ah is that the reason why my patch never made it into FreeBSD 9? I'm talking about this thread, where I also commented on seeking on tape: http://docs.freebsd.org/cgi/mid.cgi?20100220101724.GA26604 (Re: "tar tfv /dev/cd0" speedup patch) entire thread here: http://markmail.org/message/nfznipqik3tuhbqp Cheers, Juergen (who would still like to see a faster "tar tfv /dev/cd0"... :) From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 00:05:17 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83B5D106564A; Fri, 18 Nov 2011 00:05:17 +0000 (UTC) (envelope-from slonoman2011@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [IPv6:2a02:6b8:0:801::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3C11B8FC08; Fri, 18 Nov 2011 00:05:16 +0000 (UTC) Received: from web146.yandex.ru (web146.yandex.ru [95.108.131.161]) by forward12.mail.yandex.net (Yandex) with ESMTP id 9865FC21DB8; Fri, 18 Nov 2011 04:05:14 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321574714; bh=LfBwZ5ESfC+eIt13ZxkHz7EguMvGboVMs5E5V8fvbtA=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=Jt0XG2SGTr5MMhpoNDHskf6g9PwmeHc5B/2vUgXs9o1++h/6fnCX15lAfPSdSi/4e 5RMrcfh3KWDtVmzAQiK2MHutB8YK+dM2PCKa2WquEepxXtAwjJ9UZTWJX33+tGmuxQ tXjuozeHmrDMxF/6qYTP5iRPeR7jlulImSyT+e3M= Received: from localhost (localhost.localdomain [127.0.0.1]) by web146.yandex.ru (Yandex) with ESMTP id 6A4827158001; Fri, 18 Nov 2011 04:05:14 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1321574714; bh=LfBwZ5ESfC+eIt13ZxkHz7EguMvGboVMs5E5V8fvbtA=; h=From:To:Subject:MIME-Version:Message-Id:Date: Content-Transfer-Encoding:Content-Type; b=Jt0XG2SGTr5MMhpoNDHskf6g9PwmeHc5B/2vUgXs9o1++h/6fnCX15lAfPSdSi/4e 5RMrcfh3KWDtVmzAQiK2MHutB8YK+dM2PCKa2WquEepxXtAwjJ9UZTWJX33+tGmuxQ tXjuozeHmrDMxF/6qYTP5iRPeR7jlulImSyT+e3M= X-Yandex-Spam: 1 Received: from nat140-249-205-109.tvoe.tv (nat140-249-205-109.tvoe.tv [109.205.249.140]) by web146.yandex.ru with HTTP; Fri, 18 Nov 2011 04:05:13 +0400 From: Slono Slono To: freebsd-hackers@freebsd.org,freebsd-stable@freebsd.org MIME-Version: 1.0 Message-Id: <297161321574713@web146.yandex.ru> Date: Fri, 18 Nov 2011 04:05:13 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailman-Approved-At: Fri, 18 Nov 2011 00:32:07 +0000 Cc: Subject: memory leaks (and some other warning like divison by zero; ) auto reports for FreeBSD source code 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, 18 Nov 2011 00:05:17 -0000 Hi This information can be interesting - in most cases really doesn't suffice free() and someone is necessary with commit bit who it can to correct. reported by cppcheck (http://cppcheck.sourceforge.net/): This report is actual for FreeBSD 9.0-PRERELEASE Scan for /usr/src/libexec/: [rtld-elf/rtld.c:1660]: (error) Resource leak: fd [ftpd/ftpd.c:610]: (error) Mismatching allocation and deallocation: fd Scan for /usr/src/lib/ [libarchive/archive_entry_link_resolver.c:240]: (error) Memory leak: le [libarchive/archive_read_open_filename.c:115]: (error) Resource leak: fd [libarchive/archive_read_support_format_tar.c:638]: (error) Buffer access out-of-bounds: header.magic [libarchive/archive_write_disk.c:1767]: (error) Memory leak: le [libc/db/test/btree.tests/main.c:601]: (error) Resource leak: fp [libc/gen/_pthread_stubs.c:218]: (error) Analysis failed. If the code is valid then please report this failure. [libc/mips/gen/makecontext.c:107]: (error) Uninitialized variable: i [libc/net/getifaddrs.c:250]: (error) Invalid deallocation [libc/net/getifaddrs.c:255]: (error) Invalid deallocation [libc/net/nscache.c:118]: (error) Common realloc mistake: 'buffer' nulled but not freed upon failure [libc/net/nscache.c:204]: (error) Common realloc mistake: 'buffer' nulled but not freed upon failure [libc/net/nscache.c:299]: (error) Common realloc mistake: 'buffer' nulled but not freed upon failure [libc/net/nscache.c:375]: (error) Common realloc mistake: 'buffer' nulled but not freed upon failure [libc/quad/qdivrem.c:100]: (error) Division by zero [libc/rpc/clnt_perror.c:301]: (error) Allocation with clnt_spcreateerror, fprintf doesn't release it. [libc/rpc/netnamer.c:331]: (error) Resource leak: fd [libdisk/open_disk.c:89]: (error) Memory leak: d [libdwarf/dwarf_attr.c:49]: (error) Possible null pointer dereference: at - otherwise it is redundant to check if at is null at line 54 [libdwarf/dwarf_init.c:505]: (error) Memory leak: cu [libedit/readline.c:1009]: (error) Possible null pointer dereference: arr - otherwise it is redundant to check if arr is null at line 1006 [libedit/readline.c:1693]: (error) Possible null pointer dereference: pwd - otherwise it is redundant to check if pwd is null at line 1695 [libedit/readline.c:1934]: (error) Memory leak: wbuf [libfetch/file.c:148]: (error) Resource leak: dir [libgssapi/gss_accept_sec_context.c:217]: (error) Possible null pointer dereference: mc - otherwise it is redundant to check if mc is null at line 219 [libgssapi/gss_accept_sec_context.c:220]: (error) Memory leak: ctx [libgssapi/gss_inquire_cred_by_mech.c:68]: (error) Possible null pointer dereference: mcp - otherwise it is redundant to check if mcp is null at line 70 [libgssapi/gss_verify_mic.c:42]: (error) Possible null pointer dereference: ctx - otherwise it is redundant to check if ctx is null at line 46 [libgssapi/gss_wrap_size_limit.c:43]: (error) Possible null pointer dereference: ctx - otherwise it is redundant to check if ctx is null at line 46 [libjail/jail_getid.c:103]: (error) Uninitialized variable: namebuf [libmd/mdXhl.c:63]: (error) Resource leak: f [libncp/ncpl_conn.c:495]: (error) Resource leak: d [libncp/ncpl_file.c:89]: (error) Resource leak: d [libprocstat/libprocstat.c:723]: (error) Memory leak: path [librt/timer.c:106]: (error) Memory leak: timer [libstand/bzipfs.c:194]: (error) Resource leak: rawfd [libstand/qdivrem.c:99]: (error) Division by zero Scan for /usr/src/bin/: [ps/print.c:427]: (error) Memory leak: buf [ps/print.c:457]: (error) Memory leak: buf [sh/jobs.c:825]: (error) Allocation with open, if doesn't release it. [sh/mknodes.c:269]: (error) Resource leak: hfile [sh/mknodes.c:269]: (error) Resource leak: patfile [pax/cache.c:333]: (error) Possible null pointer dereference: ptr - otherwise it is redundant to check if ptr is null at line 345 [pax/cache.c:397]: (error) Possible null pointer dereference: ptr - otherwise it is redundant to check if ptr is null at line 408 Scan for /usr/src/cddl/: contrib/opensolaris/cmd/dtrace/test/cmd/baddof/baddof.c:202]: (error) Deallocating a deallocated pointer: fd [contrib/opensolaris/cmd/lockstat/sym.c:150]: (error) Memory leak: name [contrib/opensolaris/cmd/sgs/tools/common/sgsmsg.c:311]: (error) Memory leak: buffer [contrib/opensolaris/cmd/sgs/tools/common/sgsmsg.c:503]: (error) Memory leak: buf [contrib/opensolaris/cmd/sgs/tools/common/sgsmsg.c:950]: (error) Common realloc mistake: 'token_buffer' nulled but not freed upon failure [contrib/opensolaris/cmd/zpool/zpool_main.c:4622]: (error) Resource leak: fd [contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c:568]: (error) Memory leak: percpu [contrib/opensolaris/lib/libdtrace/common/dt_cc.c:2117]: (error) Resource leak: dirp [contrib/opensolaris/lib/libdtrace/common/dt_link.c:1735]: (error) Resource leak: fd [contrib/opensolaris/lib/libdtrace/common/dt_strtab.c:257]: (error) Memory leak: hp [contrib/opensolaris/lib/libzfs/common/libzfs_import.c:1006]: (error) Dangerous usage of 'diskname' (strncpy doesn't always 0-terminate it) [contrib/opensolaris/tools/ctf/cvt/dwarf.c:503]: (error) Possible null pointer dereference: loc - otherwise it is redundant to check if loc is null at line 505 Scan for /usr/src/usr.bin/: [column/column.c:272]: (error) Memory leak: lens [cpio/cmdline.c:348]: (error) Memory leak: user [csup/updater.c:1905]: (error) Resource leak: fd [csup/updater.c:1988]: (error) Resource leak: orig [elf2aout/elf2aout.c:154]: (error) Resource leak: fd [env/envopts.c:467]: (error) Memory leak: newstr [finger/lprint.c:306]: (error) Resource leak: fd [grep/regex/tre-fastmatch.c:534]: (error) Memory leak: p [grep/regex/tre-fastmatch.c:537]: (error) Memory leak: wp [grep/regex/tre-fastmatch.c:766]: (error) Memory leak: p [grep/regex/tre-fastmatch.c:769]: (error) Memory leak: wp [gzip/gzip.c:1272]: (error) Resource leak: in [join/join.c:495]: (error) Possible null pointer dereference: olist - otherwise it is redundant to check if olist is null at line 485 [last/last.c:283]: (error) Possible null pointer dereference: tt - otherwise it is redundant to check if tt is null at line 286 [login/login.c:624]: (error) Memory leak: cx [m4/main.c:643]: (error) Common realloc mistake: 'sstack' nulled but not freed upon failure [make/var.c:1764]: (error) Uninitialized variable: error [makewhatis/makewhatis.c:351]: (error) Resource leak: output [msgs/msgs.c:804]: (error) Resource leak: cpfrom [newkey/update.c:273]: (error) Resource leak: rf [newkey/update.c:320]: (error) Memory leak: tmpname [pr/pr.c:211]: (error) Memory leak: obuf [pr/pr.c:362]: (error) Memory leak: buf [pr/pr.c:383]: (error) Memory leak: vc [pr/pr.c:395]: (error) Memory leak: indy [pr/pr.c:669]: (error) Memory leak: buf [sed/compile.c:842]: (error) Memory leak: p [showmount/showmount.c:332]: (error) Memory leak: ep [showmount/showmount.c:341]: (error) Memory leak: gp [tip/tip/cmds.c:129]: (error) Resource leak: fd [truss/amd64-fbsd.c:214]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 218 [truss/amd64-fbsd32.c:217]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 221 [truss/amd64-linux32.c:187]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 191 [truss/i386-fbsd.c:207]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 211 [truss/i386-linux.c:187]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 191 [truss/ia64-fbsd.c:189]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 193 [truss/mips-fbsd.c:234]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 238 [truss/powerpc-fbsd.c:221]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 225 [truss/powerpc64-fbsd.c:209]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 213 [truss/sparc64-fbsd.c:232]: (error) Possible null pointer dereference: sc - otherwise it is redundant to check if sc is null at line 236 [truss/syscalls.c:518]: (error) Common realloc mistake: 'buf' nulled but not freed upon failure [tset/wrterm.c:114]: (error) Memory leak: sep [unvis/unvis.c:69]: (error) Resource leak: fp [vgrind/vgrindefs.c:119]: (error) Resource leak: tf [vgrind/vgrindefs.c:150]: (error) Possible null pointer dereference: q - otherwise it is redundant to check if q is null at line 148 [vis/vis.c:112]: (error) Resource leak: fp [yacc/lr0.c:289]: (error) The given size 102 is mismatching Scan for /usr/src/usr.sbin: [acpi/acpidb/acpidb.c:373]: (error) Resource leak: fd [acpi/acpidump/acpi.c:1199]: (error) Dangerous usage of 'tmpstr' (strncpy doesn't always 0-terminate it) [asf/asf.c:186]: (error) Resource leak: objcopy [asf/asf_prog.c:73]: (error) Resource leak: kldstat [bluetooth/bt3cfw/bt3cfw.c:225]: (error) Resource leak: firmware_file [boot0cfg/boot0cfg.c:337]: (error) Resource leak: fd [bootparamd/bootparamd/bootparamd.c:239]: (error) Resource leak: bpf [bsdinstall/distextract/distextract.c:52]: (error) Memory leak: diststring [bsdinstall/distfetch/distfetch.c:51]: (error) Memory leak: diststring [bsdinstall/partedit/gpart_ops.c:1218]: (error) Possible null pointer dereference: cp - otherwise it is redundant to check if cp is null at line 1222 [bsdinstall/partedit/gpart_ops.c:307]: (error) Resource leak: bootfd [bsdinstall/partedit/gpart_ops.c:950]: (error) Possible null pointer dereference: gc - otherwise it is redundant to check if gc is null at line 952 [bsdinstall/partedit/part_wizard.c:136]: (error) Undefined behavior: variable is used as parameter and destination in s[n]printf(). [bsdinstall/partedit/part_wizard.c:182]: (error) Possible null pointer dereference: pp - otherwise it is redundant to check if pp is null at line 185 [bsdinstall/partedit/part_wizard.c:206]: (error) Possible null pointer dereference: classp - otherwise it is redundant to check if classp is null at line 209 [bsdinstall/partedit/partedit.c:202]: (error) Possible null pointer dereference: md - otherwise it is redundant to check if md is null at line 205 [bsnmpd/modules/snmp_bridge/bridge_sys.c:1249]: (error) Possible null pointer dereference: bp - otherwise it is redundant to check if bp is null at line 1247 [bsnmpd/modules/snmp_hostres/hostres_fs_tbl.c:161]: (error) Possible null pointer dereference: map - otherwise it is redundant to check if map is null at line 164 [bsnmpd/modules/snmp_hostres/hostres_network_tbl.c:182]: (error) Possible null pointer dereference: net - otherwise it is redundant to check if net is null at line 185 [bsnmpd/modules/snmp_hostres/hostres_partition_tbl.c:172]: (error) Possible null pointer dereference: map - otherwise it is redundant to check if map is null at line 175 [bsnmpd/modules/snmp_hostres/hostres_storage_tbl.c:150]: (error) Possible null pointer dereference: map - otherwise it is redundant to check if map is null at line 153 [bsnmpd/tools/libbsnmptools/bsnmptools.c:1084]: (error) Invalid deallocation [config/main.c:506]: (error) Memory leak: p [config/main.c:516]: (error) Allocation with path, moveifchanged doesn't release it. [config/main.c:612]: (error) Allocation with path, unlink doesn't release it. [config/mkmakefile.c:685]: (error) Memory leak: suff [config/mkoptions.c:190]: (error) Possible null pointer dereference: ol - otherwise it is redundant to check if ol is null at line 227 [config/mkoptions.c:220]: (error) Possible null pointer dereference: ol - otherwise it is redundant to check if ol is null at line 227 [config/mkoptions.c:382]: (error) Memory leak: this [cron/lib/compat.c:235]: (error) Memory leak: tmp [crunch/crunchgen/crunchgen.c:733]: (error) Mismatching allocation and deallocation: f [ctm/ctm/ctm_input.c:90]: (error) Memory leak: p [edquota/edquota.c:558]: (error) Resource leak: fd [edquota/edquota.c:736]: (error) Resource leak: fd [faithd/faithd.c:633]: (error) Invalid number of character (() when these macros are defined: ''. [faithd/faithd.c:633]: (error) Invalid number of character (() when these macros are defined: 'HAVE_POLL_H'. [faithd/faithd.c:633]: (error) Invalid number of character (() when these macros are defined: 'IPV6_FAITH'. [faithd/faithd.c:633]: (error) Invalid number of character (() when these macros are defined: 'IPV6_V6ONLY'. [faithd/faithd.c:633]: (error) Invalid number of character (() when these macros are defined: 'SA_NOCLDWAIT'. [faithd/faithd.c:633]: (error) Invalid number of character (() when these macros are defined: '__KAME__'. [fdcontrol/fdcontrol.c:208]: (error) Resource leak: fd [fdformat/fdformat.c:290]: (error) Resource leak: fd [fdread/fdread.c:295]: (error) Memory leak: trackbuf [fifolog/lib/fifolog_create.c:121]: (error) Resource leak: fd [fwcontrol/fwcontrol.c:154]: (error) Possible null pointer dereference: data - otherwise it is redundant to check if data is null at line 155 [kbdcontrol/kbdcontrol.c:163]: (error) Common realloc mistake: 'buf' nulled but not freed upon failure [lpr/common_source/common.c:186]: (error) Memory leak: q [lpr/common_source/ctlinfo.c:294]: (error) Resource leak: cfile [lpr/lpd/lpd.c:423]: (error) Resource leak: lfd [lpr/lpd/printjob.c:653]: (error) Dereferencing 'fi' after it is deallocated / released [makefs/cd9660.c:2038]: (error) Memory leak: temp [makefs/cd9660.c:2065]: (error) Memory leak: temp [makefs/cd9660.c:701]: (error) Array 'record.ext_attr_length[0]' index 0 out of bounds [makefs/cd9660/cd9660_eltorito.c:233]: (error) Memory leak: temp [makefs/compat/pwcache.c:391]: (error) Possible null pointer dereference: ptr - otherwise it is redundant to check if ptr is null at line 404 [makefs/compat/pwcache.c:455]: (error) Possible null pointer dereference: ptr - otherwise it is redundant to check if ptr is null at line 468 [mixer/mixer.c:183]: (error) Resource leak: baz [mlxcontrol/command.c:580]: (error) Resource leak: fd [mlxcontrol/command.c:634]: (error) Resource leak: fd [mlxcontrol/interface.c:103]: (error) Resource leak: ctrlfd [mlxcontrol/interface.c:262]: (error) Assigning address of local auto-variable to a function parameter. [mlxcontrol/interface.c:263]: (error) Assigning address of local auto-variable to a function parameter. [mlxcontrol/interface.c:264]: (error) Assigning address of local auto-variable to a function parameter. [mptutil/mpt_config.c:113]: (error) Resource leak: vfd [mptutil/mpt_config.c:129]: (error) Resource leak: dfd [mptutil/mpt_config.c:713]: (error) Memory leak: info [ndiscvt/ndiscvt.c:215]: (error) Memory leak: outfile [newsyslog/newsyslog.c:1950]: (error) Possible null pointer dereference: zwork - otherwise it is redundant to check if zwork is null at line 1951 [ngctl/main.c:205]: (error) Resource leak: fp [pciconf/pciconf.c:645]: (error) Resource leak: fd [pciconf/pciconf.c:664]: (error) Resource leak: fd [pkg_install/lib/exec.c:50]: (error) Memory leak: cmd [pkg_install/lib/exec.c:79]: (error) Memory leak: rp [pkg_install/lib/plist.c:592]: (error) Memory leak: cp1 [pkg_install/lib/url.c:115]: (error) Resource leak: pkgfd [pkg_install/updating/main.c:125]: (error) Possible null pointer dereference: curr - otherwise it is redundant to check if curr is null at line 122 [pkg_install/updating/main.c:126]: (error) Possible null pointer dereference: curr - otherwise it is redundant to check if curr is null at line 122 [pkg_install/updating/main.c:220]: (error) Memory leak: dateline [pmcstat/pmcstat_log.c:862]: (error) Possible null pointer dereference: pcm - otherwise it is redundant to check if pcm is null at line 865 [ppp/lqr.c:204]: (error) Possible null pointer dereference: p - otherwise it is redundant to check if p is null at line 207 [pwd_mkdb/pwd_mkdb.c:710]: (error) Resource leak: from_fd [pwd_mkdb/pwd_mkdb.c:710]: (error) Resource leak: to_fd [rpc.ypupdated/update.c:270]: (error) Resource leak: rf [rpc.ypupdated/update.c:317]: (error) Memory leak: tmpname [rpcbind/rpcb_svc_com.c:414]: (error) Resource leak: fd [rpcbind/rpcbind.c:661]: (error) Memory leak: pml [rtadvd/advcap.c:169]: (error) Resource leak: tf [sade/dmenu.c:120]: (error) Memory leak: var [sade/label.c:1231]: (error) Possible null pointer dereference: pi - otherwise it is redundant to check if pi is null at line 1233 [services_mkdb/uniq.c:126]: (error) Memory leak: cline [sicontrol/sicontrol.c:243]: (error) Memory leak: acp [sysinstall/config.c:426]: (error) Resource leak: rcSite [sysinstall/dispatch.c:465]: (error) Memory leak: list [sysinstall/dispatch.c:518]: (error) Memory leak: list [sysinstall/dispatch.c:562]: (error) Common realloc mistake: 'menu' nulled but not freed upon failure [sysinstall/dispatch.c:653]: (error) Memory leak: list [sysinstall/dmenu.c:160]: (error) Memory leak: var [sysinstall/index.c:715]: (error) Possible null pointer dereference: id - otherwise it is redundant to check if id is null at line 719 [sysinstall/label.c:1217]: (error) Possible null pointer dereference: pi - otherwise it is redundant to check if pi is null at line 1219 [sysinstall/media.c:538]: (error) Memory leak: ufsDevice.private [sysinstall/modules.c:168]: (error) Common realloc mistake: 'menu' nulled but not freed upon failure [sysinstall/modules.c:194]: (error) Possible null pointer dereference: menu [sysinstall/modules.c:204]: (error) Resource leak: dir [sysinstall/tcpip.c:284]: (error) Mismatching allocation and deallocation: ifp [sysinstall/tcpip.c:339]: (error) Mismatching allocation and deallocation: ifp [tzsetup/tzsetup.c:609]: (error) Resource leak: fd1 [tzsetup/tzsetup.c:627]: (error) Resource leak: fd2 [ypserv/yp_dnslookup.c:516]: (error) Memory leak: q [ypserv/yp_main.c:364]: (error) Memory leak: sname PS: Other catalogs as contrib, sys weren't checked - probably and it makes sense From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 12:26:06 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 720D61065675 for ; Fri, 18 Nov 2011 12:26:06 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm13-vm0.bullet.mail.sp2.yahoo.com (nm13-vm0.bullet.mail.sp2.yahoo.com [98.139.91.244]) by mx1.freebsd.org (Postfix) with SMTP id 527148FC08 for ; Fri, 18 Nov 2011 12:26:06 +0000 (UTC) Received: from [98.139.91.67] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 18 Nov 2011 12:13:18 -0000 Received: from [208.71.42.206] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 18 Nov 2011 12:13:18 -0000 Received: from [127.0.0.1] by smtp217.mail.gq1.yahoo.com with NNFMP; 18 Nov 2011 12:13:18 -0000 X-Yahoo-Newman-Id: 759634.23237.bm@smtp217.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: L_0B7kAVM1keuTtlHSFm1ZwF8cfnqp42lrNHMpPq2uG2s6E fb7dT7cRWyQ1vehP3y5lLLqRQFu1BTKJa3VfhFBsc8Y4aZa0XWj8XLXmixCP 1VeYP39EiRdsi7IRm7.bPZLY07OQLJv9HQ9mW5yvhoGjj6IGo8v1tv2BYShR P.x5Sl9xFfbECmrvqpJPopkEWToHAiA.wLSmZuaHeyriLlJXdvgW8R4qN8GJ xNQJiqYRiEdRBae1RsOJZRRsDTBQ.Uy5Q9E4upazMV9mtKg1f.4t0q2p0sCL hGkDpz0WmodJP0f.UrYO_isaF3fp0kfdpqFNvYaYsgPRKzCbqj1JEO1JX10d k2jqA3A.BPtms7yJOim84MS2.dGXFNj6u5KJdzBF_VtFZvTRneRRMAd8kxzE 2EDDGL3GmfxMWcCfk X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.20] (se@81.173.150.113 with plain) by smtp217.mail.gq1.yahoo.com with SMTP; 18 Nov 2011 04:13:18 -0800 PST Message-ID: <4EC64BDE.70801@freebsd.org> Date: Fri, 18 Nov 2011 13:13:18 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <20111117175514.274040@gmx.com> <4ec5e676.P+DwfO0SrmiegcuB%perryh@pluto.rain.com> In-Reply-To: <4ec5e676.P+DwfO0SrmiegcuB%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, dieterbsd@engineer.com Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 12:26:06 -0000 Am 18.11.2011 06:00, schrieb perryh@pluto.rain.com: > "Dieter BSD" wrote: >> IIRC some tape drives can seek, while others cannot. >> Vague memories that it is supposed to be possible to put a >> filesystem on a DECtape and mount the filesystem. > > Back in the Bell Labs 6th Edition days, it was possible to put > a filesystem on a _9-track magtape_ and mount it, although such > a mount had to be read-only since writing to a 9-track would > effectively delete any blocks following the one written. > I've done it. Access was painfully slow (no surprise), but > it did work. > > DECtape _could_ be updated in place. It was effectively the > linear equivalent of a floppy disk (before floppy disks existed). > Sequential access was slow. Random access was very slow. I dealt with quite a number of tape formats, long agao in a former millennium, and still remember a few details ... There used to be two types of tape: 9-track (and IIRC IBM3480/90) would write variable size blocks separated by gaps, while most other formats (QIC, DLT, Exabyte, DDS) used fix size sectors (some of them emulated variable block sizes by using a variable number of sectors per logical block with an interface similar to 9-track tape drives). These drives used block headers to hold information about (emulated) block sizes and to indicate file marks or EOT marks. Linear read speed was in the range of 60KB/s (QIC-150) to 800KB/s to 1MB/s (9-track, Exabyte 8500c with compressible data), 3MB/s (IBM3480), and 6MB (DLT8000). Very expensive high speed drives went to 60MB/s and possibly beyond, but only when streaming large files. While seeks are easy to implement for formats based on sectors (and e.g. Exabyte offered "fast" seeks to sectors), each tape block may contain any number of bytes on variable block size formats. This makes direct seeks to byte offsets impossible, while it is still possible to skip any number of block or file marks. Seek times depended on the data layout on tape: linear (9-track, 3490), serpentine (QIC, DLT), or helical scan (Exabtye, DDS). Linear and helical scan tapes can skip to file marks at high speed by retracting the R/W head or lifting the tape from the head (reduction of friction and wear), while serpentine tapes just move the head to a height near the target position (DLT drives have an index of file marks in a tape lead-in block just for this purpose, which makes seeks to file marks especially fast). Due to the different hardware characteristics of tape formats, the possible semantics of seek are different. And then there is the question of how to deal with file marks (i.e. whether seeks end at a file mark, as if the end of media had been encountered, or whether the seek proceeds after the file mark, possibly to end of tape). Some tape drives supported reading/seeking to a specific block and switching to write mode without any gap. There was different behavior with regard to file and EOT marks, e.g. whether a skip to filemark stopped before or after a file mark. All these differences made it hard to deal with seek/skip semantics in the kernel, and only a few operating systems had proprietary code to fully control the vendors drives (IBM, DEC). All others just made the low level functionality available to applications, e.g. via ioctl(), and let the application (e.g. backup software) implement support for all the different tape drive behaviors (especially important for fast restore of specific data from tape). I have no idea, whether tape drives are still in wide use. For the purposes that I administrated and used tapes for (gamma/particle coincidence spectroscopy and large numerical simulations), large disk arrays have completely replaced tape storage. Disk drives are cheaper than tape cartridges, today ... Regards, STefan From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 17:15:54 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA255106566C; Fri, 18 Nov 2011 17:15:54 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4CE7C8FC15; Fri, 18 Nov 2011 17:15:54 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so518146vbb.13 for ; Fri, 18 Nov 2011 09:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=xNbtsJiw94fYeLw3F9lSRqFMe9XCIsmIn/DtdUU1f3M=; b=Edca7CEj5DoOxVBYSV5m5ioHT3ZsFjmSeoWKFgdOtMwbjfJTspau2ggWRE+XHJW7dT d447X7JfjWh0FkqVLIGj6eTptNK8yyinqvPDJt9rWR8A/YC6KPeL0UEo16f0YMGYj/HD C9yKy+RqNwn5cyP55DIP7qN7Yzk6KubaWA4e0= MIME-Version: 1.0 Received: by 10.52.65.77 with SMTP id v13mr4195166vds.95.1321634900786; Fri, 18 Nov 2011 08:48:20 -0800 (PST) Received: by 10.52.101.132 with HTTP; Fri, 18 Nov 2011 08:48:20 -0800 (PST) Date: Fri, 18 Nov 2011 16:48:20 +0000 Message-ID: From: "Paul B. Mahol" To: FreeBSD-Current , FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Reprobing of devices after module load? 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, 18 Nov 2011 17:15:54 -0000 Hi, Is there nice way in FreeBSD to force reprobe of devices for specific driver like it is done when kernel module is loaded (via DRIVER_MODULE(...) stuff)? From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 19:49:42 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11910106564A for ; Fri, 18 Nov 2011 19:49:42 +0000 (UTC) (envelope-from brodbd@uw.edu) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7F38FC1D for ; Fri, 18 Nov 2011 19:49:41 +0000 (UTC) Received: by eyd10 with SMTP id 10so5370059eyd.13 for ; Fri, 18 Nov 2011 11:49:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.114.6 with SMTP id c6mr677631ebq.0.1321644417853; Fri, 18 Nov 2011 11:26:57 -0800 (PST) Received: by 10.213.113.197 with HTTP; Fri, 18 Nov 2011 11:26:57 -0800 (PST) In-Reply-To: <4EC64BDE.70801@freebsd.org> References: <20111117175514.274040@gmx.com> <4ec5e676.P+DwfO0SrmiegcuB%perryh@pluto.rain.com> <4EC64BDE.70801@freebsd.org> Date: Fri, 18 Nov 2011 11:26:57 -0800 Message-ID: From: David Brodbeck To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 19:49:42 -0000 On Fri, Nov 18, 2011 at 4:13 AM, Stefan Esser wrote: > I have no idea, whether tape drives are still in wide use. For the > purposes that I administrated and used tapes for (gamma/particle > coincidence spectroscopy and large numerical simulations), large disk > arrays have completely replaced tape storage. Disk drives are cheaper > than tape cartridges, today ... > > >From what I've seen, tape for *backup* is mostly going away; disk-to-disk backup is as cheap or cheaper and much faster. Tape for *archival*, however, is still alive and well; when you have many petabytes of data that you're required to keep in storage forever, but may or may not ever need to read again, tape still looks more attractive. In big installations the tape drives are often buffered by disk arrays to minimize backup time and allow the tape drives to stream more effectively. You also still see tape used a lot for offsite backups, although as Internet speeds have gone up more and more of that is happening by sending bits across the network instead of tapes over the highway. The bandwidth of the proverbial station wagon full of tapes is no longer quite as impressive as it used to be. ;) -- David Brodbeck System Administrator, Linguistics University of Washington From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 20:00:09 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3E751065670; Fri, 18 Nov 2011 20:00:09 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 69A798FC0C; Fri, 18 Nov 2011 20:00:09 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAIK086s066483; Fri, 18 Nov 2011 20:00:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id zk83czsjfxjswn2m2wcs2j5xdn; Fri, 18 Nov 2011 20:00:08 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <201111172055.pAHKtZso061118@triton8.kn-bremen.de> Date: Fri, 18 Nov 2011 12:00:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> <201111172055.pAHKtZso061118@triton8.kn-bremen.de> To: Juergen Lock X-Mailer: Apple Mail (2.1251.1) Cc: Alexander Best , freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 20:00:09 -0000 On Nov 17, 2011, at 12:55 PM, Juergen Lock wrote: >>=20 >> After a few experiments, bsdtar stopped using lseek() on >> FreeBSD for anything other than regular files and block >> devices. I believe there are other things that do support >> seeking, but I don't believe there is an accurate mechanism >> for determining whether lseek() is correctly supported. >=20 > Ah is that the reason why my patch never made it into FreeBSD 9? > I'm talking about this thread, where I also commented on seeking > on tape: >=20 > http://docs.freebsd.org/cgi/mid.cgi?20100220101724.GA26604 > (Re: "tar tfv /dev/cd0" speedup patch) >=20 > entire thread here: > http://markmail.org/message/nfznipqik3tuhbqp >=20 > Cheers, > Juergen (who would still like to see a faster "tar tfv = /dev/cd0"... :) I would like to see that as well. Take a look at=20 = http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_fi= lename.c Especially the comments about detecting "disk-like" devices. I rewrote a bunch of this code to introduce an explicit notion of "strategy" so that we could optimize access to a variety of different devices. This code has a notion of "disk-like" file descriptors and some optimizations for such. There are some comments in there outlining similar optimizations that could be made for "tape-like" or "socket-like" devices. Cheers, Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 20:31:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 6E883106566B; Fri, 18 Nov 2011 20:31:22 +0000 (UTC) Date: Fri, 18 Nov 2011 20:31:22 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20111118203122.GA9508@freebsd.org> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> <201111172055.pAHKtZso061118@triton8.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-hackers@freebsd.org, Juergen Lock Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 20:31:22 -0000 On Fri Nov 18 11, Tim Kientzle wrote: > > On Nov 17, 2011, at 12:55 PM, Juergen Lock wrote: > > >> > >> After a few experiments, bsdtar stopped using lseek() on > >> FreeBSD for anything other than regular files and block > >> devices. I believe there are other things that do support > >> seeking, but I don't believe there is an accurate mechanism > >> for determining whether lseek() is correctly supported. > > > > Ah is that the reason why my patch never made it into FreeBSD 9? > > I'm talking about this thread, where I also commented on seeking > > on tape: > > > > http://docs.freebsd.org/cgi/mid.cgi?20100220101724.GA26604 > > (Re: "tar tfv /dev/cd0" speedup patch) > > > > entire thread here: > > http://markmail.org/message/nfznipqik3tuhbqp > > > > Cheers, > > Juergen (who would still like to see a faster "tar tfv /dev/cd0"... :) > > I would like to see that as well. > > Take a look at > > http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c > > Especially the comments about detecting "disk-like" devices. > I rewrote a bunch of this code to introduce an explicit > notion of "strategy" so that we could optimize access > to a variety of different devices. > > This code has a notion of "disk-like" file descriptors and > some optimizations for such. There are some comments > in there outlining similar optimizations that could be made > for "tape-like" or "socket-like" devices. great you posted that file as reference. i believe most of the stuff done there should actually be done within lseek(). if userspace applications have to determine between file types they're operating on we're back to in the pre-unix days. ;) cheers. alex maybe support for block special files could completely be dropped, since freebsd seems to have entirely switched to character special files? > > Cheers, > > Tim > From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 20:32:14 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEF4B1065674; Fri, 18 Nov 2011 20:32:14 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9CAE08FC16; Fri, 18 Nov 2011 20:32:14 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id pAIKWEGC066606; Fri, 18 Nov 2011 20:32:14 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id uirspyp4pbtek6imj8ztbbhjca; Fri, 18 Nov 2011 20:32:14 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20111117214805.GA96937@freebsd.org> Date: Fri, 18 Nov 2011 12:32:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <34A2877A-977A-4668-8E37-642C6062AAC1@kientzle.com> References: <20111117175514.274040@gmx.com> <20111117214805.GA96937@freebsd.org> To: Alexander Best X-Mailer: Apple Mail (2.1251.1) Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 20:32:14 -0000 On Nov 17, 2011, at 1:48 PM, Alexander Best wrote: > On Thu Nov 17 11, Dieter BSD wrote: >>> lseek() on a tape drive does not return an error, nor does it >>> actually do anything. >>=20 >> IIRC some tape drives can seek, while others cannot. >> Vague memories that it is supposed to be possible to put a >> filesystem on a DECtape and mount the filesystem. >=20 > or how about the following: >=20 > 1) if the file argument we're seeking on is a tape drive, just do a = regular > seek operation. > 2) afterwards use ftell() to verify that the seek REALLY happend. if = it didn't, > return -1 and set errno =3D EBADF. ftell() can't tell whether the seek really happened or not. All it can do is ask the kernel, and the kernel doesn't know. Here is my current understanding: When you call lseek(), the kernel just stores the requested offset in the file descriptor. lseek() always succeeds because storing the requested offset in the file descriptor always succeeds. (Except that the kernel specially checks if the file descriptor is a pipe.) ftell() just obtains the data from the file descriptor. So it always succeeds and always returns the data from the previous seek request, regardless of whether that seek actually did anything. With the next read or write request, the device driver may inspect the offset information in the file descriptor. Or it can ignore it. Almost all tape device drivers ignore it. Filesystems uniformly support it. Disk drivers uniformly support it. Other drivers vary considerably. In short: No, there is no "easy way" to determine if an arbitrary stream or fd is seekable. If you try to create a function that determines this, be certain to include "Don't Know" as a possible return value. Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 20:53:26 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1BFD51065672; Fri, 18 Nov 2011 20:53:25 +0000 (UTC) Date: Fri, 18 Nov 2011 20:53:25 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20111118205325.GA12245@freebsd.org> References: <20111117175514.274040@gmx.com> <20111117214805.GA96937@freebsd.org> <34A2877A-977A-4668-8E37-642C6062AAC1@kientzle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34A2877A-977A-4668-8E37-642C6062AAC1@kientzle.com> Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 20:53:26 -0000 On Fri Nov 18 11, Tim Kientzle wrote: > On Nov 17, 2011, at 1:48 PM, Alexander Best wrote: > > > On Thu Nov 17 11, Dieter BSD wrote: > >>> lseek() on a tape drive does not return an error, nor does it > >>> actually do anything. > >> > >> IIRC some tape drives can seek, while others cannot. > >> Vague memories that it is supposed to be possible to put a > >> filesystem on a DECtape and mount the filesystem. > > > > or how about the following: > > > > 1) if the file argument we're seeking on is a tape drive, just do a regular > > seek operation. > > 2) afterwards use ftell() to verify that the seek REALLY happend. if it didn't, > > return -1 and set errno = EBADF. > > ftell() can't tell whether the seek really happened or not. > All it can do is ask the kernel, and the kernel doesn't know. > > Here is my current understanding: > > When you call lseek(), the kernel just stores the requested > offset in the file descriptor. lseek() always succeeds because > storing the requested offset in the file descriptor always succeeds. > (Except that the kernel specially checks if the file descriptor > is a pipe.) > > ftell() just obtains the data from the file descriptor. > So it always succeeds and always returns the data from > the previous seek request, regardless of whether that seek > actually did anything. > > With the next read or write request, the device driver may inspect the > offset information in the file descriptor. Or it can ignore > it. Almost all tape device drivers ignore it. Filesystems > uniformly support it. Disk drivers uniformly support it. > Other drivers vary considerably. > > In short: No, there is no "easy way" to determine if an > arbitrary stream or fd is seekable. If you try to create > a function that determines this, be certain to include > "Don't Know" as a possible return value. well it really depends what the goal is. it appears fixing fseek() for all cases is impossible then. however from a pragmatic point of view: why does a user have to wait for a command such as hd(1) or dd(1) working on files such as /dev/zero, /dev/null, /dev/(u)random or even /dev/ada* (only hd(1) -- dd(1) supports seeking here) for ages, although it could suceed in less than a second? the fact is: users care for speed and freebsd is slower than linux and openbsd in these cases. users aren't interested in the fact that lseek() won't work with tapes. most of them have probably never seen one (me included). if we return an error from within lseek() whenever lseek() was fired at a tape drive, wouldn't that cover 99% of all the possible cases? cheers. alex > > Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 21:06:16 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 18DED106567A; Fri, 18 Nov 2011 21:06:16 +0000 (UTC) Date: Fri, 18 Nov 2011 21:06:16 +0000 From: Alexander Best To: Tim Kientzle Message-ID: <20111118210616.GA15763@freebsd.org> References: <20111117175514.274040@gmx.com> <20111117214805.GA96937@freebsd.org> <34A2877A-977A-4668-8E37-642C6062AAC1@kientzle.com> <20111118205325.GA12245@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111118205325.GA12245@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 21:06:16 -0000 On Fri Nov 18 11, Alexander Best wrote: > On Fri Nov 18 11, Tim Kientzle wrote: > > On Nov 17, 2011, at 1:48 PM, Alexander Best wrote: > > > > > On Thu Nov 17 11, Dieter BSD wrote: > > >>> lseek() on a tape drive does not return an error, nor does it > > >>> actually do anything. > > >> > > >> IIRC some tape drives can seek, while others cannot. > > >> Vague memories that it is supposed to be possible to put a > > >> filesystem on a DECtape and mount the filesystem. > > > > > > or how about the following: > > > > > > 1) if the file argument we're seeking on is a tape drive, just do a regular > > > seek operation. > > > 2) afterwards use ftell() to verify that the seek REALLY happend. if it didn't, > > > return -1 and set errno = EBADF. > > > > ftell() can't tell whether the seek really happened or not. > > All it can do is ask the kernel, and the kernel doesn't know. > > > > Here is my current understanding: > > > > When you call lseek(), the kernel just stores the requested > > offset in the file descriptor. lseek() always succeeds because > > storing the requested offset in the file descriptor always succeeds. > > (Except that the kernel specially checks if the file descriptor > > is a pipe.) > > > > ftell() just obtains the data from the file descriptor. > > So it always succeeds and always returns the data from > > the previous seek request, regardless of whether that seek > > actually did anything. > > > > With the next read or write request, the device driver may inspect the > > offset information in the file descriptor. Or it can ignore > > it. Almost all tape device drivers ignore it. Filesystems > > uniformly support it. Disk drivers uniformly support it. > > Other drivers vary considerably. > > > > In short: No, there is no "easy way" to determine if an > > arbitrary stream or fd is seekable. If you try to create > > a function that determines this, be certain to include > > "Don't Know" as a possible return value. > > well it really depends what the goal is. it appears fixing fseek() for all > cases is impossible then. however from a pragmatic point of view: > > why does a user have to wait for a command such as hd(1) or dd(1) working on > files such as /dev/zero, /dev/null, /dev/(u)random or even /dev/ada* (only > hd(1) -- dd(1) supports seeking here) for ages, although it could suceed in > less than a second? > > the fact is: users care for speed and freebsd is slower than linux and openbsd > in these cases. users aren't interested in the fact that lseek() won't work > with tapes. most of them have probably never seen one (me included). > > if we return an error from within lseek() whenever lseek() was fired at a tape > drive, wouldn't that cover 99% of all the possible cases? something like the following inside lseek() would take care of tape drives: if (S_ISCHR(sb.st_mode) || S_ISBLK(sb.st_mode)) { if (ioctl(io->fd, FIODTYPE, &type) == -1) err(1, "%s", io->name); if (type & D_TAPE) return(EBADF) } cheers. alex > > cheers. > alex > > > > > Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 18 22:11:22 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50B2E106564A; Fri, 18 Nov 2011 22:11:22 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 078068FC08; Fri, 18 Nov 2011 22:11:21 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 04EB01E000C2; Fri, 18 Nov 2011 23:11:19 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id pAIMAC2t000372; Fri, 18 Nov 2011 23:10:12 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id pAIMABsg000371; Fri, 18 Nov 2011 23:10:11 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Fri, 18 Nov 2011 23:10:11 +0100 To: Tim Kientzle Message-ID: <20111118221011.GA99985@triton8.kn-bremen.de> References: <20111115202450.GA73512@freebsd.org> <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> <201111172055.pAHKtZso061118@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Fri, 18 Nov 2011 22:16:07 +0000 Cc: Alexander Best , Juergen Lock , freebsd-hackers@freebsd.org Subject: Re: easy way to determine if a stream or fd is seekable 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, 18 Nov 2011 22:11:22 -0000 On Fri, Nov 18, 2011 at 12:00:07PM -0800, Tim Kientzle wrote: > > On Nov 17, 2011, at 12:55 PM, Juergen Lock wrote: > > >> > >> After a few experiments, bsdtar stopped using lseek() on > >> FreeBSD for anything other than regular files and block > >> devices. I believe there are other things that do support > >> seeking, but I don't believe there is an accurate mechanism > >> for determining whether lseek() is correctly supported. > > > > Ah is that the reason why my patch never made it into FreeBSD 9? > > I'm talking about this thread, where I also commented on seeking > > on tape: > > > > http://docs.freebsd.org/cgi/mid.cgi?20100220101724.GA26604 > > (Re: "tar tfv /dev/cd0" speedup patch) > > > > entire thread here: > > http://markmail.org/message/nfznipqik3tuhbqp > > > > Cheers, > > Juergen (who would still like to see a faster "tar tfv /dev/cd0"... :) > > I would like to see that as well. > > Take a look at > > http://libarchive.googlecode.com/svn/trunk/libarchive/archive_read_open_filename.c > > Especially the comments about detecting "disk-like" devices. > I rewrote a bunch of this code to introduce an explicit > notion of "strategy" so that we could optimize access > to a variety of different devices. > > This code has a notion of "disk-like" file descriptors and > some optimizations for such. There are some comments > in there outlining similar optimizations that could be made > for "tape-like" or "socket-like" devices. Ah so it's `just' a slow release cycle? % grep DIOCGMEDIASIZE /home/ncvs/src/lib/libarchive/archive_read_open_filename.c,v % When will we see this code in FreeBSD? 10.0? 9.1? 8.3? :) Curious... Juergen From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 09:02:51 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FB7E106566B for ; Sat, 19 Nov 2011 09:02:51 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0253B8FC08 for ; Sat, 19 Nov 2011 09:02:50 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id pAJ92lrA097187 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 19 Nov 2011 01:02:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4EC770B7.8060806@freebsd.org> Date: Sat, 19 Nov 2011 01:02:47 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.24) Gecko/20111103 Thunderbird/3.1.16 MIME-Version: 1.0 To: Maxim Ignatenko References: <201111152218.41031.gelraen.ua@gmail.com> <20111116085508.GF36205@hoeg.nl> <4EC55669.2060908@freebsd.org> <4ec5632f.4b25df0a.1118.ffff9381@mx.google.com> In-Reply-To: <4ec5632f.4b25df0a.1118.ffff9381@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Communication between kernel and userspace via local socket 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, 19 Nov 2011 09:02:51 -0000 On 11/17/11 11:40 AM, Maxim Ignatenko wrote: > Julian Elischer wrote: > >> On 11/16/11 12:55 AM, Ed Schouten wrote: >>> * Maxim Ignatenko, 20111115 21:18: >>>> I'm currently inventing the wheel^W^W^Wwriting a firewall from scratch and >>>> looking for most convenient way to establish communication between >>>> userspace processes and kernel part. Communication pattern best fits to >>>> listening PF_LOCAL socket opened from kernel and userspace processes >>>> connecting to it. >>> What's wrong with a character device? >> you can't easily have a different character device depending on which >> jail you are in.. >> (well, you can but it gets tricky).. see the problem with /dev/pflog >> and vimages. >> >> >> Maxim, look at the usage of sockets with netgraph ng_socket node.. also >> divert sockets. >> > Did you meant ng_ksocket? I've looked on it, but in case of ng_ksocket > connections accepted upon receiving control message NGM_KSOCKET_ACCEPT, but I > need to accept connections without such "punch". As far as I understand, I > need to spawn kernel process or thread which will listen for incoming > connections and respond to requests, just like normal network daemon does, but > I don't know how to do this. > divert(4) will not do the job, since packets written to divert socket goes to > IP stack. No I meant ng_socket.. you wanted to communicate between userland and kernel. that ng_socket is the interface between kernel and userland for netgraph. I also meant, "look at how the divert sockets create the sockets", not that you should use divert. ng_ksocket is something else. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 10:14:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 796201065670; Sat, 19 Nov 2011 10:14:48 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D5DC28FC12; Sat, 19 Nov 2011 10:14:47 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5972633bkb.13 for ; Sat, 19 Nov 2011 02:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=b9RbveUiwlCAzQRlSUvzOu51PgQBiNAnGegwDMlHfq4=; b=Dqs3GrCrZsj6EaQiTUFTZp9X7SXnO8+rn9OqqzmWd660ShyIgL1yfg6le7nyOTVOjT sgEk5NtT2m9RNtVShCAl1i3GEIBXm14TpZhDDfcToNcZuReRxq7yW4MVNIzj5fXRFdLw KWZPn+vJw+097pT2HT7N5ONx4Fl6pT79dbZfM= Received: by 10.204.129.88 with SMTP id n24mr6851282bks.19.1321697686196; Sat, 19 Nov 2011 02:14:46 -0800 (PST) Received: from imax.localnet (35-86-200-46.pool.ukrtel.net. [46.200.86.35]) by mx.google.com with ESMTPS id n25sm8238838fah.15.2011.11.19.02.14.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Nov 2011 02:14:44 -0800 (PST) From: Maxim Ignatenko To: Julian Elischer Date: Sat, 19 Nov 2011 12:14:36 +0200 User-Agent: KMail/1.13.7 (FreeBSD/8.2-STABLE; KDE/4.7.3; i386; ; ) References: <201111152218.41031.gelraen.ua@gmail.com> <4ec5632f.4b25df0a.1118.ffff9381@mx.google.com> <4EC770B7.8060806@freebsd.org> In-Reply-To: <4EC770B7.8060806@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201111191214.36824.gelraen.ua@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Communication between kernel and userspace via local socket 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, 19 Nov 2011 10:14:48 -0000 On =D1=81=D0=B1, 19 =D0=BB=D0=B8=D1=81 2011 11:02:47 Julian Elischer wrote: > On 11/17/11 11:40 AM, Maxim Ignatenko wrote: > > Julian Elischer wrote: > >> On 11/16/11 12:55 AM, Ed Schouten wrote: > >>> * Maxim Ignatenko, 20111115 21:18: > >>>> I'm currently inventing the wheel^W^W^Wwriting a firewall from scrat= ch > >>>> and looking for most convenient way to establish communication > >>>> between userspace processes and kernel part. Communication pattern > >>>> best fits to listening PF_LOCAL socket opened from kernel and > >>>> userspace processes connecting to it. > >>>=20 > >>> What's wrong with a character device? > >>=20 > >> you can't easily have a different character device depending on which > >> jail you are in.. > >> (well, you can but it gets tricky).. see the problem with /dev/pflog > >> and vimages. > >>=20 > >>=20 > >> Maxim, look at the usage of sockets with netgraph ng_socket node.. al= so > >> divert sockets. > >=20 > > Did you meant ng_ksocket? I've looked on it, but in case of ng_ksocket > > connections accepted upon receiving control message NGM_KSOCKET_ACCEPT, > > but I need to accept connections without such "punch". As far as I > > understand, I need to spawn kernel process or thread which will listen > > for incoming connections and respond to requests, just like normal > > network daemon does, but I don't know how to do this. > > divert(4) will not do the job, since packets written to divert socket > > goes to IP stack. >=20 > No I meant ng_socket.. you wanted to communicate between userland and > kernel. > that ng_socket is the interface between kernel and userland for netgraph. >=20 Thanks! Creating new domain is, probably, overkill, but should work :) From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 10:23:48 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93581106566B for ; Sat, 19 Nov 2011 10:23:48 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 25BFA8FC08 for ; Sat, 19 Nov 2011 10:23:47 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so5980442bkb.13 for ; Sat, 19 Nov 2011 02:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=2aANlYcmb9mFMjVZgQWr2r0Bi3ixzDVc5GWkIh3oFqM=; b=VTvQ7jF5IB/kqjDusvyprEsR6p9aLovGtMwvmDagDY6koq8YL23o+GPQwkUcbFqPxK s5bOZIerwyhIdNerUqaHtv/RjZ+UKIu8y9dBVyU9rFxGh65S/ZJn2vtYoa3mpyxZAkhb NiOGth3hLk4pTvJxGdV+OowVmMswMo8SrlkY0= Received: by 10.204.41.66 with SMTP id n2mr6875197bke.77.1321696910834; Sat, 19 Nov 2011 02:01:50 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id c4sm2659701bkk.13.2011.11.19.02.01.49 (version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 02:01:49 -0800 (PST) Date: Sat, 19 Nov 2011 12:01:50 +0200 From: Gleb Kurtsou To: freebsd-hackers@FreeBSD.org Message-ID: <20111119100150.GA1560@reks> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mdf@freebsd.org Subject: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 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, 19 Nov 2011 10:23:48 -0000 Hi, I was lucky to write a bit of code which gcc 4.2 fails to compile correctly with -O2. Too keep long story short the code fails for gcc from base system and last gcc 4.2 snapshot from ports. It works with gcc 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and -Os optimization levels are fine (I've tried with all -f* flags mentioned in documentation) -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I presume i386 should be fine. These options are also used for compilation of kernel (with debugging enabled) and modules. I'm not able to share the code, but have a test case reproducing the bug. I've encountered the issue over a week ago and tried narrowing it down to a simple test I could share but without much success. The code itself is very common: initialize two structs on stack, call a function with pointers to those stucts as arguments. A number of inlined assertion functions. gcc fails to correctly optimize struct assignments with -fno-omit-frame-pointer, I have a number of small structs assigned, gcc decides not to use data coping but to assign fields directly. I've tried disabling sra, tweaking sra parameters -- no luck in forcing it to copy data. Replacing one particular assignment with memcpy produces correct code, but that's not a solution. -O2 -fno-omit-frame-pointer -fno-inline is buggy -O2 -fno-omit-frame-pointer -frename-registers is buggy I found similar issue with gcc 4.6, but I'm not able to reproduce it with gcc test case: https://bugzilla.redhat.com/show_bug.cgi?id=679924 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 I'll be glad to help debugging it and will be hanging on #bsddev during weekend as glk. Thanks, Gleb. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 12:25:38 2011 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D6197106566C; Sat, 19 Nov 2011 12:25:38 +0000 (UTC) Date: Sat, 19 Nov 2011 12:25:38 +0000 From: Alexander Best To: Gleb Kurtsou Message-ID: <20111119122538.GA47771@freebsd.org> References: <20111119100150.GA1560@reks> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111119100150.GA1560@reks> Cc: freebsd-hackers@FreeBSD.org, mdf@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 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, 19 Nov 2011 12:25:38 -0000 On Sat Nov 19 11, Gleb Kurtsou wrote: > Hi, > > I was lucky to write a bit of code which gcc 4.2 fails to compile > correctly with -O2. Too keep long story short the code fails for gcc > from base system and last gcc 4.2 snapshot from ports. It works with gcc > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and > -Os optimization levels are fine (I've tried with all -f* flags > mentioned in documentation) > > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > presume i386 should be fine. These options are also used for > compilation of kernel (with debugging enabled) and modules. > > I'm not able to share the code, but have a test case reproducing the > bug. I've encountered the issue over a week ago and tried narrowing it down > to a simple test I could share but without much success. > > The code itself is very common: initialize two structs on stack, call a > function with pointers to those stucts as arguments. A number of inlined > assertion functions. gcc fails to correctly optimize struct assignments > with -fno-omit-frame-pointer, I have a number of small structs assigned, > gcc decides not to use data coping but to assign fields directly. I've > tried disabling sra, tweaking sra parameters -- no luck in forcing it > to copy data. Replacing one particular assignment with memcpy produces > correct code, but that's not a solution. > > -O2 -fno-omit-frame-pointer -fno-inline is buggy > -O2 -fno-omit-frame-pointer -frename-registers is buggy does the issue also come up with '-fno-builtin' in addition to those flags? is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist when using -O1 and -O3? cheers. alex > > I found similar issue with gcc 4.6, but I'm not able to reproduce it > with gcc test case: > https://bugzilla.redhat.com/show_bug.cgi?id=679924 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 > > I'll be glad to help debugging it and will be hanging on #bsddev during > weekend as glk. > > > Thanks, > Gleb. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 13:39:15 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C38601065673 for ; Sat, 19 Nov 2011 13:39:15 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 572A68FC0C for ; Sat, 19 Nov 2011 13:39:14 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so6167746bkb.13 for ; Sat, 19 Nov 2011 05:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=F1574QhwP6LPV1Bgsi9THsZupx8uP3SqsdM008StNrw=; b=kQD5P7r1pYT+AQCSHBeK+WWvIqXkv/a3NsWMXHUvUd8iRAMdO4GDku5NiKJvUf+jn6 ne2rdDZW1/aw5ZYX3oIBezasj3Akdfq49QpLJfJliJ9DvatCbmxqgwISiHqJBtRSbSbj 0JZ65cEOaxIi5N4zXuPpaPeH0l3NwSWfrxodM= Received: by 10.204.148.4 with SMTP id n4mr7522014bkv.42.1321709954222; Sat, 19 Nov 2011 05:39:14 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id j9sm3015176bkd.2.2011.11.19.05.39.12 (version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 05:39:13 -0800 (PST) Date: Sat, 19 Nov 2011 15:39:13 +0200 From: Gleb Kurtsou To: Alexander Best Message-ID: <20111119133913.GA87101@reks> References: <20111119100150.GA1560@reks> <20111119122538.GA47771@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20111119122538.GA47771@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 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, 19 Nov 2011 13:39:15 -0000 On (19/11/2011 12:25), Alexander Best wrote: > On Sat Nov 19 11, Gleb Kurtsou wrote: > > Hi, > > > > I was lucky to write a bit of code which gcc 4.2 fails to compile > > correctly with -O2. Too keep long story short the code fails for gcc > > from base system and last gcc 4.2 snapshot from ports. It works with gcc > > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and > > -Os optimization levels are fine (I've tried with all -f* flags > > mentioned in documentation) > > > > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > > presume i386 should be fine. These options are also used for > > compilation of kernel (with debugging enabled) and modules. > > > > I'm not able to share the code, but have a test case reproducing the > > bug. I've encountered the issue over a week ago and tried narrowing it down > > to a simple test I could share but without much success. > > > > The code itself is very common: initialize two structs on stack, call a > > function with pointers to those stucts as arguments. A number of inlined > > assertion functions. gcc fails to correctly optimize struct assignments > > with -fno-omit-frame-pointer, I have a number of small structs assigned, > > gcc decides not to use data coping but to assign fields directly. I've > > tried disabling sra, tweaking sra parameters -- no luck in forcing it > > to copy data. Replacing one particular assignment with memcpy produces > > correct code, but that's not a solution. > > > > -O2 -fno-omit-frame-pointer -fno-inline is buggy > > -O2 -fno-omit-frame-pointer -frename-registers is buggy > > does the issue also come up with '-fno-builtin' in addition to those flags? > is '-O2 -fno-omit-frame-pointer' alone also buggy? does the issue also exist > when using -O1 and -O3? -O0 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -Os -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK -O -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O1 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -- BAD -O2 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-builtin -fno-strict-aliasing -- BAD -O3 -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK!! -O3 -fno-inline-functions -fno-unswitch-loops -fno-gcse-after-reload -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O3 -fno-inline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- BAD -O2 -finline-functions -g -std=gnu99 -pipe -fno-omit-frame-pointer -fno-strict-aliasing -- OK So, it's -finline-functions that makes it work. But I'm afraid it just masks the real problem. The rest of CFLAGS is warnings and includes: -D_GNU_SOURCE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wno-write-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -Wstrict-aliasing=2 -Wno-error=strict-aliasing > > cheers. > alex > > > > > I found similar issue with gcc 4.6, but I'm not able to reproduce it > > with gcc test case: > > https://bugzilla.redhat.com/show_bug.cgi?id=679924 > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47893 > > > > I'll be glad to help debugging it and will be hanging on #bsddev during > > weekend as glk. > > > > > > Thanks, > > Gleb. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 15:26:45 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAB24106566C for ; Sat, 19 Nov 2011 15:26:45 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B4FF8FC08 for ; Sat, 19 Nov 2011 15:26:45 +0000 (UTC) Received: by yenl11 with SMTP id l11so5036227yen.13 for ; Sat, 19 Nov 2011 07:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eaJDJ7lyrUkC/1HHESuNDJ91LzbDg7oO2Y7G/D0MAdo=; b=DANtUlk0BuYCLyG3ypOA91pmoJKKQFsNMy7iBmdQ/aMOJ32yCa7DX4A7MAAjMXsW8t WTWkW00lN58WMJ1dhXO9j4W7aY+BbvYB1DO5baMwvg4OrgWoTPpYl6FjFugk8BlM20i7 PTuW1O1MxnCIg9ebKtqDIz71LeVyfD5LhG/js= MIME-Version: 1.0 Received: by 10.68.59.73 with SMTP id x9mr14380265pbq.42.1321716404321; Sat, 19 Nov 2011 07:26:44 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Sat, 19 Nov 2011 07:26:44 -0800 (PST) In-Reply-To: <20111119100150.GA1560@reks> References: <20111119100150.GA1560@reks> Date: Sat, 19 Nov 2011 07:26:44 -0800 X-Google-Sender-Auth: WgKoJTlMnz30PrxC_Zw-1TPrl3Q Message-ID: From: mdf@FreeBSD.org To: Gleb Kurtsou Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 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, 19 Nov 2011 15:26:45 -0000 On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou wrote: > Hi, > > I was lucky to write a bit of code which gcc 4.2 fails to compile > correctly with -O2. Too keep long story short the code fails for gcc > from base system and last gcc 4.2 snapshot from ports. It works with gcc > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and > -Os optimization levels are fine (I've tried with all -f* flags > mentioned in documentation) > > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > presume i386 should be fine. These options are also used for > compilation of kernel (with debugging enabled) and modules. > > I'm not able to share the code, but have a test case reproducing the > bug. I've encountered the issue over a week ago and tried narrowing it down > to a simple test I could share but without much success. > > The code itself is very common: initialize two structs on stack, call a > function with pointers to those stucts as arguments. A number of inlined > assertion functions. gcc fails to correctly optimize struct assignments > with -fno-omit-frame-pointer, I have a number of small structs assigned, > gcc decides not to use data coping but to assign fields directly. I've > tried disabling sra, tweaking sra parameters -- no luck in forcing it > to copy data. Replacing one particular assignment with memcpy produces > correct code, but that's not a solution. How small are the structs? gcc has an optimization for structs that are no larger than a register, but it's buggy in 4.2 and we disabled it at $WORK. I can dig up the patch if this is the problem. Thanks, matthew From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 16:20:01 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCCFE1065670; Sat, 19 Nov 2011 16:20:01 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2A63A8FC12; Sat, 19 Nov 2011 16:20:00 +0000 (UTC) Received: by bkbzs8 with SMTP id zs8so6321073bkb.13 for ; Sat, 19 Nov 2011 08:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=runb1jEGd8Qg8JOmiu2GJphSi7GojDIU3zyj4QWUfyU=; b=sc/5znHrvgqU23LXtubfEihdGtp8cUTUd2MOXxEH9tyWYFeeWGQm0I7JtKBeKRN/6a 3YQgbfYAck+7+7eFmJoLCNuE49mYjmcKGPprsJbKlIntwzvFMfmgnVRlV4w8XurkqDNJ 6zY9nYjPMdxBdwA+rISO3VBrLvhlnGt25zYBo= Received: by 10.205.126.13 with SMTP id gu13mr7840081bkc.114.1321719600123; Sat, 19 Nov 2011 08:20:00 -0800 (PST) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id o7sm3204331bkw.16.2011.11.19.08.19.58 (version=SSLv3 cipher=OTHER); Sat, 19 Nov 2011 08:19:58 -0800 (PST) Date: Sat, 19 Nov 2011 18:19:59 +0200 From: Gleb Kurtsou To: mdf@FreeBSD.org Message-ID: <20111119161958.GA91681@reks> References: <20111119100150.GA1560@reks> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 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, 19 Nov 2011 16:20:01 -0000 On (19/11/2011 07:26), mdf@FreeBSD.org wrote: > On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou wrote: > > Hi, > > > > I was lucky to write a bit of code which gcc 4.2 fails to compile > > correctly with -O2. Too keep long story short the code fails for gcc > > from base system and last gcc 4.2 snapshot from ports. It works with gcc > > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O and > > -Os optimization levels are fine (I've tried with all -f* flags > > mentioned in documentation) > > > > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I > > presume i386 should be fine. These options are also used for > > compilation of kernel (with debugging enabled) and modules. > > > > I'm not able to share the code, but have a test case reproducing the > > bug. I've encountered the issue over a week ago and tried narrowing it down > > to a simple test I could share but without much success. > > > > The code itself is very common: initialize two structs on stack, call a > > function with pointers to those stucts as arguments. A number of inlined > > assertion functions. gcc fails to correctly optimize struct assignments > > with -fno-omit-frame-pointer, I have a number of small structs assigned, > > gcc decides not to use data coping but to assign fields directly. I've > > tried disabling sra, tweaking sra parameters -- no luck in forcing it > > to copy data. Replacing one particular assignment with memcpy produces > > correct code, but that's not a solution. > > How small are the structs? gcc has an optimization for structs that > are no larger than a register, but it's buggy in 4.2 and we disabled > it at $WORK. I can dig up the patch if this is the problem. struct sockaddr_in in this particular test. 16 bytes. Register size structs are rather common, e.g. struct in_addr. I could test the patch. Adding -finline-functions seems to fix the issue for me. Thanks, Gleb. > > Thanks, > matthew From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 19 17:11:04 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0D661065674 for ; Sat, 19 Nov 2011 17:11:04 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8EA848FC14 for ; Sat, 19 Nov 2011 17:11:04 +0000 (UTC) Received: by ywe9 with SMTP id 9so5125092ywe.13 for ; Sat, 19 Nov 2011 09:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T1T/drm0jNnTXxdlU/U5pwJK54NQm/G/b8u848NCcLE=; b=m1SGxdn00bCXrhaWQuUsgmkw9ixGU+KV5Z5KFH1dO4GrCk0+rJceZI98eWUff4kQfw n7qHLYx69HEDKwjCcNV9pR44F75zXwRL+W+9Ic3cYO9E2vv9I+IIp+MGbVxMuWCh7Foj NnRx+KMa/eH36aGhTnu9hCRu9t0rwmNrz4eDI= MIME-Version: 1.0 Received: by 10.68.21.162 with SMTP id w2mr15823386pbe.25.1321722663368; Sat, 19 Nov 2011 09:11:03 -0800 (PST) Sender: mdf356@gmail.com Received: by 10.68.56.97 with HTTP; Sat, 19 Nov 2011 09:11:03 -0800 (PST) In-Reply-To: <20111119161958.GA91681@reks> References: <20111119100150.GA1560@reks> <20111119161958.GA91681@reks> Date: Sat, 19 Nov 2011 09:11:03 -0800 X-Google-Sender-Auth: gYP-nPg9s9Dsp1WsEOcNEa2xOyQ Message-ID: From: mdf@FreeBSD.org To: Gleb Kurtsou Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: gcc 4.2 miscompilation with -O2 -fno-omit-frame-pointer on amd64 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, 19 Nov 2011 17:11:05 -0000 On Sat, Nov 19, 2011 at 8:19 AM, Gleb Kurtsou wrot= e: > On (19/11/2011 07:26), mdf@FreeBSD.org wrote: >> On Sat, Nov 19, 2011 at 2:01 AM, Gleb Kurtsou w= rote: >> > Hi, >> > >> > I was lucky to write a bit of code which gcc 4.2 fails to compile >> > correctly with -O2. Too keep long story short the code fails for gcc >> > from base system and last gcc 4.2 snapshot from ports. It works with g= cc >> > 4.3, gcc 4.4 on FreeBSD and Linux. Clang from base is also good. -O an= d >> > -Os optimization levels are fine (I've tried with all -f* flags >> > mentioned in documentation) >> > >> > -O2 -fno-omit-frame-pointer combination is troublesome on amd64. I >> > presume i386 should be fine. These options are also used for >> > compilation of kernel (with debugging enabled) and modules. >> > >> > I'm not able to share the code, but have a test case reproducing the >> > bug. I've encountered the issue over a week ago and tried narrowing it= down >> > to a simple test I could share but without much success. >> > >> > The code itself is very common: initialize two structs on stack, call = a >> > function with pointers to those stucts as arguments. A number of inlin= ed >> > assertion functions. gcc fails to correctly optimize struct assignment= s >> > with -fno-omit-frame-pointer, I have a number of small structs assigne= d, >> > gcc decides not to use data coping but to assign fields directly. I've >> > tried disabling sra, tweaking sra parameters -- no luck in forcing it >> > to copy data. Replacing one particular assignment with memcpy produces >> > correct code, but that's not a solution. >> >> How small are the structs? =A0gcc has an optimization for structs that >> are no larger than a register, but it's buggy in 4.2 and we disabled >> it at $WORK. =A0I can dig up the patch if this is the problem. > struct sockaddr_in in this particular test. 16 bytes. > > Register size structs are rather common, e.g. struct in_addr. > > I could test the patch. Adding -finline-functions seems to fix the issue > for me. I can't find the thing I'm thinking of. The only potentially relevant patch I see in our gcc sources is this: Index: opts.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- opts.c (.../vendor.branches/freebsd/stable/7/src/contrib/gcc/opts.c) (r= evision 211574) +++ opts.c (.../head/src/contrib/gcc/opts.c) (revision 211574) @@ -457,11 +457,7 @@ flag_tree_dse =3D 1; flag_tree_ter =3D 1; flag_tree_live_range_split =3D 1; + /** + * 7dot1MERGE: tree-sra in gcc 4.2.x is buggy and + * breaks bitfield structs. + */ + flag_tree_sra =3D 0; - flag_tree_sra =3D 1; flag_tree_copyrename =3D 1; flag_tree_fre =3D 1; flag_tree_copy_prop =3D 1; Thanks, matthew