From owner-freebsd-hackers@freebsd.org Sun Feb 26 12:25:59 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F73ECEC560 for ; Sun, 26 Feb 2017 12:25:59 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 82201BFE for ; Sun, 26 Feb 2017 12:25:57 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 26 Feb 2017 13:25:49 +0100 id 00F4BCCC.58B2C94D.00012E0C Date: Sun, 26 Feb 2017 13:25:48 +0100 From: Milan Obuch To: freebsd-hackers@freebsd.org Subject: kern.ostype - where gets its value? Message-ID: <20170226132548.69223dcd@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 12:25:59 -0000 Hi, I am building FreeBSD from source all the time, and recently I realised there is something I do not fully understand. I use 'svn update' to fetch current source tree and for various devices I share this tree via nfs. It is at least convenient for smaller devices like Orange Pi or Pine64, svn is run once and used on more devices. This has one effect I do not like - kernel compiled on machine used for 'svn update' gets full version information including svn revision number, as in # uname -v FreeBSD 10.3-STABLE #0 r313019: Wed Feb 1 07:07:02 CET 2017 root@tiny.dino.sk:/usr/obj/usr/src/sys/TINY (line wrapped) versus missing revision as in # uname -v FreeBSD 12.0-CURRENT #0: Thu Feb 2 05:00:09 CET 2017 root@tiny.dino.sk:/usr/obj/usr/src/sys/ALLWINNER_ONE (again, line wrapped by mailer, by these are just an examples). =46rom my experience it looks like this problem is caused by svn not being able to be run on nfs mounted directory, no matter the architecture - today I tried with both server and client running 10.3-STABLE on i386, svn just fails. So I think this is root cause for missing svn revision number, buildkernel process somehow uses svn to fetch svn revision number, fails, and then just omits it. If I undestand it right, this information is put into /sys/kern/kern_mib.c file's kern.version sysctl, maybe via some include or some generated .c file is used for it. Could someone point me to the right direction how is this done? I would like to find at least some workaround for that... Regards, Milan From owner-freebsd-hackers@freebsd.org Sun Feb 26 13:06:49 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE0A6CED786 for ; Sun, 26 Feb 2017 13:06:49 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 616CDBB0 for ; Sun, 26 Feb 2017 13:06:48 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 26 Feb 2017 14:06:46 +0100 id 00F4BCCC.58B2D2E6.0001316A Date: Sun, 26 Feb 2017 14:06:45 +0100 From: Milan Obuch To: Daniel Shahaf Cc: freebsd-hackers@freebsd.org Subject: Re: kern.ostype - where gets its value? Message-ID: <20170226140645.5d3ad3c1@zeta.dino.sk> In-Reply-To: <20170226124742.GA10967@fujitsu.shahaf.local2> References: <20170226132548.69223dcd@zeta.dino.sk> <20170226124742.GA10967@fujitsu.shahaf.local2> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 13:06:50 -0000 On Sun, 26 Feb 2017 12:47:42 +0000 Daniel Shahaf wrote: > Milan Obuch wrote on Sun, Feb 26, 2017 at 13:25:48 +0100: > > From my experience it looks like this problem is caused by svn not > > being able to be run on nfs mounted directory, no matter the > > architecture - today I tried with both server and client running > > 10.3-STABLE on i386, svn just fails. > > svn can work over nfs provided that locking is supported. > How could I find whether locking is supported/make sure it is? > > So I think this is root cause for missing svn revision number, > > buildkernel process somehow uses svn to fetch svn revision number, > > fails, and then just omits it. If I undestand it right, this > > information is put into /sys/kern/kern_mib.c file's kern.version > > sysctl, maybe via some include or some generated .c file is used for > > it. Could someone point me to the right direction how is this done? > > I would like to find at least some workaround for that... > > sys/conf/newvers.sh, grep for 'svnversion'. Thanks, I knew it is something like that, I found vers.c file just moment ago, it is probably output of this script... Regards, Milan From owner-freebsd-hackers@freebsd.org Sun Feb 26 12:52:23 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61E63CED303 for ; Sun, 26 Feb 2017 12:52:23 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37885E8D for ; Sun, 26 Feb 2017 12:52:22 +0000 (UTC) (envelope-from danielsh@apache.org) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 60C5A20792; Sun, 26 Feb 2017 07:52:21 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sun, 26 Feb 2017 07:52:21 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=jiRirI5r6hAHZ9 f/l4WxcqkwfGA=; b=CqQl5Bu2aaGQI2Ncq4xxz3ig6MzJxfv6w5WizdIlfNTaPh YoCxzUsNBn3Qepgg2QjxHCXdncAbeOsHmuVFRHbQF7XaYtj/pCrHWrU10evUbOks wqWqpe7evIHlrbHFY/30CAoFgsZD924VB2Q3o/FjVThKgOUHwYq1OQJ/iEZao= X-ME-Sender: X-Sasl-enc: dslLIDG/z0gvy0pz4SOGEvJG4F2Aw86DQh8PSgYy2xpz 1488113540 Received: from fujitsu.shahaf.local2 (bzq-109-65-57-127.red.bezeqint.net [109.65.57.127]) by mail.messagingengine.com (Postfix) with ESMTPA id E90257E2B2; Sun, 26 Feb 2017 07:52:20 -0500 (EST) Received: by fujitsu.shahaf.local2 (Postfix, from userid 1000) id 3vWPkk5z2Jz21X; Sun, 26 Feb 2017 12:47:42 +0000 (UTC) Date: Sun, 26 Feb 2017 12:47:42 +0000 From: Daniel Shahaf To: Milan Obuch Cc: freebsd-hackers@freebsd.org Subject: Re: kern.ostype - where gets its value? Message-ID: <20170226124742.GA10967@fujitsu.shahaf.local2> References: <20170226132548.69223dcd@zeta.dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170226132548.69223dcd@zeta.dino.sk> User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Sun, 26 Feb 2017 13:19:50 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 12:52:23 -0000 Milan Obuch wrote on Sun, Feb 26, 2017 at 13:25:48 +0100: > From my experience it looks like this problem is caused by svn not > being able to be run on nfs mounted directory, no matter the > architecture - today I tried with both server and client running > 10.3-STABLE on i386, svn just fails. svn can work over nfs provided that locking is supported. > So I think this is root cause for missing svn revision number, > buildkernel process somehow uses svn to fetch svn revision number, > fails, and then just omits it. If I undestand it right, this > information is put into /sys/kern/kern_mib.c file's kern.version > sysctl, maybe via some include or some generated .c file is used for > it. Could someone point me to the right direction how is this done? I > would like to find at least some workaround for that... sys/conf/newvers.sh, grep for 'svnversion'. From owner-freebsd-hackers@freebsd.org Sun Feb 26 14:15:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA3AACEEBC2; Sun, 26 Feb 2017 14:15:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B6A1CFB3; Sun, 26 Feb 2017 14:15:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA10301; Sun, 26 Feb 2017 16:15:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1chzbJ-0003XF-3f; Sun, 26 Feb 2017 16:15:01 +0200 Subject: Re: firefox crashes during pkg upgrade To: Konstantin Belousov References: <567BF197.10908@FreeBSD.org> <2a4cad57-ddbf-6ef0-13e6-c2d24280fd24@FreeBSD.org> <20170130104041.GK3018@kib.kiev.ua> Cc: freebsd-gecko@FreeBSD.org, FreeBSD Hackers From: Andriy Gapon Message-ID: Date: Sun, 26 Feb 2017 16:14:04 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170130104041.GK3018@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 14:15:09 -0000 On 30/01/2017 12:40, Konstantin Belousov wrote: > On Mon, Jan 30, 2017 at 12:13:34PM +0200, Andriy Gapon wrote: >> On 24/12/2015 15:22, Andriy Gapon wrote: >>> I've got a strange problem: sometime when I do pkg upgrade a firefox process >>> crashes with SIGBUS. And that happens rather often. >> >> I am still seeing this problem. Sometimes it's firefox, sometimes thunderbird, >> sometimes none, sometimes both. >> >> In all cases the crashes involve libgio. >> >> Here is the latest example. >> Thunderbird aborted after hitting an assertion: >> GLib-GIO:ERROR:glocalfilemonitor.c:344:g_file_monitor_source_handle_event: >> assertion failed: (!child || is_basename (child)) >> Redirecting call to abort() to mozalloc_abort [snip] >> The above string is the value of 'child' parameter. >> It seems like it points to some invalid memory. >> Given that 'Z' is 0x5a it seems like freed memory. > > I am not sure that my issue is same as your issue, but I also see gtk > applications sometimes faulting during the packages updates. There is probably more than issue then. I managed to reproduce my issue with more debugging information: https://bugzilla.gnome.org/show_bug.cgi?id=779060 > If you > take a look into firefox address map, there are the following interesting > items: > 1356 0x8023a1000 0x8023c1000 r-- 32 32 4 0 ---- vn /var/db/fontconfig/a2bfc4e431963a28dd6df8adc7776b96-le64.cache-7 > 1356 0x80797a000 0x8079b9000 r-- 39 44 2 0 CN-- vn /usr/sfw/local8/share/fonts/webfonts/tahoma.ttf > 1356 0x80eeb0000 0x80eecf000 r-- 16 16 1 0 ---- vn /usr/sfw/local8/share/mime/mime.cache > 1356 0x80eecf000 0x80eedd000 r-- 14 14 2 0 CN-- vn /usr/sfw/local8/share/icons/Adwaita/icon-theme.cache > 1356 0x80ee1e000 0x80ee4a000 r-- 44 44 1 0 CN-- vn /usr/home/kostik/.mozilla/firefox/q3eu9l5y.default/extensions/compatibility@addons.mozilla.org.xpi > 1356 0x815800000 0x817100000 r-- 256 260 1 0 ---- vn /usr/sfw/local8/share/icu/58.2/icudt58l.dat > > They are many different things I picked, e.g. the fontconfig cache files, > ttf fonts, some icons pointers, xpi extentions, probably there are more > things to list. The common between them is the fact that they are mapped > into the target process, but they are not ELF shared objects. More, I > know that at least fontconfig and icons caches are rebuilt at the package > install or upgrade time. > > The problem with them is that the files are filled with the new data live. > This means that the previous mapping potentially shrinked, and previously > read data, in particular, internal pointers in the process inside the > mapped data, also invalidated. For shared objects, pkg ensures that the > existing mappings are not affected, by removing and then recreating the > files. No such procedure exists or can be applied to the caches. > > I discussed this once with bapt, no good solution seems to exist. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Sun Feb 26 14:20:25 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1396CEED22 for ; Sun, 26 Feb 2017 14:20:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 604101F2 for ; Sun, 26 Feb 2017 14:20:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from sgi-2.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1chzSH-000I5y-I2; Sun, 26 Feb 2017 16:05:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: kern.ostype - where gets its value? From: Daniel Braniss In-Reply-To: <20170226140645.5d3ad3c1@zeta.dino.sk> Date: Sun, 26 Feb 2017 16:05:41 +0200 Cc: Daniel Shahaf , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170226132548.69223dcd@zeta.dino.sk> <20170226124742.GA10967@fujitsu.shahaf.local2> <20170226140645.5d3ad3c1@zeta.dino.sk> To: Milan Obuch X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 14:20:25 -0000 > On 26 Feb 2017, at 15:06, Milan Obuch wrote: >=20 > On Sun, 26 Feb 2017 12:47:42 +0000 > Daniel Shahaf wrote: >=20 >> Milan Obuch wrote on Sun, Feb 26, 2017 at 13:25:48 +0100: >>> =46rom my experience it looks like this problem is caused by svn not >>> being able to be run on nfs mounted directory, no matter the >>> architecture - today I tried with both server and client running >>> 10.3-STABLE on i386, svn just fails. =20 >>=20 >> svn can work over nfs provided that locking is supported. >>=20 >=20 > How could I find whether locking is supported/make sure it is? you need to run rpc_lockd on both server & client (rpc_lockd_enable=3Dyes = in rc.conf) probably also rpc_statd too. >=20 >>> So I think this is root cause for missing svn revision number, >>> buildkernel process somehow uses svn to fetch svn revision number, >>> fails, and then just omits it. If I undestand it right, this >>> information is put into /sys/kern/kern_mib.c file's kern.version >>> sysctl, maybe via some include or some generated .c file is used for >>> it. Could someone point me to the right direction how is this done? >>> I would like to find at least some workaround for that... =20 >>=20 >> sys/conf/newvers.sh, grep for 'svnversion'. >=20 > Thanks, I knew it is something like that, I found vers.c file just > moment ago, it is probably output of this script... >=20 > Regards, > Milan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sun Feb 26 14:43:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10318CEE369 for ; Sun, 26 Feb 2017 14:43:30 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 963DD7C1 for ; Sun, 26 Feb 2017 14:43:28 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 26 Feb 2017 15:43:26 +0100 id 00F4BD11.58B2E98E.00013A49 Date: Sun, 26 Feb 2017 15:43:25 +0100 From: Milan Obuch To: Daniel Braniss Cc: Daniel Shahaf , freebsd-hackers@freebsd.org Subject: svn over nfs - was kern.ostype - where gets its value? Message-ID: <20170226154325.48cab161@zeta.dino.sk> In-Reply-To: References: <20170226132548.69223dcd@zeta.dino.sk> <20170226124742.GA10967@fujitsu.shahaf.local2> <20170226140645.5d3ad3c1@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 14:43:30 -0000 On Sun, 26 Feb 2017 16:05:41 +0200 Daniel Braniss wrote: > > On 26 Feb 2017, at 15:06, Milan Obuch > > wrote: > > > > On Sun, 26 Feb 2017 12:47:42 +0000 > > Daniel Shahaf wrote: > > > >> Milan Obuch wrote on Sun, Feb 26, 2017 at 13:25:48 +0100: > >>> From my experience it looks like this problem is caused by svn not > >>> being able to be run on nfs mounted directory, no matter the > >>> architecture - today I tried with both server and client running > >>> 10.3-STABLE on i386, svn just fails. > >> > >> svn can work over nfs provided that locking is supported. > >> > > > > How could I find whether locking is supported/make sure it is? > you need to run rpc_lockd on both server & client > (rpc_lockd_enable=yes in rc.conf) probably also rpc_statd too. > [ snip ] Yes, I found this in FreeBSD handbook too, see URL https://www.freebsd.org/doc/handbook/network-nfs.html, but it does not solve this issue... I make sure both lockd and statd processes are running on both server and client, restarted them and nfsd, mountd, rpcbind couple of times, but while things changed, issue is not yet resolved. Without lockd/statd, svnliteversion on client shows # svnliteversion /usr/src svnversion: E155016: The working copy database at '/usr/src' is corrupt. When lockd/statd are running, it changes to # svnliteversion /usr/src svnversion: E200033: sqlite[S5]: database is locked, executing statement 'PRAGMA case_sensitive_like=1;PRAGMA synchronous=OFF;PRAGMA recursive_triggers=ON;PRAGMA foreign_keys=OFF;PRAGMA locking_mode = NORMAL;PRAGMA journal_mode = TRUNCATE;' and that's it. I will try to checkout fresh svn on server with both lockd/statd running as well, just in case, but I do not expect it will work then. Regards, Milan From owner-freebsd-hackers@freebsd.org Sun Feb 26 21:57:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D62D2CEE0EB for ; Sun, 26 Feb 2017 21:57:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670062.outbound.protection.outlook.com [40.107.67.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D5E011A for ; Sun, 26 Feb 2017 21:57:03 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Sun, 26 Feb 2017 21:57:01 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0933.019; Sun, 26 Feb 2017 21:57:00 +0000 From: Rick Macklem To: Milan Obuch , Daniel Braniss CC: Daniel Shahaf , "freebsd-hackers@freebsd.org" Subject: Re: svn over nfs - was kern.ostype - where gets its value? Thread-Topic: svn over nfs - was kern.ostype - where gets its value? Thread-Index: AQHSkCuZQ2f5llNZWEqChGjYa5KXHKF7QiyOgAAQUICAAAqLgIAAd908 Date: Sun, 26 Feb 2017 21:57:00 +0000 Message-ID: References: <20170226132548.69223dcd@zeta.dino.sk> <20170226124742.GA10967@fujitsu.shahaf.local2> <20170226140645.5d3ad3c1@zeta.dino.sk> , <20170226154325.48cab161@zeta.dino.sk> In-Reply-To: <20170226154325.48cab161@zeta.dino.sk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 76d4d1fd-e4df-4ee1-19fb-08d45e92646b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:QkxBLX0wA/Chf3cSglqXLE6Yqg0hQt91Pu8ZJTD1bz4wexnIpG6JlC0k5udLmwne3ZJeHOj9BFoXSdj6DlSFpFbbkxqeLXrA6uL7VtlSpaMEHzLKv8YU9X7r4EunXBdZO4lfr4IhsnhuzPFwF2QhOSVqs5rqugRgIhlJ7hZV5s5gohgh3iXG6awx/QbNuLnedY+KTF1jqY1u90uojTzzD/IcacVHPIGtc6pkt36PleNV4TEKD6DShhKzXRrpjTExBxD4R57U2ipioqyJdhn0IDARiVp/OsceAaC+YRiga7vbNc/keiXGkktzVJ1REbuzIYO3tb08FSJW5WuBIzs7YA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(6042181); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 0230B09AC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(189002)(7696004)(53936002)(2950100002)(33656002)(97736004)(305945005)(8936002)(38730400002)(6246003)(81166006)(81156014)(8676002)(55016002)(68736007)(189998001)(9686003)(92566002)(122556002)(54906002)(93886004)(2900100001)(106116001)(6506006)(106356001)(76176999)(50986999)(54356999)(74482002)(101416001)(74316002)(6436002)(5660300001)(86362001)(3660700001)(102836003)(3280700002)(4326007)(2906002)(77096006)(105586002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2017 21:57:00.7653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 21:57:03 -0000 Milan Obuch wrote: [more snipped] > > How could I find whether locking is supported/make sure it is? > you need to run rpc_lockd on both server & client > (rpc_lockd_enable=3Dyes in rc.conf) probably also rpc_statd too. > You could try the "nolockd" mount option instead. It allows for the locking to be done locally within the client. The only time this option isn't appropriate is if other clients need to see the locks. For that, I recommend using NFSv4. rick From owner-freebsd-hackers@freebsd.org Sun Feb 26 23:31:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9881FCEECE4 for ; Sun, 26 Feb 2017 23:31:56 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31A6862D for ; Sun, 26 Feb 2017 23:31:56 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id v77so49625639wmv.1 for ; Sun, 26 Feb 2017 15:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=02bi78eLJwpGQ9MUGu28A4o/gxq79WVFVnREyEFB2so=; b=Jy/BiMZFt5+7kkkAm1uoHz4eh/6yTIcVP20zC7olTZRjW143qRkU0Oiv/FI6jF9C97 FuD5XOZe6eemXBIB3kIq1wPebdWSmU5Vko639XHhflWdPGpVHWP+gHH5p/CVNfmL7dX1 HE9FlaMUjS4d0r4bSSzUaUgvnWc59+RubAqdJypfjZAYP6DOV0RuTFEclUgdFqcXyRcJ ql+ei606sPRj3dkP9CfLvWmeTul8tcXMg+YZGtAofkB53q5UedJ5dzJt2bUT2EVgaus2 0fScvBwEcAnACcFz8K3EHQZpprsSIV9CK8geu1NPpAY492/L/Ylf6vliS3jEn8XPFp3R ZLeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=02bi78eLJwpGQ9MUGu28A4o/gxq79WVFVnREyEFB2so=; b=MubAtpKRbgZnpRLln849732nFscZf7Z/ip5o0MFwehH/N4bSENq0DBWQTND69T90Ev gJgOD1jCRK9O8SnWKUnuMosByOKrLC2bAXTWrwPaLgCTi4+qYNpi256m16V8CGnyEajC weuDYIgXLwaT7TH7+0LSv+EODwyyraXdy7YA+X9nruAh2ybhNBpEI+q80SVyLywcPC3S Ro8EnxqgKWu2ztJApDEfBLyeqV7fMo0TTLfIj0RKoq6ERkGSSAgliFUJZYQE0rpahWkD 7OeusHIqB8wGwFOKFunw0s0X9jO4dpQA7ATCLxSDFlDDahrcp8pDmPd16oOGLDebemKK jY2w== X-Gm-Message-State: AMke39loQmbdjqwuy5gh/5y3EjLrywgAzdrYkwiZhOpefJ4tyJZfdTgSmL+nqfes+4mmgsnRyWMswG84pTMSWA== X-Received: by 10.28.102.86 with SMTP id a83mr1034791wmc.76.1488151914562; Sun, 26 Feb 2017 15:31:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.158.102 with HTTP; Sun, 26 Feb 2017 15:31:54 -0800 (PST) From: Zaphod Beeblebrox Date: Sun, 26 Feb 2017 18:31:54 -0500 Message-ID: Subject: ZFS should prefer the most specific... or something. To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 23:31:56 -0000 So, my experience is that I added two drives (that showed up as ada0 and ada1) ... something odd with the raid card added a da0 ... which is unreadable ... seems to be a bogon. ... and ZFS, in it's infinite wisdom changes my nice, neat da0s2a zfs to diskid/s2a. ... this is doubly bad, because then the /dev/da0s1a cannot mount as swap. I realize that this is can be somewhat fixed for non-root zfs with import/export, but for root ZFS ... you're stuck. Can we have ZFS prefer the shortest (rather than longest)? Can we have it prefer labels, if they exist (have a priority field in the different types of geom ... an order in which they are tasted)? The current situation has been annoying multiple distinct times. From owner-freebsd-hackers@freebsd.org Mon Feb 27 00:09:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82463CEEB0E for ; Mon, 27 Feb 2017 00:09:20 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 449556CF for ; Mon, 27 Feb 2017 00:09:20 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by mail-qk0-x236.google.com with SMTP id x71so74874008qkb.3 for ; Sun, 26 Feb 2017 16:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q962S6GUuDEvpasIUbWUg0I7r4z6kfyEX1dpGxqfOZ8=; b=GBvgbUHpIMCveSfATsy7WmyPp/24eEXKLqAGVC3IXrWtITkOWFe/tVNzlV1yfegcAM 2BOSCO5WsfjI8JPZbNA+6QAZp0Q9UObIvcCQLBTk88xOlfD2L2C3d2Kp2yb+sTdp+4tI WWUHsVArgG0CZF7ZjGBqgQANb+397QgLX1YJMjOb5eHUgNnL3WrpQ9btzXXuCZX52AS+ WfTAbMONFOhQnAlO6fk8iXUpe5lVEGtjkw6ULMucP0UfWFmyh0yxShXWmqpfKzj5TvhW B4V7P9CeQNH+GVsPtsTrj5xb+bzCgZc1BA8D25uEfCzysHbuYsph4TzzOtKYDpQoG2hH aF+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q962S6GUuDEvpasIUbWUg0I7r4z6kfyEX1dpGxqfOZ8=; b=iDuL1Kn4MrTZqNfysjXkL7Lez1Mh0sCoO1c27OZ+zRGng/6KkFd7RLx6cET79LmHva hqmrSBOMqgItiKCUbFXTr3f95kDPVtFmOBrLGeFKLmAG4M4croumheL7nJy0gOVSkFIt 3bgT8puS0fPqYZuW48gx3wR4tqiDrjTVvttU7AC6lAalG1zXGDiQ9MBhDoaOD/lLrfjG y3pfBUmjCLwF6/s+owZKB4jv3yCw7BtlYuj3gLNoIneVrhqSNCL5oACcjblWYzwM2+zY rL5BP8hoiph5bVl9ubRjLusztHWMjK9N9wXSCwkCj2hgSjlfmkhFrGFaPjAQZpWa+KK7 B64A== X-Gm-Message-State: AMke39lgL+btJ2cVrzPpc9mc1c1m38XIsl8+towG0XlB59powgFO6DZgMWBzj/bAfMPff5SShMRKci+CNWpqmA== X-Received: by 10.55.103.10 with SMTP id b10mr546640qkc.207.1488154159407; Sun, 26 Feb 2017 16:09:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.184.131 with HTTP; Sun, 26 Feb 2017 16:09:18 -0800 (PST) In-Reply-To: References: From: Andrey Fesenko Date: Mon, 27 Feb 2017 03:09:18 +0300 Message-ID: Subject: Re: ZFS should prefer the most specific... or something. To: Zaphod Beeblebrox Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 00:09:20 -0000 On Mon, Feb 27, 2017 at 2:31 AM, Zaphod Beeblebrox wrote: > So, my experience is that I added two drives (that showed up as ada0 and > ada1) ... something odd with the raid card added a da0 ... which is > unreadable ... seems to be a bogon. > > ... and ZFS, in it's infinite wisdom changes my nice, neat da0s2a zfs to > diskid/s2a. > > ... this is doubly bad, because then the /dev/da0s1a cannot mount as swap. > > I realize that this is can be somewhat fixed for non-root zfs with > import/export, but for root ZFS ... you're stuck. > > Can we have ZFS prefer the shortest (rather than longest)? Can we have it > prefer labels, if they exist (have a priority field in the different types > of geom ... an order in which they are tasted)? > > The current situation has been annoying multiple distinct times. "A disk can be specified by a full path to the device or the geom(4) provider name" see zpool(8) For example gpt lables gpart add -a 4k -t freebsd-zfs -l local0 da0 ... % zpool status localz1 NAME STATE READ WRITE CKSUM localz1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/local1 ONLINE 0 0 0 gpt/local2 ONLINE 0 0 0 gpt/local0 ONLINE 0 0 0 logs gpt/l2arc ONLINE 0 0 0 cache gpt/cache ONLINE 0 0 0 Label or disk name may be changed if need after export/import (If I remember it right) From owner-freebsd-hackers@freebsd.org Mon Feb 27 01:28:12 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1AA59CEFDC0 for ; Mon, 27 Feb 2017 01:28:12 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4C2A8CA for ; Mon, 27 Feb 2017 01:28:11 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id v77so50540966wmv.1 for ; Sun, 26 Feb 2017 17:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HrUqgAWlvpO4Y0oIsecCLSylswHE8uj7UAM+Wroe+JM=; b=oKPhVgkAUlR5lvTHSToIU5hl23NrZavu1g1+wpppTfNCaDg7IgYkIJdLYr61jMBoyx MCNJDip5M9B12cx/fBU2Z1SXEYvs1y4p5WVpCbCfWEiBXZ74J80SfSoM6HfluQ9RHZJa CI6WOCCvFjI8JWNh+4xL/zxNi7Sm4LlAoOsQKX2dHGpGeT2KqmoSbTBkTxErp0SjLESx KTGUutl7UHHbeDnbcv2wLGxHGK/CSroPfiPRQIz1C/mZRe3HO0g+VNNDsx51GBM1CYpa LT34IDFngM3FLWnh6AprRE5wzGPn2qM13ep4nK0Y/reJpiNJgmnqbXY73Qm1pYbn29zJ 3qKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HrUqgAWlvpO4Y0oIsecCLSylswHE8uj7UAM+Wroe+JM=; b=VMjQCQ7mzidhmoVQh5TrAr4yzu/dj31OYvVmZTUsb0s2aeg0tQfaH+GkFOyJK1IKA+ wX3kuINS2bSRofmx5ETRcn/EXWPRz9I7zf6z5SMy2JEQ84L4jjbbCXN+q6sAjeLsRudq rinPX40py+3tViKY0LX5vEaPPaTc8d7GVvvBn3dhx4d9M/B2OTIKcSFaNcAtWEgdeZWy J31rzkhiGOBfWOHpE0EEJGEpVN2DwGlRa7HORtvk4JatleFqjWIIdJsPPZNMkYbOM384 tgfAm5MPvb4Dfbnc5eSjMO4pELBkYz8wJIPcgrxI/qYiwb3Bu9aSkRaTdig9iHNY8gko LyYQ== X-Gm-Message-State: AMke39lbrnHTwEHcPCd9EC/Yv0f9gRB++U0wDrAew3aF5HJkyoXldZCnnhYnE+CpbW38plA5hrTcrwfg8oLhSg== X-Received: by 10.28.10.70 with SMTP id 67mr11667496wmk.76.1488158888982; Sun, 26 Feb 2017 17:28:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.158.102 with HTTP; Sun, 26 Feb 2017 17:28:08 -0800 (PST) In-Reply-To: References: From: Zaphod Beeblebrox Date: Sun, 26 Feb 2017 20:28:08 -0500 Message-ID: Subject: Re: ZFS should prefer the most specific... or something. To: Andrey Fesenko Cc: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 01:28:12 -0000 On Sun, Feb 26, 2017 at 7:09 PM, Andrey Fesenko wrote: > > "A disk can be specified by a full path to the device or the geom(4) > provider name" see zpool(8) > For example gpt lables > > Yeah, no. You didn't read carefully. Let me be more clear. Some random rejig of device names causes zfs to abandon your carefully constructed name. GPT and GPT labels are more stable, but some machines will not allow a GPT label. Anyways, after the random event, you have maximally long, low-signal-to-noise ratio names. From owner-freebsd-hackers@freebsd.org Mon Feb 27 02:24:08 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 722E3CEFB30 for ; Mon, 27 Feb 2017 02:24:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3517B3BF for ; Mon, 27 Feb 2017 02:24:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x241.google.com with SMTP id l138so1000437ywc.0 for ; Sun, 26 Feb 2017 18:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LINNW1MLtLUGvEWYc2GTtJvSqBCWGF0iYzLcy44c3po=; b=iNuiKX0kLpwrhfKnRRf1Ejttnqvux2obhOBUFEJZboz+z1U01urSKQI2Oca+jJGgZ8 5eMefoRhwJwZCRITBNqI+EvYF4BTil4WGObPcgkMo+Exf2okX307FMFT6lxi4ccoVkFB yyds/YqedLjVWYX9CtSNNdwQpYF2FRAf4UgBvM07JXvTm+x3tjx8IzzFzm3r5qD43/vu i6utQwNe7C8+Y+o6smFQkbXtE3pjBRBxRw9euPrXByfVFkVFvxBJKe9RZb6Iwb7C3YRf vug7id/XgmnZWOdhcqZwO56fCze8uk87huq4uxuqQtJSf7tNzwXFYl/8pphpPnOSqPse p2mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LINNW1MLtLUGvEWYc2GTtJvSqBCWGF0iYzLcy44c3po=; b=oWPQcuJzhvsvojvKzC0B8DXFTnPbBDFbbz1CxmOceFGDqZdYUZG8hUH34sLTbVzUre C8g/Pim+tSK5oxddJ979NFj3Jh0SxnCLzNG6UCwfBGTQjUKjqe7GisER3w1v79RYiWNJ o+uHBwi+3J6fB3y/sbzVnK+6Bc8Rmg/R+vfJD4E7j92qpmAymIT3uzKZCQL9RjDhwvi3 BK/eXk9aRnsMz3ejpFKHFqYl9biPLhFVUQA+rvJkcu3PK8nryLj7jYSC/uutalVR9+pk nN3Z15wNoKXbNrL+ZRKcQQPYenhIbwBWHanMOQwTaahRkSjCexpTr3Nk5S2xnLf9PAB0 jDTg== X-Gm-Message-State: AMke39k6KrdP3RPJRCP+nZcckjMCxENI/PrFG2n9W5MrDQWuGY/01hz2yq/SJCfkYt4EGncuofZrtiG+HEL7Ag== X-Received: by 10.129.173.68 with SMTP id l4mr6596515ywk.351.1488162247475; Sun, 26 Feb 2017 18:24:07 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Sun, 26 Feb 2017 18:24:07 -0800 (PST) In-Reply-To: References: From: Alan Somers Date: Sun, 26 Feb 2017 19:24:07 -0700 X-Google-Sender-Auth: ofcLPoCq464oKGYdyirDFmnDd0k Message-ID: Subject: Re: ZFS should prefer the most specific... or something. To: Zaphod Beeblebrox Cc: Andrey Fesenko , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 02:24:08 -0000 On Sun, Feb 26, 2017 at 6:28 PM, Zaphod Beeblebrox wrote: > On Sun, Feb 26, 2017 at 7:09 PM, Andrey Fesenko wrote: > >> >> "A disk can be specified by a full path to the device or the geom(4) >> provider name" see zpool(8) >> For example gpt lables >> >> > Yeah, no. You didn't read carefully. Let me be more clear. Some random > rejig of device names causes zfs to abandon your carefully constructed > name. GPT and GPT labels are more stable, but some machines will not allow > a GPT label. Anyways, after the random event, you have maximally long, > low-signal-to-noise ratio names. Zaphod, You can fix your particular problem by setting "kern.geom.label.disk_ident.enable=0" in /boot/loader.conf. -Alan From owner-freebsd-hackers@freebsd.org Mon Feb 27 05:35:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06070CEF5D2 for ; Mon, 27 Feb 2017 05:35:14 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C1EB07E4 for ; Mon, 27 Feb 2017 05:35:13 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-oi0-x22d.google.com with SMTP id f192so14477278oic.3 for ; Sun, 26 Feb 2017 21:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yowbqyMHSMPzFEMw/DzFfy0z7OA41R9VRXYTY4Lb+B8=; b=TLRdVJB2xs8OZxkO2vgQVZwbcGVykHrnF3y/Zu6UDlO6j9ESay0Q749o3Ddp1PZKc3 H0wcUmgGzU9Q+iDMgpd60qEhuhwtERooFuBh9C1FGLdvDHIT+SS+7txESTzswYEqb/vu e3mmsLB1hAHQQtiWGqlDtpLzQzBfKzI/2k2yf0bCeLK/hmeCCWnOl5r9GZN5PoYSocl5 2OGdpFUJon6qqijNn582ti6+ypdGP/yzq3lBZ2jm5Cl/BomUfCwdpdK684vkuh5GP67V hrHSJFK/Um0i649gTQL5SyDtZXwASogVsIpUpvFUqz429kVwNMkdxowntey7E9uG9Pm3 lx7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yowbqyMHSMPzFEMw/DzFfy0z7OA41R9VRXYTY4Lb+B8=; b=SmKXOyPjvkNhLo4YsCWolTsVK/lXcpoptUGfD5nKoh42cRTmxpo+oPm+U4ZGsenroC FBRMHLxIcKa4lVQgOyAgfYCvhihO4K19h/RA01ervSxMjKYI0e0ewtmEASWj2tWoHm3I dxZrbqps/KOGLdq9LtCHv7bzbZgx/osoOeOtsTF/DYMYzKmbVRjJs3qrZjidzl2las/z FRQEW9D6jzkLPVhN3c3Q6kwenjCUHXTbssny9m7b5H9DKtX27gD5y9k0rhDYRWpmx3LS H8I8JLVcSXp/yCNVzY2LRb6t8sMZXMUkbIDLsicxSEg0b6ZwJnXTZshALOj83v816Vul DscQ== X-Gm-Message-State: AMke39nKkgA8lnTi1pcd/7hEjvQEQSsufN48Wa1jVELVVaJ29epLKs3yYyNlw1N845B6JxDtjd93vgTa7aRtMg== X-Received: by 10.202.85.193 with SMTP id j184mr7045966oib.199.1488173712879; Sun, 26 Feb 2017 21:35:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.54.130 with HTTP; Sun, 26 Feb 2017 21:34:32 -0800 (PST) From: Lee D Date: Mon, 27 Feb 2017 00:34:32 -0500 Message-ID: Subject: How approach debugging a kernel crash? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 05:35:14 -0000 Hi, I am trying to write a custom boot loader for ARM, to replace u-boot and ubldr. As I'm working through this, I keep getting kernel crashes. I've got the kernel debugger enabled, but doing a backtrace doesn't reveal any useful information. How does one go about figuring out exactly what caused an exception? I need to know where the kernel crashed so I can figure out what piece of hardware I haven't set up correctly. The back trace is just a bunch of abort stuff, and ends in the message "Unable to unwind into user mode". I've quoted the backtrace below, and also my kernel message. Mostly I'm looking for suggestions on how to go about finding the location of the crash, as I expect to be doing this a lot this week :-) Thanks! Lee db> bt Tracing pid 0 tid 100000 td 0xc08f8470 db_trace_self() at db_trace_self pc = 0xc0669b44 lr = 0xc014c288 (db_hex2dec+0x1f4) sp = 0xffff0cb0 fp = 0xffff0cc8 db_hex2dec() at db_hex2dec+0x1f4 pc = 0xc014c288 lr = 0xc014becc (db_command_loop+0x2f4) sp = 0xffff0cd0 fp = 0xffff0d70 r4 = 0x00000001 r5 = 0x00000000 r6 = 0xc0704ae6 r10 = 0xc08f6f98 db_command_loop() at db_command_loop+0x2f4 pc = 0xc014becc lr = 0xc014bc4c (db_command_loop+0x74) sp = 0xffff0d78 fp = 0xffff0d88 r4 = 0xc06cfe7d r5 = 0xc06e1e0e r6 = 0xc08f6f84 r7 = 0xffff0fa0 r8 = 0xc08ead98 r9 = 0xc0791060 r10 = 0xc08ead9c db_command_loop() at db_command_loop+0x74 pc = 0xc014bc4c lr = 0xc014f084 (db_fetch_ksymtab+0x2e8) sp = 0xffff0d90 fp = 0xffff0ea8 r4 = 0x00000807 r5 = 0x00000000 r6 = 0xc08f6f90 r10 = 0xc08ead9c db_fetch_ksymtab() at db_fetch_ksymtab+0x2e8 pc = 0xc014f084 lr = 0xc0341870 (kdb_trap+0x180) sp = 0xffff0eb0 fp = 0xffff0ed8 r4 = 0x00000000 r5 = 0x00000807 r6 = 0xc08eadb8 r10 = 0xc08ead9c kdb_trap() at kdb_trap+0x180 pc = 0xc0341870 lr = 0xc06908b4 (abort_handler+0x678) sp = 0xffff0ee0 fp = 0xffff0f00 r4 = 0xffff0fa0 r5 = 0x00000013 r6 = 0xffff1030 r7 = 0x00000007 r8 = 0x00000807 r9 = 0xc08f8470 r10 = 0xffff0fa0 abort_handler() at abort_handler+0x678 pc = 0xc06908b4 lr = 0xc0690600 (abort_handler+0x3c4) sp = 0xffff0f08 fp = 0xffff0f98 r4 = 0x00000001 r5 = 0x00000007 r6 = 0x00000000 r7 = 0x00000807 r8 = 0x00000013 r10 = 0xffff0fa0 abort_handler() at abort_handler+0x3c4 pc = 0xc0690600 lr = 0xc066c42c (exception_exit) sp = 0xffff0fa0 fp = 0xc0a13e70 r4 = 0x00000000 r5 = 0xc08f8808 r6 = 0x00000001 r7 = 0x00000000 r8 = 0xc08f890c r9 = 0xc08f8908 r10 = 0x00002802 exception_exit() at exception_exit pc = 0xc066c42c lr = 0x1000019c (0x1000019c) sp = 0xffff1034 fp = 0xc0a13e70 r0 = 0xc066c534 r1 = 0xc0a0b000 r2 = 0xffff107c r3 = 0x20010193 r4 = 0x00000000 r5 = 0xc08f8808 r6 = 0x00000001 r7 = 0x00000000 r8 = 0xc08f890c r9 = 0xc08f8908 r10 = 0x00002802 r12 = 0xfefefeff data_abort_entry() at data_abort_entry+0x30 pc = 0xc066c534 lr = 0x1000019c (0x1000019c) sp = 0xffff1034 fp = 0xc0a13e70 Unable to unwind into user mode KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-RELEASE-p1 #27 r309723M: Sat Feb 25 18:51:15 EST 2017 builder@abe:/usr/home/builder/projects/fbsd_11.0.1/obj/arm.armv6/usr/home/builder/projects/fbsd_11.0.1/src/sys/AXSACM arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) VT: init without driver. CPU: Cortex A9-r3 rev 0 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB enabled LABT branch prediction disabled LoUU:2 LoC:2 LoUIS:2 Cache level 1: 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 4-way instruction cache Read-Alloc real memory = 535822336 (511 MB) avail memory = 513486848 (489 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random: entropy device external interface ofwbus0: simplebus0: on ofwbus0 simplebus1: on ofwbus0 simplebus2: on ofwbus0 l2cache0: mem 0xf02000-0xf02fff on simplebus0 l2cache0: cannot allocate IRQ, not using interrupt l2cache0: Part number: 0x3, release: 0x8 l2cache0: L2 Cache enabled: 512KB/32B 8 ways gic0: mem 0xf01000-0xf01fff,0xf00100-0xf001ff on simplebus0 gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b irqs 96 mp_tmr0: mem 0xf00200-0xf002ff,0xf00600-0xf0061f on simplebus0 Timecounter "MPCore" frequency 325000000 Hz quality 800 Event timer "MPCore" frequency 325000000 Hz quality 1000 zy7_slcr0: mem 0-0xfff on simplebus0 zy7_devcfg0: mem 0x7000-0x7fff on simplebus0 uart0: mem 0x1000-0x1fff on simplebus1 uart0: console (-1,n,8,1) ehci0: mem 0x2000-0x2fff on simplebus1 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0 on ehci0 gpio0: mem 0xa000-0xafff on simplebus1 gpiobus0: on gpio0 gpioc0: on gpio0 cgem0: mem 0xb000-0xbfff on simplebus1 miibus0: on cgem0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto rgephy1: PHY 1 on miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto cgem0: no mac address found, assigning random: 62:73:64:b9:65:d2 cgem0: Ethernet address: 62:73:64:b9:65:d2 sdhci_fdt0: mem 0x100000-0x100fff on simplebus1 sdhci_fdt0: 1 slot(s) allocated mmc0: on sdhci_fdt0 sdhci_fdt1: mem 0x101000-0x101fff on simplebus1 sdhci_fdt1: 1 slot(s) allocated mmc1: on sdhci_fdt1 cryptosoft0: Fatal kernel mode data abort: 'Translation Fault (L2)' on write trapframe: 0xffff0fa0 FSR=00000807, FAR=ffff1030, spsr=20010193 r0 =c066c534, r1 =c0a0b000, r2 =ffff107c, r3 =20010193 r4 =00000000, r5 =c08f8808, r6 =00000001, r7 =00000000 r8 =c08f890c, r9 =c08f8908, r10=00002802, r11=c0a13e70 r12=fefefeff, ssp=ffff1034, slr=1000019c, pc =c066c534 [ thread pid 0 tid 100000 ] Stopped at data_abort_entry+0x30: str r0, [r13, -#0x004]! From owner-freebsd-hackers@freebsd.org Mon Feb 27 06:24:51 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D49BCEF0C8 for ; Mon, 27 Feb 2017 06:24:51 +0000 (UTC) (envelope-from allanjude@FreeBSD.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67C8DC82 for ; Mon, 27 Feb 2017 06:24:50 +0000 (UTC) (envelope-from allanjude@FreeBSD.org) Received: from [10.145.2.129] (unknown [209.171.88.129]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 4233A1360F; Mon, 27 Feb 2017 06:24:48 +0000 (UTC) Date: Sun, 26 Feb 2017 22:24:43 -0800 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ZFS should prefer the most specific... or something. To: freebsd-hackers@freebsd.org,Zaphod Beeblebrox From: Allan Jude Message-ID: <94827A0B-2F42-4D6D-8112-29FCD7DBF122@FreeBSD.org> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 06:24:51 -0000 On February 26, 2017 3:31:54 PM PST, Zaphod Beeblebrox wrote: >So, my experience is that I added two drives (that showed up as ada0 >and >ada1) =2E=2E=2E something odd with the raid card added a da0 =2E=2E=2E wh= ich is >unreadable =2E=2E=2E seems to be a bogon=2E > >=2E=2E=2E and ZFS, in it's infinite wisdom changes my nice, neat da0s2a z= fs >to >diskid/s2a=2E > >=2E=2E=2E this is doubly bad, because then the /dev/da0s1a cannot mount a= s >swap=2E > >I realize that this is can be somewhat fixed for non-root zfs with >import/export, but for root ZFS =2E=2E=2E you're stuck=2E > >Can we have ZFS prefer the shortest (rather than longest)? Can we have >it >prefer labels, if they exist (have a priority field in the different >types >of geom =2E=2E=2E an order in which they are tasted)? > >The current situation has been annoying multiple distinct times=2E >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" Zfs has no Control over this, it is GEOM that decides the device names=2E = There are multiple for each disk, and once one is used, geom hides the rest= =2E As Alan Somers pointed out, you can disable the names you do not want= =2E Disk ID can be useful as it is the serial number of the disk --=20 Allan Jude From owner-freebsd-hackers@freebsd.org Mon Feb 27 06:43:46 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79D8DCEF54B for ; Mon, 27 Feb 2017 06:43:46 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E70546E1 for ; Mon, 27 Feb 2017 06:43:45 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Mon, 27 Feb 2017 07:43:40 +0100 id 00F4BD53.58B3CA9C.00001029 Date: Mon, 27 Feb 2017 07:43:40 +0100 From: Milan Obuch To: Rick Macklem Cc: Daniel Braniss , Daniel Shahaf , freebsd-hackers@freebsd.org Subject: Re: svn over nfs - was kern.ostype - where gets its value? Message-ID: <20170227074340.236ce0b9@zeta.dino.sk> In-Reply-To: References: <20170226132548.69223dcd@zeta.dino.sk> <20170226124742.GA10967@fujitsu.shahaf.local2> <20170226140645.5d3ad3c1@zeta.dino.sk> <20170226154325.48cab161@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 06:43:46 -0000 On Sun, 26 Feb 2017 21:57:00 +0000 Rick Macklem wrote: > Milan Obuch wrote: > [more snipped] > > > How could I find whether locking is supported/make sure it is? > > you need to run rpc_lockd on both server & client > > (rpc_lockd_enable=yes in rc.conf) probably also rpc_statd too. > > > You could try the "nolockd" mount option instead. It allows for > the locking to be done locally within the client. > > The only time this option isn't appropriate is if other clients need > to see the locks. For that, I recommend using NFSv4. > > rick > Thanks, this works! Normally, for /usr/src (and partially for /usr/ports) read only access is enough, I see no need for locking at all, in any case, first action is 'svn update' from svn server (here both read and write are necessary), followed by 'make buildworld' et all on any nfs client device (only read is necessary). No potential conflict here. With proper setting in /etc/make.conf, similar use case could be achieved with /usr/ports tree... so I am glad it works. Regards, Milan From owner-freebsd-hackers@freebsd.org Mon Feb 27 11:58:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CCE3CEFE96 for ; Mon, 27 Feb 2017 11:58:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E406C26 for ; Mon, 27 Feb 2017 11:58:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1ciJx8-000JdQ-2w; Mon, 27 Feb 2017 14:58:54 +0300 Date: Mon, 27 Feb 2017 14:58:54 +0300 From: Slawa Olhovchenkov To: Zaphod Beeblebrox Cc: Andrey Fesenko , FreeBSD Hackers Subject: Re: ZFS should prefer the most specific... or something. Message-ID: <20170227115854.GK15630@zxy.spb.ru> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 11:58:56 -0000 On Sun, Feb 26, 2017 at 08:28:08PM -0500, Zaphod Beeblebrox wrote: > On Sun, Feb 26, 2017 at 7:09 PM, Andrey Fesenko wrote: > > > > > "A disk can be specified by a full path to the device or the geom(4) > > provider name" see zpool(8) > > For example gpt lables > > > > > Yeah, no. You didn't read carefully. Let me be more clear. Some random > rejig of device names causes zfs to abandon your carefully constructed > name. GPT and GPT labels are more stable, but some machines will not allow > a GPT label. Anyways, after the random event, you have maximally long, > low-signal-to-noise ratio names. zfs don't need label, zfs can use raw disk name and full tolerante to change this names between reboot. ps: /boot/loader.conf: kern.geom.label.gptid.enable="0" kern.geom.label.disk_ident.enable=0 From owner-freebsd-hackers@freebsd.org Mon Feb 27 12:01:43 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6891CEE939 for ; Mon, 27 Feb 2017 12:01:43 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3982C27B for ; Mon, 27 Feb 2017 12:01:42 +0000 (UTC) (envelope-from freebsd-hackers@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Mon, 27 Feb 2017 13:01:38 +0100 id 00F4BED1.58B41522.0000A3FF Date: Mon, 27 Feb 2017 13:01:38 +0100 From: Milan Obuch To: Daniel Braniss Cc: Daniel Shahaf , freebsd-hackers@freebsd.org Subject: Re: kern.ostype - where gets its value? Message-ID: <20170227130138.778b6571@zeta.dino.sk> In-Reply-To: References: <20170226132548.69223dcd@zeta.dino.sk> <20170226124742.GA10967@fujitsu.shahaf.local2> <20170226140645.5d3ad3c1@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 12:01:43 -0000 On Sun, 26 Feb 2017 16:05:41 +0200 Daniel Braniss wrote: > > On 26 Feb 2017, at 15:06, Milan Obuch > > wrote: > > > > On Sun, 26 Feb 2017 12:47:42 +0000 > > Daniel Shahaf wrote: > > > >> Milan Obuch wrote on Sun, Feb 26, 2017 at 13:25:48 +0100: > >>> From my experience it looks like this problem is caused by svn not > >>> being able to be run on nfs mounted directory, no matter the > >>> architecture - today I tried with both server and client running > >>> 10.3-STABLE on i386, svn just fails. > >> > >> svn can work over nfs provided that locking is supported. > >> > > > > How could I find whether locking is supported/make sure it is? > you need to run rpc_lockd on both server & client > (rpc_lockd_enable=yes in rc.conf) probably also rpc_statd too. > Thanks, I took another solution - mount /usr/src read only with option nolockd. I verified 'svnliteversion /usr/src' command gives correct results on both arm and arm64 (I tested it on my Mac NFS with i386 and amd64 as well, this was another trouble solvable the same way for me). So next kernel should have correct svn revision now... Regards, Milan From owner-freebsd-hackers@freebsd.org Mon Feb 27 13:31:46 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6D25CEDD43 for ; Mon, 27 Feb 2017 13:31:46 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40D25F42 for ; Mon, 27 Feb 2017 13:31:46 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: by mail-wr0-x22b.google.com with SMTP id u108so22323941wrb.3 for ; Mon, 27 Feb 2017 05:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=F0pcIX/RreV0yKVd/G6lddgGPC/S6/9qTV9CmXLYJHo=; b=eyQizDgEw3UtmuM/5MYWSF1Q6c57jbbDOiiuFRMUO5WVdwSB0CpvIFXaVFysVY+7AN sZTjt52LyGdQCyCH+P5DU5SIriQyAZia9lsNS1Jk4vOFWKP6iquu0AOdaKsPIXEISaLe 0vPpd7Yt2i0zjGfU5IHzjTnXluWdLWLalQFbU+D83ysxm2VVfUSRLLyZmPT3ydULT0zw ZBVv00zzNZBu0T3TImMT4Uzd+D4tQpaiNnZyN1LJF3G+v6riaBvT+WAcehOYECbAZrFp Rq46coan0Hu9z8gWejjGnSKlhG3hgoQTeywPehZDQLqJMQcLbHIyZoz0vOOIO4UE8v7e bdDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=F0pcIX/RreV0yKVd/G6lddgGPC/S6/9qTV9CmXLYJHo=; b=qX2fknvQrmvp6u8RLSjboSSSl0DWMu87yhv26Gc9FFfo53y0ezdmvJ6JoHd4f8Z4gA TyNmqTln8DTnFDmRM/JprOmiAbOD+yAr5YVmhla87QpN90MqIZ4Z7HmZMyOT4JvObjqt /Lt2rgHc//Mf5Ga0CeXn/a1c9uQiSzBzhY0ZXbMZcXC+ZxT7VkqylvzCBTOSXW5Vp1Mp dwHj+Ax0LWJgGQITH8LERHImC+sK/uPmerG9yD1jBm9pOQbgRqPKEMmqP5buD9lI+ct4 AHwCEmAGAq/YgUYqu+dMvD5SOI1uDKZPwoKj1gpVFulE9MHE1Es1YxrCg0+3UbIdQEHu 5Ctg== X-Gm-Message-State: AMke39kRDeGZ8Ez4HxW1vetjIoquMbfPaWH66mC9WWcNLBuah1Rqv/RAOfRbkZmFFdQpy1U6WigXMslSm1N34w== X-Received: by 10.223.178.205 with SMTP id g71mr13192331wrd.158.1488202304540; Mon, 27 Feb 2017 05:31:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.144.6 with HTTP; Mon, 27 Feb 2017 05:31:43 -0800 (PST) From: Saurav Sachidanand Date: Mon, 27 Feb 2017 19:01:43 +0530 Message-ID: Subject: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:31:46 -0000 Hello FreeBSD community, I'm =E2=80=8B Saurav Sachidanand, and I'm=E2=80=8B a CS sophomore studying in India =E2=80=8B. I have an interest in operating systems development and wish to contribute to the FreeBSD community. I'm proficient with C and have some experience in kernel programming. Hence, I'd like to propose an original project for GSoC 2017 that I feel would benefit this community. In past years, the Lua interpreter was ported to run inside the Linux and NetBSD kernel [1]. Lua was chosen because it's interpreter is very small (~= 240 KB) compared to that of Python or Ruby, it's MIT licensed, and is almost freestanding. A working demonstration of it is a packet filtering algorithm written entirely in kernel Lua [2]. Specifically, my proposal would be to port the following that are currently written for NetBSD: - the modified Lua VM source code with _KERNEL preprocessor directives to exclude user-space functionality like floating point, the io and os module in the standard library, etc. [3] - the kernel module device driver for /dev/lua, to which Lua scripts are fed to be executed [4], [5] - the luactl user-space program to control the Lua device and a couple of sysctl variables which serve similar purpose [6], [7] And then: - run the Lua test suite targeting whatever we support in the kernel to make sure it works [8] - and write Lua bindings to the kernel interfaces that would interest the FreeBSD community Since NetBSD and FreeBSD have similar kernel interfaces (mutexes, linked lists, device switch interface), the porting shouldn't involve too much code refactoring. Also, this would all be an experiment in that we don't fully know what the real world use cases might be, but it would attract more people to writing kernel code who otherwise wouldn't because of having to do everything in C. And it would be interesting to carry out it out in FreeBSD as well since it has a larger community than NetBSD. I humbly request anyone who is interested in this project to be my potential mentor(s) for GSoC. More slides on kernel Lua in NetBSD - [9], [10]. Thanks, Saurav [1] - http://www.netbsd.org/~lneto/dls14.pdf [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/dist/src [4] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/lua [5] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/ sys/modules/luasystm [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin/luactl [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current [8] - http://www.lua.org/tests/ [9] - https://www.netbsd.org/gallery/presentations/mbalmer/ fosdem2012/kernel_mode_lua.pdf [10] - https://www.lua.org/wshop13/Cormack.pdf From owner-freebsd-hackers@freebsd.org Mon Feb 27 13:28:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C948CEDBBA for ; Mon, 27 Feb 2017 13:28:44 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29EB7D13; Mon, 27 Feb 2017 13:28:44 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id v77so62521207wmv.0; Mon, 27 Feb 2017 05:28:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IYzC8mYtEgChgpdkUDJCAzJe2n3eyF6ANb5Ue8xbMiI=; b=ujd+78SlWaQA1BZCeawch4eCJKpEhXUxml5W/tC3EwpwCaul6rU8U3N+BWZVrYa1tC hOYkOu3axRGQRsYav8zRJHJVbqzPvZVjn8q4AZVdargeplzH7LZFeIOVuB9Aq5KEFQLL fkAj2pZc6M2gBmqf45HxomA2AvZzfwusau6Hj2jFR1g+7cdtnWcH4YRzA2jSZQCpr7L2 bd3s00HICH/9VQ48ltxOsYRWhtELhljBIFEG7G0NaFzLUuyQcSEIUPjyEBuadXZ2rROn sN2lRIhky9x85Z92J+myxjdA7hru2qTLpuisSas4LJL5c7iVR5zanS/6zyUFMVzlDbvF JuIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IYzC8mYtEgChgpdkUDJCAzJe2n3eyF6ANb5Ue8xbMiI=; b=DUSbq97k5IIgT2rUSCwgqLnEyU7RdwYFlFsdATfAwP1wy3QpnHVvhzkUm06WMp2wbD xulRvCGoZL1aUf/0hxTgphL4UfKuTh1bz4zoR+8XRbbocQ4WCdRYEozWtu0bf4+QfvmS aQ2QL4wcw7BL40GoSfK6MbmfWASHujxjdh7u2/6MYL74xBAIkeNVfZDgc2sopct2UoLH LZoMWRp5nLNYl/3qy9eDldL3K627gJl9DSsx0dIon0TaqI6piqUN7oqQGsEmK/5OdMk8 utlChggzfaGDlkZM1Pwj30iD+R+TKOm5cv3ii56DUS1kDxU/1ETCjnvoWPvFoMCqYXvJ sySg== X-Gm-Message-State: AMke39n9SjA7bYB/mVTnKj91CkGqT6O1omQFkuVvLnQlnz7dPK5YBMlf2Y8H8gYFtSJLUENM1J9aUfeiVlYZog== X-Received: by 10.28.98.194 with SMTP id w185mr14447609wmb.84.1488202122055; Mon, 27 Feb 2017 05:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.144.6 with HTTP; Mon, 27 Feb 2017 05:28:41 -0800 (PST) From: Saurav Sachidanand Date: Mon, 27 Feb 2017 18:58:41 +0530 Message-ID: Subject: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: soc-admins@freebsd.org, freebsd-hackers@freebsd.org X-Mailman-Approved-At: Mon, 27 Feb 2017 13:32:37 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 13:28:44 -0000 Hello FreeBSD community, I'm =E2=80=8B Saurav Sachidanand, and I'm=E2=80=8B a CS sophomore studying in India =E2=80=8B. I have an interest in operating systems development and wish to contribute to the FreeBSD community. I'm proficient with C and have some experience in kernel programming. Hence, I'd like to propose an original project for GSoC 2017 that I feel would benefit this community. In past years, the Lua interpreter was ported to run inside the Linux and NetBSD kernel [1]. Lua was chosen because it's interpreter is very small (~= 240 KB) compared to that of Python or Ruby, it's MIT licensed, and is almost freestanding. A working demonstration of it is a packet filtering algorithm written entirely in kernel Lua [2]. Specifically, my proposal would be to port the following that are currently written for NetBSD: - the modified Lua VM source code with _KERNEL preprocessor directives to exclude user-space functionality like floating point, the io and os module in the standard library, etc. [3] - the kernel module device driver for /dev/lua, to which Lua scripts are fed to be executed [4], [5] - the luactl user-space program to control the Lua device and a couple of sysctl variables which serve similar purpose [6], [7] And then: - run the Lua test suite targeting whatever we support in the kernel to make sure it works [8] - and write Lua bindings to the kernel interfaces that would interest the FreeBSD community Since NetBSD and FreeBSD have similar kernel interfaces (mutexes, linked lists, device switch interface), the porting shouldn't involve too much code refactoring. Also, this would all be an experiment in that we don't fully know what the real world use cases might be, but it would attract more people to writing kernel code who otherwise wouldn't because of having to do everything in C. And it would be interesting to carry out it out in FreeBSD as well since it has a larger community than NetBSD. I humbly request anyone who is interested in this project to be my potential mentor(s) for GSoC. More slides on kernel Lua in NetBSD - [9], [10]. Thanks, Saurav [1] - http://www.netbsd.org/~lneto/dls14.pdf [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/dist/src [4] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/lua [5] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/luasystm [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin/luactl [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current [8] - http://www.lua.org/tests/ [9] - https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012/kernel_mode= _lua.pdf [10] - https://www.lua.org/wshop13/Cormack.pdf From owner-freebsd-hackers@freebsd.org Mon Feb 27 15:26:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6F51CF0711 for ; Mon, 27 Feb 2017 15:26:17 +0000 (UTC) (envelope-from allanjude@FreeBSD.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E9D3F44; Mon, 27 Feb 2017 15:26:17 +0000 (UTC) (envelope-from allanjude@FreeBSD.org) Received: from [10.145.2.129] (unknown [209.171.88.129]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id B6D1C13517; Mon, 27 Feb 2017 15:26:14 +0000 (UTC) Date: Mon, 27 Feb 2017 07:26:09 -0800 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: freebsd-hackers@freebsd.org, Saurav Sachidanand , soc-admins@freebsd.org From: Allan Jude Message-ID: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 15:26:17 -0000 On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand wrote: >Hello FreeBSD community, > >I'm >=E2=80=8B Saurav Sachidanand, and I'm=E2=80=8B > a CS sophomore studying in India >=E2=80=8B=2E >I have an interest in operating systems development and wish to >contribute >to the FreeBSD community=2E I'm proficient with C and have some >experience in >kernel programming=2E Hence, I'd like to propose an original project for >GSoC >2017 that I feel would benefit this community=2E > >In past years, the Lua interpreter was ported to run inside the Linux >and >NetBSD kernel [1]=2E Lua was chosen because it's interpreter is very >small (~240 >KB) compared to that of Python or Ruby, it's MIT licensed, and is >almost >freestanding=2E A working demonstration of it is a packet filtering >algorithm >written entirely in kernel Lua [2]=2E > >Specifically, my proposal would be to port the following that are >currently >written for NetBSD: >- the modified Lua VM source code with _KERNEL preprocessor directives >to >exclude user-space functionality like floating point, the io and os >module >in the standard library, etc=2E [3] >- the kernel module device driver for /dev/lua, to which Lua scripts >are >fed to be executed [4], [5] >- the luactl user-space program to control the Lua device and a couple >of >sysctl variables which serve similar purpose [6], [7] > >And then: >- run the Lua test suite targeting whatever we support in the kernel to >make sure it works [8] >- and write Lua bindings to the kernel interfaces that would interest >the >FreeBSD community > >Since NetBSD and FreeBSD have similar kernel interfaces (mutexes, >linked >lists, device switch interface), the porting shouldn't involve too much >code refactoring=2E Also, this would all be an experiment in that we >don't >fully know what the real world use cases might be, but it would attract >more people to writing kernel code who otherwise wouldn't because of >having >to do everything in C=2E And it would be interesting to carry out it out >in >FreeBSD as well since it has a larger community than NetBSD=2E > >I humbly request anyone who is interested in this project to be my >potential mentor(s) for GSoC=2E > >More slides on kernel Lua in NetBSD - [9], [10]=2E > >Thanks, >Saurav > >[1] - http://www=2Enetbsd=2Eorg/~lneto/dls14=2Epdf >[2] - https://www=2Enetbsd=2Eorg/~lneto/eurobsdcon14=2Epdf >[3] - https://github=2Ecom/jsonn/src/tree/trunk/external/mit/lua/dist/src >[4] - >https://github=2Ecom/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/lua >[5] - >https://github=2Ecom/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/luasys= tm >[6] - https://github=2Ecom/IIJ-NetBSD/netbsd-src/tree/master/sbin/luactl >[7] - http://netbsd=2Egw=2Ecom/cgi-bin/man-cgi?lua+4+NetBSD-current >[8] - http://www=2Elua=2Eorg/tests/ >[9] - >https://www=2Enetbsd=2Eorg/gallery/presentations/mbalmer/fosdem2012/kerne= l_mode_lua=2Epdf >[10] - https://www=2Elua=2Eorg/wshop13/Cormack=2Epdf >_______________________________________________ >freebsd-hackers@freebsd=2Eorg mailing list >https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd=2Eorg" This may be quite a nice thing to have=2E Another upcoming use for LUA in = the kernel is ZFS Channel Programs=2E These allow a number of ZFS operation= s to be completed as a single atomic transaction=2E I would hope we could structure this in such a way as to not end up with t= wo copies of Lua in the kernel=2E --=20 Allan Jude From owner-freebsd-hackers@freebsd.org Mon Feb 27 18:01:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EFB3CEFD63 for ; Mon, 27 Feb 2017 18:01:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F075FB88 for ; Mon, 27 Feb 2017 18:01:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x243.google.com with SMTP id r141so1713884ita.1 for ; Mon, 27 Feb 2017 10:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0oCRxZ6MDHPlem7g3nxSxGMkhrBy0X3f8xSiMaMkAWk=; b=hd6IoHo0g9HNKcOXvVSqkgykJ464cS/B1BoBQUG2RkUSF9QP6Vztrv5P9RgQmRgAM7 Jk1Y2yJq80fIbk2kwmrwmGEqYQP9eNDZFbWCiS7FhorsVsQFbQMKEHpkjjhPD4Rp5/GV /ApxcUk351tYRsKKqubxyAoi2fy9f2BPu1Kd/1qkD5Nef7eU6Qg/4FY+dSo/ygGm96ug gQNVSvi7/SVBYcONxBXxxryDTGuxiW+Z0GRB9mlLgGq35eFJAFlTGEJRqVGK8r6PgbAx ulCtCThcODJ7l0UbuOuPMmg13Rj8Fxj2mUEBOk0eKKGJmvl8E8qVDgtQB+BWhgtfh1RG 8y2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0oCRxZ6MDHPlem7g3nxSxGMkhrBy0X3f8xSiMaMkAWk=; b=IVkNozItWtGe8E/Vo73Xszw1qflBT1s/2auQG/X2pyfcM2fk3xPUBAZ1XQwKkZshHN J7guWwOQpytkE+pz7/YdbqD6Za8Jwqny0h6rWihw0Bqm0wT/aF/TZ/+TryoG7dDJtKVg b7KwyEGGBQtlx+lX6x0dY4gbNyL954APiTC9NKwtpRXItVPZOxFR6iXeJrej4LxKyV9p 2fxqw9zxtcpevl00BP0pZTcQMgwfT5YYROjBqpf0j5ilGs91itUKGYweRngLxTawHavT bVz1xYu5GJAbBXKp4+WtgsmWs/jpSVvmwcXJIW2GD5WZhiLGxTwSRsSpapWwIfAbWJpd E5ew== X-Gm-Message-State: AMke39ktzc7KDtvXwS0oSLkSLVFAls5d4Ir90jheJbx3ebmNza1YvhxcREbsYI/Y06T20IbDKY0pKRB01Mi1lw== X-Received: by 10.36.147.71 with SMTP id y68mr15505202itd.85.1488218485115; Mon, 27 Feb 2017 10:01:25 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Mon, 27 Feb 2017 10:01:24 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> From: Warner Losh Date: Mon, 27 Feb 2017 11:01:24 -0700 X-Google-Sender-Auth: G7rBZQLljkW11dSphZ6n0yiS2_8 Message-ID: Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Allan Jude Cc: "freebsd-hackers@freebsd.org" , Saurav Sachidanand , soc-admins@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:01:26 -0000 On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude wrote: > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand wrote: >>Hello FreeBSD community, >> >>I'm >> Saurav Sachidanand, and I'm >> a CS sophomore studying in India >>. >>I have an interest in operating systems development and wish to >>contribute >>to the FreeBSD community. I'm proficient with C and have some >>experience in >>kernel programming. Hence, I'd like to propose an original project for >>GSoC >>2017 that I feel would benefit this community. >> >>In past years, the Lua interpreter was ported to run inside the Linux >>and >>NetBSD kernel [1]. Lua was chosen because it's interpreter is very >>small (~240 >>KB) compared to that of Python or Ruby, it's MIT licensed, and is >>almost >>freestanding. A working demonstration of it is a packet filtering >>algorithm >>written entirely in kernel Lua [2]. >> >>Specifically, my proposal would be to port the following that are >>currently >>written for NetBSD: >>- the modified Lua VM source code with _KERNEL preprocessor directives >>to >>exclude user-space functionality like floating point, the io and os >>module >>in the standard library, etc. [3] >>- the kernel module device driver for /dev/lua, to which Lua scripts >>are >>fed to be executed [4], [5] >>- the luactl user-space program to control the Lua device and a couple >>of >>sysctl variables which serve similar purpose [6], [7] >> >>And then: >>- run the Lua test suite targeting whatever we support in the kernel to >>make sure it works [8] >>- and write Lua bindings to the kernel interfaces that would interest >>the >>FreeBSD community >> >>Since NetBSD and FreeBSD have similar kernel interfaces (mutexes, >>linked >>lists, device switch interface), the porting shouldn't involve too much >>code refactoring. Also, this would all be an experiment in that we >>don't >>fully know what the real world use cases might be, but it would attract >>more people to writing kernel code who otherwise wouldn't because of >>having >>to do everything in C. And it would be interesting to carry out it out >>in >>FreeBSD as well since it has a larger community than NetBSD. >> >>I humbly request anyone who is interested in this project to be my >>potential mentor(s) for GSoC. >> >>More slides on kernel Lua in NetBSD - [9], [10]. >> >>Thanks, >>Saurav >> >>[1] - http://www.netbsd.org/~lneto/dls14.pdf >>[2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf >>[3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/dist/src >>[4] - >>https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/lua >>[5] - >>https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/luasystm >>[6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin/luactl >>[7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current >>[8] - http://www.lua.org/tests/ >>[9] - >>https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012/kernel_mode_lua.pdf >>[10] - https://www.lua.org/wshop13/Cormack.pdf >>_______________________________________________ >>freebsd-hackers@freebsd.org mailing list >>https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>To unsubscribe, send any mail to >>"freebsd-hackers-unsubscribe@freebsd.org" > > This may be quite a nice thing to have. Another upcoming use for LUA in the kernel is ZFS Channel Programs. These allow a number of ZFS operations to be completed as a single atomic transaction. > > I would hope we could structure this in such a way as to not end up with two copies of Lua in the kernel. There's also a 3/4 finished lua in the boot loader that you might be able to leverage as well.... Warner From owner-freebsd-hackers@freebsd.org Mon Feb 27 18:31:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3BCBCF03CB for ; Mon, 27 Feb 2017 18:31:19 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm20-vm0.bullet.mail.ne1.yahoo.com (nm20-vm0.bullet.mail.ne1.yahoo.com [98.138.91.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 778A1BF2 for ; Mon, 27 Feb 2017 18:31:19 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1488220278; bh=dnO8rGHwOeKz7c5uTRxfIfaM5fn9g5Tru7rJKpdhyf0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ml+G4K3l4vJBB7i6ZizBmaqK1GHAPwsr7RfUduK7G3LFyhgRPhCQJHbA7I7Roj05gUL4KWVGTLx0CDGiO32KqMEE7LWjpzymNVFQRbKVPDjyGqLm+ESH0jazaKyZwvIZUbhUuF5cnlxBay0zKrnO+nBDSTheePqmQGb0anSo4qMUPCS+7CWBvTRrzu3VCnP/w8nAui0atFcdFIBcWkkYUTYZRJSzTmfECUZkQxs4k4Stx83IoS9ej67z1ppJAbQHzpROM4ZQgWjfjijfrfLGrYWB7irvuBFYFO94ZgjvV7gvkhBqpbveXxFCoichTFyDrD5jSoygh+mgfT6afLltLg== Received: from [98.138.100.112] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 27 Feb 2017 18:31:18 -0000 Received: from [98.138.84.45] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 27 Feb 2017 18:31:18 -0000 Received: from [127.0.0.1] by smtp113.mail.ne1.yahoo.com with NNFMP; 27 Feb 2017 18:31:18 -0000 X-Yahoo-Newman-Id: 579417.88944.bm@smtp113.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: UZhvuOQVM1nTbgTnk2cBZiVs6qklcD7g1nUOgIfMrCj9qyt WoZ3GbX2tG4xJYc6pSMIRmTWa22PYBlDTjLRR2fiUxXQ64rEko39ymbo9rq. Ej2wCw0TqBNu2X1xX7w4FaBFNCseouqZgQlt3JyTHcCLhyUVvWP6AKymrP7l viXx4wufbRO3gciPqnwVHFq_w0bx9L653lRXO0CAtVVkOj28PyugK7k092Jk 18qnlA3vPmZ3SAcvNY0NuPgdDmEbpZyHCpmdCQ4.31dgdG4z_r.fkvQU8iZc i3vq14YC3myNrXiV.HXJf4AX8tjgQ26cHgN5HKUDfDNkUurQQDfWaZ_xuWMb Dj4tPyUWjXA0N3XkO91B7SOP0njT3oZg5bUcsaTT11_FqV8HHHzaSVSgfLhH 1bJ6d4H947o4zz9PJATXMpmOMVniBOjsdXLOYMWdPGjQQXBpjpd9sFh5UcuK lyyUtacOEw1BwzpI859RszsrFdb15lz0Hw1pFn0EHnP_egSP9n_htPKijP_H zHQQPnxIegetnyyiSjN6eeWDK0bCHn3yDRNnkW7mJ2pN0kcg- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Saurav Sachidanand , freebsd-hackers@freebsd.org References: From: Pedro Giffuni Message-ID: <2634b0e5-2ef1-87fa-27a1-9aab13f01901@FreeBSD.org> Date: Mon, 27 Feb 2017 13:34:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:31:19 -0000 [Please don't include soc-admin for project proposals: the list is exclusively for administrative purposes.] On 2/27/2017 8:28 AM, Saurav Sachidanand wrote: > Hello FreeBSD community, > > I'm > ​ Saurav Sachidanand, and I'm​ > a CS sophomore studying in India > ​. > I have an interest in operating systems development and wish to > contribute to the FreeBSD community. I'm proficient with C and have > some experience in kernel programming. Hence, I'd like to propose an > original project for GSoC 2017 that I feel would benefit this community. > > In past years, the Lua interpreter was ported to run inside the Linux > and NetBSD kernel [1]. Lua was chosen because it's interpreter is very > small (~240 KB) compared to that of Python or Ruby, it's MIT licensed, > and is almost freestanding. A working demonstration of it is a packet > filtering algorithm written entirely in kernel Lua [2]. > > Specifically, my proposal would be to port the following that are > currently written for NetBSD: I think a FreeBSD developer (wkozek?) already did this some time ago. I do recall seeing the code somewhere in github. I don't mean to discourage you but I think the NetBSD guys haven't found much uses for the Lua module so the justification for working on this would have to find a real use. There was also a suggestion in the NetBSD lists to use Lua for the kernel debugger (ddb) and in their firewall (NPF) but AFAICT those don't really depend on the kernel module. Pedro. From owner-freebsd-hackers@freebsd.org Tue Feb 28 11:13:48 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB99ACF1429 for ; Tue, 28 Feb 2017 11:13:48 +0000 (UTC) (envelope-from hrant@dadivanyan.net) Received: from pandora.amnic.net (pandora.amnic.net [IPv6:2001:67c:21c:a610::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A5FFD6F; Tue, 28 Feb 2017 11:13:48 +0000 (UTC) (envelope-from hrant@dadivanyan.net) Received: from ran by pandora.amnic.net with local (Exim 4.88 (FreeBSD)) (envelope-from ) id 1cifiy-0003hg-1B; Tue, 28 Feb 2017 15:13:44 +0400 Subject: Re: system time instability In-Reply-To: To: Ian Lepore Date: Tue, 28 Feb 2017 15:13:43 +0400 (+04) From: Hrant Dadivanyan CC: Konstantin Belousov , freebsd-hackers@freebsd.org X-PGP: https://amnic.net/pgpkeys/hrant.asc X-NCC-RegID: am.isoc X-Mailer: ELM [version 2.4ME+ PL127 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Message-Id: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 11:13:48 -0000 > [ Charset ISO-8859-1 converted... ] Dear Ian, Two months are passed, everything works fine and this is status report. > > > The server did run for almost a day without PPS and looks stable. I > > > start > > > to believe, to my shame, that I did a mistake when testing this > > > previously. > > > Then the whole post is wrong and cable seems to be most suspected > > > part again. > > > Even now it's hard to understand this wrong behaviour, but anyway ... > > > > > > Just replaced the cable with shielded one where each pair has > > > separate > > > shield, used dedicated pair for PPS and ground; grounded the shields. > > > > > > Thank you Konstantin, thank you Ian ! > > > Hrant > > > > > > > A bad PPS signal could definitely lead to frequency trouble, if the way > > the signal is bad involves ringing, or the electrical level floating > > around the cutoff points for detecting low vs. high level -- you'd get > > false pulses, and some of them would be close enough to the time of the > > real pulse that they would make it through the spike/median filters in > > ntpd.  An early or late pulse looks like a phase step, and several > > consistant-enough phase steps in the same polling period looks like a > > frequency step. > > > > You mentioned using a 74LS245 bus driver... that can lead to ringing if > > the load is light, maybe the rs232 port on this new hardware has a much > > higher input impedance than your old system.  It might be worth adding > > a series resistor at the computer end to soak up reflections, something > > in the 30-100 ohm range should work. > > > > Wow, thank you, will try ! > There was the load of 1kOhm that I forgot about. But cable was the issue, there was no a single jump in frequency after replacement and jitter is below 1-2us all the time. The second node (the servers are anycasted for redundancy) is upgraded to 11.0 and also works pretty stable. Thank you and Konstantin for great help and sorry for this off-topic thread. Hrant > > -- Ian > > -- > Hrant Dadivanyan (aka Ran d'Adi) hrant(at)dadivanyan.net > /* "Feci quod potui, faciant meliora potentes." */ ran(at)psg.com -- Hrant Dadivanyan (aka Ran d'Adi) hrant(at)dadivanyan.net /* "Feci quod potui, faciant meliora potentes." */ ran(at)psg.com From owner-freebsd-hackers@freebsd.org Tue Feb 28 20:19:03 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C153CF2AD5 for ; Tue, 28 Feb 2017 20:19:03 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 2D5E732F; Tue, 28 Feb 2017 20:19:02 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 28 Feb 2017 12:29:53 -0800 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.15.2/8.14.4) with ESMTP id v1SKHsBi001556; Tue, 28 Feb 2017 12:17:54 -0800 (PST) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.15.2/8.14.4/Submit) id v1SKHsAb001555; Tue, 28 Feb 2017 12:17:54 -0800 (PST) (envelope-from ambrisko) Date: Tue, 28 Feb 2017 12:17:54 -0800 From: Doug Ambrisko To: Harry Schmalzbauer Cc: ambrisko@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20170228201753.GA99322@ambrisko.com> References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de> <20150710154654.GA71708@ambrisko.com> <58B5D571.2010103@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <58B5D571.2010103@omnilan.de> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:19:03 -0000 On Tue, Feb 28, 2017 at 08:54:25PM +0100, Harry Schmalzbauer wrote: | Bezüglich Doug Ambrisko's Nachricht vom 10.07.2015 17:46 (localtime): | > On Fri, Jul 10, 2015 at 04:18:14PM +0200, Harald Schmalzbauer wrote: | > | | > | > | Hello, | > | > | | > | > | first sorry for the missing thread references in the header, I'm not | > | > | subscribed to hackers@. | > | > | | > | > | bdrewery@ pointed me to this discussion in response to my question to | > | > | stable@ | > | > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) | > | > | | > | > | Last promising post I found: | > | > | | > | > | > |/ > I have a new patch at: | > | > | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch | > | > | > /|/ > that I tested against head. This should be pretty close to commiting | > | > | > /|/ > unless people find some issues with it. | > | > | > /|/ | > | > | > /|/ In sys/kern/vfs_mount.c: | > | > | > /|/ + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); | > | > | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); | > | > | > /|/ | > | > | > /|/ This always strips the last byte off the fspath. | > | > | > /|/ | > | > | > /|/ I like that this only touches the kernel, so it does not break anything | > | > | > /|/ regarding mount/umount of filesystems with short paths, including | > | > | > /|/ (NFS) filesystems that do not respond. | > | > | > /|/ | > | > | > /|/ The patch does not enlarge f_mntfromname which may be a problem for | > | > | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] | > | > | > /|/ errors could still occur in more extreme situations. | > | > | > / | > | > | > Good point on nullfs. I'll look at fixing that. To do that I'm | > | > | > changing mnt_path to mnt_topath so then I can have a mnt_frompath. | > | > | > I'll add nullfs to my test cases. I'll need to run through the uses | > | > | > of f_mntfromname. It was pretty easy with f_mntonname since it was | > | > | > only allocated in one place just used a bunch of other place. I assume | > | > | > that mount root would be short. | > | > | | > | > | Thanks a lot so far for working hard on that problem! | > | > | Is there anything newer than "mount_bigger_2.patch", which considers | > | > | potential nullfs problems? | > | > | I'm heavily using nullfs (without poudriere), but I'd give it a try on | > | > | my rather lightly loaded local 10.1 storage box ??? almost all snapshots | > | > | are useless, can't access them in case of the case; which happens | > | > | frequently :-( | > | > | Would I have to expect any nullfs regressions with the april | > | > | (mount_bigger_2) patch?? | > | | > | Bez?glich Doug Ambrisko's Nachricht vom 01.11.2014 16:40 (localtime): | > | > I should be able to resume working on this since things are starting to | > | > slow down. It shouldn't be much more work to get it finished off to | > | > put up for review. | > | | > | Hello Doug, | > | | > | I've been using your mount_bigger_2.patch for some months without | > | problems, but haven't done any kind of stress test. | > | It just saves my soul in case I have to recover files from | > | (zfs-)snapshots from time to time :-) | > | | | Hello Doug, | | I hope you are fine! | Nice website, which I checked to see if you gave up on FreeBSD, before | trying to nag you ;-) | | | | Welcome Page | | | :-) :-) :-) | | But I saw r307326, so I thought it's time for my annual | "mount_bigger_2_1.patch" status question ;-) | | | I'm currently planning to upgrade some machines from 10 to 11-stable, | where I've been happyly running your patch. | Any updates on the MNAMELEN front? I nearby read about plans to extend | it to ?1000:1088?. | | But just for now I'd highly appreciate if you could tell me if you are | ware of any objections applying your | mount_bigger_2.patch on 11-stable. | | Hope you don't mind if I quote a question from about a year ago: | | Bezüglich Harry Schmalzbauer's Nachricht vom 19.11.2015 11:38 (localtime): | … | >> | I've been using your mount_bigger_2.path for some months without | >> | problems, but haven't done any kind of stress test. | >> | It just saves my soul in case I have to recover files from | >> | (zfs-)snapshots from time to time :-) | > | > Hello Doug, | > | > unfortunately, mount_bigger doesn't cover the length restriction for | > make_dev_p(), which leads to inaccessable zvols | > (g_dev_taste: make_dev_p() failed | > (gp->name=zvol/babasP0.1xSATA7k2-0/liveBACKSTOR/zfsREPL/esm-vega/P1/iscsi.redtsdatahdd500@epochp2, | > error=63)) | | Do you have anything handy which solves the make_dev_p() limitation? This got lost in my emails. I need to clean out my home emails. Too many things get lost on I need to go back and look at it but then forget what. I was going to look at the this issue when I got a free moment but then couldn't find it. Do you have a simple repro. to show this. It would be great if the repo. was based on md disk that was ZFS created, mounted and this done to. Then I can repro. it locally and look at it. I have bhyve setup to UEFI PXE boot on my laptop to test things out. I'm still waiting for 64 bit inodes to come in which is supposed to help with this and make it not needed. I'm still running this code and need to put it on my laptop since I've run into this issue there now. It's been nice that people haven't been changing things so the patch still applies. Although it touches a bunch of files it doesn't touch much. I wanted it to be fairly transparent. The main piece missing is getting the full paths back to user-land so that running mount would show them versus the trancated versus. I had some ideas on that but stopped looking at it. A hack could be done to use a sysctl to pass that info. like some other tools use. Thanks, Doug A. From owner-freebsd-hackers@freebsd.org Tue Feb 28 19:54:30 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E3DECF2177 for ; Tue, 28 Feb 2017 19:54:30 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF69DB37; Tue, 28 Feb 2017 19:54:29 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v1SJsQWX034816; Tue, 28 Feb 2017 20:54:26 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 08B12363; Tue, 28 Feb 2017 20:54:25 +0100 (CET) Message-ID: <58B5D571.2010103@omnilan.de> Date: Tue, 28 Feb 2017 20:54:25 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: ambrisko@freebsd.org CC: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de> <20150710154654.GA71708@ambrisko.com> In-Reply-To: <20150710154654.GA71708@ambrisko.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 28 Feb 2017 20:54:26 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-Mailman-Approved-At: Tue, 28 Feb 2017 20:44:53 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:54:30 -0000 Bezüglich Doug Ambrisko's Nachricht vom 10.07.2015 17:46 (localtime): > On Fri, Jul 10, 2015 at 04:18:14PM +0200, Harald Schmalzbauer wrote: > | > | > | Hello, > | > | > | > | first sorry for the missing thread references in the header, I'm not > | > | subscribed to hackers@. > | > | > | > | bdrewery@ pointed me to this discussion in response to my question to > | > | stable@ > | > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) > | > | > | > | Last promising post I found: > | > | > | > | > |/ > I have a new patch at: > | > | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch > | > | > /|/ > that I tested against head. This should be pretty close to commiting > | > | > /|/ > unless people find some issues with it. > | > | > /|/ > | > | > /|/ In sys/kern/vfs_mount.c: > | > | > /|/ + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); > | > | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); > | > | > /|/ > | > | > /|/ This always strips the last byte off the fspath. > | > | > /|/ > | > | > /|/ I like that this only touches the kernel, so it does not break anything > | > | > /|/ regarding mount/umount of filesystems with short paths, including > | > | > /|/ (NFS) filesystems that do not respond. > | > | > /|/ > | > | > /|/ The patch does not enlarge f_mntfromname which may be a problem for > | > | > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOOLONG] > | > | > /|/ errors could still occur in more extreme situations. > | > | > / > | > | > Good point on nullfs. I'll look at fixing that. To do that I'm > | > | > changing mnt_path to mnt_topath so then I can have a mnt_frompath. > | > | > I'll add nullfs to my test cases. I'll need to run through the uses > | > | > of f_mntfromname. It was pretty easy with f_mntonname since it was > | > | > only allocated in one place just used a bunch of other place. I assume > | > | > that mount root would be short. > | > | > | > | Thanks a lot so far for working hard on that problem! > | > | Is there anything newer than "mount_bigger_2.patch", which considers > | > | potential nullfs problems? > | > | I'm heavily using nullfs (without poudriere), but I'd give it a try on > | > | my rather lightly loaded local 10.1 storage box ??? almost all snapshots > | > | are useless, can't access them in case of the case; which happens > | > | frequently :-( > | > | Would I have to expect any nullfs regressions with the april > | > | (mount_bigger_2) patch?? > | > | Bez?glich Doug Ambrisko's Nachricht vom 01.11.2014 16:40 (localtime): > | > I should be able to resume working on this since things are starting to > | > slow down. It shouldn't be much more work to get it finished off to > | > put up for review. > | > | Hello Doug, > | > | I've been using your mount_bigger_2.patch for some months without > | problems, but haven't done any kind of stress test. > | It just saves my soul in case I have to recover files from > | (zfs-)snapshots from time to time :-) > | Hello Doug, I hope you are fine! Nice website, which I checked to see if you gave up on FreeBSD, before trying to nag you ;-) Welcome Page :-) :-) :-) But I saw r307326, so I thought it's time for my annual "mount_bigger_2_1.patch" status question ;-) I'm currently planning to upgrade some machines from 10 to 11-stable, where I've been happyly running your patch. Any updates on the MNAMELEN front? I nearby read about plans to extend it to ?1000:1088?. But just for now I'd highly appreciate if you could tell me if you are ware of any objections applying your mount_bigger_2.patch on 11-stable. Hope you don't mind if I quote a question from about a year ago: Bezüglich Harry Schmalzbauer's Nachricht vom 19.11.2015 11:38 (localtime): … >> | I've been using your mount_bigger_2.path for some months without >> | problems, but haven't done any kind of stress test. >> | It just saves my soul in case I have to recover files from >> | (zfs-)snapshots from time to time :-) > > Hello Doug, > > unfortunately, mount_bigger doesn't cover the length restriction for > make_dev_p(), which leads to inaccessable zvols > (g_dev_taste: make_dev_p() failed > (gp->name=zvol/babasP0.1xSATA7k2-0/liveBACKSTOR/zfsREPL/esm-vega/P1/iscsi.redtsdatahdd500@epochp2, > error=63)) > > … Do you have anything handy which solves the make_dev_p() limitation? Greetings, -harry From owner-freebsd-hackers@freebsd.org Wed Mar 1 08:14:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 282F4CF2A96 for ; Wed, 1 Mar 2017 08:14:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D192DB4; Wed, 1 Mar 2017 08:14:43 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (220-253-188-71.dyn.iinet.net.au [220.253.188.71]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v218EZJ2018411 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Mar 2017 00:14:38 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Warner Losh , Allan Jude References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> Cc: "freebsd-hackers@freebsd.org" , Saurav Sachidanand From: Julian Elischer Message-ID: Date: Wed, 1 Mar 2017 16:14:29 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 08:14:44 -0000 On 28/2/17 2:01 am, Warner Losh wrote: > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude wrote: >> On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand wrote: >>> Hello FreeBSD community, >>> >>> I'm >>> Saurav Sachidanand, and I'm >>> a CS sophomore studying in India >>> . >>> I have an interest in operating systems development and wish to >>> contribute >>> to the FreeBSD community. I'm proficient with C and have some >>> experience in >>> kernel programming. Hence, I'd like to propose an original project for >>> GSoC >>> 2017 that I feel would benefit this community. >>> >>> In past years, the Lua interpreter was ported to run inside the Linux >>> and >>> NetBSD kernel [1]. Lua was chosen because it's interpreter is very >>> small (~240 >>> KB) compared to that of Python or Ruby, it's MIT licensed, and is >>> almost >>> freestanding. A working demonstration of it is a packet filtering >>> algorithm >>> written entirely in kernel Lua [2]. >>> >>> Specifically, my proposal would be to port the following that are >>> currently >>> written for NetBSD: >>> - the modified Lua VM source code with _KERNEL preprocessor directives >>> to >>> exclude user-space functionality like floating point, the io and os >>> module >>> in the standard library, etc. [3] >>> - the kernel module device driver for /dev/lua, to which Lua scripts >>> are >>> fed to be executed [4], [5] >>> - the luactl user-space program to control the Lua device and a couple >>> of >>> sysctl variables which serve similar purpose [6], [7] >>> >>> And then: >>> - run the Lua test suite targeting whatever we support in the kernel to >>> make sure it works [8] >>> - and write Lua bindings to the kernel interfaces that would interest >>> the >>> FreeBSD community >>> >>> Since NetBSD and FreeBSD have similar kernel interfaces (mutexes, >>> linked >>> lists, device switch interface), the porting shouldn't involve too much >>> code refactoring. Also, this would all be an experiment in that we >>> don't >>> fully know what the real world use cases might be, but it would attract >>> more people to writing kernel code who otherwise wouldn't because of >>> having >>> to do everything in C. And it would be interesting to carry out it out >>> in >>> FreeBSD as well since it has a larger community than NetBSD. >>> >>> I humbly request anyone who is interested in this project to be my >>> potential mentor(s) for GSoC. >>> >>> More slides on kernel Lua in NetBSD - [9], [10]. >>> >>> Thanks, >>> Saurav >>> >>> [1] - http://www.netbsd.org/~lneto/dls14.pdf >>> [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf >>> [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/dist/src >>> [4] - >>> https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/lua >>> [5] - >>> https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/modules/luasystm >>> [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin/luactl >>> [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current >>> [8] - http://www.lua.org/tests/ >>> [9] - >>> https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012/kernel_mode_lua.pdf >>> [10] - https://www.lua.org/wshop13/Cormack.pdf >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> This may be quite a nice thing to have. Another upcoming use for LUA in the kernel is ZFS Channel Programs. These allow a number of ZFS operations to be completed as a single atomic transaction. >> >> I would hope we could structure this in such a way as to not end up with two copies of Lua in the kernel. > There's also a 3/4 finished lua in the boot loader that you might be > able to leverage as well.... I'd like to see that finished. While Devin has done Heroic work with the forth in the loader, I think it's time has come. It' be nice to have something a little less '60s. > > Warner > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://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 Mar 1 15:47:08 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC92ECF2988 for ; Wed, 1 Mar 2017 15:47:08 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7104413B for ; Wed, 1 Mar 2017 15:47:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 506595b1-fe96-11e6-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 506595b1-fe96-11e6-95b5-6dfd7dbb0ee5; Wed, 01 Mar 2017 15:47:04 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v21FkrtZ006720; Wed, 1 Mar 2017 08:46:53 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488383213.60166.10.camel@freebsd.org> Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD From: Ian Lepore To: Julian Elischer , Warner Losh , Allan Jude Cc: "freebsd-hackers@freebsd.org" , Saurav Sachidanand Date: Wed, 01 Mar 2017 08:46:53 -0700 In-Reply-To: References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:47:09 -0000 On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: > On 28/2/17 2:01 am, Warner Losh wrote: > > > > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude > > wrote: > > > > > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand > > chidanand@gmail.com> wrote: > > > > > > > > Hello FreeBSD community, > > > > > > > > I'm > > > > Saurav Sachidanand, and I'm > > > > a CS sophomore studying in India > > > > . > > > > I have an interest in operating systems development and wish to > > > > contribute > > > > to the FreeBSD community. I'm proficient with C and have some > > > > experience in > > > > kernel programming. Hence, I'd like to propose an original > > > > project for > > > > GSoC > > > > 2017 that I feel would benefit this community. > > > > > > > > In past years, the Lua interpreter was ported to run inside the > > > > Linux > > > > and > > > > NetBSD kernel [1]. Lua was chosen because it's interpreter is > > > > very > > > > small (~240 > > > > KB) compared to that of Python or Ruby, it's MIT licensed, and > > > > is > > > > almost > > > > freestanding. A working demonstration of it is a packet > > > > filtering > > > > algorithm > > > > written entirely in kernel Lua [2]. > > > > > > > > Specifically, my proposal would be to port the following that > > > > are > > > > currently > > > > written for NetBSD: > > > > - the modified Lua VM source code with _KERNEL preprocessor > > > > directives > > > > to > > > > exclude user-space functionality like floating point, the io > > > > and os > > > > module > > > > in the standard library, etc. [3] > > > > - the kernel module device driver for /dev/lua, to which Lua > > > > scripts > > > > are > > > > fed to be executed [4], [5] > > > > - the luactl user-space program to control the Lua device and a > > > > couple > > > > of > > > > sysctl variables which serve similar purpose [6], [7] > > > > > > > > And then: > > > > - run the Lua test suite targeting whatever we support in the > > > > kernel to > > > > make sure it works [8] > > > > - and write Lua bindings to the kernel interfaces that would > > > > interest > > > > the > > > > FreeBSD community > > > > > > > > Since NetBSD and FreeBSD have similar kernel interfaces > > > > (mutexes, > > > > linked > > > > lists, device switch interface), the porting shouldn't involve > > > > too much > > > > code refactoring. Also, this would all be an experiment in that > > > > we > > > > don't > > > > fully know what the real world use cases might be, but it would > > > > attract > > > > more people to writing kernel code who otherwise wouldn't > > > > because of > > > > having > > > > to do everything in C. And it would be interesting to carry out > > > > it out > > > > in > > > > FreeBSD as well since it has a larger community than NetBSD. > > > > > > > > I humbly request anyone who is interested in this project to be > > > > my > > > > potential mentor(s) for GSoC. > > > > > > > > More slides on kernel Lua in NetBSD - [9], [10]. > > > > > > > > Thanks, > > > > Saurav > > > > > > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf > > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf > > > > [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/ > > > > dist/src > > > > [4] - > > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module > > > > s/lua > > > > [5] - > > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module > > > > s/luasystm > > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin > > > > /luactl > > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current > > > > [8] - http://www.lua.org/tests/ > > > > [9] - > > > > https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012 > > > > /kernel_mode_lua.pdf > > > > [10] - https://www.lua.org/wshop13/Cormack.pdf > > > > _______________________________________________ > > > > freebsd-hackers@freebsd.org mailing list > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > > To unsubscribe, send any mail to > > > > "freebsd-hackers-unsubscribe@freebsd.org" > > > This may be quite a nice thing to have. Another upcoming use for > > > LUA in the kernel is ZFS Channel Programs. These allow a number > > > of ZFS operations to be completed as a single atomic transaction. > > > > > > I would hope we could structure this in such a way as to not end > > > up with two copies of Lua in the kernel. > > There's also a 3/4 finished lua in the boot loader that you might > > be > > able to leverage as well.... > I'd like to see that finished. While Devin has done Heroic work with  > the forth in the loader, I think it's time has come. > It' be nice to have something a little less '60s. > > > > > > > Warner I was under the impression that the "lua in bootloader" work was basically done and just needed testing, which nobody has done.  I think it's all sitting in the projects/lua-bootloader branch in svn. -- Ian From owner-freebsd-hackers@freebsd.org Wed Mar 1 15:51:05 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B14B4CF2C13 for ; Wed, 1 Mar 2017 15:51:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78086A26 for ; Wed, 1 Mar 2017 15:51:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x243.google.com with SMTP id f84so5117099ioj.0 for ; Wed, 01 Mar 2017 07:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=F1wO7aWQ5PX0SC7sWxrxvBCDHv4RIrxdP8YaBsOZsPY=; b=r1xQjFhmKiXaZtFUou3j3nR2ajedQyf8CmjvVTXYIfk2OBYQlOxM/Az5f4dFBTVnFG FnOuTYpNIz0fn6W9q5gQqD0xO0YaAjmF8Vx0zdPAsJBbSO71dlkSlkQNXP1eK1iwMOrV ty+PYmram3Dn+oPKz4nSjl0ce+ff0F8h+eBo6flqC6VMguamMlQ+9laNfTSbmwFOytxN zAHCMP9gU8KwPEE8ELEZ/1hhm2h5S0lXvBGzOfHQkPua5Lp7VpVcxkHOmD10qdWM7tkS 6DmhpkyMGDJ25sBUQtwss8BX5SNuw6ZRQyzd/kgU5RTjjs0xWAKLAeW26cCc7nQvNze5 fC3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=F1wO7aWQ5PX0SC7sWxrxvBCDHv4RIrxdP8YaBsOZsPY=; b=CX/qILFuxWiRCEdUlbcWrFSZxfYWfth42w3y4q5PTyQ5kG6DWAnOxcpDJcRW/KxkiU E+jP84m/hzolmSVc75T8ao+te651w21m2ZVd2UXGfbIrw37YXw2XsUSzLW9PQUt7XJK2 Wg0KUyPKI1UV3visagBM+Q4v9D1ZAhh/Vz+kMbqr0MRe8BsRaZfmCx2VACODO/f8ExxB ngLv/N5uXaxUA9hxDswLyatgkaM9LxWtBC1MtVf7wI7Rv4BMQDI/1mQ093SvHpimbiNo CynV6qHGxUaEGUAG/p6l6PY2O0ZNMt1+JN1vsCrLDgs7n3yZA/PCgYCGCx+Jy02pqxHd klVw== X-Gm-Message-State: AMke39kqX1zRqXlrlnaDULJ6yLqIm71vTRBemroKkw4CGAQUIbZ/bTGqvZCVVyKwcHScFKqd9pQ1rjqaNrzVrg== X-Received: by 10.107.174.220 with SMTP id n89mr9891985ioo.166.1488383464456; Wed, 01 Mar 2017 07:51:04 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Wed, 1 Mar 2017 07:51:03 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <1488383213.60166.10.camel@freebsd.org> References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> <1488383213.60166.10.camel@freebsd.org> From: Warner Losh Date: Wed, 1 Mar 2017 08:51:03 -0700 X-Google-Sender-Auth: PJfb9EmLqoPPzzkBCr8qFDriTH8 Message-ID: Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Ian Lepore Cc: Julian Elischer , Allan Jude , "freebsd-hackers@freebsd.org" , Saurav Sachidanand Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:51:05 -0000 On Wed, Mar 1, 2017 at 8:46 AM, Ian Lepore wrote: > On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: >> On 28/2/17 2:01 am, Warner Losh wrote: >> > >> > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude >> > wrote: >> > > >> > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand > > > chidanand@gmail.com> wrote: >> > > > >> > > > Hello FreeBSD community, >> > > > >> > > > I'm >> > > > Saurav Sachidanand, and I'm >> > > > a CS sophomore studying in India >> > > > . >> > > > I have an interest in operating systems development and wish to >> > > > contribute >> > > > to the FreeBSD community. I'm proficient with C and have some >> > > > experience in >> > > > kernel programming. Hence, I'd like to propose an original >> > > > project for >> > > > GSoC >> > > > 2017 that I feel would benefit this community. >> > > > >> > > > In past years, the Lua interpreter was ported to run inside the >> > > > Linux >> > > > and >> > > > NetBSD kernel [1]. Lua was chosen because it's interpreter is >> > > > very >> > > > small (~240 >> > > > KB) compared to that of Python or Ruby, it's MIT licensed, and >> > > > is >> > > > almost >> > > > freestanding. A working demonstration of it is a packet >> > > > filtering >> > > > algorithm >> > > > written entirely in kernel Lua [2]. >> > > > >> > > > Specifically, my proposal would be to port the following that >> > > > are >> > > > currently >> > > > written for NetBSD: >> > > > - the modified Lua VM source code with _KERNEL preprocessor >> > > > directives >> > > > to >> > > > exclude user-space functionality like floating point, the io >> > > > and os >> > > > module >> > > > in the standard library, etc. [3] >> > > > - the kernel module device driver for /dev/lua, to which Lua >> > > > scripts >> > > > are >> > > > fed to be executed [4], [5] >> > > > - the luactl user-space program to control the Lua device and a >> > > > couple >> > > > of >> > > > sysctl variables which serve similar purpose [6], [7] >> > > > >> > > > And then: >> > > > - run the Lua test suite targeting whatever we support in the >> > > > kernel to >> > > > make sure it works [8] >> > > > - and write Lua bindings to the kernel interfaces that would >> > > > interest >> > > > the >> > > > FreeBSD community >> > > > >> > > > Since NetBSD and FreeBSD have similar kernel interfaces >> > > > (mutexes, >> > > > linked >> > > > lists, device switch interface), the porting shouldn't involve >> > > > too much >> > > > code refactoring. Also, this would all be an experiment in that >> > > > we >> > > > don't >> > > > fully know what the real world use cases might be, but it would >> > > > attract >> > > > more people to writing kernel code who otherwise wouldn't >> > > > because of >> > > > having >> > > > to do everything in C. And it would be interesting to carry out >> > > > it out >> > > > in >> > > > FreeBSD as well since it has a larger community than NetBSD. >> > > > >> > > > I humbly request anyone who is interested in this project to be >> > > > my >> > > > potential mentor(s) for GSoC. >> > > > >> > > > More slides on kernel Lua in NetBSD - [9], [10]. >> > > > >> > > > Thanks, >> > > > Saurav >> > > > >> > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf >> > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf >> > > > [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/ >> > > > dist/src >> > > > [4] - >> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >> > > > s/lua >> > > > [5] - >> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >> > > > s/luasystm >> > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin >> > > > /luactl >> > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current >> > > > [8] - http://www.lua.org/tests/ >> > > > [9] - >> > > > https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012 >> > > > /kernel_mode_lua.pdf >> > > > [10] - https://www.lua.org/wshop13/Cormack.pdf >> > > > _______________________________________________ >> > > > freebsd-hackers@freebsd.org mailing list >> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > > > To unsubscribe, send any mail to >> > > > "freebsd-hackers-unsubscribe@freebsd.org" >> > > This may be quite a nice thing to have. Another upcoming use for >> > > LUA in the kernel is ZFS Channel Programs. These allow a number >> > > of ZFS operations to be completed as a single atomic transaction. >> > > >> > > I would hope we could structure this in such a way as to not end >> > > up with two copies of Lua in the kernel. >> > There's also a 3/4 finished lua in the boot loader that you might >> > be >> > able to leverage as well.... >> I'd like to see that finished. While Devin has done Heroic work with >> the forth in the loader, I think it's time has come. >> It' be nice to have something a little less '60s. >> >> > >> > >> > Warner > > I was under the impression that the "lua in bootloader" work was > basically done and just needed testing, which nobody has done. I think > it's all sitting in the projects/lua-bootloader branch in svn. The branch compiles. Testing has been done, but there's some missing bits. It basically kinda works for the average case, but more advanced uses of the bootloader still have sharp pointy edges on them, the extent of the pointy edges is unknown. At this point the rebasing of the branch is non-trivial due to the merge conflicts that have crept in. They don't look awful, but when I tried to use git to rebase to a more modern FreeBSD, there were lots of stupid things. Maybe I'll try again... Warner From owner-freebsd-hackers@freebsd.org Wed Mar 1 16:08:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C896CE4597 for ; Wed, 1 Mar 2017 16:08:26 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 203BFC06; Wed, 1 Mar 2017 16:08:26 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: by mail-wm0-x242.google.com with SMTP id m70so8151567wma.1; Wed, 01 Mar 2017 08:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fIayQCfIWZkPy1Wjsyu8VRnSHnP58fcLPdsrudQAccA=; b=tdmbudGxBDLhrSqHMwy/eI+ZG8IkLyqAp1Rg6MlOfiZB8J/VztbqAnJ5dTu12WAUEO pvOLiKXW/4H/1wVB6cbyNus1S7B7eLpvdn2x9SrbAUL6p+9utcdBgZKheBn5l4TKxifZ A9P1lvPsySi4SWVWo7+OVXN3CYrMbzwHCGgvtpRN0dNm4Hqr5srOCJZUYCdQi5WhWGdG /wmpzK1k0Qnq9DoQ9rElo9jAe/gchZpyPFKoK55d1DA9tvXC0KtY6VwyvgXLAVhgZITU T32mcQXMhJvmWmW1lGnndHVLkOurKBJwP4MIuptRnLcpxeAHX+d3CNcKRuc0R8K5VJuC +Q0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fIayQCfIWZkPy1Wjsyu8VRnSHnP58fcLPdsrudQAccA=; b=Lz+Xn4p7vlY+JCVT3JoSzJv2GUh/Dh+px4pA25DPft0GDFNUcTzjJc2v4N0gZBIMBJ kdKCyUqKCeN6Y+rOXweg9T9xg1x8pyfx+z8qf9TqbOzXbZvDU1UCgYTinBNDY7eH+UoA 0fIKVw9sQIdeXkbFLe13cK7TjGLYOf/cAuQyA7Segn7AToKRtxfAe0v8+6RF8fuVgui+ 5X1SmUIsKTrBFI+JC8vmyFvV7Nhoe4wlA7z2Ne6d5di4Gnjp4U/1sXZNfP6zqfIuHjET +junOpROqDjj4/goSJtXMTMhJpAn/B76obHmWp5+xG020cZ240Bk15ZCgkTYBeYv/Bul wueA== X-Gm-Message-State: AMke39mzsbUDL/aLgN3e+CtvAmpq1cD6eoex/z4rmVhDnTIsSoQhOKiJyh0SI1prle/Z54YEOq8hF4U7w0BsTA== X-Received: by 10.28.181.80 with SMTP id e77mr4024205wmf.57.1488384504269; Wed, 01 Mar 2017 08:08:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.144.6 with HTTP; Wed, 1 Mar 2017 08:08:23 -0800 (PST) In-Reply-To: References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> <1488383213.60166.10.camel@freebsd.org> From: Saurav Sachidanand Date: Wed, 1 Mar 2017 16:08:23 +0000 Message-ID: Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Warner Losh Cc: Ian Lepore , Julian Elischer , Allan Jude , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:08:26 -0000 Is it related to this project https://wiki.freebsd.org/SummerOfCode2014/LuaLoader ? Apparently, that project created a generic interface in the bootloader to plug in any interpreter, and then added Lua. How about adding Python as well, as a GSoC project? A team from Intel managed to get Python to run inside GRUB [1] [2]. I can use their work as a reference for modifying the Python interpreter. [1] - https://lwn.net/Articles/641244/ [2] - https://github.com/biosbits/bits On Wed, Mar 1, 2017 at 3:51 PM, Warner Losh wrote: > On Wed, Mar 1, 2017 at 8:46 AM, Ian Lepore wrote: >> On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: >>> On 28/2/17 2:01 am, Warner Losh wrote: >>> > >>> > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude >>> > wrote: >>> > > >>> > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand >> > > chidanand@gmail.com> wrote: >>> > > > >>> > > > Hello FreeBSD community, >>> > > > >>> > > > I'm >>> > > > Saurav Sachidanand, and I'm >>> > > > a CS sophomore studying in India >>> > > > . >>> > > > I have an interest in operating systems development and wish to >>> > > > contribute >>> > > > to the FreeBSD community. I'm proficient with C and have some >>> > > > experience in >>> > > > kernel programming. Hence, I'd like to propose an original >>> > > > project for >>> > > > GSoC >>> > > > 2017 that I feel would benefit this community. >>> > > > >>> > > > In past years, the Lua interpreter was ported to run inside the >>> > > > Linux >>> > > > and >>> > > > NetBSD kernel [1]. Lua was chosen because it's interpreter is >>> > > > very >>> > > > small (~240 >>> > > > KB) compared to that of Python or Ruby, it's MIT licensed, and >>> > > > is >>> > > > almost >>> > > > freestanding. A working demonstration of it is a packet >>> > > > filtering >>> > > > algorithm >>> > > > written entirely in kernel Lua [2]. >>> > > > >>> > > > Specifically, my proposal would be to port the following that >>> > > > are >>> > > > currently >>> > > > written for NetBSD: >>> > > > - the modified Lua VM source code with _KERNEL preprocessor >>> > > > directives >>> > > > to >>> > > > exclude user-space functionality like floating point, the io >>> > > > and os >>> > > > module >>> > > > in the standard library, etc. [3] >>> > > > - the kernel module device driver for /dev/lua, to which Lua >>> > > > scripts >>> > > > are >>> > > > fed to be executed [4], [5] >>> > > > - the luactl user-space program to control the Lua device and a >>> > > > couple >>> > > > of >>> > > > sysctl variables which serve similar purpose [6], [7] >>> > > > >>> > > > And then: >>> > > > - run the Lua test suite targeting whatever we support in the >>> > > > kernel to >>> > > > make sure it works [8] >>> > > > - and write Lua bindings to the kernel interfaces that would >>> > > > interest >>> > > > the >>> > > > FreeBSD community >>> > > > >>> > > > Since NetBSD and FreeBSD have similar kernel interfaces >>> > > > (mutexes, >>> > > > linked >>> > > > lists, device switch interface), the porting shouldn't involve >>> > > > too much >>> > > > code refactoring. Also, this would all be an experiment in that >>> > > > we >>> > > > don't >>> > > > fully know what the real world use cases might be, but it would >>> > > > attract >>> > > > more people to writing kernel code who otherwise wouldn't >>> > > > because of >>> > > > having >>> > > > to do everything in C. And it would be interesting to carry out >>> > > > it out >>> > > > in >>> > > > FreeBSD as well since it has a larger community than NetBSD. >>> > > > >>> > > > I humbly request anyone who is interested in this project to be >>> > > > my >>> > > > potential mentor(s) for GSoC. >>> > > > >>> > > > More slides on kernel Lua in NetBSD - [9], [10]. >>> > > > >>> > > > Thanks, >>> > > > Saurav >>> > > > >>> > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf >>> > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf >>> > > > [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/ >>> > > > dist/src >>> > > > [4] - >>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >>> > > > s/lua >>> > > > [5] - >>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >>> > > > s/luasystm >>> > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin >>> > > > /luactl >>> > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current >>> > > > [8] - http://www.lua.org/tests/ >>> > > > [9] - >>> > > > https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012 >>> > > > /kernel_mode_lua.pdf >>> > > > [10] - https://www.lua.org/wshop13/Cormack.pdf >>> > > > _______________________________________________ >>> > > > freebsd-hackers@freebsd.org mailing list >>> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> > > > To unsubscribe, send any mail to >>> > > > "freebsd-hackers-unsubscribe@freebsd.org" >>> > > This may be quite a nice thing to have. Another upcoming use for >>> > > LUA in the kernel is ZFS Channel Programs. These allow a number >>> > > of ZFS operations to be completed as a single atomic transaction. >>> > > >>> > > I would hope we could structure this in such a way as to not end >>> > > up with two copies of Lua in the kernel. >>> > There's also a 3/4 finished lua in the boot loader that you might >>> > be >>> > able to leverage as well.... >>> I'd like to see that finished. While Devin has done Heroic work with >>> the forth in the loader, I think it's time has come. >>> It' be nice to have something a little less '60s. >>> >>> > >>> > >>> > Warner >> >> I was under the impression that the "lua in bootloader" work was >> basically done and just needed testing, which nobody has done. I think >> it's all sitting in the projects/lua-bootloader branch in svn. > > The branch compiles. Testing has been done, but there's some missing > bits. It basically kinda works for the average case, but more advanced > uses of the bootloader still have sharp pointy edges on them, the > extent of the pointy edges is unknown. At this point the rebasing of > the branch is non-trivial due to the merge conflicts that have crept > in. They don't look awful, but when I tried to use git to rebase to a > more modern FreeBSD, there were lots of stupid things. Maybe I'll try > again... > > Warner From owner-freebsd-hackers@freebsd.org Wed Mar 1 16:13:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F2B0CE48CE for ; Wed, 1 Mar 2017 16:13:01 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x242.google.com (mail-yw0-x242.google.com [IPv6:2607:f8b0:4002:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEFD5303; Wed, 1 Mar 2017 16:13:00 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x242.google.com with SMTP id s15so1517566ywg.0; Wed, 01 Mar 2017 08:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=FwaFIyCwKuVEMGQM1RumSh8/l0UyFKgjM0RNzrKMwBI=; b=qqCOfFryGmrk8HUQHCNQnJa5ohUiy1e7DT7VKK5LEqO+zgmrAtx9UnLTuorIbdtYZ4 r8k6I7P7wOFI5PjUn7mjWlo9B7ZoOuHG4bP4xVzMNxMcdreItL0Gq2PnJHvcRmkMEMs1 oMRVvouC7LbH1pcGqjRIri/Zjz73boC4UnHgOKE/smk6n9ApkdeEWPR4yeTRkWOO7WoY YrWN/hvscKfxVNl1EuxrGzo78W3FudKixLfWw0u/3puWVHcFtzF1S1Ff6WzAtqaPAccZ UGUoqhOmNdFLxGLlsFIbHF9aLBPd+3nbx4wy7fi26jWZ3C29551KwkURAE6oV3eKmpqQ knRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=FwaFIyCwKuVEMGQM1RumSh8/l0UyFKgjM0RNzrKMwBI=; b=cZtXuA34nX95NvTv7ckeAw/KCqTutzChLoHF/kU5z+6sX3cgB8k62c4FuJRaYo9YZn GMZSqTx1tXIJnpB8IJ7UGP9TVWlBNHOKP1HxvZqJ4XHo1jHS/fdo1iAwfo6i9OxDuaVB KlKlmTlf95aUbvC75OrIpYywe1PdvZWiAd1o7OQxGVeBQq1rQmzRUQ2gV4xSjC3/qkpE ZYCZrVL+bGWHeomrOH8JL0o5eOWliydrrn8xtHkUyDRoBFtLRTF7CQcStmlAnrQKBuHX u6rvVFW6YxLkmP7AbLN6OnDJu1Bvz8toB/3ck4opbH6xNz3g9K7U3BDlGW1v5FKEvUUG mgOQ== X-Gm-Message-State: AMke39lVInIV1fVQueX6DyWOB33BM+l0qJW1swb9J6LCSP9MXcZodNajlfm/0rbHRT3YooJ5xTaa6cxv9FDL8A== X-Received: by 10.129.68.31 with SMTP id r31mr3024637ywa.307.1488384779829; Wed, 01 Mar 2017 08:12:59 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Wed, 1 Mar 2017 08:12:59 -0800 (PST) In-Reply-To: References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> <1488383213.60166.10.camel@freebsd.org> From: Alan Somers Date: Wed, 1 Mar 2017 09:12:59 -0700 X-Google-Sender-Auth: HsMfjPqvNKjCLRACKizyGwPl1wo Message-ID: Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Saurav Sachidanand Cc: Warner Losh , "freebsd-hackers@freebsd.org" , Allan Jude , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:13:01 -0000 Python is huge, and we already have people complaining that the bootloader doesn't fit in their boot partitions ever since it gained GELI support. The advantage of Lua is that the embedded interpreter is very small. I'd rather not bloat the bootloader too much. -Alan On Wed, Mar 1, 2017 at 9:08 AM, Saurav Sachidanand wrote: > Is it related to this project > https://wiki.freebsd.org/SummerOfCode2014/LuaLoader ? > Apparently, that project created a generic interface in the bootloader > to plug in any > interpreter, and then added Lua. > > How about adding Python as well, as a GSoC project? A team from Intel managed to > get Python to run inside GRUB [1] [2]. I can use their work as a > reference for modifying > the Python interpreter. > > [1] - https://lwn.net/Articles/641244/ > [2] - https://github.com/biosbits/bits > > On Wed, Mar 1, 2017 at 3:51 PM, Warner Losh wrote: >> On Wed, Mar 1, 2017 at 8:46 AM, Ian Lepore wrote: >>> On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: >>>> On 28/2/17 2:01 am, Warner Losh wrote: >>>> > >>>> > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude >>>> > wrote: >>>> > > >>>> > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand >>> > > chidanand@gmail.com> wrote: >>>> > > > >>>> > > > Hello FreeBSD community, >>>> > > > >>>> > > > I'm >>>> > > > Saurav Sachidanand, and I'm >>>> > > > a CS sophomore studying in India >>>> > > > . >>>> > > > I have an interest in operating systems development and wish to >>>> > > > contribute >>>> > > > to the FreeBSD community. I'm proficient with C and have some >>>> > > > experience in >>>> > > > kernel programming. Hence, I'd like to propose an original >>>> > > > project for >>>> > > > GSoC >>>> > > > 2017 that I feel would benefit this community. >>>> > > > >>>> > > > In past years, the Lua interpreter was ported to run inside the >>>> > > > Linux >>>> > > > and >>>> > > > NetBSD kernel [1]. Lua was chosen because it's interpreter is >>>> > > > very >>>> > > > small (~240 >>>> > > > KB) compared to that of Python or Ruby, it's MIT licensed, and >>>> > > > is >>>> > > > almost >>>> > > > freestanding. A working demonstration of it is a packet >>>> > > > filtering >>>> > > > algorithm >>>> > > > written entirely in kernel Lua [2]. >>>> > > > >>>> > > > Specifically, my proposal would be to port the following that >>>> > > > are >>>> > > > currently >>>> > > > written for NetBSD: >>>> > > > - the modified Lua VM source code with _KERNEL preprocessor >>>> > > > directives >>>> > > > to >>>> > > > exclude user-space functionality like floating point, the io >>>> > > > and os >>>> > > > module >>>> > > > in the standard library, etc. [3] >>>> > > > - the kernel module device driver for /dev/lua, to which Lua >>>> > > > scripts >>>> > > > are >>>> > > > fed to be executed [4], [5] >>>> > > > - the luactl user-space program to control the Lua device and a >>>> > > > couple >>>> > > > of >>>> > > > sysctl variables which serve similar purpose [6], [7] >>>> > > > >>>> > > > And then: >>>> > > > - run the Lua test suite targeting whatever we support in the >>>> > > > kernel to >>>> > > > make sure it works [8] >>>> > > > - and write Lua bindings to the kernel interfaces that would >>>> > > > interest >>>> > > > the >>>> > > > FreeBSD community >>>> > > > >>>> > > > Since NetBSD and FreeBSD have similar kernel interfaces >>>> > > > (mutexes, >>>> > > > linked >>>> > > > lists, device switch interface), the porting shouldn't involve >>>> > > > too much >>>> > > > code refactoring. Also, this would all be an experiment in that >>>> > > > we >>>> > > > don't >>>> > > > fully know what the real world use cases might be, but it would >>>> > > > attract >>>> > > > more people to writing kernel code who otherwise wouldn't >>>> > > > because of >>>> > > > having >>>> > > > to do everything in C. And it would be interesting to carry out >>>> > > > it out >>>> > > > in >>>> > > > FreeBSD as well since it has a larger community than NetBSD. >>>> > > > >>>> > > > I humbly request anyone who is interested in this project to be >>>> > > > my >>>> > > > potential mentor(s) for GSoC. >>>> > > > >>>> > > > More slides on kernel Lua in NetBSD - [9], [10]. >>>> > > > >>>> > > > Thanks, >>>> > > > Saurav >>>> > > > >>>> > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf >>>> > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf >>>> > > > [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/ >>>> > > > dist/src >>>> > > > [4] - >>>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >>>> > > > s/lua >>>> > > > [5] - >>>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >>>> > > > s/luasystm >>>> > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin >>>> > > > /luactl >>>> > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current >>>> > > > [8] - http://www.lua.org/tests/ >>>> > > > [9] - >>>> > > > https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012 >>>> > > > /kernel_mode_lua.pdf >>>> > > > [10] - https://www.lua.org/wshop13/Cormack.pdf >>>> > > > _______________________________________________ >>>> > > > freebsd-hackers@freebsd.org mailing list >>>> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>> > > > To unsubscribe, send any mail to >>>> > > > "freebsd-hackers-unsubscribe@freebsd.org" >>>> > > This may be quite a nice thing to have. Another upcoming use for >>>> > > LUA in the kernel is ZFS Channel Programs. These allow a number >>>> > > of ZFS operations to be completed as a single atomic transaction. >>>> > > >>>> > > I would hope we could structure this in such a way as to not end >>>> > > up with two copies of Lua in the kernel. >>>> > There's also a 3/4 finished lua in the boot loader that you might >>>> > be >>>> > able to leverage as well.... >>>> I'd like to see that finished. While Devin has done Heroic work with >>>> the forth in the loader, I think it's time has come. >>>> It' be nice to have something a little less '60s. >>>> >>>> > >>>> > >>>> > Warner >>> >>> I was under the impression that the "lua in bootloader" work was >>> basically done and just needed testing, which nobody has done. I think >>> it's all sitting in the projects/lua-bootloader branch in svn. >> >> The branch compiles. Testing has been done, but there's some missing >> bits. It basically kinda works for the average case, but more advanced >> uses of the bootloader still have sharp pointy edges on them, the >> extent of the pointy edges is unknown. At this point the rebasing of >> the branch is non-trivial due to the merge conflicts that have crept >> in. They don't look awful, but when I tried to use git to rebase to a >> more modern FreeBSD, there were lots of stupid things. Maybe I'll try >> again... >> >> Warner > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://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 Mar 1 17:48:11 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E01AACF2DF8 for ; Wed, 1 Mar 2017 17:48:11 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 731E1C87; Wed, 1 Mar 2017 17:48:11 +0000 (UTC) (envelope-from sauravsachidanand@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id m70so8593052wma.1; Wed, 01 Mar 2017 09:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ajiVKKAF4Uh2bfslfU738431XpGmmSlq22i43EXORew=; b=XSAjs+N0zggvq5kywlyfSgw/pPsWo0Q7WF1F7EKqF34XC95FsLkJ7tkcbYSqSozHju JiJRe/23bWIZtFGv4ezMC0Vl73KIu0l92d1KdS7ND3AxSl30r3tR1C7Wpi2oxJgnY+45 unQks+HwIY8vwjgITiBUO8PLDg24Wi1t8KfIOB9w+kR0bBKrOj3YxRPw4a7p1dz+DbTm 7P4fVu/uO3o26+iw1FnhBkionPHYlYT201LFaT609hwhodCrG2ux/EyLG0Sh2cOnv0ds occW5HFtYBU6HHWzI6mbzS9depkjUhM24aACgIqgk5BNY24SRcIR0EiTWYfxaxUfcdli wR3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ajiVKKAF4Uh2bfslfU738431XpGmmSlq22i43EXORew=; b=O32grDLrMkP5zSFDTD/L42rA4aKpob0bdygkVLu1MFrbduzoAbEz2MWY6mg0mhy/lS emMNlnCG1JFBT8rGHBBoO2Ehq8FEd45tyIomdJnsjm1hN9figW1jIl8CpljwcMIMSAKQ 7xFmqzZA9TZeS80ztb7PXiLgrGhC+I7MqmNkxkfeqFXQqc1hIOcvTYMIl4NIwp0LIYE1 xb+FibCL1iaU2HTANp3GwYWqVAZqVgEBR6Hl0JaxpOQa5PSoLobL8QHwoBsf6cipkbAB 1d6FYjiVVO1DP9PG2ys2RRUgxl7ci+8+VSwUDBiCYSDrNFjaJ8+drbXJX5XZg2/0JJSi LF0Q== X-Gm-Message-State: AMke39ld40fQSFhoY2zfm1b5sU9YpU9ceXChC3iIhOZowA3aw2AsvqCqRXic6dfDs2HtdenJjJDr3BhMFWttXg== X-Received: by 10.28.178.142 with SMTP id b136mr4402063wmf.57.1488390489608; Wed, 01 Mar 2017 09:48:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.144.6 with HTTP; Wed, 1 Mar 2017 09:48:09 -0800 (PST) In-Reply-To: References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> <1488383213.60166.10.camel@freebsd.org> From: Saurav Sachidanand Date: Wed, 1 Mar 2017 23:18:09 +0530 Message-ID: Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Alan Somers Cc: Warner Losh , "freebsd-hackers@freebsd.org" , Allan Jude , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:48:12 -0000 Since the language(s) to be included are chosen at compile time it wouldn't be forcing anyone to use a bloated bootloader. Wouldn't Python's richer standard library (eg: re) be useful in certain situations? On Wed, Mar 1, 2017 at 9:42 PM, Alan Somers wrote: > Python is huge, and we already have people complaining that the > bootloader doesn't fit in their boot partitions ever since it gained > GELI support. The advantage of Lua is that the embedded interpreter > is very small. I'd rather not bloat the bootloader too much. > > -Alan > > On Wed, Mar 1, 2017 at 9:08 AM, Saurav Sachidanand > wrote: >> Is it related to this project >> https://wiki.freebsd.org/SummerOfCode2014/LuaLoader ? >> Apparently, that project created a generic interface in the bootloader >> to plug in any >> interpreter, and then added Lua. >> >> How about adding Python as well, as a GSoC project? A team from Intel managed to >> get Python to run inside GRUB [1] [2]. I can use their work as a >> reference for modifying >> the Python interpreter. >> >> [1] - https://lwn.net/Articles/641244/ >> [2] - https://github.com/biosbits/bits >> >> On Wed, Mar 1, 2017 at 3:51 PM, Warner Losh wrote: >>> On Wed, Mar 1, 2017 at 8:46 AM, Ian Lepore wrote: >>>> On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: >>>>> On 28/2/17 2:01 am, Warner Losh wrote: >>>>> > >>>>> > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude >>>>> > wrote: >>>>> > > >>>>> > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand >>>> > > chidanand@gmail.com> wrote: >>>>> > > > >>>>> > > > Hello FreeBSD community, >>>>> > > > >>>>> > > > I'm >>>>> > > > Saurav Sachidanand, and I'm >>>>> > > > a CS sophomore studying in India >>>>> > > > . >>>>> > > > I have an interest in operating systems development and wish to >>>>> > > > contribute >>>>> > > > to the FreeBSD community. I'm proficient with C and have some >>>>> > > > experience in >>>>> > > > kernel programming. Hence, I'd like to propose an original >>>>> > > > project for >>>>> > > > GSoC >>>>> > > > 2017 that I feel would benefit this community. >>>>> > > > >>>>> > > > In past years, the Lua interpreter was ported to run inside the >>>>> > > > Linux >>>>> > > > and >>>>> > > > NetBSD kernel [1]. Lua was chosen because it's interpreter is >>>>> > > > very >>>>> > > > small (~240 >>>>> > > > KB) compared to that of Python or Ruby, it's MIT licensed, and >>>>> > > > is >>>>> > > > almost >>>>> > > > freestanding. A working demonstration of it is a packet >>>>> > > > filtering >>>>> > > > algorithm >>>>> > > > written entirely in kernel Lua [2]. >>>>> > > > >>>>> > > > Specifically, my proposal would be to port the following that >>>>> > > > are >>>>> > > > currently >>>>> > > > written for NetBSD: >>>>> > > > - the modified Lua VM source code with _KERNEL preprocessor >>>>> > > > directives >>>>> > > > to >>>>> > > > exclude user-space functionality like floating point, the io >>>>> > > > and os >>>>> > > > module >>>>> > > > in the standard library, etc. [3] >>>>> > > > - the kernel module device driver for /dev/lua, to which Lua >>>>> > > > scripts >>>>> > > > are >>>>> > > > fed to be executed [4], [5] >>>>> > > > - the luactl user-space program to control the Lua device and a >>>>> > > > couple >>>>> > > > of >>>>> > > > sysctl variables which serve similar purpose [6], [7] >>>>> > > > >>>>> > > > And then: >>>>> > > > - run the Lua test suite targeting whatever we support in the >>>>> > > > kernel to >>>>> > > > make sure it works [8] >>>>> > > > - and write Lua bindings to the kernel interfaces that would >>>>> > > > interest >>>>> > > > the >>>>> > > > FreeBSD community >>>>> > > > >>>>> > > > Since NetBSD and FreeBSD have similar kernel interfaces >>>>> > > > (mutexes, >>>>> > > > linked >>>>> > > > lists, device switch interface), the porting shouldn't involve >>>>> > > > too much >>>>> > > > code refactoring. Also, this would all be an experiment in that >>>>> > > > we >>>>> > > > don't >>>>> > > > fully know what the real world use cases might be, but it would >>>>> > > > attract >>>>> > > > more people to writing kernel code who otherwise wouldn't >>>>> > > > because of >>>>> > > > having >>>>> > > > to do everything in C. And it would be interesting to carry out >>>>> > > > it out >>>>> > > > in >>>>> > > > FreeBSD as well since it has a larger community than NetBSD. >>>>> > > > >>>>> > > > I humbly request anyone who is interested in this project to be >>>>> > > > my >>>>> > > > potential mentor(s) for GSoC. >>>>> > > > >>>>> > > > More slides on kernel Lua in NetBSD - [9], [10]. >>>>> > > > >>>>> > > > Thanks, >>>>> > > > Saurav >>>>> > > > >>>>> > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf >>>>> > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf >>>>> > > > [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/ >>>>> > > > dist/src >>>>> > > > [4] - >>>>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >>>>> > > > s/lua >>>>> > > > [5] - >>>>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module >>>>> > > > s/luasystm >>>>> > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin >>>>> > > > /luactl >>>>> > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current >>>>> > > > [8] - http://www.lua.org/tests/ >>>>> > > > [9] - >>>>> > > > https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012 >>>>> > > > /kernel_mode_lua.pdf >>>>> > > > [10] - https://www.lua.org/wshop13/Cormack.pdf >>>>> > > > _______________________________________________ >>>>> > > > freebsd-hackers@freebsd.org mailing list >>>>> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>>>> > > > To unsubscribe, send any mail to >>>>> > > > "freebsd-hackers-unsubscribe@freebsd.org" >>>>> > > This may be quite a nice thing to have. Another upcoming use for >>>>> > > LUA in the kernel is ZFS Channel Programs. These allow a number >>>>> > > of ZFS operations to be completed as a single atomic transaction. >>>>> > > >>>>> > > I would hope we could structure this in such a way as to not end >>>>> > > up with two copies of Lua in the kernel. >>>>> > There's also a 3/4 finished lua in the boot loader that you might >>>>> > be >>>>> > able to leverage as well.... >>>>> I'd like to see that finished. While Devin has done Heroic work with >>>>> the forth in the loader, I think it's time has come. >>>>> It' be nice to have something a little less '60s. >>>>> >>>>> > >>>>> > >>>>> > Warner >>>> >>>> I was under the impression that the "lua in bootloader" work was >>>> basically done and just needed testing, which nobody has done. I think >>>> it's all sitting in the projects/lua-bootloader branch in svn. >>> >>> The branch compiles. Testing has been done, but there's some missing >>> bits. It basically kinda works for the average case, but more advanced >>> uses of the bootloader still have sharp pointy edges on them, the >>> extent of the pointy edges is unknown. At this point the rebasing of >>> the branch is non-trivial due to the merge conflicts that have crept >>> in. They don't look awful, but when I tried to use git to rebase to a >>> more modern FreeBSD, there were lots of stupid things. Maybe I'll try >>> again... >>> >>> Warner >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://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 Mar 1 17:49:20 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9291CF2F23 for ; Wed, 1 Mar 2017 17:49:20 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40DE3E1F for ; Wed, 1 Mar 2017 17:49:20 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 66536b32-fea7-11e6-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 66536b32-fea7-11e6-95b5-6dfd7dbb0ee5; Wed, 01 Mar 2017 17:49:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v21HnCjI007063; Wed, 1 Mar 2017 10:49:12 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488390552.60166.23.camel@freebsd.org> Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD From: Ian Lepore To: Saurav Sachidanand , Alan Somers Cc: "freebsd-hackers@freebsd.org" , Allan Jude Date: Wed, 01 Mar 2017 10:49:12 -0700 In-Reply-To: References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> <1488383213.60166.10.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:49:20 -0000 The thought of python being any part of the base system is nothing less than horrifying.  Didn't we learn our lesson with perl all those years ago? -- Ian On Wed, 2017-03-01 at 23:18 +0530, Saurav Sachidanand wrote: > Since the language(s) to be included are chosen at compile time > it wouldn't be forcing anyone to use a bloated bootloader. > Wouldn't Python's richer standard library (eg: re) be useful in > certain situations? > > On Wed, Mar 1, 2017 at 9:42 PM, Alan Somers > wrote: > > > > Python is huge, and we already have people complaining that the > > bootloader doesn't fit in their boot partitions ever since it > > gained > > GELI support.  The advantage of Lua is that the embedded > > interpreter > > is very small.  I'd rather not bloat the bootloader too much. > > > > -Alan > > > > On Wed, Mar 1, 2017 at 9:08 AM, Saurav Sachidanand > > wrote: > > > > > > Is it related to this project > > > https://wiki.freebsd.org/SummerOfCode2014/LuaLoader ? > > > Apparently, that project created a generic interface in the > > > bootloader > > > to plug in any > > > interpreter, and then added Lua. > > > > > > How about adding Python as well, as a GSoC project? A team from > > > Intel managed to > > > get Python to run inside GRUB [1] [2]. I can use their work as a > > > reference for modifying > > > the Python interpreter. > > > > > > [1] - https://lwn.net/Articles/641244/ > > > [2] - https://github.com/biosbits/bits > > > > > > On Wed, Mar 1, 2017 at 3:51 PM, Warner Losh > > > wrote: > > > > > > > > On Wed, Mar 1, 2017 at 8:46 AM, Ian Lepore > > > > wrote: > > > > > > > > > > On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: > > > > > > > > > > > > On 28/2/17 2:01 am, Warner Losh wrote: > > > > > > > > > > > > > > > > > > > > > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude > > > > > > eebsd.org> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand > > > > > > > > > > > > > > > chidanand@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello FreeBSD community, > > > > > > > > > > > > > > > > > > I'm > > > > > > > > > Saurav Sachidanand, and I'm > > > > > > > > > a CS sophomore studying in India > > > > > > > > > . > > > > > > > > > I have an interest in operating systems development > > > > > > > > > and wish to > > > > > > > > > contribute > > > > > > > > > to the FreeBSD community. I'm proficient with C and > > > > > > > > > have some > > > > > > > > > experience in > > > > > > > > > kernel programming. Hence, I'd like to propose an > > > > > > > > > original > > > > > > > > > project for > > > > > > > > > GSoC > > > > > > > > > 2017 that I feel would benefit this community. > > > > > > > > > > > > > > > > > > In past years, the Lua interpreter was ported to run > > > > > > > > > inside the > > > > > > > > > Linux > > > > > > > > > and > > > > > > > > > NetBSD kernel [1]. Lua was chosen because it's > > > > > > > > > interpreter is > > > > > > > > > very > > > > > > > > > small (~240 > > > > > > > > > KB) compared to that of Python or Ruby, it's MIT > > > > > > > > > licensed, and > > > > > > > > > is > > > > > > > > > almost > > > > > > > > > freestanding. A working demonstration of it is a > > > > > > > > > packet > > > > > > > > > filtering > > > > > > > > > algorithm > > > > > > > > > written entirely in kernel Lua [2]. > > > > > > > > > > > > > > > > > > Specifically, my proposal would be to port the > > > > > > > > > following that > > > > > > > > > are > > > > > > > > > currently > > > > > > > > > written for NetBSD: > > > > > > > > > - the modified Lua VM source code with _KERNEL > > > > > > > > > preprocessor > > > > > > > > > directives > > > > > > > > > to > > > > > > > > > exclude user-space functionality like floating point, > > > > > > > > > the io > > > > > > > > > and os > > > > > > > > > module > > > > > > > > > in the standard library, etc. [3] > > > > > > > > > - the kernel module device driver for /dev/lua, to > > > > > > > > > which Lua > > > > > > > > > scripts > > > > > > > > > are > > > > > > > > > fed to be executed [4], [5] > > > > > > > > > - the luactl user-space program to control the Lua > > > > > > > > > device and a > > > > > > > > > couple > > > > > > > > > of > > > > > > > > > sysctl variables which serve similar purpose [6], [7] > > > > > > > > > > > > > > > > > > And then: > > > > > > > > > - run the Lua test suite targeting whatever we > > > > > > > > > support in the > > > > > > > > > kernel to > > > > > > > > > make sure it works [8] > > > > > > > > > - and write Lua bindings to the kernel interfaces > > > > > > > > > that would > > > > > > > > > interest > > > > > > > > > the > > > > > > > > > FreeBSD community > > > > > > > > > > > > > > > > > > Since NetBSD and FreeBSD have similar kernel > > > > > > > > > interfaces > > > > > > > > > (mutexes, > > > > > > > > > linked > > > > > > > > > lists, device switch interface), the porting > > > > > > > > > shouldn't involve > > > > > > > > > too much > > > > > > > > > code refactoring. Also, this would all be an > > > > > > > > > experiment in that > > > > > > > > > we > > > > > > > > > don't > > > > > > > > > fully know what the real world use cases might be, > > > > > > > > > but it would > > > > > > > > > attract > > > > > > > > > more people to writing kernel code who otherwise > > > > > > > > > wouldn't > > > > > > > > > because of > > > > > > > > > having > > > > > > > > > to do everything in C. And it would be interesting to > > > > > > > > > carry out > > > > > > > > > it out > > > > > > > > > in > > > > > > > > > FreeBSD as well since it has a larger community than > > > > > > > > > NetBSD. > > > > > > > > > > > > > > > > > > I humbly request anyone who is interested in this > > > > > > > > > project to be > > > > > > > > > my > > > > > > > > > potential mentor(s) for GSoC. > > > > > > > > > > > > > > > > > > More slides on kernel Lua in NetBSD - [9], [10]. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Saurav > > > > > > > > > > > > > > > > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf > > > > > > > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf > > > > > > > > > [3] - https://github.com/jsonn/src/tree/trunk/externa > > > > > > > > > l/mit/lua/ > > > > > > > > > dist/src > > > > > > > > > [4] - > > > > > > > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/ > > > > > > > > > sys/module > > > > > > > > > s/lua > > > > > > > > > [5] - > > > > > > > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/ > > > > > > > > > sys/module > > > > > > > > > s/luasystm > > > > > > > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/m > > > > > > > > > aster/sbin > > > > > > > > > /luactl > > > > > > > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetB > > > > > > > > > SD-current > > > > > > > > > [8] - http://www.lua.org/tests/ > > > > > > > > > [9] - > > > > > > > > > https://www.netbsd.org/gallery/presentations/mbalmer/ > > > > > > > > > fosdem2012 > > > > > > > > > /kernel_mode_lua.pdf > > > > > > > > > [10] - https://www.lua.org/wshop13/Cormack.pdf > > > > > > > > > _______________________________________________ > > > > > > > > > freebsd-hackers@freebsd.org mailing list > > > > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-ha > > > > > > > > > ckers > > > > > > > > > To unsubscribe, send any mail to > > > > > > > > > "freebsd-hackers-unsubscribe@freebsd.org" > > > > > > > > This may be quite a nice thing to have. Another > > > > > > > > upcoming use for > > > > > > > > LUA in the kernel is ZFS Channel Programs. These allow > > > > > > > > a number > > > > > > > > of ZFS operations to be completed as a single atomic > > > > > > > > transaction. > > > > > > > > > > > > > > > > I would hope we could structure this in such a way as > > > > > > > > to not end > > > > > > > > up with two copies of Lua in the kernel. > > > > > > > There's also a 3/4 finished lua in the boot loader that > > > > > > > you might > > > > > > > be > > > > > > > able to leverage as well.... > > > > > > I'd like to see that finished. While Devin has done Heroic > > > > > > work with > > > > > > the forth in the loader, I think it's time has come. > > > > > > It' be nice to have something a little less '60s. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Warner > > > > > I was under the impression that the "lua in bootloader" work > > > > > was > > > > > basically done and just needed testing, which nobody has > > > > > done.  I think > > > > > it's all sitting in the projects/lua-bootloader branch in > > > > > svn. > > > > The branch compiles. Testing has been done, but there's some > > > > missing > > > > bits. It basically kinda works for the average case, but more > > > > advanced > > > > uses of the bootloader still have sharp pointy edges on them, > > > > the > > > > extent of the pointy edges is unknown. At this point the > > > > rebasing of > > > > the branch is non-trivial due to the merge conflicts that have > > > > crept > > > > in. They don't look awful, but when I tried to use git to > > > > rebase to a > > > > more modern FreeBSD, there were lots of stupid things. Maybe > > > > I'll try > > > > again... > > > > > > > > Warner > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@fre > > > ebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://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 Mar 1 17:49:56 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51AA9CF3012 for ; Wed, 1 Mar 2017 17:49:56 +0000 (UTC) (envelope-from bygrandao@gmail.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14ECCF28; Wed, 1 Mar 2017 17:49:56 +0000 (UTC) (envelope-from bygrandao@gmail.com) Received: by mail-it0-x241.google.com with SMTP id w185so5756908ita.3; Wed, 01 Mar 2017 09:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dOjQ5aX3K5xKr+pOMtiGZROaQSRQxQdwYYS4bDTNfnU=; b=Wb8vxaP/9Ft/fJ1Ah78ose7jnkiTDSJYwEphNz9x+djMDjXDNAMwyfQ7Re9wV8lycp /Eqvd6WrUJbUIM5diFibhqfhtx51TvF+HZX5xaTWE4AqPUH2SYoqiq4WyDnFH9zSMWb9 IdSA4ZF6sex7JMQ1LGnRPIdmE0zxfL2YMvN/82YVxVTXRFaczFNFrpT1oduHMIzc5WfY fSBpW92n4ZdLFjp2Q9EaonlAzFRfvvkCpc7/YZUkZW43Ntsxwexjk5lxougeNH2VTmtr 03+FvCXPkGkY/4TDYGTIRaVFt1Vcxzu2vYGXGw8hugDqRKBj4EJyS+DRxYXeBNeaBZ5b F3nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dOjQ5aX3K5xKr+pOMtiGZROaQSRQxQdwYYS4bDTNfnU=; b=XXzAzH20w9tFqJbwoZAWwBgIXjK+S7QUOpXn9nQIWr5qiBvTnsiP6KZsZMakjF6CgQ Gnu7hZvp8CEUjRLaL4mXaUrwoiJckcgSAX7dhGDMWVvEmVwtfVByqMt9S5Lr6rwZutro tKGcR/8HkQZAcp7q2uB8nyvRH5pST2FrQYdNqa2TeIGXtJJ5iKFftLP2xmkAaxXliAu8 31LckO1vQ9MBVAbBTBwv1EEjt9wzVphDWDK8hcbUaJjH4I7lOW5ESWEuytCHt3mnr6K6 QPYo9xUFgPLA6zEuAdJ8JV2JwS6lffzOMwrcWRZ7yhxebHoxCvAFXicpvg0MqrOledr/ FwXw== X-Gm-Message-State: AMke39kI/M8OE84QWLdySytEkSpTdzM7NxCt5zbiq5RZqNlDOs6Sx4JOcvbueNhn2wYY1ZDqzex1qhKej+bLHQ== X-Received: by 10.36.146.134 with SMTP id l128mr5587161itd.19.1488390595380; Wed, 01 Mar 2017 09:49:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.121.165 with HTTP; Wed, 1 Mar 2017 09:49:54 -0800 (PST) In-Reply-To: References: <244231A2-EB18-4E58-A2B2-927F55D54950@FreeBSD.org> <1488383213.60166.10.camel@freebsd.org> From: Pedro Arthur Date: Wed, 1 Mar 2017 14:49:54 -0300 Message-ID: Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: Alan Somers Cc: Saurav Sachidanand , "freebsd-hackers@freebsd.org" , Ian Lepore , Allan Jude Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:49:56 -0000 Hi, I'm the author of the lua bootloader project, I think Rui Paulo did a few improvements located in [1]. I don't remember correctly but I guess there was a few issues with lua using floating point for numbers, but it can easily be changed to use integers. I think rebasing the branch would be painful, maybe we could cherry pick the changes to a fresh branch? If needed I may help getting the code up to date, also it would be helpful if the "sharp edges" were documented in the project wiki page [2] or a new one dedicated to the lua bootloader. [1] - https://svnweb.freebsd.org/base/projects/lua-bootloader/ [2] - https://wiki.freebsd.org/SummerOfCode2014/LuaLoader 2017-03-01 13:12 GMT-03:00 Alan Somers : > Python is huge, and we already have people complaining that the > bootloader doesn't fit in their boot partitions ever since it gained > GELI support. The advantage of Lua is that the embedded interpreter > is very small. I'd rather not bloat the bootloader too much. > > -Alan > > On Wed, Mar 1, 2017 at 9:08 AM, Saurav Sachidanand > wrote: > > Is it related to this project > > https://wiki.freebsd.org/SummerOfCode2014/LuaLoader ? > > Apparently, that project created a generic interface in the bootloader > > to plug in any > > interpreter, and then added Lua. > > > > How about adding Python as well, as a GSoC project? A team from Intel > managed to > > get Python to run inside GRUB [1] [2]. I can use their work as a > > reference for modifying > > the Python interpreter. > > > > [1] - https://lwn.net/Articles/641244/ > > [2] - https://github.com/biosbits/bits > > > > On Wed, Mar 1, 2017 at 3:51 PM, Warner Losh wrote: > >> On Wed, Mar 1, 2017 at 8:46 AM, Ian Lepore wrote: > >>> On Wed, 2017-03-01 at 16:14 +0800, Julian Elischer wrote: > >>>> On 28/2/17 2:01 am, Warner Losh wrote: > >>>> > > >>>> > On Mon, Feb 27, 2017 at 8:26 AM, Allan Jude > >>>> > wrote: > >>>> > > > >>>> > > On February 27, 2017 5:28:41 AM PST, Saurav Sachidanand >>>> > > chidanand@gmail.com> wrote: > >>>> > > > > >>>> > > > Hello FreeBSD community, > >>>> > > > > >>>> > > > I'm > >>>> > > > Saurav Sachidanand, and I'm > >>>> > > > a CS sophomore studying in India > >>>> > > > . > >>>> > > > I have an interest in operating systems development and wish to > >>>> > > > contribute > >>>> > > > to the FreeBSD community. I'm proficient with C and have some > >>>> > > > experience in > >>>> > > > kernel programming. Hence, I'd like to propose an original > >>>> > > > project for > >>>> > > > GSoC > >>>> > > > 2017 that I feel would benefit this community. > >>>> > > > > >>>> > > > In past years, the Lua interpreter was ported to run inside the > >>>> > > > Linux > >>>> > > > and > >>>> > > > NetBSD kernel [1]. Lua was chosen because it's interpreter is > >>>> > > > very > >>>> > > > small (~240 > >>>> > > > KB) compared to that of Python or Ruby, it's MIT licensed, and > >>>> > > > is > >>>> > > > almost > >>>> > > > freestanding. A working demonstration of it is a packet > >>>> > > > filtering > >>>> > > > algorithm > >>>> > > > written entirely in kernel Lua [2]. > >>>> > > > > >>>> > > > Specifically, my proposal would be to port the following that > >>>> > > > are > >>>> > > > currently > >>>> > > > written for NetBSD: > >>>> > > > - the modified Lua VM source code with _KERNEL preprocessor > >>>> > > > directives > >>>> > > > to > >>>> > > > exclude user-space functionality like floating point, the io > >>>> > > > and os > >>>> > > > module > >>>> > > > in the standard library, etc. [3] > >>>> > > > - the kernel module device driver for /dev/lua, to which Lua > >>>> > > > scripts > >>>> > > > are > >>>> > > > fed to be executed [4], [5] > >>>> > > > - the luactl user-space program to control the Lua device and a > >>>> > > > couple > >>>> > > > of > >>>> > > > sysctl variables which serve similar purpose [6], [7] > >>>> > > > > >>>> > > > And then: > >>>> > > > - run the Lua test suite targeting whatever we support in the > >>>> > > > kernel to > >>>> > > > make sure it works [8] > >>>> > > > - and write Lua bindings to the kernel interfaces that would > >>>> > > > interest > >>>> > > > the > >>>> > > > FreeBSD community > >>>> > > > > >>>> > > > Since NetBSD and FreeBSD have similar kernel interfaces > >>>> > > > (mutexes, > >>>> > > > linked > >>>> > > > lists, device switch interface), the porting shouldn't involve > >>>> > > > too much > >>>> > > > code refactoring. Also, this would all be an experiment in that > >>>> > > > we > >>>> > > > don't > >>>> > > > fully know what the real world use cases might be, but it would > >>>> > > > attract > >>>> > > > more people to writing kernel code who otherwise wouldn't > >>>> > > > because of > >>>> > > > having > >>>> > > > to do everything in C. And it would be interesting to carry out > >>>> > > > it out > >>>> > > > in > >>>> > > > FreeBSD as well since it has a larger community than NetBSD. > >>>> > > > > >>>> > > > I humbly request anyone who is interested in this project to be > >>>> > > > my > >>>> > > > potential mentor(s) for GSoC. > >>>> > > > > >>>> > > > More slides on kernel Lua in NetBSD - [9], [10]. > >>>> > > > > >>>> > > > Thanks, > >>>> > > > Saurav > >>>> > > > > >>>> > > > [1] - http://www.netbsd.org/~lneto/dls14.pdf > >>>> > > > [2] - https://www.netbsd.org/~lneto/eurobsdcon14.pdf > >>>> > > > [3] - https://github.com/jsonn/src/tree/trunk/external/mit/lua/ > >>>> > > > dist/src > >>>> > > > [4] - > >>>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module > >>>> > > > s/lua > >>>> > > > [5] - > >>>> > > > https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sys/module > >>>> > > > s/luasystm > >>>> > > > [6] - https://github.com/IIJ-NetBSD/netbsd-src/tree/master/sbin > >>>> > > > /luactl > >>>> > > > [7] - http://netbsd.gw.com/cgi-bin/man-cgi?lua+4+NetBSD-current > >>>> > > > [8] - http://www.lua.org/tests/ > >>>> > > > [9] - > >>>> > > > https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2012 > >>>> > > > /kernel_mode_lua.pdf > >>>> > > > [10] - https://www.lua.org/wshop13/Cormack.pdf > >>>> > > > _______________________________________________ > >>>> > > > freebsd-hackers@freebsd.org mailing list > >>>> > > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >>>> > > > To unsubscribe, send any mail to > >>>> > > > "freebsd-hackers-unsubscribe@freebsd.org" > >>>> > > This may be quite a nice thing to have. Another upcoming use for > >>>> > > LUA in the kernel is ZFS Channel Programs. These allow a number > >>>> > > of ZFS operations to be completed as a single atomic transaction. > >>>> > > > >>>> > > I would hope we could structure this in such a way as to not end > >>>> > > up with two copies of Lua in the kernel. > >>>> > There's also a 3/4 finished lua in the boot loader that you might > >>>> > be > >>>> > able to leverage as well.... > >>>> I'd like to see that finished. While Devin has done Heroic work with > >>>> the forth in the loader, I think it's time has come. > >>>> It' be nice to have something a little less '60s. > >>>> > >>>> > > >>>> > > >>>> > Warner > >>> > >>> I was under the impression that the "lua in bootloader" work was > >>> basically done and just needed testing, which nobody has done. I think > >>> it's all sitting in the projects/lua-bootloader branch in svn. > >> > >> The branch compiles. Testing has been done, but there's some missing > >> bits. It basically kinda works for the average case, but more advanced > >> uses of the bootloader still have sharp pointy edges on them, the > >> extent of the pointy edges is unknown. At this point the rebasing of > >> the branch is non-trivial due to the merge conflicts that have crept > >> in. They don't look awful, but when I tried to use git to rebase to a > >> more modern FreeBSD, there were lots of stupid things. Maybe I'll try > >> again... > >> > >> Warner > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ > freebsd.org" > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://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 Mar 1 15:15:26 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8806CF1000 for ; Wed, 1 Mar 2017 15:15:26 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74733D91; Wed, 1 Mar 2017 15:15:26 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id v21FFJVL047899; Wed, 1 Mar 2017 16:15:19 +0100 (CET) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id BDDFF53E; Wed, 1 Mar 2017 16:15:18 +0100 (CET) Message-ID: <58B6E586.4070507@omnilan.de> Date: Wed, 01 Mar 2017 16:15:18 +0100 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Doug Ambrisko CC: ambrisko@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs References: <20140415233133.GA14686@ambrisko.com> <5452600C.5030003@omnilan.de> <20141101154004.GA40398@ambrisko.com> <559FD426.3000108@omnilan.de> <20150710154654.GA71708@ambrisko.com> <58B5D571.2010103@omnilan.de> <20170228201753.GA99322@ambrisko.com> In-Reply-To: <20170228201753.GA99322@ambrisko.com> Content-Type: multipart/mixed; boundary="------------090904000408010604050402" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Wed, 01 Mar 2017 16:15:19 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-Mailman-Approved-At: Wed, 01 Mar 2017 17:51:05 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:15:26 -0000 This is a multi-part message in MIME format. --------------090904000408010604050402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bezüglich Doug Ambrisko's Nachricht vom 28.02.2017 21:17 (localtime): > On Tue, Feb 28, 2017 at 08:54:25PM +0100, Harry Schmalzbauer wrote: > | Bezüglich Doug Ambrisko's Nachricht vom 10.07.2015 17:46 (localtime): > | > On Fri, Jul 10, 2015 at 04:18:14PM +0200, Harald Schmalzbauer wrote: > | > | > | > | > | Hello, > | > | > | > | > | > | first sorry for the missing thread references in the header, I'm not > | > | > | subscribed to hackers@. > | > | > | > | > | > | bdrewery@ pointed me to this discussion in response to my question to > | > | > | stable@ > | > | > | (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) > | > | > | > | > | > | Last promising post I found: > | > | > | > | > | > | > |/ > I have a new patch at: > | > | > | > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch > | > | > | > /|/ > that I tested against head. This should be pretty close to commiting > | > | > | > /|/ > unless people find some issues with it. > | > | > | > /|/ > | > | > | > /|/ In sys/kern/vfs_mount.c: > | > | > | > /|/ + mp->mnt_path = malloc(strlen(fspath), M_MOUNT, M_WAITOK); > | > | > | > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); > | > | > | > /|/ … > | > | I'm currently planning to upgrade some machines from 10 to 11-stable, > | where I've been happyly running your patch. > | Any updates on the MNAMELEN front? I nearby read about plans to extend > | it to ?1000:1088?. > | > | But just for now I'd highly appreciate if you could tell me if you are > | ware of any objections applying your > | mount_bigger_2.patch on 11-stable. > | > | Hope you don't mind if I quote a question from about a year ago: > | > | Bezüglich Harry Schmalzbauer's Nachricht vom 19.11.2015 11:38 (localtime): > | … > | >> | I've been using your mount_bigger_2.path for some months without > | >> | problems, but haven't done any kind of stress test. > | >> | It just saves my soul in case I have to recover files from > | >> | (zfs-)snapshots from time to time :-) > | > > | > Hello Doug, > | > > | > unfortunately, mount_bigger doesn't cover the length restriction for > | > make_dev_p(), which leads to inaccessable zvols > | > (g_dev_taste: make_dev_p() failed > | > (gp->name=zvol/babasP0.1xSATA7k2-0/liveBACKSTOR/zfsREPL/esm-vega/P1/iscsi.redtsdatahdd500@epochp2, > | > error=63)) > | > | Do you have anything handy which solves the make_dev_p() limitation? > > This got lost in my emails. I need to clean out my home emails. Too many > things get lost on I need to go back and look at it but then forget what. > I was going to look at the this issue when I got a free moment but then > couldn't find it. > > Do you have a simple repro. to show this. It would be great if the > repo. was based on md disk that was ZFS created, mounted and this done > to. Then I can repro. it locally and look at it. I have bhyve setup > to UEFI PXE boot on my laptop to test things out. Hi, thanks for your attention! Due to time constraints I'll need some weeks coming up with that. But I'm confident I'll find some time to do that and I'll get back to you, probably in April. > I'm still waiting for 64 bit inodes to come in which is supposed to help > with this and make it not needed. I'm still running this code and need > to put it on my laptop since I've run into this issue there now. > > It's been nice that people haven't been changing things so the patch still > applies. Although it touches a bunch of files it doesn't touch much. I Actually it doesn't apply o.o.t.b., but at first it seemed to be rather easy to me so I started altering, which quickly shows my horrible C deficiencies. Unfortunately I don't know anybody who could help me filling such a simple knowledge gap. So I ended up with a pratially patch(-patch), which needs some cast cleanups. So far I could solve the following problems: Besides some minor patch-context related changes, there's r275856, changing fs/ext2fs/ext2_lookup.c. (u_long)ip got (uintmax)ip, which – monkey see monkey do – I simply adopted to your patch. Analogous for (uintmax)va.va_fileid" in sys/security/mac_lomac/mac_lomac.c. In sys/ufs/ufs/ufs_quota.c, r306553 changed ITOV(ip)->v_mount->mnt_stat.f_mntonname,quotatypes[i]); into ITOVFS(ip)->mnt_stat.f_mntonname,quotatypes[i]); Again, monkey see monkey do, - ITOVFS(ip)->mnt_stat.f_mntonname, + ITOVFS(ip)->mnt_path, is what I modified. I attached a maximal reduced patch-patch which makes your mount_bigger_2.patch (as linked at the beginning) RELENG11 applicable. This leads to the following clang error (Werror) error: cast from 'const char *' to 'char *' drops const qualifie r [-Werror,-Wcast-qual] So one needs to change the following casts: In sys/fs/cd9660/cd9660_rrip.c: (char *)ana In sys/fs/fuse/fuse_vnops.c: (char *)vnode_mount(vp) In sys/geom/journal/g_journal.c: (char *)mp The last one also needs to be fixed in sys/kern/vfs_mount.c where strlcpy() and free() are added by the patch. Since I even wasn't able to find the struct definitions of these I must give up here, unfortunately I don't have the time to iron out my long overdue C deficiencies (along with the lack of knowledge how to read code split over several files). Hopefully someone can easily solve these cast issues. -harry --------------090904000408010604050402 Content-Type: text/x-patch; name="mount_bigger_2.patch-RELENG11dif-minimal.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mount_bigger_2.patch-RELENG11dif-minimal.patch" --- mount_bigger_2.patch.orig 2017-03-01 14:03:21.937517000 +0100 +++ mount_bigger_2.patch 2017-03-01 14:40:10.943851000 +0100 @@ -8,9 +8,9 @@ */ - if (strlen(fstype) >= MFSNAMELEN || strlen(fspath) >= MNAMELEN) + if (strlen(fstype) >= MFSNAMELEN || strlen(fspath) >= MAXPATHLEN) - return (ENAMETOOLONG); - - vfsp = vfs_byname_kld(fstype, td, &error); + error = ENAMETOOLONG; + if (error == 0 && (vfsp = vfs_byname_kld(fstype, td, &error)) == NULL) + error = ENODEV; Index: sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c =================================================================== --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ctldir.c (revision 264468) @@ -27,9 +27,9 @@ "%s/" ZFS_CTLDIR_NAME "/snapshot/%s", - dvp->v_vfsp->mnt_stat.f_mntonname, nm); + dvp->v_vfsp->mnt_path, nm); - err = mount_snapshot(curthread, vpp, "zfs", mountpoint, snapname, 0); - kmem_free(mountpoint, mountpoint_len); - if (err == 0) { + mutex_exit(&sdp->sd_lock); + + /* Index: sys/fs/cd9660/cd9660_rrip.c =================================================================== --- sys/fs/cd9660/cd9660_rrip.c (revision 264468) @@ -47,16 +47,18 @@ =================================================================== --- sys/fs/ext2fs/ext2_lookup.c (revision 264468) +++ sys/fs/ext2fs/ext2_lookup.c (working copy) -@@ -802,10 +802,10 @@ +@@ -802,12 +802,10 @@ mp = ITOV(ip)->v_mount; if ((mp->mnt_flag & MNT_RDONLY) == 0) - panic("ext2_dirbad: %s: bad dir ino %lu at offset %ld: %s\n", -- mp->mnt_stat.f_mntonname, (u_long)ip->i_number,(long)offset, how); -+ mp->mnt_path, (u_long)ip->i_number,(long)offset, how); + panic("ext2_dirbad: %s: bad dir ino %ju at offset %ld: %s\n", +- mp->mnt_stat.f_mntonname, (uintmax_t)ip->i_number, +- (long)offset, how); ++ mp->mnt_path, (uintmax_t)ip->i_number, (long)offset, how); else - (void)printf("%s: bad dir ino %lu at offset %ld: %s\n", -- mp->mnt_stat.f_mntonname, (u_long)ip->i_number, (long)offset, how); -+ mp->mnt_path, (u_long)ip->i_number, (long)offset, how); + (void)printf("%s: bad dir ino %ju at offset %ld: %s\n", +- mp->mnt_stat.f_mntonname, (uintmax_t)ip->i_number, +- (long)offset, how); ++ mp->mnt_path, (uintmax_t)ip->i_number, (long)offset, how); } @@ -125,28 +127,6 @@ error = vn_start_write(NULL, &mp, V_WAIT); if (error != 0) { -Index: sys/gnu/fs/reiserfs/reiserfs_vfsops.c -=================================================================== ---- sys/gnu/fs/reiserfs/reiserfs_vfsops.c (revision 264468) -+++ sys/gnu/fs/reiserfs/reiserfs_vfsops.c (working copy) -@@ -309,7 +309,7 @@ - reiserfs_log(LOG_DEBUG, "...done\n"); - - if (sbp != &mp->mnt_stat) { -- reiserfs_log(LOG_DEBUG, "copying monut point info\n"); -+ reiserfs_log(LOG_DEBUG, "copying mount point info\n"); - sbp->f_type = mp->mnt_vfc->vfc_typenum; - bcopy((caddr_t)mp->mnt_stat.f_mntonname, - (caddr_t)&sbp->f_mntonname[0], MNAMELEN); -@@ -318,7 +318,7 @@ - reiserfs_log(LOG_DEBUG, " mount from: %s\n", - sbp->f_mntfromname); - reiserfs_log(LOG_DEBUG, " mount on: %s\n", -- sbp->f_mntonname); -+ mp->mnt_path); - reiserfs_log(LOG_DEBUG, "...done\n"); - } - Index: sys/kern/kern_jail.c =================================================================== --- sys/kern/kern_jail.c (revision 264468) @@ -263,11 +243,11 @@ } mtx_lock(&mountlist_mtx); TAILQ_FOREACH_REVERSE(mp, &mountlist, mntlist, mnt_list) { -- if (strcmp(mp->mnt_stat.f_mntonname, pathbuf) == 0) -+ if (strcmp(mp->mnt_path, pathbuf) == 0) +- if (strcmp(mp->mnt_stat.f_mntonname, pathbuf) == 0) { ++ if (strcmp(mp->mnt_path, pathbuf) == 0) { + vfs_ref(mp); break; - } - mtx_unlock(&mountlist_mtx); + } Index: sys/kern/vfs_mountroot.c =================================================================== --- sys/kern/vfs_mountroot.c (revision 264468) @@ -303,15 +283,6 @@ buf[0] = '\0'; mflags = mp->mnt_flag; -@@ -3406,7 +3406,7 @@ - */ - if (strcmp(mp->mnt_vfc->vfc_name, "devfs") != 0) { - printf("unmount of %s failed (", -- mp->mnt_stat.f_mntonname); -+ mp->mnt_path); - if (error == EBUSY) - printf("BUSY)\n"); - else Index: sys/security/mac_lomac/mac_lomac.c =================================================================== --- sys/security/mac_lomac/mac_lomac.c (revision 264468) @@ -320,8 +291,8 @@ "mountpount=%s)\n", subjlabeltext, p->p_pid, pgid, curthread->td_ucred->cr_uid, p->p_comm, subjtext, actionname, objlabeltext, objname, -- va.va_fileid, vp->v_mount->mnt_stat.f_mntonname); -+ va.va_fileid, vp->v_mount->mnt_path); +- (uintmax_t)va.va_fileid, vp->v_mount->mnt_stat.f_mntonname); ++ (uintmax_t)va.va_fileid, vp->v_mount->mnt_path); } else { log(LOG_INFO, "LOMAC: level-%s subject p%dg%du%d:%s demoted to" " level %s after %s a level-%s %s\n", @@ -548,8 +519,8 @@ * We need the name for the mount point (also used for * "last mounted on") copied in. If an error occurs, * the mount point is discarded by the upper level code. -- * Note that vfs_mount() populates f_mntonname for us. -+ * Note that vfs_mount() populates mnt_path for us. +- * Note that vfs_mount_alloc() populates f_mntonname for us. ++ * Note that vfs_mount_alloc() populates mnt_path for us. */ if ((error = ffs_mountfs(devvp, mp, td)) != 0) { vrele(devvp); @@ -694,8 +665,8 @@ DQI_UNLOCK(dq); if (warn) uprintf("\n%s: warning, %s disk quota exceeded\n", -- ITOV(ip)->v_mount->mnt_stat.f_mntonname, -+ ITOV(ip)->v_mount->mnt_path, +- ITOVFS(ip)->mnt_stat.f_mntonname, ++ ITOVFS(ip)->mnt_path, quotatypes[i]); } return (0); @@ -703,8 +674,8 @@ dq->dq_flags |= DQ_BLKS; DQI_UNLOCK(dq); uprintf("\n%s: write failed, %s disk limit reached\n", -- ITOV(ip)->v_mount->mnt_stat.f_mntonname, -+ ITOV(ip)->v_mount->mnt_path, +- ITOVFS(ip)->mnt_stat.f_mntonname, ++ ITOVFS(ip)->mnt_path, quotatypes[type]); return (EDQUOT); } @@ -712,8 +683,8 @@ DQI_UNLOCK(dq); uprintf("\n%s: write failed, %s " "disk quota exceeded for too long\n", -- ITOV(ip)->v_mount->mnt_stat.f_mntonname, -+ ITOV(ip)->v_mount->mnt_path, +- ITOVFS(ip)->mnt_stat.f_mntonname, ++ ITOVFS(ip)->mnt_path, quotatypes[type]); return (EDQUOT); } @@ -721,8 +692,8 @@ DQI_UNLOCK(dq); if (warn) uprintf("\n%s: warning, %s inode quota exceeded\n", -- ITOV(ip)->v_mount->mnt_stat.f_mntonname, -+ ITOV(ip)->v_mount->mnt_path, +- ITOVFS(ip)->mnt_stat.f_mntonname, ++ ITOVFS(ip)->mnt_path, quotatypes[i]); } return (0); @@ -730,8 +701,8 @@ dq->dq_flags |= DQ_INODS; DQI_UNLOCK(dq); uprintf("\n%s: write failed, %s inode limit reached\n", -- ITOV(ip)->v_mount->mnt_stat.f_mntonname, -+ ITOV(ip)->v_mount->mnt_path, +- ITOVFS(ip)->mnt_stat.f_mntonname, ++ ITOVFS(ip)->mnt_path, quotatypes[type]); return (EDQUOT); } @@ -739,8 +710,8 @@ DQI_UNLOCK(dq); uprintf("\n%s: write failed, %s " "inode quota exceeded for too long\n", -- ITOV(ip)->v_mount->mnt_stat.f_mntonname, -+ ITOV(ip)->v_mount->mnt_path, +- ITOVFS(ip)->mnt_stat.f_mntonname, ++ ITOVFS(ip)->mnt_path, quotatypes[type]); return (EDQUOT); } --------------090904000408010604050402-- From owner-freebsd-hackers@freebsd.org Thu Mar 2 05:17:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 201A7CF4454 for ; Thu, 2 Mar 2017 05:17:02 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2B0E99E for ; Thu, 2 Mar 2017 05:17:01 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id n11so15089889wma.1 for ; Wed, 01 Mar 2017 21:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=l9o0TLWsLkiOszZcYl8zezc3/QhjD6lob0LRyuaYc3E=; b=nbdMT/jiDlJdNgqd3XXvAq59f1xi5e9qofgP1eX4Cb8UmDKIJI1oMfscVfCBWoy2Hx bjMN1f2QgyaxzZMkTZ+6vgoweH5dGKWIMU75Vme1yGmi7yJVn7LhB1dbmdFRHYqzGSUr /LCGVD3b1TVoQ8qcgzhkCSdw6c1vTEC5MiMQhGwZTGDUjmLiv3FzIb4hOlXXms9s3Erm gdMiOUVNYhcOTEcsIlLvOuxBcW91t5qbifHhS+xtB2ALepF4tU3s+JGA7mM4pfv2vUcy NrSrzGyWAOQLEJvOwFEZUC4tjz/l7HWyeJIcd9jD9WO52sEk0iL0X6KtvEE2huw2Ol9E BMYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=l9o0TLWsLkiOszZcYl8zezc3/QhjD6lob0LRyuaYc3E=; b=sVbFfezLyhEOWKtn0OBF2XKr+My1fEOMfLv99t1CfkHCu3ARbJp5auJIC9vz6TeSOq /KlG1fC5kFpGCVbrQvn2Rg9HPAHh0TgJ/IfMZDGIAXjEkULs0oobGul4g5KLl4FGmnzd H4F8kTQxYzoAJ6B25QfnlBEbp/F9BxBJsWJOeQT/Dn/AXuQ/F9bZRpYvo4aM2z3K7ZmF Rqp9CLa8cvbo5P+wD5VgQ4Q+ucavpdb6Txt5YVYaXtBG3GLuLe6XD/rP3gfgnIiA7Sl9 YDT173jKLaDpsw2IeWfhEykTO/czSKJgvFiiQDIG88mtjus+aUuMrcnoakvU4mT0YGPy rV8w== X-Gm-Message-State: AMke39m7P/RNipC+OOPA/MJW5HgSABDwNn7pJEy8X1Y0GTdFCUXkqt+EHkJUsXMbDHOGOqK3dPCdFoagkvDzRg== X-Received: by 10.28.10.70 with SMTP id 67mr6539338wmk.76.1488431819008; Wed, 01 Mar 2017 21:16:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.138.143 with HTTP; Wed, 1 Mar 2017 21:16:58 -0800 (PST) From: Zaphod Beeblebrox Date: Thu, 2 Mar 2017 00:16:58 -0500 Message-ID: Subject: Disk controller heizenbug. To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 05:17:02 -0000 I have a disk controller. I works in a modern AMD motherboard at home (9590 processor), but when connected to a sunfire 4140 (opteron 2345 based machine vintage 2008-ish) the disks spontaneously detach by just doing a "zfs import" The board has it's own mounting for the flash disks (two of them) and probes as: ahci0: port 0x8c00-0x8c07,0x8880-0x8883,0x8800-0x8807,0x8480-0x8483,0x8400-0x841f mem 0xdfbff800-0xdfbfffff irq 16 at device 0.0 numa-domain 0 on pci3 The disks show up as: ada0 at ahcich0 bus 0 scbus6 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number S248NXAH112465B ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors) ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> Under heavy bonnie++, they work in the AMD 9590 system. On the opteron machine, the following occurs: ahcich1: Timeout on slot 11 port 0 ahcich1: is ffffffff cs ffffffff ss ffffffff rs 00000800 tfd ffffffff serr ffffffff cmd ffffffff (ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 00 00 00 (ada1:ahcich1:0:0:0): CAM status: Command timeout (ada1:ahcich1:0:0:0): Retrying command ahcich1: stopping AHCI engine failed ahcich0: ada1 at ahcich1 bus 0 scbus7 target 0 lun 0 Timeout on slot 31 port 0 ada1: ahcich0: is ffffffff cs ffffffff ss ffffffff rs 80000000 tfd ffffffff serr ffffffff cmd ffffffff s/n S248NXAH112471L detached (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command ahcich0: stopping AHCI engine failed ada0 at ahcich0 bus 0 scbus6 target 0 lun 0 ada0: s/n S248NXAH112465B detached [2:43:343]root@yak:/usr/ports/net-mgmt/net-snmp> less /var/run/dmesg.boot [2:44:344]root@yak:/usr/ports/net-mgmt/net-snmp> dmesg pid 78200 (httpd), uid 80: exited on signal 11 ahcich1: Timeout on slot 11 port 0 ahcich1: is ffffffff cs ffffffff ss ffffffff rs 00000800 tfd ffffffff serr ffffffff cmd ffffffff (ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 00 00 00 (ada1:ahcich1:0:0:0): CAM status: Command timeout (ada1:ahcich1:0:0:0): Retrying command ahcich1: stopping AHCI engine failed ahcich0: ada1 at ahcich1 bus 0 scbus7 target 0 lun 0 Timeout on slot 31 port 0 ada1: ahcich0: is ffffffff cs ffffffff ss ffffffff rs 80000000 tfd ffffffff serr ffffffff cmd ffffffff s/n S248NXAH112471L detached (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 00 00 00 (ada0:ahcich0:0:0:0): CAM status: Command timeout (ada0:ahcich0:0:0:0): Retrying command ahcich0: stopping AHCI engine failed ada0 at ahcich0 bus 0 scbus6 target 0 lun 0 ada0: s/n S248NXAH112465B detached I'm posting here to hackers because this seems to violate layers --- on the AMD machine ... it runs fine... even under load. The SATA bus is local to the card (and so travels with it to the server), yet the error looks like a SATA BUS or drive error. What gives? From owner-freebsd-hackers@freebsd.org Thu Mar 2 06:06:16 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CDBD1CF5B67 for ; Thu, 2 Mar 2017 06:06:16 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B92679D7 for ; Thu, 2 Mar 2017 06:06:16 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id v2267erh009639 for ; Wed, 1 Mar 2017 22:07:46 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: In-Reply-To: References: From: "Chris H" Subject: Re: Disk controller heizenbug. Date: Wed, 01 Mar 2017 22:07:46 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 06:06:16 -0000 On Thu, 2 Mar 2017 00:16:58 -0500 Zaphod Beeblebrox wrote > I have a disk controller. I works in a modern AMD motherboard at home > (9590 processor), Nice thing about these processors, is the ability to cook your meals on them, too. :-) > but when connected to a sunfire 4140 (opteron 2345 based > machine vintage 2008-ish) the disks spontaneously detach by just doing a > "zfs import" > > The board has it's own mounting for the flash disks (two of them) and > probes as: > > ahci0: port > 0x8c00-0x8c07,0x8880-0x8883,0x8800-0x8807,0x8480-0x8483,0x8400-0x841f mem > 0xdfbff800-0xdfbfffff irq 16 at device 0.0 numa-domain 0 on pci3 > > The disks show up as: > > ada0 at ahcich0 bus 0 scbus6 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number S248NXAH112465B > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) > ada0: Command Queueing enabled > ada0: 238475MB (488397168 512 byte sectors) > ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> > > Under heavy bonnie++, they work in the AMD 9590 system. On the opteron > machine, the following occurs: > > ahcich1: Timeout on slot 11 port 0 > ahcich1: is ffffffff cs ffffffff ss ffffffff rs 00000800 tfd ffffffff serr > ffffffff cmd ffffffff > (ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 > 00 00 00 > (ada1:ahcich1:0:0:0): CAM status: Command timeout > (ada1:ahcich1:0:0:0): Retrying command > ahcich1: stopping AHCI engine failed > ahcich0: ada1 at ahcich1 bus 0 scbus7 target 0 lun 0 > Timeout on slot 31 port 0 > ada1: ahcich0: is ffffffff cs > ffffffff ss ffffffff rs 80000000 tfd ffffffff serr ffffffff cmd ffffffff > s/n S248NXAH112471L detached > (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 > 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Command timeout > (ada0:ahcich0:0:0:0): Retrying command > ahcich0: stopping AHCI engine failed > ada0 at ahcich0 bus 0 scbus6 target 0 lun 0 > ada0: s/n S248NXAH112465B > detached > [2:43:343]root@yak:/usr/ports/net-mgmt/net-snmp> less /var/run/dmesg.boot > [2:44:344]root@yak:/usr/ports/net-mgmt/net-snmp> dmesg > pid 78200 (httpd), uid 80: exited on signal 11 > ahcich1: Timeout on slot 11 port 0 > ahcich1: is ffffffff cs ffffffff ss ffffffff rs 00000800 tfd ffffffff serr > ffffffff cmd ffffffff > (ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 > 00 00 00 > (ada1:ahcich1:0:0:0): CAM status: Command timeout > (ada1:ahcich1:0:0:0): Retrying command > ahcich1: stopping AHCI engine failed > ahcich0: ada1 at ahcich1 bus 0 scbus7 target 0 lun 0 > Timeout on slot 31 port 0 > ada1: ahcich0: is ffffffff cs > ffffffff ss ffffffff rs 80000000 tfd ffffffff serr ffffffff cmd ffffffff > s/n S248NXAH112471L detached > (ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 90 e0 20 a0 40 17 00 00 > 00 00 00 > (ada0:ahcich0:0:0:0): CAM status: Command timeout > (ada0:ahcich0:0:0:0): Retrying command > ahcich0: stopping AHCI engine failed > ada0 at ahcich0 bus 0 scbus6 target 0 lun 0 > ada0: s/n S248NXAH112465B > detached > > I'm posting here to hackers because this seems to violate layers --- on the > AMD machine ... it runs fine... even under load. The SATA bus is local to > the card (and so travels with it to the server), yet the error looks like a > SATA BUS or drive error. > > What gives? I may be misunderstanding your question. But this smells like a BUS timing issue. eg; maybe your sunfire isn't quite synced -- BIOS settings for bus, ram && cpu? I have the same issue on one of my boards. In my case, I OC'd the CPU ~500Mhz over spec. Just thought I'd mention it. --Chris > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Mar 2 19:29:47 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F111CF6EB0; Thu, 2 Mar 2017 19:29:47 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C5206B9; Thu, 2 Mar 2017 19:29:47 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-qk0-x241.google.com with SMTP id n127so21603565qkf.2; Thu, 02 Mar 2017 11:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/kTCpRDCRzXFw03gpduEMR7SymZLLB/5IaZ8YA7oYTw=; b=CMD4YWo+Z+3T5/oZxbaMkXICXrHesstkiETQfcOIz87CU31q7RKtzDX7D6FsF4353N s0EQX6MpUX96xclWcxNMMfZVBEvLmO2JTlbBercZ5hgu7oz/suskYZHuBkonfp0VLxkY WpLTcuRobHeZCbg4+hjrnxZJ9bly6fi+cBzZm5xVsRrwxbQHdfzo3Y3JHwtPNyftBC/s tla/Vogsm0wwguX6BGnQWGrjx0GqCx+SSAQdwdZt8OfysSV4Vaev8zSmSaYDYKjJMKf4 x+FYOe4peeD8u8Z/DgdnIQdIo9MtCTEx9ksOhhEGdodu6qPyrLgDkiX2+iMPsZzG3n3N o9lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/kTCpRDCRzXFw03gpduEMR7SymZLLB/5IaZ8YA7oYTw=; b=dxgtsbEItspPwIf5obgWB32xqIert4+l6JW5h6CdbcUdqbRcohk7QjB5gwSvLAe49S yhB+9xnfqvjl32gVpNdqQ9PCo1sH4/bjIiTorZ92pWEHko7tmf01cTgC2MStAttPmgSk ScZ6bRJwCST15edUerLKLpMkkulSVTSRUp0XcpT7lv6ETigr8k1ya9i5sijYnKtBz5TS TPVxnvJOWMy/6gEo3ufchJXh22PyjVzijvx+vJCh/k60n/DPprJA4ywmSTnLaA05MBZm LDWVRNxBieEMXuOGgi5hNlvztPRGY185OM2vbzp53rUfIA6oLb5WxY8i7oJxKz5vigI8 ra9g== X-Gm-Message-State: AMke39mkQbZDD8IXIPnYGOxCsA2dI9dJ4Wq1HIOfSGntFax/92wXykUnE+p+MnAO7TkPh+NwTKlmTYWHkTXORw== X-Received: by 10.55.212.206 with SMTP id s75mr18199752qks.71.1488482986309; Thu, 02 Mar 2017 11:29:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.134.70 with HTTP; Thu, 2 Mar 2017 11:29:46 -0800 (PST) From: Subbsd Date: Thu, 2 Mar 2017 22:29:46 +0300 Message-ID: Subject: effect of strip(1) on du(1) To: freebsd-current Current , freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 19:29:47 -0000 Hi, Not sure for FreeBSD < 12, but i found interesting behavior strip effect(1) on du(1) command: -- % strip /bin/pax && sleep 4 && du -sh /bin/pax 65K /bin/pax % strip /bin/pax && sleep 3 && du -sh /bin/pax 65K /bin/pax % strip /bin/pax && sleep 2 && du -sh /bin/pax 512B /bin/pax % strip /bin/pax && sleep 3 && du -sh /bin/pax 65K /bin/pax -- During some interval after strip call, du will show 512B for any file. If execute du(1) after strip(1) without delay, this behavior is reproduced 100%: % strip /bin/sh && du /bin/sh 1 /bin/sh What such behavior is connected with? From owner-freebsd-hackers@freebsd.org Thu Mar 2 23:11:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5126CF5276; Thu, 2 Mar 2017 23:11:42 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 352501F29; Thu, 2 Mar 2017 23:11:41 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v22N4MJF058013 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Mar 2017 10:04:28 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id v22N4HIf091899 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Mar 2017 10:04:17 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v22N4Gif091898; Fri, 3 Mar 2017 10:04:16 +1100 (AEDT) (envelope-from peter) Date: Fri, 3 Mar 2017 10:04:16 +1100 From: Peter Jeremy To: Subbsd Cc: freebsd-current Current , freebsd-hackers Subject: Re: effect of strip(1) on du(1) Message-ID: <20170302230416.GK4503@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 23:11:42 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Mar-02 22:29:46 +0300, Subbsd wrote: >During some interval after strip call, du will show 512B for any file. >If execute du(1) after strip(1) without delay, this behavior is reproduced= 100%: What filesystem are you using? strip(1) rewrites the target file and du(1) reports the number of blocks reported by stat(2). It seems that you are hitting a situation where the file metadata isn't immediately updated. --=20 Peter Jeremy --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYuKTwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0no0P/Rng2LxAzKXCIVHEGvtNGKS8 ZGxy2B+2iEnFI1e3RmDOWqeu5Uvl8QriTELRgPF086bofpqwzZoyBLYIRhVkgu5u XRewSKeKHdav2I9uMITrG7vcmJKrA+QDVu9kY5qJJJSDtvC0MHZoPG+RIhrxj5bZ Um59eAqGrY8lLp7o30xWZEkmM9FtAZM81Oe/LESoxwyYYbj2yjJLGtCT3RtDBcj0 ScwcKN1e2quGFvBlCh+lnS66XCx33deZ2p9ReD/NQdKzQqVj43QLvOQ+7p/mdGag wJnrsHyUnxStAbgRRIbjfTglT8VuMq+gZCsYFE+Au7XnVxUIOHa0GjVDnMnh+++m wTkExDuInNPgehD24QDrfFVqE3CD/fQnX1yqb1nY7oxSomgzT9mNOH9yyXGU4b+A EaNp39FXocpjdFtHvevyBDGMtZPG2PkqbJJX/Eg9zy625nXJCMKPp5uTxmvu9F+x /8L2n1g6nGlh1tvDH6BKRKhvNvu5wieWPvInNRwnGXYrX3WfCOgkAT/QBaZu4/Qr zB8QgG6HBmU6YYVOq3Hv0aukx8dcvxlwQs2V4+9Ztamh9SAbh7n8jhYqTPEE9ufg 5RWqjpYhd71KxDVfKnA11IifbW5NVDpxrxLtplPllSqnecwETzcnFXAWBEUsjpe8 OWhEVmOTpjZBWhW4hLQT =dGys -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-hackers@freebsd.org Thu Mar 2 23:21:15 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14166CF591F; Thu, 2 Mar 2017 23:21:15 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C56901672; Thu, 2 Mar 2017 23:21:14 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by mail-qk0-x241.google.com with SMTP id m67so5584956qkf.3; Thu, 02 Mar 2017 15:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uP4igptuyWpR3a4fmaZB2neJBDS0fRI0jyaa+L/fvVo=; b=SDPn75G2GVyMsEl9ZD0E9py0Yvn9if5LY8cJw6QXgfoCNLxJqo8Q1Dzk/1fU6EcIph 7BaBhT5n6a/KtyPO65q01vJoIqE9H1oH2TEz+CwjUp6Pf1V2j3Dr9E541VvjatwP6h2R Vhr/EAlfMt+lDb2Jf/7HmjBqdxm9QzBwZ7cumWqo8R5j6+trr7XQtptZUC74ivMDPHFF GWvJ77kNc69/RKoCNABIL4ZIQNYA4PJpzFW6nAXB1JHsh44VnhMuGYmue8ITv3ezDGl4 qiwMkVRlMqusRxqGyo0EEX6pUYU+L6K58TZagzBwKA3yhBDcMA53MNo0WAZBdC2x5ElR n3rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uP4igptuyWpR3a4fmaZB2neJBDS0fRI0jyaa+L/fvVo=; b=RGMjTAcdLJBBiOsLVJjp4MpugYS9p+1KV9fqZ2mU77OKPKTOdQkXCC/x0gA4Y7FeQd PByU3SsLDYgGHvHVqDBh/nuXwHnDgoHFP7qGPUmqkvuttro+/Kq34fl5NKE8C4oTUwjj EaVnBQ25c533/OYd/a/MLv8vkwd3WfzLKqWkwVwjEsxLsUBLDvHC1hWRbY/11fhlo5ly 168A06TNOnKv6TK6ZUK/x+Phzeedk+nAzogc2YTYjhWQOMXTsDcMCl8qHOSXOfl7dUth FeyzcXAF3+PaLytc5Vy0W4pA9IBu5PeNLhyyhqhoY4O0BxEcf2JXt/nDPsJ7nG+8FgG9 KCng== X-Gm-Message-State: AMke39mVqZWlPLjCR+7EUy1pGgHB2mQBt8q/HzDYJMxtmSvDsG0nUHVUnOwzETB4hDcWyGHi0RQkEtg7pt2Wpw== X-Received: by 10.237.36.116 with SMTP id s49mr20418789qtc.128.1488496873968; Thu, 02 Mar 2017 15:21:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.134.70 with HTTP; Thu, 2 Mar 2017 15:21:13 -0800 (PST) In-Reply-To: <20170302230416.GK4503@server.rulingia.com> References: <20170302230416.GK4503@server.rulingia.com> From: Subbsd Date: Fri, 3 Mar 2017 02:21:13 +0300 Message-ID: Subject: Re: effect of strip(1) on du(1) To: Peter Jeremy Cc: freebsd-current Current , freebsd-hackers Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 23:21:15 -0000 On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy wrote: > On 2017-Mar-02 22:29:46 +0300, Subbsd wrote: >>During some interval after strip call, du will show 512B for any file. >>If execute du(1) after strip(1) without delay, this behavior is reproduced 100%: > > What filesystem are you using? strip(1) rewrites the target file and du(1) > reports the number of blocks reported by stat(2). It seems that you are > hitting a situation where the file metadata isn't immediately updated. > > -- > Peter Jeremy Got it. My filesystem is ZFS. Looks like when ZFS open and write data to file, we get wrong number of blocks during a small interval after writing. Thanks for pointing this out! From owner-freebsd-hackers@freebsd.org Fri Mar 3 00:32:04 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9A85CF6EE2; Fri, 3 Mar 2017 00:32:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7594818D1; Fri, 3 Mar 2017 00:32:03 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v230VxFY066399; Thu, 2 Mar 2017 16:31:59 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v230VvIl066398; Thu, 2 Mar 2017 16:31:57 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> Subject: Re: effect of strip(1) on du(1) In-Reply-To: To: Subbsd Date: Thu, 2 Mar 2017 16:31:57 -0800 (PST) CC: Peter Jeremy , freebsd-hackers , freebsd-current Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 03 Mar 2017 01:00:30 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 00:32:04 -0000 > On Fri, Mar 3, 2017 at 2:04 AM, Peter Jeremy wrote: > > On 2017-Mar-02 22:29:46 +0300, Subbsd wrote: > >>During some interval after strip call, du will show 512B for any file. > >>If execute du(1) after strip(1) without delay, this behavior is reproduced 100%: > > > > What filesystem are you using? strip(1) rewrites the target file and du(1) > > reports the number of blocks reported by stat(2). It seems that you are > > hitting a situation where the file metadata isn't immediately updated. > > > > -- > > Peter Jeremy > > > Got it. My filesystem is ZFS. Looks like when ZFS open and write data > to file, we get wrong number of blocks during a small interval after > writing. Thanks for pointing this out! Even if that is the case file system cache effects should NOT be visible to a userland process. This is NOT as if your running 2 different processing beating on a file. Your test cases are serialially syncronous shell invoked commands seperated with && the results should be exact and predictable. When strip returns the operation from the userland perspecive is completed and any and all processeses started after that should have the view of the completed strip command. This IS a bug. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Mar 3 01:12:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94178CF617F; Fri, 3 Mar 2017 01:12:34 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 593BF11EA; Fri, 3 Mar 2017 01:12:34 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-qk0-x230.google.com with SMTP id s186so153329348qkb.1; Thu, 02 Mar 2017 17:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=km7Wrgxixu9j+CrPOavgUmG/bBtPmAwk79VIygYKAzA=; b=SDs5lDLt9UOFm82UHD0fcQ20ZRK5Xp6q2OFdMwk3Yldlvku4LVwTto9MnyH+vyTBHh r4UaBHUvM8KDGudjAtjdC+06lXM8QDnTO4Jn5sQSEKI9DaSbjHFlXpkVCriiWFXIuOxz BYH56NH7vMWFO+z4X5c/XZ+5Fjnk2akwZ5Nb61dGdq/XqanRZXVhl91+lMZZpA44FvFZ h9VgsGHfCym2kS7JP0MLE9QhcAj2NCr90vxhDHVJR6OA0MDUkSwgHe7ddIjU9k2PbRV8 3Uat+uZ1lfP630JuvApsv7FCHgrhH5/DdQZJMKJxHEeHX4D93h2L3x5eGsUPHPENk9AG mSSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=km7Wrgxixu9j+CrPOavgUmG/bBtPmAwk79VIygYKAzA=; b=L6PYGwpu/LZpMUpuWZjlVyYe7tGvqMAKznddODwbJlp4iMgnjfr6jFUqTHcz34FeNG y6f6DbzCPNu/Q2ay6PIakJU1cjIKLRFhpzRMHcPISG49iCaN9oZ1HHg0hXjWeFJbPviY 7SOkfwf7jmlzscsCMmrgKBbA/wIKIz9/wiwFPX5r00qhwSCqdQ/aXTdkw9bzBmivBZI1 3LoutW93t0BFm1vFlij2MHcJqDQprHAuLx9HQqXrB52JwJsEHzmQ1roL4CVb3JDQXzZz wj+ZC0Moo43W/0bidUzmnctqilFWP1f2G9zVP5IF5W9/uROWJ93/zQz6LHAPYsJHRoJT VbBA== X-Gm-Message-State: AMke39nGHGt4BJ/aCTpW788DUdIno+L7KVSdgraOfiQORMOb/hV7HFG+m/usHnkjroHWfXQIB929tYmMee+TTA== X-Received: by 10.55.18.158 with SMTP id 30mr153084qks.123.1488503553585; Thu, 02 Mar 2017 17:12:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.104.200 with HTTP; Thu, 2 Mar 2017 17:12:33 -0800 (PST) In-Reply-To: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> References: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> From: Ngie Cooper Date: Thu, 2 Mar 2017 17:12:33 -0800 Message-ID: Subject: Re: effect of strip(1) on du(1) To: "Rodney W. Grimes" Cc: Subbsd , Peter Jeremy , freebsd-hackers , freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:12:34 -0000 On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes wrote: ... > Even if that is the case file system cache effects should NOT be > visible to a userland process. This is NOT as if your running > 2 different processing beating on a file. Your test cases are > serialially syncronous shell invoked commands seperated with > && the results should be exact and predictable. > > When strip returns the operation from the userland perspecive > is completed and any and all processeses started after that > should have the view of the completed strip command. > > This IS a bug. Would the same statement necessarily apply if the filesystem was writing things asynchronously to the backing storage? Thanks, -Ngie From owner-freebsd-hackers@freebsd.org Fri Mar 3 01:30:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F221FCF689A; Fri, 3 Mar 2017 01:30:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B01121CFA; Fri, 3 Mar 2017 01:30:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x243.google.com with SMTP id l16so8609366ywb.2; Thu, 02 Mar 2017 17:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EdM/8axQuC0OFffM0mnX9s3KpyE5JWDfqjhjtwaao2A=; b=sob9MzDHh9vbtuAErAUinxPll3KpMWhXylkbyj4Imuf/HwHRVNRWCOMQ74Gl64J7T2 QzcgcqNVZdXCA5qDo6JGpXNs/NwlmGHCspygRa0fXQU9g+gZ2HUWTOwmPSWTQWovnA0M bOfH7uRJSvTs2hYq/NQsSpHzqzsUpU+wuBl6mIzE8e15zL9fUW+HTtJEDO/NEljqlSbJ F/EA8BxyAt/IWHxASIczhO58ELeS+4jxw22Pq0/V47H5t/w2f1r5qEtatW1tjuCayLtE 1DcVWNrv3joJJS5VYE//1oscajjNLFwvV+5xKHGVPoQ7NshfrNRv5KbUfElcmDqdpYkg ZmOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EdM/8axQuC0OFffM0mnX9s3KpyE5JWDfqjhjtwaao2A=; b=d737FR6oiETO2ts4A89VFbEwF3W1isqD32yP9Da/FPpNfjmVZkmQOP9JhlWAm3wuxl 33uiWWNAAE4GHwAuPSRiWJtlkVusdZLwSG/sSi7qt7z1YMu8quAkkTTq7FirVwYPFGEN GSG5N3fit7GZkNEkXQ/m2W9NNORCe7mXRFbT3bV6JS/bfgpOZxh3EqyihAdlKpMfaxAK 60LKYwtf6ybGUeYCcBd8A48f220wnzwzzSxQA1QnWKt3pvJmObMxJWaFxwcJaS67IK3L Xn/LeBPHOAMMWVq+f9QkEAtmb78PbUYFjjlO/2jELHjWVy8tJyA60IpcWHY7lR/bYz0Y 7F+g== X-Gm-Message-State: AMke39nbyTdwcLAH8+N3U8QsxxrKcQST0Wo/zyQXY1reKtWz23jFUPzwdFb00LqOS5rNQuFeDT63t2+3L53V0Q== X-Received: by 10.37.215.23 with SMTP id o23mr121955ybg.113.1488504632767; Thu, 02 Mar 2017 17:30:32 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Thu, 2 Mar 2017 17:30:32 -0800 (PST) In-Reply-To: References: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> From: Alan Somers Date: Thu, 2 Mar 2017 18:30:32 -0700 X-Google-Sender-Auth: Qeu-d44pK0cgbWCyD6YpAsttZdk Message-ID: Subject: Re: effect of strip(1) on du(1) To: Ngie Cooper Cc: "Rodney W. Grimes" , Subbsd , Peter Jeremy , freebsd-hackers , freebsd-current Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:30:34 -0000 On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper wrote: > On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes > wrote: > ... >> Even if that is the case file system cache effects should NOT be >> visible to a userland process. This is NOT as if your running >> 2 different processing beating on a file. Your test cases are >> serialially syncronous shell invoked commands seperated with >> && the results should be exact and predictable. >> >> When strip returns the operation from the userland perspecive >> is completed and any and all processeses started after that >> should have the view of the completed strip command. >> >> This IS a bug. > > Would the same statement necessarily apply if the filesystem was > writing things asynchronously to the backing storage? > Thanks, > -Ngie du(1) is using fts_read(3), which is based on the stat(2) information. The OpenGroup defines st_blocksize as "Number of blocks allocated for this object." In the case of ZFS, a write(2) may return before any blocks are actually allocated. And thanks to compression, gang blocks, and deduplication, at this point it's not even possible for ZFS to know how many blocks it will need to allocate. I think st_blocksize should be interpreted as a "best effort" output. Just like df(1), you can't rely on du's output to be mathematically precise in any way. I certainly don't see any way to fix it besides doing something like an fsync(2) before getting stat information, and we certainly don't want to do that. -Alan From owner-freebsd-hackers@freebsd.org Fri Mar 3 03:11:08 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78E95CF6923 for ; Fri, 3 Mar 2017 03:11:08 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C9CD1120 for ; Fri, 3 Mar 2017 03:11:08 +0000 (UTC) (envelope-from alfix86@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id n11so5727137wma.1 for ; Thu, 02 Mar 2017 19:11:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=P/sf6b2ATU1V2Qa7qfMym3Dcjjea4M/Uj7lVQpe0nfY=; b=PjNvVndkD2ochCU0XUKgCdPro0czw5JsVCUPly1cwqWarbNVu2UpVOyz20XiLTifke 8Qio3jNTprEUxGlBll0y/u56UeALE1loy7upCXLu5dY3mTeUVJyJIKFRu4IVsqik4+fd VZhe4W7RxwU41Lz3pBai1Ov0FYeFMTYeN3qCwqAUMEARvMUOiQGYES4lToH2V7pHPEwu u1FXI6cTPlCyX/wwZ0NCsiDGm6hwsTTZOn9pF9u7f7X+4a6mRdal6QDKkzpkFlG9rPYK DAd3Z14uTY4MnD6hXt9aZNOpUrUsUp99bnMtWSnHNnZPLgcFYvmlNp1WdP4iJswYALQt TycA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P/sf6b2ATU1V2Qa7qfMym3Dcjjea4M/Uj7lVQpe0nfY=; b=PxmmYWfHYoq3x0PUqflTDuQnDvVFkyOUUQBVVLrao5pyIeJ0OLwaCvgM3NtP/dBf2f tiDqhmZFASQ4kOo4qoqu65QTy1cVV2PiIPaQnxOaR9NgS37kyo2XyKtsF5TQBVaa8tKv 0ZFaP4iq57se0FebZSqoABCwdYZCWJkkyBVWWzazhJQ4UclthIM2vfoE4Q6sZFfWNY+q yqhZby+Sk8b52H+UjMDOTFOHfRDTO1mTNYBD197+RYe8OOMYalbxgITHxEqWFNtHT7kz 7x/K2ZF5pdmU21J0W/POgWiG9zONOEodrJJRz0N+hg0SuZ7wxQQ6nihjAibuHefnlVhZ 5XCQ== X-Gm-Message-State: AMke39nd0vA4wEGMOZGZpnV/eWxuvjxKFhM7iOAym5CWw4OTAH/QSHo1cwlsC4s7+FlYkNANohEemjq7a1xCTA== X-Received: by 10.28.136.13 with SMTP id k13mr644403wmd.94.1488510665511; Thu, 02 Mar 2017 19:11:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.159.73 with HTTP; Thu, 2 Mar 2017 19:11:04 -0800 (PST) From: Alfonso Sabato Siciliano Date: Fri, 3 Mar 2017 04:11:04 +0100 Message-ID: Subject: Solaris Doors To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 03:11:08 -0000 Hi all! 'IdeasPage' has a very interesting project: 'Solaris Doors IPC Implementation' [0] I have created a git repo [1] with a README briefly: - first step: door_create() and door_call() - second step: remaining API (door_bind(), door_info(), ...) - third step (OPTIONAL) : fattach() and fdettach() Anyway, is this project still useful? [0] https://wiki.freebsd.org/IdeasPage#Solaris_Doors_IPC_Implementation [1] https://gitlab.com/alfix/doors Regards Alfonso From owner-freebsd-hackers@freebsd.org Fri Mar 3 08:36:02 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 183A0CF6B3D; Fri, 3 Mar 2017 08:36:02 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 076DA177A; Fri, 3 Mar 2017 08:36:01 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8003:a4d6:f496:718a:b775:a369]) by elvis.mu.org (Postfix) with ESMTPSA id E0F79346DDDC; Fri, 3 Mar 2017 00:36:00 -0800 (PST) Subject: Re: effect of strip(1) on du(1) To: Alan Somers , Ngie Cooper References: <201703030031.v230VvIl066398@pdx.rh.CN85.dnsmgr.net> Cc: "Rodney W. Grimes" , Subbsd , Peter Jeremy , freebsd-hackers , freebsd-current Current From: Alfred Perlstein Organization: FreeBSD Message-ID: <9fb69e17-cb7f-5f04-aeb3-914ba58ddab4@freebsd.org> Date: Fri, 3 Mar 2017 00:36:00 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 08:36:02 -0000 On 3/2/17 5:30 PM, Alan Somers wrote: > On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper wrote: >> On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes >> wrote: >> ... >>> Even if that is the case file system cache effects should NOT be >>> visible to a userland process. This is NOT as if your running >>> 2 different processing beating on a file. Your test cases are >>> serialially syncronous shell invoked commands seperated with >>> && the results should be exact and predictable. >>> >>> When strip returns the operation from the userland perspecive >>> is completed and any and all processeses started after that >>> should have the view of the completed strip command. >>> >>> This IS a bug. >> Would the same statement necessarily apply if the filesystem was >> writing things asynchronously to the backing storage? >> Thanks, >> -Ngie > du(1) is using fts_read(3), which is based on the stat(2) information. > The OpenGroup defines st_blocksize as "Number of blocks allocated for > this object." In the case of ZFS, a write(2) may return before any > blocks are actually allocated. And thanks to compression, gang > blocks, and deduplication, at this point it's not even possible for > ZFS to know how many blocks it will need to allocate. I think > st_blocksize should be interpreted as a "best effort" output. Just > like df(1), you can't rely on du's output to be mathematically precise > in any way. I certainly don't see any way to fix it besides doing > something like an fsync(2) before getting stat information, and we > certainly don't want to do that. > > Try adding an fsync(1) to the file before running du(1) on it. -Alfred From owner-freebsd-hackers@freebsd.org Fri Mar 3 08:55:19 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DD8CCF63A1 for ; Fri, 3 Mar 2017 08:55:19 +0000 (UTC) (envelope-from dreamashish21@gmail.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A7841556 for ; Fri, 3 Mar 2017 08:55:19 +0000 (UTC) (envelope-from dreamashish21@gmail.com) Received: by mail-it0-x22f.google.com with SMTP id 203so8990762ith.0 for ; Fri, 03 Mar 2017 00:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kw6yNPN8CkH/zZhO/NcaLhURalJ+m3VFDrRlTQsLRHk=; b=vC5lSceoMZHcWVkpcFMDkj++o7xL/nTZfbkvG30niR7r3D8Hr5KxK4cjGQC+GoQ/Xu dmU2Pk3sfng8qod3tMANB94XGTuXUXRi2jkT9UhUn+RNk0DXgOY3qKjJuH6BdaTsrZAY rLy004zlymCPvop4p/aydMbis5RWQ7aaX7Hp9Q8qxGlE2i3V9NTXEYgdr8DamWjoK8b3 I5ox26fn51+OHpDZ7RVvY+d3qQOxK8VOiCt8gJ4LrmHCeVF7/UWEahxRm312Z+KCJdjg ipnFM/Ae1+Fb4m9oLyLb2a5Xaddz177s9bmA9GNvYq5jZ7SmNTykLfUzDxo7VqbC9T0F s/dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kw6yNPN8CkH/zZhO/NcaLhURalJ+m3VFDrRlTQsLRHk=; b=KWm/4iusAHsEx3GD0H50/G6RcB1XfkE7qvMldea76OqbXiFR1XjfcdgUp6v4JkaXcF b9RcniIGO6cxrJAZ6Ezhemo6P3sgIzd7l2l8gTfsyS8fzbYuUVoHdLluDzJx0TGTa5Qe G76ygbhQmZjsdc26Yvb2c+HqYR+solxCFlWbAU1lFr+odbakWTSOBj+Ju8dNHOpG2asG 5nudzdmM0+UWQnmLNb9TZf1DjyXVPbTvYDmbrN9DFencLwJkdtT/p8/BQrvn9PK80h+8 TdJr7ENp0bXMtrIt9zXTtRQvCPzC73JqW/ZzSCuR0nsnRN5TTICgws7JS1j/2Acg6+lA mIAA== X-Gm-Message-State: AMke39m7RvNes0Zpa+YLQqEzCYi/Nexaw3waH3nh2YR3fcqef26+6bfg1PJvrci1pv3wFkwFCeeMivgtIiZLkA== X-Received: by 10.36.98.65 with SMTP id d62mr2233000itc.119.1488531318273; Fri, 03 Mar 2017 00:55:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.59.214 with HTTP; Fri, 3 Mar 2017 00:54:37 -0800 (PST) From: Ashish Gahlot Date: Fri, 3 Mar 2017 14:24:37 +0530 Message-ID: Subject: GSoC 2017 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 08:55:19 -0000 Hello all, The idea page has very interesting project "test Kload". I have prior worked on kvmtool so I have experience in loading bzImage in userspace using KVM APIs. Is there someone willing to a mentor for this project. Thanks, Ashish -- Ashish Kumar Gahlot III year, UG Govt. Engg. College, Ajmer, India From owner-freebsd-hackers@freebsd.org Fri Mar 3 09:22:01 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A61ACCF6E9E; Fri, 3 Mar 2017 09:22:01 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 524F0146B; Fri, 3 Mar 2017 09:22:00 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id v239Lo5S059870 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Mar 2017 20:21:56 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id v239LiEg095183 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Mar 2017 20:21:44 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id v239Lhim095182; Fri, 3 Mar 2017 20:21:43 +1100 (AEDT) (envelope-from peter) Date: Fri, 3 Mar 2017 20:21:43 +1100 From: Peter Jeremy To: "Rodney W. Grimes" Cc: Alan Somers , Ngie Cooper , Subbsd , freebsd-hackers , freebsd-current Current Subject: Re: effect of strip(1) on du(1) Message-ID: <20170303092143.GM4503@server.rulingia.com> References: <201703030619.v236JAph067805@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: <201703030619.v236JAph067805@pdx.rh.CN85.dnsmgr.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 09:22:01 -0000 --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2017-Mar-02 22:19:10 -0800, "Rodney W. Grimes" wrote: >> du(1) is using fts_read(3), which is based on the stat(2) information. >> The OpenGroup defines st_blocksize as "Number of blocks allocated for >> this object." In the case of ZFS, a write(2) may return before any >> blocks are actually allocated. And thanks to compression, gang =2E.. >My gut tells me that this is gona cause problems, is it ONLY >the st_blocksize data that is incorrect then not such a big >problem, or are we returning other meta data that is wrong? Note that it's st_blocks, not st_blocksize. I did an experiment, writing a (roughly) 113MB file (some data I had lying around), close()ing it and then stat()ing it in a loop. This is FreeBSD 10.3 with ZFS and lz4 compression. Over the 26ms following the close(), st_blocks gradually rose from 24169 to 51231. It then stayed stable until 4.968s after the close, when st_blocks again started increasing until it stabilized after a total of 5.031s at 87483. Based on this, st_blocks reflects the actual number of blocks physically written to disk. None of the other fields in the struct stat vary. The 5s delay is presumably the TXG delay (since this system is basically unloaded). I'm not sure why it writes roughly =BD the data immediately and the rest as part of the next TXG write. >My expectactions of executing a stat(2) call on a file would >be that the data returned is valid and stable. I think almost >any program would expect that. I think a case could be made that st_blocks is a valid representation of "the number of blocks allocated for this object" - with the number increasing as the data is physically written to disk. As for it being stable, consider a (hypothetical) filesystem that can transparently migrate data between different storage media, with different compression algorithms etc (ZFS will be able to do this once the mythical block rewrite code is written). --=20 Peter Jeremy --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJYuTWnXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0iJkP/R2TZlwppRH4SdrvGi9QddPZ ZRZWbK9Cx0PDn26s7IG8u1kuCuXRPcMuz+GH7BZ/zf+GhGzpbVfTzUV590S/0QMP /9VLpmqX7/6oR0RVH5iPZZ6fI1WNuycbeipr8wKXKfkc3B8zeJfVeFLyWVCOkbVC MMqcn/1fwRIyYLbjeJfJvgKrKNiB4ubhVOz+TnASXm1Z/SWavyMmX2nOOA8OTxUe CUGmbu5533NYlkLiBT7Jm+hcgiUwjLyzj0cg5yEgeR8CE9uCvqPma4sHpseVrBWl 95nyuR6mxfwRaUyJtcwbZNgE6f+QR3yOlQudK4zo50BTfHxnk4swwz4MS+VXoz6o OprH9VahjO5RV5Gbo6IMSOYZBqkRxgov8xhFFG+IeZEeWMNS9+EEMYGOEW+cbPdT pNOtatqbGDG7Q0q9rEIAP9t6OpLjTsExxomxBmWaLzuDz5Gn/qeAIp3ZtqLLJP37 MP8OU8QO5g82bdETk+o8gZ3zb+2IwWJLCU4iRoWZuiqbDRYbuX9pgfIAb4E91aOU hEl5pQBOq0BZC9Wx/vFdFmJYZsTdxg7JDl4QtV50sno9OHCJ5LtLrU5Ir5gS+KeK e6M7x6kyCTEJkfuMvBHBYrgeEZiN+G4TVuLBxDV/5YdNcCun1VpqvCFRe86WB8RX f366wz6bQC3BuFA41ZV+ =0Gmi -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- From owner-freebsd-hackers@freebsd.org Fri Mar 3 06:13:55 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 65412CF4358; Fri, 3 Mar 2017 06:13:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2C6E1137C; Fri, 3 Mar 2017 06:13:54 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v236DrJM067775; Thu, 2 Mar 2017 22:13:53 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v236DqUN067774; Thu, 2 Mar 2017 22:13:52 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703030613.v236DqUN067774@pdx.rh.CN85.dnsmgr.net> Subject: Re: effect of strip(1) on du(1) In-Reply-To: To: Ngie Cooper Date: Thu, 2 Mar 2017 22:13:52 -0800 (PST) CC: Subbsd , Peter Jeremy , freebsd-hackers , freebsd-current Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 03 Mar 2017 12:13:27 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 06:13:55 -0000 [ Charset UTF-8 unsupported, converting... ] > On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes > wrote: > ... > > Even if that is the case file system cache effects should NOT be > > visible to a userland process. This is NOT as if your running > > 2 different processing beating on a file. Your test cases are > > serialially syncronous shell invoked commands seperated with > > && the results should be exact and predictable. > > > > When strip returns the operation from the userland perspecive > > is completed and any and all processeses started after that > > should have the view of the completed strip command. > > > > This IS a bug. > > Would the same statement necessarily apply if the filesystem was > writing things asynchronously to the backing storage? Caching should^h^h^h^hshall be transparent to a userland process. Are you actually advocating that a userland process should be able to see that zfs is write caching meta data? The strip(1) command has completed and exited, pola dictates that anything I asked strip(1) to do be reflected in all commands or system calls executed after it. Anything else would be a bug. > Thanks, > -Ngie -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Mar 3 06:19:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47109CF457A; Fri, 3 Mar 2017 06:19:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB71D180A; Fri, 3 Mar 2017 06:19:13 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v236JCZ6067806; Thu, 2 Mar 2017 22:19:12 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v236JAph067805; Thu, 2 Mar 2017 22:19:10 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703030619.v236JAph067805@pdx.rh.CN85.dnsmgr.net> Subject: Re: effect of strip(1) on du(1) In-Reply-To: To: Alan Somers Date: Thu, 2 Mar 2017 22:19:10 -0800 (PST) CC: Ngie Cooper , Subbsd , Peter Jeremy , freebsd-hackers , freebsd-current Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 03 Mar 2017 12:23:20 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 06:19:14 -0000 > On Thu, Mar 2, 2017 at 6:12 PM, Ngie Cooper wrote: > > On Thu, Mar 2, 2017 at 4:31 PM, Rodney W. Grimes > > wrote: > > ... > >> Even if that is the case file system cache effects should NOT be > >> visible to a userland process. This is NOT as if your running > >> 2 different processing beating on a file. Your test cases are > >> serialially syncronous shell invoked commands seperated with > >> && the results should be exact and predictable. > >> > >> When strip returns the operation from the userland perspecive > >> is completed and any and all processeses started after that > >> should have the view of the completed strip command. > >> > >> This IS a bug. > > > > Would the same statement necessarily apply if the filesystem was > > writing things asynchronously to the backing storage? > > Thanks, > > -Ngie > > du(1) is using fts_read(3), which is based on the stat(2) information. > The OpenGroup defines st_blocksize as "Number of blocks allocated for > this object." In the case of ZFS, a write(2) may return before any > blocks are actually allocated. And thanks to compression, gang > blocks, and deduplication, at this point it's not even possible for > ZFS to know how many blocks it will need to allocate. I think > st_blocksize should be interpreted as a "best effort" output. Just > like df(1), you can't rely on du's output to be mathematically precise > in any way. I certainly don't see any way to fix it besides doing > something like an fsync(2) before getting stat information, and we > certainly don't want to do that. My gut tells me that this is gona cause problems, is it ONLY the st_blocksize data that is incorrect then not such a big problem, or are we returning other meta data that is wrong? Waving hands over this report as async write behind meta data issues is not making sure we dont have a more serious problem. My expectactions of executing a stat(2) call on a file would be that the data returned is valid and stable. I think almost any program would expect that. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Mar 3 12:40:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBA61CF3F98 for ; Fri, 3 Mar 2017 12:40:31 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A21F1B08 for ; Fri, 3 Mar 2017 12:40:30 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [88.198.220.130] (helo=sslproxy01.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1cjmAL-0001lC-TB for freebsd-hackers@freebsd.org; Fri, 03 Mar 2017 13:18:33 +0100 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy01.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cjmAL-0003hd-Ls for freebsd-hackers@freebsd.org; Fri, 03 Mar 2017 13:18:33 +0100 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1987E2A17F3 for ; Fri, 3 Mar 2017 13:18:38 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 0Qi_KVLuBTQP for ; Fri, 3 Mar 2017 13:18:37 +0100 (CET) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id AD6A92A17F4 for ; Fri, 3 Mar 2017 13:18:37 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DiMdoZluD99u for ; Fri, 3 Mar 2017 13:18:37 +0100 (CET) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 93BB52A17F3 for ; Fri, 3 Mar 2017 13:18:37 +0100 (CET) To: FreeBSD From: Sebastian Huber Subject: Mailing list for network interface driver patches? Message-ID: <58B95F18.7040004@embedded-brains.de> Date: Fri, 3 Mar 2017 13:18:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.99.2/23159/Fri Mar 3 09:58:12 2017) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 12:40:31 -0000 Hello, what is the right mailing list for network interface driver patches? Is=20 this freebsd-drivers or freebsd-net? --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= . From owner-freebsd-hackers@freebsd.org Fri Mar 3 14:11:40 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6021CF50C9 for ; Fri, 3 Mar 2017 14:11:40 +0000 (UTC) (envelope-from ssgriffonuser@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FBE0115B for ; Fri, 3 Mar 2017 14:11:40 +0000 (UTC) (envelope-from ssgriffonuser@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id a6so47924840lfa.0 for ; Fri, 03 Mar 2017 06:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JyV4feNoHLUxf34ziPO4tC47LvN3PoVLviHfkAR2RkI=; b=RY/rck6Li5/hBLyxtXGwySYpE9a+lkMN3iRFcxEL7+CnXQTPXDqr1ag50WvGvABwWM DNXt23SH6x6BXv0drjA4z5fwJ6/10Jru8yUMLJJ1vTSqP36kCzQUak1o1KLx4XbBFb1l bXM4W2p5rFZjwabXVSim6G0wqW8CvNzHqsCTot0U6ooa9SSl9jDjWp7rKARWNiOq5beI 9kIy7TihIz7hJQzG9/MIZ8CJ0pqStacudm0OE9ODmUiXXPvSjIXbfw1J440IVFrmypa4 I8Ace96T945OhxqvmXiJB1O/KZ9GLk3f2rHLX6q/+bMpWMsS7s2RV2DQm8H7doyvbGPI dzWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JyV4feNoHLUxf34ziPO4tC47LvN3PoVLviHfkAR2RkI=; b=FQf3oudp9mslnzt71JJ4nOCzEXHVLckDOZ7YO/vY+H7RaWY24ov2PIeuJXklmVpCn0 F14Q+3mjKXwayM4KgAAzbQJfLOBqZGHUUfBIhXYCbccDPr8dX+ziZmHFpzyfghs2eI54 POZNdJ+eKyNUFeaLcbsHzHfed3rDp3e3QZE/8o0/7BMUWrXsBWHCtDGCBcVB9yJNuyxo kx6CFvZGeZe04F/ecu4TeojMz/IhLv779HSG3X7FNO0kJoAGIUy16ESJSCp8QWtp6p/d ZIXQocothbnSyeJoNrsTuUpQ8BbeSTK+8J9MOdTjt0nGcIxfqQmY40E0RE1ouTmwEkez vcww== X-Gm-Message-State: AMke39m1PxRAdQ+0z1026gaTJ4cSCTF63y9YsAY2H9hm21qFrbR8lju8Cqb+oSHuMMnEqwl8xQ0dxPyYeQJmxw== X-Received: by 10.46.71.69 with SMTP id u66mr1038304lja.99.1488550298227; Fri, 03 Mar 2017 06:11:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.151.209 with HTTP; Fri, 3 Mar 2017 06:11:37 -0800 (PST) From: ss griffon Date: Fri, 3 Mar 2017 08:11:37 -0600 Message-ID: Subject: Discrepancy between kevent error codes with socketpair fds To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:11:40 -0000 I'm hoping somebody can explain the following behavior to me. It's not causing me any issues but I find it curious: 1. open a socketpair (int sv[2]) 2. close both ends 3. attempt to add sv[0] to kevent and "Invalid Argument" is returned (EINVAL) 4. attempt to add sv[1] to kevent instead of sv[0] and "Bad Descriptor" is returned (EBADF). It doesn't seem to matter the order of closing the sockets. Sample code is below. Thanks in advance. #include #include #include #include #include #include #include int main(int argc, char** argv) { int sv[2]; int err = socketpair(AF_LOCAL, SOCK_SEQPACKET, 0, sv); if(err == -1) { perror("socketpair"); exit(1); } err = close(sv[0]); if(err == -1) { perror("close1"); exit(1); } err = close(sv[1]); if(err == -1) { perror("close2"); exit(1); } int kqfd = kqueue(); if(kqfd == -1) { perror("kqueue"); exit(1); } struct kevent event; EV_SET(&event, sv[0], EVFILT_READ, EV_ADD, 0, 0, 0); //Change to sv[1] to get EBADF int events = kevent(kqfd, &event, 1, nullptr, 0, nullptr); //Returns EINVAL if(events == -1) { perror("kevent"); exit(1); } return 0; } From owner-freebsd-hackers@freebsd.org Fri Mar 3 14:11:34 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36B8BCF5093; Fri, 3 Mar 2017 14:11:34 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AED5113D; Fri, 3 Mar 2017 14:11:33 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v23EBWmM069970; Fri, 3 Mar 2017 06:11:32 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v23EBUdM069969; Fri, 3 Mar 2017 06:11:30 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703031411.v23EBUdM069969@pdx.rh.CN85.dnsmgr.net> Subject: Re: effect of strip(1) on du(1) In-Reply-To: <20170303092143.GM4503@server.rulingia.com> To: Peter Jeremy Date: Fri, 3 Mar 2017 06:11:30 -0800 (PST) CC: freebsd-hackers , Subbsd , freebsd-current Current , Ngie Cooper , Alan Somers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 03 Mar 2017 14:56:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:11:34 -0000 -- Start of PGP signed section. [ Charset ISO-8859-1 unsupported, converting... ] > On 2017-Mar-02 22:19:10 -0800, "Rodney W. Grimes" wrote: > >> du(1) is using fts_read(3), which is based on the stat(2) information. > >> The OpenGroup defines st_blocksize as "Number of blocks allocated for > >> this object." In the case of ZFS, a write(2) may return before any > >> blocks are actually allocated. And thanks to compression, gang > ... > >My gut tells me that this is gona cause problems, is it ONLY > >the st_blocksize data that is incorrect then not such a big > >problem, or are we returning other meta data that is wrong? > > Note that it's st_blocks, not st_blocksize. Yes, I just ignore that digretion, as well as the digretion into fts_read being anything special about this, as it just ends up calling stat(2) in the end anyway. > > I did an experiment, writing a (roughly) 113MB file (some data I had > lying around), close()ing it and then stat()ing it in a loop. This is > FreeBSD 10.3 with ZFS and lz4 compression. Over the 26ms following the > close(), st_blocks gradually rose from 24169 to 51231. It then stayed > stable until 4.968s after the close, when st_blocks again started > increasing until it stabilized after a total of 5.031s at 87483. Based > on this, st_blocks reflects the actual number of blocks physically > written to disk. None of the other fields in the struct stat vary. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thank you for doing the proper regression test, that satisfies me that we dont have a lattent bug sitting here and infact what we have is exposure of the kernel caching, which I might be too thrilled about, is just how its gona have to be. > > The 5s delay is presumably the TXG delay (since this system is basically > unloaded). I'm not sure why it writes roughly ? the data immediately > and the rest as part of the next TXG write. > > >My expectactions of executing a stat(2) call on a file would > >be that the data returned is valid and stable. I think almost > >any program would expect that. > > I think a case could be made that st_blocks is a valid representation > of "the number of blocks allocated for this object" - with the number > increasing as the data is physically written to disk. As for it being > stable, consider a (hypothetical) filesystem that can transparently > migrate data between different storage media, with different compression > algorithms etc (ZFS will be able to do this once the mythical block > rewrite code is written). I could counter argue that st_blocks is: st_blocks The actual number of blocks allocated for the file in 512-byte units. Nothing in that says anything about "on disk". So while this thing is sitting in memory on the TXG queue we should return the number of 512 byte blocks used by the memory holding the data. I think that would be the more correct thing than exposing the fact this thing is setting in a write back cache to userland. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Mar 3 14:57:58 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD090CF6284 for ; Fri, 3 Mar 2017 14:57:58 +0000 (UTC) (envelope-from alexander.tarasikov@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94DD51230 for ; Fri, 3 Mar 2017 14:57:58 +0000 (UTC) (envelope-from alexander.tarasikov@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id m124so56810497oig.1 for ; Fri, 03 Mar 2017 06:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xJB5o5CKNlROJkA7pC2bfecjajY9jm0X35nk7uIjD80=; b=BWuFkS6Bhml+mc4RTdAD9H1/nIqaVEQX67kstUyxQHAebIby8OkZkukcN/QqR1QVFt H4/qoJGpDiIDUAhXFvJCYfoGoXILBzGCfIx8YA1iuqyHfSVan/890GTD/5x80Fbi1y+u xPHE1e07F7qps3qHR2UVTdNVZUcYLWB6kvdXlDmFBGBtfQiHwQh05cxbi18vANQb3Qei yC1pW/47nreHSqco2lvjsY5PoBlJeHlGzlrIEx4hzfXlISTs9+tq9eP+KMICphN0ovcI NiF+KcgPN0UELYp5xaLeJdTJ+b/l/GCWZZMeDSND2rjs2qaK8tZehxLw/ifLjQET7f7W MIgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xJB5o5CKNlROJkA7pC2bfecjajY9jm0X35nk7uIjD80=; b=tltckvFf76fMtUBNDKWIA6nng0ogEQdD8lPFqZaEnYzbOzIKtwyZMNhosEAtu3nHkj DszqCVf0tPJTNc/sWL6vfbOUko2X/Yscr1w7+UM5PM3lpZn8yYQ6MbBQYg7IK0sT4giZ 5G3Ou60fb+W8D/v3zIMKfnM3gkEm1fz+k5pwFbS7g16WKwLlseZ7y2GnqeRIbkPjTxZ0 bch9Jj58tNumOnJH0tz/8aC870qtqK9GCeZMqezKP/PwaoNS9j9hgK2FBYR53d8u2LCp Qb1wm8L9jIqypR7iviLZG1PyPnwgxZ8Wu02zVacJcZbweYpGL7NAo7Tq2NTV2gOkZStH 5uBw== X-Gm-Message-State: AMke39leZ5yeUpyrPSjHrYDB05pikre66RORMAPKDh8g9f6NSx/m0XAzdhCAWcZGNCrYCeohF6n0zAnkHxCxgw== X-Received: by 10.202.72.2 with SMTP id v2mr1672711oia.179.1488553077337; Fri, 03 Mar 2017 06:57:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.102.10 with HTTP; Fri, 3 Mar 2017 06:57:56 -0800 (PST) Received: by 10.182.102.10 with HTTP; Fri, 3 Mar 2017 06:57:56 -0800 (PST) In-Reply-To: References: From: Alexander Tarasikov Date: Fri, 3 Mar 2017 15:57:56 +0100 Message-ID: Subject: Re: How approach debugging a kernel crash? To: Lee D Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:57:58 -0000 Hi, the kernel prints the FAR, the fault address register, and the registers. Looks like it crashes inside the fault handler itself? I would go to the "abort_handler" or "exception_exit" and add debugging prints to UART into there to catch the initial abort. Hope this leads somewhere On Feb 27, 2017 06:35, "Lee D" wrote: > Hi, > > I am trying to write a custom boot loader for ARM, to replace u-boot and > ubldr. > > As I'm working through this, I keep getting kernel crashes. I've got the > kernel debugger enabled, but doing a backtrace doesn't reveal any useful > information. > > How does one go about figuring out exactly what caused an exception? I > need to know where the kernel crashed so I can figure out what piece of > hardware I haven't set up correctly. > > The back trace is just a bunch of abort stuff, and ends in the message > "Unable to unwind into user mode". > > I've quoted the backtrace below, and also my kernel message. > > Mostly I'm looking for suggestions on how to go about finding the location > of the crash, as I expect to be doing this a lot this week :-) > > Thanks! > > Lee > > > db> bt > Tracing pid 0 tid 100000 td 0xc08f8470 > db_trace_self() at db_trace_self > pc = 0xc0669b44 lr = 0xc014c288 (db_hex2dec+0x1f4) > sp = 0xffff0cb0 fp = 0xffff0cc8 > db_hex2dec() at db_hex2dec+0x1f4 > pc = 0xc014c288 lr = 0xc014becc (db_command_loop+0x2f4) > sp = 0xffff0cd0 fp = 0xffff0d70 > r4 = 0x00000001 r5 = 0x00000000 > r6 = 0xc0704ae6 r10 = 0xc08f6f98 > db_command_loop() at db_command_loop+0x2f4 > pc = 0xc014becc lr = 0xc014bc4c (db_command_loop+0x74) > sp = 0xffff0d78 fp = 0xffff0d88 > r4 = 0xc06cfe7d r5 = 0xc06e1e0e > r6 = 0xc08f6f84 r7 = 0xffff0fa0 > r8 = 0xc08ead98 r9 = 0xc0791060 > r10 = 0xc08ead9c > db_command_loop() at db_command_loop+0x74 > pc = 0xc014bc4c lr = 0xc014f084 (db_fetch_ksymtab+0x2e8) > sp = 0xffff0d90 fp = 0xffff0ea8 > r4 = 0x00000807 r5 = 0x00000000 > r6 = 0xc08f6f90 r10 = 0xc08ead9c > db_fetch_ksymtab() at db_fetch_ksymtab+0x2e8 > pc = 0xc014f084 lr = 0xc0341870 (kdb_trap+0x180) > sp = 0xffff0eb0 fp = 0xffff0ed8 > r4 = 0x00000000 r5 = 0x00000807 > r6 = 0xc08eadb8 r10 = 0xc08ead9c > kdb_trap() at kdb_trap+0x180 > pc = 0xc0341870 lr = 0xc06908b4 (abort_handler+0x678) > sp = 0xffff0ee0 fp = 0xffff0f00 > r4 = 0xffff0fa0 r5 = 0x00000013 > r6 = 0xffff1030 r7 = 0x00000007 > r8 = 0x00000807 r9 = 0xc08f8470 > r10 = 0xffff0fa0 > abort_handler() at abort_handler+0x678 > pc = 0xc06908b4 lr = 0xc0690600 (abort_handler+0x3c4) > sp = 0xffff0f08 fp = 0xffff0f98 > r4 = 0x00000001 r5 = 0x00000007 > r6 = 0x00000000 r7 = 0x00000807 > r8 = 0x00000013 r10 = 0xffff0fa0 > abort_handler() at abort_handler+0x3c4 > pc = 0xc0690600 lr = 0xc066c42c (exception_exit) > sp = 0xffff0fa0 fp = 0xc0a13e70 > r4 = 0x00000000 r5 = 0xc08f8808 > r6 = 0x00000001 r7 = 0x00000000 > r8 = 0xc08f890c r9 = 0xc08f8908 > r10 = 0x00002802 > exception_exit() at exception_exit > pc = 0xc066c42c lr = 0x1000019c (0x1000019c) > sp = 0xffff1034 fp = 0xc0a13e70 > r0 = 0xc066c534 r1 = 0xc0a0b000 > r2 = 0xffff107c r3 = 0x20010193 > r4 = 0x00000000 r5 = 0xc08f8808 > r6 = 0x00000001 r7 = 0x00000000 > r8 = 0xc08f890c r9 = 0xc08f8908 > r10 = 0x00002802 r12 = 0xfefefeff > data_abort_entry() at data_abort_entry+0x30 > pc = 0xc066c534 lr = 0x1000019c (0x1000019c) > sp = 0xffff1034 fp = 0xc0a13e70 > Unable to unwind into user mode > > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2016 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.0-RELEASE-p1 #27 r309723M: Sat Feb 25 18:51:15 EST 2017 > builder@abe:/usr/home/builder/projects/fbsd_11.0.1/obj/arm. > armv6/usr/home/builder/projects/fbsd_11.0.1/src/sys/AXSACM > arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM > 3.8.0) > VT: init without driver. > CPU: Cortex A9-r3 rev 0 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB enabled LABT branch prediction disabled > LoUU:2 LoC:2 LoUIS:2 > Cache level 1: > 32KB/32B 4-way data cache WB Read-Alloc Write-Alloc > 32KB/32B 4-way instruction cache Read-Alloc > real memory = 535822336 (511 MB) > avail memory = 513486848 (489 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > random: entropy device external interface > ofwbus0: > simplebus0: on ofwbus0 > simplebus1: on ofwbus0 > simplebus2: on ofwbus0 > l2cache0: mem 0xf02000-0xf02fff on simplebus0 > l2cache0: cannot allocate IRQ, not using interrupt > l2cache0: Part number: 0x3, release: 0x8 > l2cache0: L2 Cache enabled: 512KB/32B 8 ways > gic0: mem > 0xf01000-0xf01fff,0xf00100-0xf001ff on simplebus0 > gic0: pn 0x390, arch 0x1, rev 0x2, implementer 0x43b irqs 96 > mp_tmr0: mem 0xf00200-0xf002ff,0xf00600-0xf0061f on > simplebus0 > Timecounter "MPCore" frequency 325000000 Hz quality 800 > Event timer "MPCore" frequency 325000000 Hz quality 1000 > zy7_slcr0: mem 0-0xfff on simplebus0 > zy7_devcfg0: mem 0x7000-0x7fff on simplebus0 > uart0: mem 0x1000-0x1fff on simplebus1 > uart0: console (-1,n,8,1) > ehci0: mem 0x2000-0x2fff on simplebus1 > usbus0: EHCI version 1.0 > usbus0: stop timeout > usbus0 on ehci0 > gpio0: mem 0xa000-0xafff on simplebus1 > gpiobus0: on gpio0 > gpioc0: on gpio0 > cgem0: mem 0xb000-0xbfff on > simplebus1 > miibus0: on cgem0 > rgephy0: PHY 0 on miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT-FDX, 1000baseT-FDX-master, auto > rgephy1: PHY 1 on miibus0 > rgephy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT-FDX, 1000baseT-FDX-master, auto > cgem0: no mac address found, assigning random: 62:73:64:b9:65:d2 > cgem0: Ethernet address: 62:73:64:b9:65:d2 > sdhci_fdt0: mem 0x100000-0x100fff > on simplebus1 > sdhci_fdt0: 1 slot(s) allocated > mmc0: on sdhci_fdt0 > sdhci_fdt1: mem 0x101000-0x101fff > on simplebus1 > sdhci_fdt1: 1 slot(s) allocated > mmc1: on sdhci_fdt1 > cryptosoft0: > Fatal kernel mode data abort: 'Translation Fault (L2)' on write > trapframe: 0xffff0fa0 > FSR=00000807, FAR=ffff1030, spsr=20010193 > r0 =c066c534, r1 =c0a0b000, r2 =ffff107c, r3 =20010193 > r4 =00000000, r5 =c08f8808, r6 =00000001, r7 =00000000 > r8 =c08f890c, r9 =c08f8908, r10=00002802, r11=c0a13e70 > r12=fefefeff, ssp=ffff1034, slr=1000019c, pc =c066c534 > > [ thread pid 0 tid 100000 ] > Stopped at data_abort_entry+0x30: str r0, [r13, -#0x004]! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Fri Mar 3 14:58:10 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C80DCCF62A3 for ; Fri, 3 Mar 2017 14:58:10 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm30-vm5.bullet.mail.ne1.yahoo.com (nm30-vm5.bullet.mail.ne1.yahoo.com [98.138.91.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B2B61290 for ; Fri, 3 Mar 2017 14:58:10 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1488553083; bh=ydC1J47R+Zh6/Saxds5P+UKN5UNzIjeQwrV0L1DJWho=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=fXX4MrSpbCpZ/hIlW/+pwRxfbGQ0cx0rJOefby2FdCO/wmBGmlOvt0MFHSRNNjGD342WfCKoVM8smTZBnBXrTo7lDSulK2Wyd8AKtz+L38KWvmHQudIegRYrbHp/pXsDvwxBfetH4Q/qlHxP0a3wqjIAs2M4wTN3l2TbwFzoSoon127zfhUC4J7eDWkoep81GHh2P8bdWeDhGQxh8OKE+RpuzIo5yDsIoESizuGQ9F0vtXllgF+Vq8Ja4k6NX1tnOSN4dS2WdzTNu5EMqlwm2sDe+zVUBnlUVg+MJxLPEUn/JwQ2UtLhnIVpQI1zVgao8D+PAVOGeWKJlNox1KuEeg== Received: from [98.138.100.111] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 14:58:03 -0000 Received: from [98.138.104.114] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 14:58:03 -0000 Received: from [127.0.0.1] by smtp223.mail.ne1.yahoo.com with NNFMP; 03 Mar 2017 14:58:03 -0000 X-Yahoo-Newman-Id: 52321.93541.bm@smtp223.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6c.KQJkVM1lRLU1br1iNRoCMbW.y49wwcuFfVJPLkbrFd5X 04QzWi5OPm5fvuiolMpeT4PTpQl1YPuh133JIBRhd1SHIsJlHyUgQFbw4iAJ LY8XIpX.VunOFgKiJ_X_AEC07_zzP7UPTnjtz4lrbqtK0zmYg5XFbh_Mh9Lg zKITrdJtYzHW1RYHvp1qMPLWP77VF0dAeCI76DtAxbSKnq_rUKiUu9J8fmfj .qrHRxiuHgicSjvg4AZ.XQ09ykiP4zw3jWnw9.ZcpzY9fND5i7QiMSDcRYrG _kjuSvjA_cFVssFTev5BCxQSjybJNk51cRTVWw5nvqzMHc5J6mQXggwqS0kd SJDjiPSbF92JAX.sJ1uYtfzdysyn7VIlBDkjQdZkwswddVSxBkCr0pFQzk5x cIZd8rPPccs4EG2tXahdwliFLC4PzSY.mqMvbQw4NmT4ELcCotLN2ERTjXwP 7nuzlCqW2KxWnUM.Kn5hR6eeX.Oc1nh4QX8nRt8_yF8ZA.eEg31SryDv4Gqz Pny8lMGD8Y7MoRB34Mz6q.Qh.9A65HkxJbNe6GrvkYVNIX7o- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: [GSoC 2017] Original proposal: Port kernel Lua to FreeBSD To: freebsd-hackers@freebsd.org References: <2634b0e5-2ef1-87fa-27a1-9aab13f01901@FreeBSD.org> From: Pedro Giffuni Message-ID: <180dca0e-cba5-cdb9-b347-402c7df6139a@FreeBSD.org> Date: Fri, 3 Mar 2017 10:00:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <2634b0e5-2ef1-87fa-27a1-9aab13f01901@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 14:58:10 -0000 (Previous attempt to post this bounced back) Concerning the bootloader, There is a tiny (64k!) version of python: http://www.tinypy.org/ So, I guess it's doable. There was also a GSoC project to update the bootloader to ficl4. https://svnweb.freebsd.org/socsvn/soc2015/clord/ The illumos bootlader already uses ficl4 BTW. Cheers, Pedro. From owner-freebsd-hackers@freebsd.org Fri Mar 3 15:43:31 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78D59CF627C for ; Fri, 3 Mar 2017 15:43:31 +0000 (UTC) (envelope-from nowakpl@platinum.linux.pl) Received: from platinum.edu.pl (platinum.edu.pl [137.74.1.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3E54F12E4 for ; Fri, 3 Mar 2017 15:43:30 +0000 (UTC) (envelope-from nowakpl@platinum.linux.pl) Received: from platinum.edu.pl (localhost [127.0.0.1]) by platinum.edu.pl (Postfix) with ESMTP id 6EAA0780176 for ; Fri, 3 Mar 2017 16:43:16 +0100 (CET) Received: by platinum.edu.pl (Postfix, from userid 87) id 60D77780171; Fri, 3 Mar 2017 16:43:16 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on platinum.edu.pl X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 Received: from [10.255.1.11] (unknown [109.231.16.141]) by platinum.edu.pl (Postfix) with ESMTPA id 1C193780171 for ; Fri, 3 Mar 2017 16:43:14 +0100 (CET) Subject: Re: Discrepancy between kevent error codes with socketpair fds To: freebsd-hackers@freebsd.org References: From: Adam Nowacki Message-ID: Date: Fri, 3 Mar 2017 16:43:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:43:31 -0000 Because the first descriptor is now a kqueue (kqfd == sv[0]). You can't add a kqueue descriptor to another kqueue so EINVAL. Second descriptor doesn't exist anymore so EBADF. On 2017-03-03 15:11, ss griffon wrote: > I'm hoping somebody can explain the following behavior to me. It's not > causing me any issues but I find it curious: > > 1. open a socketpair (int sv[2]) > 2. close both ends > 3. attempt to add sv[0] to kevent and "Invalid Argument" is returned > (EINVAL) > 4. attempt to add sv[1] to kevent instead of sv[0] and "Bad Descriptor" is > returned (EBADF). > > It doesn't seem to matter the order of closing the sockets. Sample code is > below. Thanks in advance. > > #include > #include > #include > #include > #include > #include > #include > > int main(int argc, char** argv) > { > int sv[2]; > > int err = socketpair(AF_LOCAL, SOCK_SEQPACKET, 0, sv); > if(err == -1) > { > perror("socketpair"); > exit(1); > } > > err = close(sv[0]); > if(err == -1) > { > perror("close1"); > exit(1); > } > > err = close(sv[1]); > if(err == -1) > { > perror("close2"); > exit(1); > } > > int kqfd = kqueue(); > if(kqfd == -1) > { > perror("kqueue"); > exit(1); > } > > struct kevent event; > EV_SET(&event, sv[0], EVFILT_READ, EV_ADD, 0, 0, 0); //Change to sv[1] > to get EBADF > > int events = kevent(kqfd, &event, 1, > nullptr, 0, nullptr); //Returns EINVAL > if(events == -1) > { > perror("kevent"); > exit(1); > } > > return 0; > } > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Fri Mar 3 15:59:14 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 926BDCF6A5E for ; Fri, 3 Mar 2017 15:59:14 +0000 (UTC) (envelope-from ssgriffonuser@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EE611E29 for ; Fri, 3 Mar 2017 15:59:14 +0000 (UTC) (envelope-from ssgriffonuser@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id y193so49204823lfd.3 for ; Fri, 03 Mar 2017 07:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=keNSq0PcXtRkd8pwXSdusNMSfi/LawyAw7UsCRnwdRI=; b=hDpXywaJRuTRt6E5w4RT9A+nWpZYFKzgIILlxp0thUEpdmyMUxn1gDwX4x0Tm7Rj6K sIUtBFSrZf7OVGGvxJTLQjRojySXiRzhdGe/kLnsQ3STPn6BdmnErbi//rujHbo7ZUAx TKIFHTyv6SUkB4FSOtVUhrMwA84SkvpcJwVvX6KivAE0z2xyciI+YRFHb55MkxktW06j yAbkjGIvqkoxhoQUQTXYQ3BVdJFjFwjMowCZQFInVii1/xF+Yp5sEZl1NAjPFwM53CY7 wOrMtWduvyc6OCbEyKxIhiyPl5qea/8ePx+2zw/SZM0nKLhVBvwbz6ywBjLdK/Eq7YaE mV1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=keNSq0PcXtRkd8pwXSdusNMSfi/LawyAw7UsCRnwdRI=; b=XG4/ZiYTCgcsVkZEm8qfrazHVbcYb1PS81iTTz4uRm/P+kORTdbfFYMVbDTOfVXace 3DnJvDMrVzZGBI4DRr1i+6ZR5tMVEoaQdbNmSZJIOtYkox5rvlUTei3NACTEgr52Qtwn c8RDrqUS9nlB/a3BnkbZXW/B6cTrW3KSJJ34CGCVzHDT3rQyg+MgIRodNEzDhaIGx8mr sk6Uu1Yy3FBOX6qNM32rAxiP2Xg8Omwxe80kGCa6eaPPhgKpxPlg/APkyP1Sp091RcJU NWF1EP3BG7UiLfDI5rfttjqjbaRr32xgLD52FdniV9pIrTW5it+IIUENh2zJWHxwW5+j Dxmw== X-Gm-Message-State: AMke39lIOnr4WX+/qJ2xXXN47wYnYt+IDVZ3+8O1LYvaAF+pl2EC1oCeSmyp90CwX8JLN5TUKNQyFNrKk0+usg== X-Received: by 10.25.170.1 with SMTP id t1mr1262454lfe.105.1488556751992; Fri, 03 Mar 2017 07:59:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.151.209 with HTTP; Fri, 3 Mar 2017 07:59:11 -0800 (PST) In-Reply-To: References: From: ss griffon Date: Fri, 3 Mar 2017 09:59:11 -0600 Message-ID: Subject: Re: Discrepancy between kevent error codes with socketpair fds To: Adam Nowacki Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 15:59:14 -0000 Ah, that's a bit of a *facepalm*, thanks for mentioning that. Moving the kqueue() to the top makes it behave as expected. From owner-freebsd-hackers@freebsd.org Fri Mar 3 16:39:17 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55797CF6A0C; Fri, 3 Mar 2017 16:39:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 13D531D59; Fri, 3 Mar 2017 16:39:17 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x234.google.com with SMTP id o4so22476647ywd.3; Fri, 03 Mar 2017 08:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=lZ+Qryg0b+bCBA27Yre2S2cBCxTDhzPcM54+HMtGvbU=; b=MNE29DVGeE9V0PcjeIAYbX6wwmFg+ZIoh7v1XHiXgfk1w0SY7equk5lzijHxtpvXod ISh6koP0XUQr7z7OyK6skjpECZiKIldx02Mlf7dx2uRrHZMYesTke6UaLm3XfdQknmmq rKRzkluJs4ssGWTV0mwDA3xE+O3B567jUxkrxGaE3IdpzNfCjG/t2RKlh5OcMLkYJFXF Ktq7a6W0sADOVvCJQJeUWCcyDYFwS0bPZ6JZ4w642IY+SCuHTSoEhSwq1MVJHVXcMkvc NR2uCqVA0VF6p2+hhcok+ANOneUTTRCBklpmhXkv1fNye8WZ7ueXM60Rx4Sikofy+Vqv YAxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=lZ+Qryg0b+bCBA27Yre2S2cBCxTDhzPcM54+HMtGvbU=; b=PHmiVXfHTxypMsd+QKJO9yLrOA5pmyzVmPCS1l9mIJ0hQQeWd+focDiGMwV4iUJAKf 7LrsFH/em8Vgsgpv/4sCOygrI9RPMdIGk+xqzUESHEawHoVXX4kIfTv2ZyWsH9m3FFWT SxLR1cU9ejWrACwmYqcN+m6zsKgK1hEC+vMwNny4GoYR1MfHPKONGr2sJ5UEEg/dv4Fa 1oYH5+Qr0Fw9ct2md2+kzENzhmalSUhA6HmVK5aKoGaZkFxZFXC4lf4KK0yRXouzyL/N sTfA9OITcxF84mXhN3q4brt2rcjF0E07xoEJsg+55erRte5YlIzjJN1vaMnj5W4sbpPA ilgA== X-Gm-Message-State: AMke39ngwbIsm52lRtjdRb87hZDpgLqmpNyhxOwZb2M3Tyjn6AyyFYceNky5my9bb2ACHVgDDIhCI1xJO/IDtA== X-Received: by 10.129.173.68 with SMTP id l4mr2234595ywk.351.1488559156153; Fri, 03 Mar 2017 08:39:16 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Fri, 3 Mar 2017 08:39:15 -0800 (PST) In-Reply-To: <201703031411.v23EBUdM069969@pdx.rh.CN85.dnsmgr.net> References: <20170303092143.GM4503@server.rulingia.com> <201703031411.v23EBUdM069969@pdx.rh.CN85.dnsmgr.net> From: Alan Somers Date: Fri, 3 Mar 2017 09:39:15 -0700 X-Google-Sender-Auth: L-5vPRC_iJFswuRI1uojQjdZX9Q Message-ID: Subject: Re: effect of strip(1) on du(1) To: "Rodney W. Grimes" Cc: Peter Jeremy , freebsd-hackers , Subbsd , freebsd-current Current , Ngie Cooper Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:39:17 -0000 On Fri, Mar 3, 2017 at 7:11 AM, Rodney W. Grimes wrote: > -- Start of PGP signed section. > [ Charset ISO-8859-1 unsupported, converting... ] >> On 2017-Mar-02 22:19:10 -0800, "Rodney W. Grimes" wrote: >> >> du(1) is using fts_read(3), which is based on the stat(2) information. >> >> The OpenGroup defines st_blocksize as "Number of blocks allocated for >> >> this object." In the case of ZFS, a write(2) may return before any >> >> blocks are actually allocated. And thanks to compression, gang >> ... >> >My gut tells me that this is gona cause problems, is it ONLY >> >the st_blocksize data that is incorrect then not such a big >> >problem, or are we returning other meta data that is wrong? >> >> Note that it's st_blocks, not st_blocksize. > Yes, I just ignore that digretion, as well as the digretion into fts_read > being anything special about this, as it just ends up calling stat(2) in > the end anyway. > >> >> I did an experiment, writing a (roughly) 113MB file (some data I had >> lying around), close()ing it and then stat()ing it in a loop. This is >> FreeBSD 10.3 with ZFS and lz4 compression. Over the 26ms following the >> close(), st_blocks gradually rose from 24169 to 51231. It then stayed >> stable until 4.968s after the close, when st_blocks again started >> increasing until it stabilized after a total of 5.031s at 87483. Based >> on this, st_blocks reflects the actual number of blocks physically >> written to disk. None of the other fields in the struct stat vary. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Thank you for doing the proper regression test, that satisfies me that > we dont have a lattent bug sitting here and infact what we have is > exposure of the kernel caching, which I might be too thrilled about, > is just how its gona have to be. > >> >> The 5s delay is presumably the TXG delay (since this system is basically >> unloaded). I'm not sure why it writes roughly ? the data immediately >> and the rest as part of the next TXG write. >> >> >My expectactions of executing a stat(2) call on a file would >> >be that the data returned is valid and stable. I think almost >> >any program would expect that. >> >> I think a case could be made that st_blocks is a valid representation >> of "the number of blocks allocated for this object" - with the number >> increasing as the data is physically written to disk. As for it being >> stable, consider a (hypothetical) filesystem that can transparently >> migrate data between different storage media, with different compression >> algorithms etc (ZFS will be able to do this once the mythical block >> rewrite code is written). > > I could counter argue that st_blocks is: > st_blocks The actual number of blocks allocated for the file in > 512-byte units. > > Nothing in that says anything about "on disk". So while this thing > is sitting in memory on the TXG queue we should return the number of > 512 byte blocks used by the memory holding the data. > I think that would be the more correct thing than exposing the > fact this thing is setting in a write back cache to userland. > > -- > Rod Grimes rgrimes@freebsd.org "Transparent" does not mean "undetectable". For example, ZFS's transparent compression will affect the st_blocks reported for a file. I think the only sane use of st_blocks is to treat it as advisory. I've seen a lot of bugs caused by programmers assuming a certain mathematical relationship between the numbers presented by "df", "zfs list", etc. BTW, I've confirmed that ZFS on Illumos has the same behavior. A file's st_blocks doesn't stabilize until a few seconds after you write it. And it turns out that the fsync(1) doesn't work. This suggests that ZFS doesn't consider blocks in the ZIL when it reports st_blocks. -Alan From owner-freebsd-hackers@freebsd.org Fri Mar 3 17:25:09 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3097BCF78EF; Fri, 3 Mar 2017 17:25:09 +0000 (UTC) (envelope-from allanjude@FreeBSD.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0989A1C2F; Fri, 3 Mar 2017 17:25:08 +0000 (UTC) (envelope-from allanjude@FreeBSD.org) Received: from [10.250.112.121] (unknown [209.171.88.121]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 832F2137BE; Fri, 3 Mar 2017 17:25:06 +0000 (UTC) Date: Fri, 03 Mar 2017 12:25:02 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <201703031411.v23EBUdM069969@pdx.rh.CN85.dnsmgr.net> References: <201703031411.v23EBUdM069969@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: effect of strip(1) on du(1) To: freebsd-current@freebsd.org, "Rodney W. Grimes" , Peter Jeremy CC: freebsd-hackers , Subbsd , freebsd-current Current , Ngie Cooper , Alan Somers From: Allan Jude Message-ID: <3FAE8942-2896-4EC6-95C6-D87945E57B29@FreeBSD.org> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:25:09 -0000 On March 3, 2017 9:11:30 AM EST, "Rodney W=2E Grimes" wrote: >-- Start of PGP signed section=2E >[ Charset ISO-8859-1 unsupported, converting=2E=2E=2E ] >> On 2017-Mar-02 22:19:10 -0800, "Rodney W=2E Grimes" > wrote: >> >> du(1) is using fts_read(3), which is based on the stat(2) >information=2E >> >> The OpenGroup defines st_blocksize as "Number of blocks allocated >for >> >> this object=2E" In the case of ZFS, a write(2) may return before >any >> >> blocks are actually allocated=2E And thanks to compression, gang >> =2E=2E=2E >> >My gut tells me that this is gona cause problems, is it ONLY >> >the st_blocksize data that is incorrect then not such a big >> >problem, or are we returning other meta data that is wrong? >>=20 >> Note that it's st_blocks, not st_blocksize=2E >Yes, I just ignore that digretion, as well as the digretion into >fts_read >being anything special about this, as it just ends up calling stat(2) >in >the end anyway=2E > >>=20 >> I did an experiment, writing a (roughly) 113MB file (some data I had >> lying around), close()ing it and then stat()ing it in a loop=2E This >is >> FreeBSD 10=2E3 with ZFS and lz4 compression=2E Over the 26ms following >the >> close(), st_blocks gradually rose from 24169 to 51231=2E It then >stayed >> stable until 4=2E968s after the close, when st_blocks again started >> increasing until it stabilized after a total of 5=2E031s at 87483=2E=20 >Based >> on this, st_blocks reflects the actual number of blocks physically >> written to disk=2E None of the other fields in the struct stat vary=2E > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Thank you for doing the proper regression test, that satisfies me that >we dont have a lattent bug sitting here and infact what we have is >exposure of the kernel caching, which I might be too thrilled about, >is just how its gona have to be=2E > >>=20 >> The 5s delay is presumably the TXG delay (since this system is >basically >> unloaded)=2E I'm not sure why it writes roughly ? the data immediately >> and the rest as part of the next TXG write=2E >>=20 >> >My expectactions of executing a stat(2) call on a file would >> >be that the data returned is valid and stable=2E I think almost >> >any program would expect that=2E >>=20 >> I think a case could be made that st_blocks is a valid representation >> of "the number of blocks allocated for this object" - with the number >> increasing as the data is physically written to disk=2E As for it >being >> stable, consider a (hypothetical) filesystem that can transparently >> migrate data between different storage media, with different >compression >> algorithms etc (ZFS will be able to do this once the mythical block >> rewrite code is written)=2E > >I could counter argue that st_blocks is: >st_blocks The actual number of blocks allocated for the file in > 512-byte units=2E > >Nothing in that says anything about "on disk"=2E So while this thing >is sitting in memory on the TXG queue we should return the number of >512 byte blocks used by the memory holding the data=2E >I think that would be the more correct thing than exposing the >fact this thing is setting in a write back cache to userland=2E Can we compare the results of du with du -A? Du will show compression savings, and -A wont ZFS compresses between the write cache and the disk, so the final size may= not be know for 5+ seconds --=20 Allan Jude From owner-freebsd-hackers@freebsd.org Fri Mar 3 17:30:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F79BCF7BB0; Fri, 3 Mar 2017 17:30:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D1091247; Fri, 3 Mar 2017 17:30:06 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yw0-x230.google.com with SMTP id p77so85278426ywg.1; Fri, 03 Mar 2017 09:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=d+iRaAlr7GB8t8hONouDYau+H+NT30vfNnQu1gQ3usA=; b=c+HdzOZvoMEY0YSvc3Ep6vaujp1NU4meNaTup8sPljVgbTD/3DKjZVSCQhFVFwf7de CQ6+vCWY35Pdea4XlVZEEhPqh5YBGFFfA5pTOEh/d6bHi5AnhAEI6KLU4tfFl2WrmEvW PqTp4+ppXikKaxcxiPD2atRF5TcoygwLJZVfg22Xqaw18ralnXGsiiJ4aOJh8d1WHlk0 HZx6t0jH7ZiycJ+c03g5XohDtP3qCDZ2xTUeS5p+ajVQEFgofOP4Afub+T+9SSCjnate RFckrdTzfPRczo7APa1G0/pON58eVhaxXLCciOsFYz3lvGywcTGb89/iMUmJB2ckhHGJ 4Ehg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=d+iRaAlr7GB8t8hONouDYau+H+NT30vfNnQu1gQ3usA=; b=UmB87OInySyWGiQ1P3l2ZjqbFYX/MoaRR7JIQA2CvQ6CLuTGVloPHvK797wqI2nXVF K8PeTFA3e9EkI88kbMpp4d5QuHbusFvT1q7ovJ/4u/olhh2ZyDO6V2mDK/vHLsbiq0jO b3ip8NWCpVu4cxOr/Vfp+s49g2+MJWprhpHjgaCGH9Q7FW40hPfffMC1rLOKNEgR6ML7 tLlH1hnjnu6w/RErt2h7NXx6vvUj7LLC/X6uiklrBMY0WMSdJfxYkkqg0nsUxXVG2cNM zQ+PEZazyOGaAoi8U/ANOz1EjmcrLnedannuP2qMm4oOUBP+orR+/5uJknDnS0mXaWNZ 31OA== X-Gm-Message-State: AMke39mUd94L/lRyuH2ZgKVrMsn4/j4HtQxHgBfMDGJbAB3KvNcdk2Edl5tDDetXxHMT8725BxUeacM9OZdpvg== X-Received: by 10.37.34.9 with SMTP id i9mr2705913ybi.92.1488562205235; Fri, 03 Mar 2017 09:30:05 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.38.133 with HTTP; Fri, 3 Mar 2017 09:30:04 -0800 (PST) In-Reply-To: <3FAE8942-2896-4EC6-95C6-D87945E57B29@FreeBSD.org> References: <201703031411.v23EBUdM069969@pdx.rh.CN85.dnsmgr.net> <3FAE8942-2896-4EC6-95C6-D87945E57B29@FreeBSD.org> From: Alan Somers Date: Fri, 3 Mar 2017 10:30:04 -0700 X-Google-Sender-Auth: aTaLcPwKtYfullDuYFopcd_3uf8 Message-ID: Subject: Re: effect of strip(1) on du(1) To: Allan Jude Cc: FreeBSD CURRENT , "Rodney W. Grimes" , Peter Jeremy , freebsd-hackers , Subbsd , Ngie Cooper Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:30:06 -0000 On Fri, Mar 3, 2017 at 10:25 AM, Allan Jude wrote: > On March 3, 2017 9:11:30 AM EST, "Rodney W. Grimes" wrote: >>-- Start of PGP signed section. >>[ Charset ISO-8859-1 unsupported, converting... ] >>> On 2017-Mar-02 22:19:10 -0800, "Rodney W. Grimes" >> wrote: >>> >> du(1) is using fts_read(3), which is based on the stat(2) >>information. >>> >> The OpenGroup defines st_blocksize as "Number of blocks allocated >>for >>> >> this object." In the case of ZFS, a write(2) may return before >>any >>> >> blocks are actually allocated. And thanks to compression, gang >>> ... >>> >My gut tells me that this is gona cause problems, is it ONLY >>> >the st_blocksize data that is incorrect then not such a big >>> >problem, or are we returning other meta data that is wrong? >>> >>> Note that it's st_blocks, not st_blocksize. >>Yes, I just ignore that digretion, as well as the digretion into >>fts_read >>being anything special about this, as it just ends up calling stat(2) >>in >>the end anyway. >> >>> >>> I did an experiment, writing a (roughly) 113MB file (some data I had >>> lying around), close()ing it and then stat()ing it in a loop. This >>is >>> FreeBSD 10.3 with ZFS and lz4 compression. Over the 26ms following >>the >>> close(), st_blocks gradually rose from 24169 to 51231. It then >>stayed >>> stable until 4.968s after the close, when st_blocks again started >>> increasing until it stabilized after a total of 5.031s at 87483. >>Based >>> on this, st_blocks reflects the actual number of blocks physically >>> written to disk. None of the other fields in the struct stat vary. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>Thank you for doing the proper regression test, that satisfies me that >>we dont have a lattent bug sitting here and infact what we have is >>exposure of the kernel caching, which I might be too thrilled about, >>is just how its gona have to be. >> >>> >>> The 5s delay is presumably the TXG delay (since this system is >>basically >>> unloaded). I'm not sure why it writes roughly ? the data immediately >>> and the rest as part of the next TXG write. >>> >>> >My expectactions of executing a stat(2) call on a file would >>> >be that the data returned is valid and stable. I think almost >>> >any program would expect that. >>> >>> I think a case could be made that st_blocks is a valid representation >>> of "the number of blocks allocated for this object" - with the number >>> increasing as the data is physically written to disk. As for it >>being >>> stable, consider a (hypothetical) filesystem that can transparently >>> migrate data between different storage media, with different >>compression >>> algorithms etc (ZFS will be able to do this once the mythical block >>> rewrite code is written). >> >>I could counter argue that st_blocks is: >>st_blocks The actual number of blocks allocated for the file in >> 512-byte units. >> >>Nothing in that says anything about "on disk". So while this thing >>is sitting in memory on the TXG queue we should return the number of >>512 byte blocks used by the memory holding the data. >>I think that would be the more correct thing than exposing the >>fact this thing is setting in a write back cache to userland. > > Can we compare the results of du with du -A? > > Du will show compression savings, and -A wont > > ZFS compresses between the write cache and the disk, so the final size may not be know for 5+ seconds > -- > Allan Jude "du -A" does what you would expect. It instantly reports the apparent size of the file. For incompressible files, this is actually less than what "du" reports, because it doesn't take into account the znode and indirect blocks. -Alan From owner-freebsd-hackers@freebsd.org Fri Mar 3 17:31:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B57CCF7E97 for ; Fri, 3 Mar 2017 17:31:44 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by mx1.freebsd.org (Postfix) with ESMTP id F236B197D for ; Fri, 3 Mar 2017 17:31:43 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 102E5175DE; Fri, 3 Mar 2017 09:31:44 -0800 (PST) Date: Fri, 3 Mar 2017 09:31:43 -0800 From: hiren panchasara To: Sebastian Huber Cc: FreeBSD Subject: Re: Mailing list for network interface driver patches? Message-ID: <20170303173143.GN58601@strugglingcoder.info> References: <58B95F18.7040004@embedded-brains.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NKtYx2Ppz7d1tORf" Content-Disposition: inline In-Reply-To: <58B95F18.7040004@embedded-brains.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 17:31:44 -0000 --NKtYx2Ppz7d1tORf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 03/03/17 at 01:18P, Sebastian Huber wrote: > Hello, >=20 > what is the right mailing list for network interface driver patches? Is= =20 > this freebsd-drivers or freebsd-net? Best would be to open a bug at https://bugs.freebsd.org/bugzilla/ against 'base system' with patch and someone would triage and assign it to freebsd-net (thats where we usually discuss such things). Cheers, Hiren --NKtYx2Ppz7d1tORf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJYuah9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lvyUH/iyVIDsCT9obA+6rd+5leOZY AW+Udiju79MxEr1wFWNSrKK72tztpShs9sepcz8gI1abDPXdjfBnNUlsOzZmrqsm 5Yy5YA2p58TWRL1YLyX5tl/vGSq8s/2DP+fzqXZGmHNY48hIChLFw0vhus8R8Vh6 IWqqawGIkiQ3lyzD8+ZVIiiEZIqo/Oiu+aSPdZGj0N8ij2vbVr+OrRRUDD0N2gQB w4w+/V3Eyl7D7Kqe9zfdnkT6Q0RHKftn08DzurxEdRq5zo7r7T1IBERZ2xyPN6Qh TusZFL7Gw0/QLWGdyOa3GHMHCKaHPPRZzapI4Gpi9NYwQ9UphtOJ/TYG6XPq5QM= =khH8 -----END PGP SIGNATURE----- --NKtYx2Ppz7d1tORf-- From owner-freebsd-hackers@freebsd.org Fri Mar 3 20:15:00 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 727A0CF7DFC for ; Fri, 3 Mar 2017 20:15:00 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 52C841617 for ; Fri, 3 Mar 2017 20:15:00 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4F4C4CF7DFB; Fri, 3 Mar 2017 20:15:00 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EF98CF7DFA for ; Fri, 3 Mar 2017 20:15:00 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 12BB51616 for ; Fri, 3 Mar 2017 20:14:59 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: by mail-ua0-f169.google.com with SMTP id f54so127212660uaa.1 for ; Fri, 03 Mar 2017 12:14:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=1Td1An3QccO0f9M73mw/O0VhCy5nx4g3v4vcl129Veg=; b=svRoKcw5cFzSx+C0dvNmvgZOIIB//Wb73shoUsRQdZ/n5N+kHXG0TqPLIab6xxN1XX Oj2u20QLbv4ewooQ0OzfAipn3ZmxDW5y6wr0kvSW9ZYpA16jdTCeEWvjRS3/qtfCcnEm NU7JKXHVIjXrU53AQSFyAdyUCw9WF1jeKDhgNWQtcYhPm3IBNOcW9+JP+zeq6NV0GIap 8Bh8QrA2+JLlYXllUanJ9D8pMLCs4PmbYTfzug5b9Rw5rYFhenZPTgUVHqsxIDr26FDH bLMp+huIiSz82bp2i9i9HheCcE/YxHv7k1ysugdv2LQfhUo7K+i29H2tH1rejB4ERNqR /PGg== X-Gm-Message-State: AMke39l46/xOLHOhIZtouWAIScX1OazjCTiRID8zew3m1ZcZiLxD1v5vKTFXet1WjGwdIA== X-Received: by 10.176.82.93 with SMTP id j29mr2082572uaa.57.1488572093169; Fri, 03 Mar 2017 12:14:53 -0800 (PST) Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com. [209.85.217.170]) by smtp.gmail.com with ESMTPSA id x32sm3134657uab.31.2017.03.03.12.14.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 12:14:53 -0800 (PST) Received: by mail-ua0-f170.google.com with SMTP id q7so92326828uaf.2 for ; Fri, 03 Mar 2017 12:14:52 -0800 (PST) X-Received: by 10.31.148.71 with SMTP id w68mr1460283vkd.87.1488572092675; Fri, 03 Mar 2017 12:14:52 -0800 (PST) MIME-Version: 1.0 Reply-To: mmokhi@freebsd.org Received: by 10.103.75.136 with HTTP; Fri, 3 Mar 2017 12:14:52 -0800 (PST) From: Mahdi Mokhtari Date: Fri, 3 Mar 2017 23:44:52 +0330 X-Gmail-Original-Message-ID: Message-ID: Subject: Some questions about kernel stuffs (namei, and AUDIT_ARG, ...) To: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 20:15:00 -0000 Hi hackers@ I'm working on implementing and completing Linuxulator syscalls with helps of trasz@ and dchagin@ (and learning more about it on this way ;-D). In middle of this way, I'm implementing execveat() natively for FreeBSD to use it for Linuxulator (yeah dogfooding ;]]) I encountered to some questions and I'm told here is the place to ask :-) I'd like to know the difference between `AUDIT_ARG_ATFD1` and `AUDIT_ARG_ATFD2`, when I should use which (for a syscall for example)? Also, Should I free the name buffer I get from `namei()` after `NDINIT_ATRIGHTS()` myself? (like what I do on `vput(node)`)? P.S. Actually namei() man page is too short to explain the API very well (at least for me, well I'm not native English speaker '':-D), so any hints/extra resources is appreciated __/|\__ -- Best regards, MMokhi. From owner-freebsd-hackers@freebsd.org Fri Mar 3 21:15:37 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E9E4CF71FB for ; Fri, 3 Mar 2017 21:15:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3C31ADA for ; Fri, 3 Mar 2017 21:15:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 6ABF8CF71FA; Fri, 3 Mar 2017 21:15:37 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A674CF71F9 for ; Fri, 3 Mar 2017 21:15:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1A71AD9; Fri, 3 Mar 2017 21:15:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id 6A9B446B91; Fri, 3 Mar 2017 16:15:31 -0500 (EST) Date: Fri, 3 Mar 2017 21:15:31 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Mahdi Mokhtari cc: hackers@freebsd.org Subject: Re: Some questions about kernel stuffs (namei, and AUDIT_ARG, ...) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 21:15:37 -0000 Hi Mahdi: The kernel audit(4) framework captures system-call arguments and return values to include in audit records. You can read about the details in the FreeBSD D+I book. Each record can carry information about two file/socket/... arguments. AUDIT_ARG_ATFD1() optionally records the first of those arguments, and AUDIT_ARG_ATFD2() optionally records the second one. Similarly, AUDITVNODE1 records information about the first vnode, and AUDITVNODE2 the second. execveat(2) presumably takes one file-descriptor argument, so you should use AUDIT_ARG_ATFD1() to capture that single argument. Robert On Fri, 3 Mar 2017, Mahdi Mokhtari wrote: > Hi hackers@ > I'm working on implementing and completing Linuxulator syscalls > with helps of trasz@ and dchagin@ > (and learning more about it on this way ;-D). > > In middle of this way, I'm implementing execveat() natively > for FreeBSD to use it for Linuxulator (yeah dogfooding ;]]) > > I encountered to some questions and I'm told here is the place to ask :-) > I'd like to know the difference between `AUDIT_ARG_ATFD1` and > `AUDIT_ARG_ATFD2`, > when I should use which (for a syscall for example)? > > Also, Should I free the name buffer I get from `namei()` after > `NDINIT_ATRIGHTS()` myself? (like what I do on `vput(node)`)? > > P.S. Actually namei() man page is too short to explain the API very well > (at least for me, well I'm not native English speaker '':-D), > so any hints/extra resources is appreciated __/|\__ > > -- > Best regards, MMokhi. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:17:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5616CF7CF4 for ; Fri, 3 Mar 2017 22:17:38 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 868DD1991 for ; Fri, 3 Mar 2017 22:17:37 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.204] (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v23MCMIk007490 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 3 Mar 2017 23:12:22 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be [10.11.0.204] From: Dirk-Willem van Gulik Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: kill -0 --- side effect or supported Message-Id: <23F3BAC3-0D8B-4290-8DC2-818D67A0B6A9@webweaving.org> Date: Fri, 3 Mar 2017 23:12:26 +0100 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Fri, 03 Mar 2017 23:12:22 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:17:39 -0000 I regularly use 'kill -0 ' on FreeBSD as a way to test if a = certain process is still running (but without actually sending the = signal). And I think it has worked reliably since the mid 80's. Is it actually a properly supported use - as I recently happened to = notice that it does not seem to be all that documented in kill( Dw. From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:22:06 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F2D8CF7F07 for ; Fri, 3 Mar 2017 22:22:06 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A69591D82 for ; Fri, 3 Mar 2017 22:22:05 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr0-x22d.google.com with SMTP id l37so82554036wrc.1 for ; Fri, 03 Mar 2017 14:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hNxf8bBNOCJqGReRshm6ZZlLtPOQR9u3zrLz43avrT4=; b=dzZ6uWUoTaVZjdiwLZVh4Wm7sJe1U3eDm4W7InlYMVcCJz+NT5QzEY/enP9yCNH+3S Xosu67FPnC2wrPCRLKE5hHsJ5+kEo5Tf1NYNV8SQQHGLXxKYQA8fxlekkvk7DimRwOYz Qv3BQUR1PVNQ2cnDcRWo1yCp5wetN7K9phqAfuLskdfUp10GcIyhI9p6t4CqbxVIeqat LwAfEp0TcccYz8zeUnQ+us4o11Ma9xUrtExOyzlxV1652aNQ2hSHNypxAvzCdCiQ5ErP FBDHt4/NOsKkmrrC5KbBM9+Ak7SCFkb8P8lXwvLNtBvx2JB7nHqIzro4diyvBm74QpQ7 9tCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=hNxf8bBNOCJqGReRshm6ZZlLtPOQR9u3zrLz43avrT4=; b=NyzN9RSfVW7DNhQGCP+0J9e+D2jr6t76zIwHvV5ha6cOmT/4Ke4MBAr5gKPkRmb3Ja Mhur9kbxkZ4vqFSKMznS9SIy1E2suRotoJaR29tzsbLO/f03CM9B+34PdrM/6BAZKbg4 fZjLCm7zV/9gxXtjDekymbeNLtHnJ6+BIfEwMtqkRZrIPvYWJvOdkwU0CZE9MU1E4KYZ MLLjQ+aMIboVhK6Bi2SsaTojt0aB+afDG3fXMiPD088j/HULqYZ8OfSF/LDum0uhYHuW WHULh+zWk2aHTEcKsfSHZtwOq6e0bcPbYFR9Ce03ZGPVVOwbGrR/L/PRPYu7SZY4PwgA SB4g== X-Gm-Message-State: AMke39mkSni09E1KGBmUICd3OzjV7Ew2azG4K8tm3CUhj6aJQLvhMc85eSUXprRluXrf0Q== X-Received: by 10.223.172.135 with SMTP id o7mr3975108wrc.121.1488579723105; Fri, 03 Mar 2017 14:22:03 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id x25sm16833812wrx.27.2017.03.03.14.22.02 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 03 Mar 2017 14:22:02 -0800 (PST) Date: Fri, 3 Mar 2017 23:22:00 +0100 From: Mateusz Guzik To: Dirk-Willem van Gulik Cc: freebsd-hackers@freebsd.org Subject: Re: kill -0 --- side effect or supported Message-ID: <20170303222159.GA24794@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Dirk-Willem van Gulik , freebsd-hackers@freebsd.org References: <23F3BAC3-0D8B-4290-8DC2-818D67A0B6A9@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <23F3BAC3-0D8B-4290-8DC2-818D67A0B6A9@webweaving.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:22:06 -0000 On Fri, Mar 03, 2017 at 11:12:26PM +0100, Dirk-Willem van Gulik wrote: > I regularly use 'kill -0 ' on FreeBSD as a way to test if a certain process is still running (but without actually sending the signal). And I think it has worked reliably since the mid 80's. > > Is it actually a properly supported use - as I recently happened to notice that it does not seem to be all that documented in kill( > The signal 0 is mostly used to check if you can deliver signals in the first place. The problem with 'is alive?' checks with this mechanism is that zombies eat up any signal sent, including 0. For a shell script this may be good enough, but chances are you want to invest into something which actually tracks children as opposed to just dropping pidfiles. -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:23:24 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF39BCF7FBC for ; Fri, 3 Mar 2017 22:23:24 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E0E81F0B for ; Fri, 3 Mar 2017 22:23:24 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.204] (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v23MM5UT007821 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 3 Mar 2017 23:22:05 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be [10.11.0.204] From: Dirk-Willem van Gulik Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: sa and mpt in FreeBSD 11.0-RELEASE-p2 Date: Fri, 3 Mar 2017 23:22:09 +0100 References: <20170220205621.GA14597@mithlond.kdm.org> <9A1C3971-0614-4E7C-9A99-C40346D794CB@webweaving.org> <20170221204551.GA32056@mithlond.kdm.org> <89CFE344-6D31-4E72-A79A-3DB638D5D8AC@webweaving.org> To: "Kenneth D. Merry" , freebsd-hackers@freebsd.org In-Reply-To: <89CFE344-6D31-4E72-A79A-3DB638D5D8AC@webweaving.org> Message-Id: <5DC8B4FC-71BD-4218-9209-1D52A47AA1CB@webweaving.org> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Fri, 03 Mar 2017 23:22:05 +0100 (CET) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:23:24 -0000 On 21 Feb 2017, at 21:45, Kenneth D. Merry wrote: >=20 > On Tue, Feb 21, 2017 at 18:15:06 +0100, Dirk-Willem van Gulik wrote: >>=20 >>> On 20 Feb 2017, at 21:56, Kenneth D. Merry wrote: >>>=20 >>> On Mon, Feb 20, 2017 at 21:04:11 +0100, Dirk-Willem van Gulik wrote: >>>> A machine, recently upgraded from 8.4 to FreeBSD 11.0-RELEASE-p2 = seems to have lost pretty much any and all performance on mpt(4) with = its attached tape drives >>>>=20 >>>> Read performance is around 50Mbyte/second - and write a paltry = 100-200kbyte/second (and occasionally hitting 800kbyte/second) (from/to = memory disk&/dev/null; no risk of shoe shining, compression off). >>>>=20 >>>> SCSI bus looks happy; with no kernel messages. Output of the DLT = script below. >>>>=20 >>>> Normal LTO drives in a tape robot, G9 server; pretty much all SAS = *except* for a U320 to tape drive with the performance issue. Active = terminator. >>>>=20 >>>> Does this ring a bell with anyone? Was anything changed in either = the sa or mpt driver since 8.x ?=20 >>>>=20 >>>> One odd thing is that a 'dd(1)' -without- a block size (compression = is off, data is a prepared urandom file on md disk) writes much faster = -- while on 8.x one -had- to use a sane blockwise to get the 'normal' = speed of around 120Mbyte/second. Could it be that one needs to fiddle = with MAXPHYS (which AFAIK is a readonly sysctl). >>>>=20 >>>=20 >>> What blocksize are you using? What blocksize were you using before? = What >>> application do you normally use to talk to the tape drive? >>=20 >> Amanda (or plain DD); we increased Amanda???s default of 32 to 64k = (which stopped any and all shoe shining at that time. It was tested in = 2013 (so likely in FreeBSD 8) up to 16 Mbyte in factors of 2 according = to our notes - but with no further improvements in performance - and = left at 64k). >>=20 > This tells me that Amanda is keeping the tape driver well supplied = with > I/O. Since 64K was probably the blocksize going down to the hardware > previously, it makes sense that increasing it in Amanda didn't make a > difference. Ok. clear. Thanks. ! >=20 >> The actual drive (mt status -v) reports (prior to increasing MAXPHYS) = on 11.0-p2 with default kernel config: >>=20 >>> Drive: sa0: Serial Number: HU1027B53Y >>> --------------------------------- >>> Mode Density Blocksize bpi Compression >>> Current: 0x46:LTO-4 variable 323215 enabled (0x1) >>> --------------------------------- >>> Current Driver State: at rest. >>> --------------------------------- >>> Partition: 0 Calc File Number: 0 Calc Record Number: 0 >>> Residual: 0 Reported File Number: 0 Reported Record Number: 0 >>> Flags: BOP >>> --------------------------------- >>> Tape I/O parameters: >>> Maximum I/O size allowed by driver and controller (maxio): 131072 = bytes >>> Maximum I/O size reported by controller (cpi_maxio): 131072 bytes >>> Maximum block size supported by tape drive and media (max_blk): = 16777215 bytes >>> Minimum block size supported by tape drive and media (min_blk): 1 = bytes >>> Block granularity supported by tape drive and media (blk_gran): 0 = bytes >>> Maximum possible I/O size (max_effective_iosize): 131072 bytes >>=20 >> ???. >>> If you want to re-enable I/O splitting (which I should have disabled = by >>> now), you can set the following loader tunable in /boot/loader.conf: >>>=20 >>> kern.cam.sa.allow_io_split=3D1 >>=20 >> Ok - this changes behaviour - non-blocksized limited writes are now = up; 2Mbyte/second; any block-sized write is 200kb/second (regardless of = bs). >>=20 >>> If so, you probably want to look at the blocksize you're using, and = bump up >>> MAXPHYS in your kernel configuration to a larger value. >>=20 >> Post MAXPHYS & DFLTPHYS increase to 4MB (4x1024x1024) (as 16MB caused = the kernel to hang during boot just post usb/knd - likely as it is there = that it starts on SAS disk & tape discovery) I get >> as ???mt status -v??? the output: >>=20 >>> Tape I/O parameters: >>> Maximum I/O size allowed by driver and controller (maxio): 1372160 = bytes >>> Maximum I/O size reported by controller (cpi_maxio): 1372160 bytes >>> Maximum block size supported by tape drive and media (max_blk): = 16777215 bytes >>> Minimum block size supported by tape drive and media (min_blk): 1 = bytes >>> Block granularity supported by tape drive and media (blk_gran): 0 = bytes >>> Maximum possible I/O size (max_effective_iosize): 1372160 bytes >>=20 >>=20 >> And see the same speeds; non blocksize limited (with dd) are = 2.7Mbyte/second (so slightly higher); the blocksized writes are better = (but still) low; 200kbyte/second for 16k, 600k for 32k, 800k for 64k, = 500k for 128k, 1M at 256k, 1M at 1024k. The writes at 2048k and 4096k = fail with a ???hardware failure asc:44,0 ??? tape is now frozen??? = error). >>=20 >> This is with `kern.cam.sa.allow_io_split=3D1??? in = /boot/loader.conf???. Doing so without that (after a reboot) give = substantially similar results: (1.8Mbyte/second (0), 450k (16k), 560k = (32k), 0.9M (64), 560k (128k), 730k (256k) and 600k (1M) ??? it fairly = errors out with a si_iosize_max=3D1372160 for sizes above that. >>=20 >=20 > The fact that you're getting substantially higher performance with I/O > splitting enabled points to probable delays in getting the data into = the > kernel. >=20 > Instead of doing a single threaded read/write dd test, I would suggest > doing something like this: >=20 > dd if=3Dinputfile bs=3D10m | dd of=3D/dev/nsa0 bs=3D1m This does not change the numbers at all (with a PHYSMEM=3D4M, = kern.cam.sa.0.*maxio reporting 1372160 and with or without splitting). We've also tried a different SCSI card (albeit also an LSI one - so also = mpt(4)); which gives near idential numbers - around 600k.=20 > Also, the fact that you're getting a hardware failure with larger = writes > may mean that the tape drive might not support what it claims to. The > hardware failure is probably coming from the tape drive. Do we've downgraded the machine back to FreeBSD 8.4-- and tested the = same setup against the same drive. That gave us normal LTO4 speeds. We = tried two mpt cards and one adaptec card. I guess that suggest it is not a drive, card or cable issue.=20 However we are seeing a difference in the output of the pciconf command = with respect to the busses and order of the cards detected; and see an = adaptec card work fine in both 8.4 and 11.0-p7 (and the adaptec cards = are reported identical ordered). So this may well be sa(4) unrelated - but PCI or LSI card specific. But thanks to your help - we do have a working solution (and able to rid = the last machines off LTO3 and LTO4). Thanks! Dw From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:23:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD480CF7FF3 for ; Fri, 3 Mar 2017 22:23:39 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A5B41FE1 for ; Fri, 3 Mar 2017 22:23:39 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf0-x22b.google.com with SMTP id w189so37130980pfb.0 for ; Fri, 03 Mar 2017 14:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=95zFBnbnrt3Puv5KlnbJByxkWvRWDW9kQD5ge1jvwfM=; b=vC6KbNisDzsbXpdxQXCYmyB6YAhRhOJWd/FWtjutCKVcbizZmkkuUM/8OEZ4eg1//e FJI+WnSWxrQ60R9do79ZdNJSud7deKbMrEJm8i1BJGVGmDqIWaCjPXatA73PkW9PL3Vt i5vca/aISifloINLu2AxdSGig8nNYC0MymjLhBfWZicheWMgQOSXbKBCo3CGyz00dBAk hoB7SD3YANFzWBZme2D4UHD5jQWLr0PbPlCvbf5iOe1ynZqcMCFzUPKvJjyLDVjYGZJ+ ytzVghjUpoFLHyfLe8Oq3rQYEqpFxTlqqRHWg/aYEGa1JkRki6p8Kx+jzLy2+8HfxuOW mOTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=95zFBnbnrt3Puv5KlnbJByxkWvRWDW9kQD5ge1jvwfM=; b=GGCASmMB22TkfXxyP2LCP/05H1gjKo7Qj1qV0T9Fxt0lGyCaOvNdNASEeew7EbX2D+ hdlPTdRqo/F0qGnHGzMr6eBYw9MoqJlL1WBhMpG1QxBbc5t9hvzFQ+pvlffncmU8wJIo ecm8iS6FrDr3VqxGvL2iQrPH0m3PTyGQ37VvbGHtlvY9Y9us40G1s+h9NAauaeQd2dEl hc/QBQUUHlrAbf1y1Wp/3ggX1ZT173+KCLcZAvkjW2aEqjtw/GR62mUryjay1SFfRL3I AUYCGVVrdAuAxa7xTqLZKL4OxxxQCeye/i3pC/p2T/l7NC/swZud0v27znnMEwnFAMm8 JLoA== X-Gm-Message-State: AMke39lcsVj4UnQfRkL2bgNAtv6xjNcgxq8Q4W/Jr8oiL49+SBA5si4F9bsxGtO8j2ZUDw== X-Received: by 10.99.115.68 with SMTP id d4mr5747327pgn.146.1488579819170; Fri, 03 Mar 2017 14:23:39 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id m12sm25416842pgc.46.2017.03.03.14.23.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Mar 2017 14:23:38 -0800 (PST) Subject: Re: kill -0 --- side effect or supported Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B6209A18-6EFA-43A5-9E7A-668EBE964B54"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <23F3BAC3-0D8B-4290-8DC2-818D67A0B6A9@webweaving.org> Date: Fri, 3 Mar 2017 14:23:37 -0800 Cc: freebsd-hackers@freebsd.org Message-Id: <11A4B6AB-E51D-4754-8E80-4503687E0F84@gmail.com> References: <23F3BAC3-0D8B-4290-8DC2-818D67A0B6A9@webweaving.org> To: Dirk-Willem van Gulik X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:23:39 -0000 --Apple-Mail=_B6209A18-6EFA-43A5-9E7A-668EBE964B54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 3, 2017, at 14:12, Dirk-Willem van Gulik = wrote: >=20 > I regularly use 'kill -0 ' on FreeBSD as a way to test if a = certain process is still running (but without actually sending the = signal). And I think it has worked reliably since the mid 80's. >=20 > Is it actually a properly supported use - as I recently happened to = notice that it does not seem to be all that documented in kill( It better work. I have code that relies on it :)=E2=80=A6 It does work as you noted, according to truss: # sudo truss -ff kill -0 1 2>&1 ... 79940: kill(1,0) =3D 0 (0x0) =E2=80=A6 # As noted in kill(2), this is one of the valid values: a group of processes. The sig argument may be one of the signals specified in sigaction(2) or it may be 0, in which case error = checking is performed but no signal is actually sent. This can be used to = check the validity of pid. So, the manpage for kill(1) is just lacking in the sense that -0 is = supported. Cheers! -Ngie --Apple-Mail=_B6209A18-6EFA-43A5-9E7A-668EBE964B54 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYuezpAAoJEPWDqSZpMIYVy1QP/i03Kw+09Ofra9eOH/kjjFd8 IvSTEvV8AQDYRTpqSWFw+IX0zRKe7U6kh/eBJohRZz9s/V9oA2E7WVI7rpW20Coo F/ft3Pot+5svUcr55i0kX0qVzbo2Gx/Jyna0oU5t/jmNNhWCfew/oYAZtZI/2/+O vSancpX5oFHa6I934mFjb1a9e0w9iiTTFp29xEMmsKZbkU1vNC5pLZY5tQuyI64k x0zT4JhDSPIUL1Ab62AJJWCVdtB4ZUgCFu2BqftLFzl5NEnh5u0luFteKTqzsYZX VSp+teCs2CzXAdBdWiQUQtvp4bqja5TerUdq6CfMmt3Z4HyWQ7aW0M4mmkCLAWfn bGPNtdo+yqmE9apNZDVoPbU+H8jCcHhjeogdSBqDFPL4j4lRYC9QWfIEwb2DrYGw OTL6mRnbJYE6Gh9gRlREpyMRMCH+fk8YkKkmx6gYAY07FFwC/wATl8JU1i0FdSit yBh14HApI0GhUXnXyZWadPYKa/KvuUviMV5Ot/DNCxIa+Vx5qJ6agAQRtQBdPF9n kAw4qCInQyVfoyq3BbbZpZUOOnNLazdJzv9AqF8yKvDMmv0+SmMXie43e16ia1hI bDUDU2h1u50qOTj9D3kRNZITfM6r0fTo8qnvXLsHUg37DZadBMSE1aK8GpNLj8wU XbYjgKp8uAy28GpyKb+/ =AyPk -----END PGP SIGNATURE----- --Apple-Mail=_B6209A18-6EFA-43A5-9E7A-668EBE964B54-- From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:36:10 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 582E3CF645C for ; Fri, 3 Mar 2017 22:36:10 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.webweaving.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDE5316EC for ; Fri, 3 Mar 2017 22:36:09 +0000 (UTC) (envelope-from dirkx@webweaving.org) Received: from [10.11.0.204] (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v23MYpKm008125 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 3 Mar 2017 23:34:52 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be [10.11.0.204] From: Dirk-Willem van Gulik Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: PCI speed Message-Id: <03745A05-DE0E-4071-B432-BFE58C3A7E16@webweaving.org> Date: Fri, 3 Mar 2017 23:34:56 +0100 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Fri, 03 Mar 2017 23:34:52 +0100 (CET) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:36:10 -0000 Forgive me my ignorance - but for some cards - pciconf(8) nicely lists = the speed of the bus: > ciss0@pci0:12:0:0: class=3D0x010400 card=3D0x3243103c = chip=3D0x323a103c rev=3D0x01 hdr=3D0x00 ... > cap 10[70] =3D PCI-Express 2 endpoint max data 128(256) RO NS > link x4(x8) speed 5.0(5.0) > cap 11[ac] =3D MSI-X supports 16 messages, enabled > Table in map 0x10[0x1c2000], PBA in map = 0x10[0x1c4000] > PCI-e errors =3D Correctable Error Detected > Fatal Error Detected > Unsupported Request Detected and that matches exactly with what it is. While for other cards it does = not seem to report that: > mpt4@pci0:7:8:1: class=3D0x010000 card=3D0x10b01000 = chip=3D0x00301000 rev=3D0x08 hdr=3D0x00 .... > cap 01[50] =3D powerspec 2 supports D0 D1 D2 D3 current D0 > cap 05[58] =3D MSI supports 1 message, 64 bit > cap 07[68] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 8 = split transactions > cap 00[70] =3D unknown and in fact seems to mis report the bus - this is a PCIe Gen 2 x4 bus = with a x8 Connector Width holding a LSI 22320SE Ultra320 SCSI dual channel PCIe X4 card. How should one interpret this ? Dw. From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:42:42 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1779CF683D for ; Fri, 3 Mar 2017 22:42:42 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE1AF1C48 for ; Fri, 3 Mar 2017 22:42:42 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x241.google.com with SMTP id s67so13865315pgb.1 for ; Fri, 03 Mar 2017 14:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=cnpOiK1ytIKRimUN65Ll4j45j/e2JW3Q5K0Rd5WGhrk=; b=BFYvhjxgoiZa7ETiHOm6BwSJbgYbm45a8VtiY9Y4Cfl88CuNdkC5zWLuu63hw412OF xnfyhejeBH0VGnwAbkWiAGWlyIv1c6PwlL9N9OZHrr0YU7oqsxsWnz7HU5NhzB80ARhC t0Ymu2u2RjaympWAZwifvvr4e48+chT361YLsBD/CoKJi5xvECm6bLknTk8mat/NWbYD 1lTE8LM5MXLY1bM4aDkB7dffLMpwiOQWy1i0rWVKnMdV9RFuWoJF2UYC4PcWEBiHBiWI AjdueAj2ZCVPhWeyhdtwbmTwI0ERmTWJRVZX2KG2U9f2qDsFdGlSW524QavesvJMXZlX 8ntw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=cnpOiK1ytIKRimUN65Ll4j45j/e2JW3Q5K0Rd5WGhrk=; b=pN5x/4/I5e3tkgpDwb2gh4bxuDBw3weQGPJ4qvfmbVK9gZFeltZ+AAwoetBIho1QoI rBswMih+jlSDIMxkP/jHJISlyCcw5H94TlA1hD/M+FAmSAHAz1Zorr66c/BKiBDsfOfK zGenIVNvUHmeap0OoIMWEsotedkpBnqx9p0D4aCJUgZzqB0/mVsHjhfaPkjNEHhJicVd 2LWlQXHnhDkpVbctjbvBGjpcj8tYaSnJ8b5dyG3gbT5SQEhh9TXc5VgBDxVjdCBMjxOw skY6Oh2F/KRuQTu4M5DZaVwbMo8+QWfEQLULag6OkpNIBhhhgdWTANvA0UTZzACaXcdQ tKmw== X-Gm-Message-State: AMke39kEXukKIDR2Vf6N9dOKoO/UI0JYKBv44pvf7eVkEcgK09sEvdX7sW4ApKW2w997+w== X-Received: by 10.99.144.73 with SMTP id a70mr6222405pge.187.1488580962039; Fri, 03 Mar 2017 14:42:42 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id e13sm25433344pgf.48.2017.03.03.14.42.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Mar 2017 14:42:41 -0800 (PST) Subject: Re: kill -0 --- side effect or supported Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1FCA6944-FF7B-4140-99D2-CE5A1AACB067"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <201703032230.v23MUg5b072955@pdx.rh.CN85.dnsmgr.net> Date: Fri, 3 Mar 2017 14:42:40 -0800 Cc: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org Message-Id: <35C6F2AA-309E-4D58-8191-AB99F0195BEC@gmail.com> References: <201703032230.v23MUg5b072955@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:42:43 -0000 --Apple-Mail=_1FCA6944-FF7B-4140-99D2-CE5A1AACB067 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 3, 2017, at 14:30, Rodney W. Grimes = wrote: >=20 > -- Start of PGP signed section. > [ Charset UTF-8 unsupported, converting... ] >>=20 >>> On Mar 3, 2017, at 14:12, Dirk-Willem van Gulik = wrote: >>>=20 >>> I regularly use 'kill -0 ' on FreeBSD as a way to test if a = certain process is still running (but without actually sending the = signal). And I think it has worked reliably since the mid 80's. >>>=20 >>> Is it actually a properly supported use - as I recently happened to = notice that it does not seem to be all that documented in kill( >>=20 >> It better work. I have code that relies on it :)? >>=20 >> It does work as you noted, according to truss: >>=20 >> # sudo truss -ff kill -0 1 2>&1 >> ... >> 79940: kill(1,0) =3D 0 (0x0) >> ? >> # >>=20 >> As noted in kill(2), this is one of the valid values: >>=20 >> a group of processes. The sig argument may be one of the signals >> specified in sigaction(2) or it may be 0, in which case error = checking is > ^^^^^^^^^^^^^^^^ >=20 > That bit of information should be promoted from kill(2) to kill(1) by > adding 0 to the list as ?. Actually=E2=80=A6 it is mentioned in kill(1) =E2=80=94 you just have to = read between the lines: -signal_number A non-negative decimal integer, specifying the signal to be = sent instead of the default TERM. 0 is technically a non-negative real number. It might be a good idea to clarify this point/behavior by pointing to = kill(2) for the signal behavior/description noted above. Thanks, -Ngie --Apple-Mail=_1FCA6944-FF7B-4140-99D2-CE5A1AACB067 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYufFgAAoJEPWDqSZpMIYVfL0QAMIt8yKXvrChGbPR/LeWkPhf n4p8+JLgcFyoDNIpr/LEUHAdCK8NWxAwY+ZmHaP95zs5txGpde1hU4QUnXsxoNu7 c8z57PESnczQBViHQhCgL7XDVodV7GWdL4Xm/0mNgFE5BsDYia0+0XbLl0Kj93yI /drwWGvEygnwYa6uZpDugJaP546Ng/d4izYY3HnvVWMRsi4WphNZs7SYfbPOMUdP an7CxvcXe/YGKd0sZVHq7Pkej1W/nWEFZJHCQ+AbrriwaHkCNpCBYJrYdsYCtrce P9ssIEj75f2tpn1O/Ybf5f8HwcBDFxG/zXnxI+/M5ZH1XlVSmSM3hO3gPNK9/PAO xjLMmOrrVlxCbKxnDiIiWhPQBSNpwzYgWUi6zDqrIOdhKc7z8NCykQUqrdfwQozm dLgtq9y1vTmSPeIYcdR1J1MD3y71l0/BaqJeBpNwgJa6fu3H2RUAwnlF0LGY2J0A FAErVi6allBejHKx+MEXBzerFO9PI8GLH/st8fX1BlrSRqsSe0BHz6x38TO8RXUK utnyFEKCLkzwUMp1Nfng+jAZheNKSoSPisX5TLPUsE7lDypmaVbY8inlVGH3/Q76 qOK2HJMhO3RXGBQhDiQUitbYkl4azuUCkObICTVR6b/OtrFtGnrSExS7dNErvv2S 0KCuaAuIM6H1etOW880J =YB3I -----END PGP SIGNATURE----- --Apple-Mail=_1FCA6944-FF7B-4140-99D2-CE5A1AACB067-- From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:52:32 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D88C4CF6CAA for ; Fri, 3 Mar 2017 22:52:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DC221564 for ; Fri, 3 Mar 2017 22:52:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x231.google.com with SMTP id 203so22298607ith.0 for ; Fri, 03 Mar 2017 14:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BgfL7rMnZsym8lJyeswPPzsSnIRH4mIEZIFv+W8DTg0=; b=cipVqD0FFLxXhGPbzOCFU39jY5Ef+e5CCL5+Nld98hFiQZNW1pf0mwm/xX+qpuoUQ5 IlcFxwvBXOol0X7ZVyZfIw0r0uvLoTQ3EUAVtjKiNS8F7bh8tWaJLw65MlVwBTKI5uvu 8ZmDpgX2HqAyH186V3mSjMC852knVx+neIgkfxWB3LNTm3W321fjkSuE+8H41YbNA5LX YP7q+ZdnmLzy82eNWy6DX+gua/KelLa2+SMS/5a1+4X6Ae1HkP6kjnuPL+Xnk3EI1+iV P0ZuAuTPpRAv9zMOpkW/0j2Aus02SuSKOUNgJIrx+v/CT7oq0veWzf8sdgoWjnKeHEsm IRcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BgfL7rMnZsym8lJyeswPPzsSnIRH4mIEZIFv+W8DTg0=; b=twtkWaesNmPGfEoiyD5kL/e0wxCKWgHSBczBUQ7w4xgRBdJ50QhGW5zVKx6i2j5/JO zfYMQI7k9GoEFpKiiIKEXAY8v92dVYAaTlOjJdWnjpE/f/u6r44JtcjJ1RkAUI99MN5O XCbN9u+mbbrhKTa5e2wTqrBrzh4er7H+KHbT3+/CA/o2rniFxeh02rGO1hf2vygqRyrG Y489O0Rtwh55T76karXU5o8iL8AmSO6RJLwAPoKoM854cpj6OjS+9XjC/YLiybAlOhOP ILtOaw7A+rIj3UPoPJwU5lCB0FX9kTLD3WtLQr3xR+V+CA5AdPupI6zrwlElpqDWMmVd egfw== X-Gm-Message-State: AMke39kWfMqXufQkQ0OiJ0Oc+N9P+ipMEGVpSpPZDTbjx5MJn9mCBQwNXhBoXzWYj08BvAjvDdxyF5mFt2M8hg== X-Received: by 10.36.58.201 with SMTP id m192mr5008631itm.103.1488581551930; Fri, 03 Mar 2017 14:52:31 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.129 with HTTP; Fri, 3 Mar 2017 14:52:31 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <03745A05-DE0E-4071-B432-BFE58C3A7E16@webweaving.org> References: <03745A05-DE0E-4071-B432-BFE58C3A7E16@webweaving.org> From: Warner Losh Date: Fri, 3 Mar 2017 15:52:31 -0700 X-Google-Sender-Auth: qn_sE--HXHjcmnMRpicdGInNJ1w Message-ID: Subject: Re: PCI speed To: Dirk-Willem van Gulik Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:52:32 -0000 On Fri, Mar 3, 2017 at 3:34 PM, Dirk-Willem van Gulik wrote: > Forgive me my ignorance - but for some cards - pciconf(8) nicely lists the speed of the bus: > >> ciss0@pci0:12:0:0: class=0x010400 card=0x3243103c chip=0x323a103c rev=0x01 hdr=0x00 > ... >> cap 10[70] = PCI-Express 2 endpoint max data 128(256) RO NS >> link x4(x8) speed 5.0(5.0) >> cap 11[ac] = MSI-X supports 16 messages, enabled >> Table in map 0x10[0x1c2000], PBA in map 0x10[0x1c4000] >> PCI-e errors = Correctable Error Detected >> Fatal Error Detected >> Unsupported Request Detected > > and that matches exactly with what it is. While for other cards it does not seem to report that: So you have a x8 card in a x4 slot. Hope that's OK. It's also reporting errors on the PCIe link level. That doesn't sound too correct. >> mpt4@pci0:7:8:1: class=0x010000 card=0x10b01000 chip=0x00301000 rev=0x08 hdr=0x00 > .... >> cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 >> cap 05[58] = MSI supports 1 message, 64 bit >> cap 07[68] = PCI-X 64-bit supports 133MHz, 2048 burst read, 8 split transactions >> cap 00[70] = unknown > > and in fact seems to mis report the bus - this is a PCIe Gen 2 x4 bus with a x8 Connector Width > holding a LSI 22320SE Ultra320 SCSI dual channel PCIe X4 card. > How should one interpret this ? That's odd. I'd have expected it to report correctly... It does for us at work. What version of FreeBSD? Warner From owner-freebsd-hackers@freebsd.org Fri Mar 3 22:30:45 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87742CF615C for ; Fri, 3 Mar 2017 22:30:45 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2170411DF for ; Fri, 3 Mar 2017 22:30:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v23MUhpE072956; Fri, 3 Mar 2017 14:30:43 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v23MUg5b072955; Fri, 3 Mar 2017 14:30:42 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703032230.v23MUg5b072955@pdx.rh.CN85.dnsmgr.net> Subject: Re: kill -0 --- side effect or supported In-Reply-To: <11A4B6AB-E51D-4754-8E80-4503687E0F84@gmail.com> To: "Ngie Cooper (yaneurabeya)" Date: Fri, 3 Mar 2017 14:30:42 -0800 (PST) CC: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 03 Mar 2017 22:54:17 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 22:30:45 -0000 -- Start of PGP signed section. [ Charset UTF-8 unsupported, converting... ] > > > On Mar 3, 2017, at 14:12, Dirk-Willem van Gulik wrote: > > > > I regularly use 'kill -0 ' on FreeBSD as a way to test if a certain process is still running (but without actually sending the signal). And I think it has worked reliably since the mid 80's. > > > > Is it actually a properly supported use - as I recently happened to notice that it does not seem to be all that documented in kill( > > It better work. I have code that relies on it :)? > > It does work as you noted, according to truss: > > # sudo truss -ff kill -0 1 2>&1 > ... > 79940: kill(1,0) = 0 (0x0) > ? > # > > As noted in kill(2), this is one of the valid values: > > a group of processes. The sig argument may be one of the signals > specified in sigaction(2) or it may be 0, in which case error checking is ^^^^^^^^^^^^^^^^ That bit of information should be promoted from kill(2) to kill(1) by adding 0 to the list as ?. > performed but no signal is actually sent. This can be used to check the > validity of pid. > > So, the manpage for kill(1) is just lacking in the sense that -0 is supported. > > Cheers! > -Ngie -- End of PGP section, PGP failed! -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Mar 3 23:17:50 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8835CF7638 for ; Fri, 3 Mar 2017 23:17:50 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 85B501536 for ; Fri, 3 Mar 2017 23:17:49 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9ca835fa-0067-11e7-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 9ca835fa-0067-11e7-95b5-6dfd7dbb0ee5; Fri, 03 Mar 2017 23:17:48 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v23NHboR002145; Fri, 3 Mar 2017 16:17:37 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1488583057.69705.3.camel@freebsd.org> Subject: Re: kill -0 --- side effect or supported From: Ian Lepore To: "Ngie Cooper (yaneurabeya)" , Dirk-Willem van Gulik Cc: freebsd-hackers@freebsd.org Date: Fri, 03 Mar 2017 16:17:37 -0700 In-Reply-To: <11A4B6AB-E51D-4754-8E80-4503687E0F84@gmail.com> References: <23F3BAC3-0D8B-4290-8DC2-818D67A0B6A9@webweaving.org> <11A4B6AB-E51D-4754-8E80-4503687E0F84@gmail.com> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 23:17:51 -0000 On Fri, 2017-03-03 at 14:23 -0800, Ngie Cooper (yaneurabeya) wrote: > > > > On Mar 3, 2017, at 14:12, Dirk-Willem van Gulik wrote: > > > > I regularly use  'kill -0 ' on FreeBSD as  a way to test if a certain process is still running (but without actually sending the signal). And I think it has worked reliably since the mid 80's. > > > > Is it actually a properly supported use - as I recently happened to notice that it does not seem to be all that documented in kill( > It better work. I have code that relies on it :)… > > It does work as you noted, according to truss: > > # sudo truss -ff kill -0 1 2>&1 > ... > 79940: kill(1,0)                                 = 0 (0x0) > … > # > > As noted in kill(2), this is one of the valid values: > >      a group of processes.  The sig argument may be one of the signals >      specified in sigaction(2) or it may be 0, in which case error checking is >      performed but no signal is actually sent.  This can be used to check the >      validity of pid. > > So, the manpage for kill(1) is just lacking in the sense that -0 is supported. > > Cheers! > -Ngie An interesting point related to "error checking is performed"... one of the error checks is "do you have permission to send a signal to this process?"  That means that kill -0 can only be used to check whether a process you have permission to control is running.   For example "killall -0 ntpd" cannot tell you whether ntpd is running unless you are root. -- Ian From owner-freebsd-hackers@freebsd.org Sat Mar 4 01:01:05 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4BBACF61C8 for ; Sat, 4 Mar 2017 01:01:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7155D19FA for ; Sat, 4 Mar 2017 01:01:05 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg0-x22d.google.com with SMTP id 77so4833326pgc.1 for ; Fri, 03 Mar 2017 17:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=iuRn/dYUTAR88rv+cHYQuxkmwvSt7amz25Xo+WpOfJE=; b=b2//QymA/CNifDTyzwunwdKqsFd6kq5l0o2xNoKW67+TQVToHXXS2hy1mRlRu4lSbh AvWItmffzNSdmADNva6FpcZvFPNjpz5I4bmlu86uez8qSOTfF2W6F7043etN/ZaldwQV f9vOQo3/nIrlfk9/xEZb8itOV6CzDdT6mn2nH+cmmcEDVDS3cvkTogP13sEPLcKyEc7l /pz6Xswl6MxrXPD66Ijj5I5+JbW7VumkWGEAHMycVN6+FVS1g/UENHHiXX/PwLNokCM6 S7Pzsc16EKKwcajtBL465m2KerULXpMVFvpVBYrc5Io+awSphFUYI5dBDzbjVTopBOIj fIEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=iuRn/dYUTAR88rv+cHYQuxkmwvSt7amz25Xo+WpOfJE=; b=UsMNA3wIhWbjXDPBWti0VTbxE7aSK8EFptUzxb3koWAjMitbKCaRCCorj9SjKoxQCF 4EImNz/DwG0ipUwxNr9oebtazzU/FlAp8YxD9OSyISnTHyXaJz5mSLz7UG4J42X/gZg8 w5nR6X84UQI7wQj8mSG+RRpfEes2KxU9NdQhRPtbK1IlzUdWBaF/G5XK2/QsRdrqnIec ESBwtTEn3CLHe5ckRC6UY4ndNG79MAoEO+a5DHFiYwKjUzlZRLmT33EErMWSp4zyNIso ZcqSiO3ZI+tpcWy7ujG9ph1EfyUl0W3hRprbbGVFzyLRy0qEeg3Wht4HF3Zbwef3TT5W 8OOQ== X-Gm-Message-State: AMke39kyH1TD+cl3Ro+UES/wWVbF4+kgPkMPvA84F+qyS/Yqov2lLeEr8mO3ZpCLAa6QVQ== X-Received: by 10.84.218.133 with SMTP id r5mr8150021pli.165.1488589265003; Fri, 03 Mar 2017 17:01:05 -0800 (PST) Received: from pinklady.local (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id o125sm25522323pfb.109.2017.03.03.17.01.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Mar 2017 17:01:04 -0800 (PST) Subject: Re: kill -0 --- side effect or supported Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_98EA757C-3087-4498-9ED2-3B2542D57094"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Ngie Cooper (yaneurabeya)" In-Reply-To: <201703040055.v240tf0H073569@pdx.rh.CN85.dnsmgr.net> Date: Fri, 3 Mar 2017 17:01:02 -0800 Cc: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org Message-Id: References: <201703040055.v240tf0H073569@pdx.rh.CN85.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 01:01:05 -0000 --Apple-Mail=_98EA757C-3087-4498-9ED2-3B2542D57094 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 3, 2017, at 16:55, Rodney W. Grimes = wrote: =E2=80=A6 > yes, but make it explicity clear just like it is explicity clear in = kill(2), > documentation should be good, clear and concise, not left for guessing > between the lines. Add a 0 item to the list of popular signals, or > add a sentence about this special case that is not well known. True. >> It might be a good idea to clarify this point/behavior by pointing to = kill(2) for the signal behavior/description noted above. >=20 > It already has a xref to kill(2). Compters derefence pointers better > than people do, so we can use all the help we can get, and if we are > reading a man page we need help! I meant, make the Xr=E2=80=99ef more obvious, e.g., See .Xr kill 2 for more details about the behavior of signum. Also, I agree that kill(2) should be clearer. POSIX already does a good = job filling in that gap. =46rom = http://pubs.opengroup.org/onlinepubs/9699919799/functions/kill.html : The kill() function shall send a signal to a process or a group of = processes specified by pid. The signal to be sent is specified by sig = and is either one from the list given in or 0. If sig is 0 = (the null signal), error checking is performed but no signal is actually = sent. The null signal can be used to check the validity of pid. Thanks, -Ngie --Apple-Mail=_98EA757C-3087-4498-9ED2-3B2542D57094 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYuhHPAAoJEPWDqSZpMIYVqKQP/3JLHXRcy+SsuW1m23CbnlYP dJ5UexMhEh5/5wP5S9eeCgPJ2YaNNIZOWlJlikRzhjF18HcmO2Q+s8NHlr0un6ZF o0GdwONA0u4zmt3qg/F5Hx5oljR2ERiL06o0Nd5/pxS9RpNvrugKQ0ftfj/5dw22 Ymlbo4UZgIj4QMRwc2mJx97JDZqcW0rfkoDOeHc2bqzCmLOPDlbRuKnhQpszZtY0 2MgobHLyjeQf1SXfmhXz6D1kOxVZkzBR+lpStD5XpAnIoNSkRJSabdY65oa29lT0 mWsJ/J5PTQNElFtOhWeiWJ3lqNnwXlipuB6O2iz4qFWiM0V4ZHWPbvnbyID3ooOa 6Vq0d/qBQVcfw0t4ZcNFU2j1etFc7MOwAaXiZ6eK+i9/GzqRd81dMNK23Ys9rn90 935SGiLUzYqbhsCmnr9dYcIDY5JUCSBrZnFc5vB0IR2WgIh+Lhzlpo7IAHqCMPir n7/Zr/3Ht/e5Du5/jZDpWWvwpxfXmDLTjQknhA1lpiprbpWns2QzpypRffH766vl NPb6kgyqJRPOVljFkc1fUXASauXvm7gtfRQX/GK5XjOH11Zkh35L9bydeHafGG9L 09ujSqAv4N6TrEXwTtaYXFb231dfVF+JSFxwL9sIjU41TTcPTz3msCMPO+Wsd6nE AFSEbhF42CxaCVZLauZf =28UN -----END PGP SIGNATURE----- --Apple-Mail=_98EA757C-3087-4498-9ED2-3B2542D57094-- From owner-freebsd-hackers@freebsd.org Sat Mar 4 00:55:44 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81284CF5ED3 for ; Sat, 4 Mar 2017 00:55:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AF3F1595 for ; Sat, 4 Mar 2017 00:55:43 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v240tfVu073570; Fri, 3 Mar 2017 16:55:41 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v240tf0H073569; Fri, 3 Mar 2017 16:55:41 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201703040055.v240tf0H073569@pdx.rh.CN85.dnsmgr.net> Subject: Re: kill -0 --- side effect or supported In-Reply-To: <35C6F2AA-309E-4D58-8191-AB99F0195BEC@gmail.com> To: "Ngie Cooper (yaneurabeya)" Date: Fri, 3 Mar 2017 16:55:41 -0800 (PST) CC: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 04 Mar 2017 01:57:50 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 00:55:44 -0000 > > > On Mar 3, 2017, at 14:30, Rodney W. Grimes wrote: > > > > -- Start of PGP signed section. > > [ Charset UTF-8 unsupported, converting... ] > >> > >>> On Mar 3, 2017, at 14:12, Dirk-Willem van Gulik wrote: > >>> > >>> I regularly use 'kill -0 ' on FreeBSD as a way to test if a certain process is still running (but without actually sending the signal). And I think it has worked reliably since the mid 80's. > >>> > >>> Is it actually a properly supported use - as I recently happened to notice that it does not seem to be all that documented in kill( > >> > >> It better work. I have code that relies on it :)? > >> > >> It does work as you noted, according to truss: > >> > >> # sudo truss -ff kill -0 1 2>&1 > >> ... > >> 79940: kill(1,0) = 0 (0x0) > >> ? > >> # > >> > >> As noted in kill(2), this is one of the valid values: > >> > >> a group of processes. The sig argument may be one of the signals > >> specified in sigaction(2) or it may be 0, in which case error checking is > > ^^^^^^^^^^^^^^^^ > > > > That bit of information should be promoted from kill(2) to kill(1) by > > adding 0 to the list as ?. > > Actually? it is mentioned in kill(1) ? you just have to read between the lines: > > -signal_number > A non-negative decimal integer, specifying the signal to be sent > instead of the default TERM. > > 0 is technically a non-negative real number. yes, but make it explicity clear just like it is explicity clear in kill(2), documentation should be good, clear and concise, not left for guessing between the lines. Add a 0 item to the list of popular signals, or add a sentence about this special case that is not well known. > It might be a good idea to clarify this point/behavior by pointing to kill(2) for the signal behavior/description noted above. It already has a xref to kill(2). Compters derefence pointers better than people do, so we can use all the help we can get, and if we are reading a man page we need help! -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Sat Mar 4 17:52:39 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7AA8CF9AB4 for ; Sat, 4 Mar 2017 17:52:39 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B69151946 for ; Sat, 4 Mar 2017 17:52:39 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B597ECF9AB3; Sat, 4 Mar 2017 17:52:39 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5388CF9AB2 for ; Sat, 4 Mar 2017 17:52:39 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76A5E1944; Sat, 4 Mar 2017 17:52:39 +0000 (UTC) (envelope-from mmokhi.fbsd@gmail.com) Received: by mail-vk0-f42.google.com with SMTP id r136so18600407vke.1; Sat, 04 Mar 2017 09:52:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=e7W/pSIGOV0JZnM0mQMCqEUs4w/0H5GRUxY49rnhWKk=; b=Mol/63LmJAqkMCzgOdOV+/3deZTK+UuIXoMtkLgbe5pbYEUVlLm27cl0575mBhzsH5 nK1cY7Y6ecWLBs5k4K12eIecuBX3mBVUfkiL71o1iIzHkMU8GpMYHCv3NuB39XapcynG zsddNsAmNYtnFaYolSp6YGQgmIwaFQd3rwGA0I6qBwjWvTyIeSP8CoFYTfjg2y7MaKWM ZZ2vTqur9DPztDY7iI5Ovok9XW2vqAgqioR9XWpICol70pBWzM2WHJVkfJHTLXeO+QRY 37Gp9NPhX5sNhYNbYOj4mnfWMYx/aGkN+BBXcNjMuy4wH2FU6a54HvJMLIt9yWgjin6l wxkQ== X-Gm-Message-State: AMke39nxogiGnTlcVC+rVa7eJTH+sdFYz4092oKFqXHnYbvB/T6qhWEmwA48ukN0pZ50Ag== X-Received: by 10.31.47.85 with SMTP id v82mr3545152vkv.2.1488648316726; Sat, 04 Mar 2017 09:25:16 -0800 (PST) Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com. [209.85.217.180]) by smtp.gmail.com with ESMTPSA id x32sm3793976uab.31.2017.03.04.09.25.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Mar 2017 09:25:16 -0800 (PST) Received: by mail-ua0-f180.google.com with SMTP id f54so138444090uaa.1; Sat, 04 Mar 2017 09:25:16 -0800 (PST) X-Received: by 10.176.82.16 with SMTP id i16mr3204771uaa.77.1488648316313; Sat, 04 Mar 2017 09:25:16 -0800 (PST) MIME-Version: 1.0 Reply-To: mmokhi@freebsd.org Received: by 10.103.75.136 with HTTP; Sat, 4 Mar 2017 09:25:16 -0800 (PST) In-Reply-To: References: From: Mahdi Mokhtari Date: Sat, 4 Mar 2017 20:55:16 +0330 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Some questions about kernel stuffs (namei, and AUDIT_ARG, ...) To: Robert Watson Cc: hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 17:52:39 -0000 Hi. Thanks rwatson@ for complete explanation (and the hint) about AUDIT part. It really helped __/|\__ Also, any hints about `namei()` part of my question? -- Best regards, MMokhi.